ソフトウェア開発の品質コスト

1. ソフトウェア開発の品質とは何ですか？
2. 低品質のソフトウェアにはどれくらいの費用がかかりますか？
3. 品質の責任者は誰ですか？

私にとって、これらの質問をする理由は、1年に3か月間、開発部門全体（約100人）がエラーと欠陥の除去に忙しく、残りの9か月は顧客のためにソフトウェアエラーを書く会社との会議でした。



以下は、答えを探しての理論的および実践的な研究の結果です。 このトピックに固有の「脳の爆発」なしで、私はそれらを簡単に述べようとしました。

ソフトウェア開発の品質とは何ですか？

ソフトウェア開発における品質とは、さまざまな観点から答えることができます。 私はユーザーと顧客と会社の長の観点から答えを定式化します。



ユーザーの立場から見ると、 高品質のソフトウェアとは、エラーがまったくないことと、それが作成された問題の解決策です。



品質の最低レベルは 、ビジネス上の問題の解決策であり、ソフトウェアの使用の可能性をブロックするエラーが存在しないことです（エラーのブロック）。



品質の平均レベルはすべて高く、ソフトウェアの使用経験に重大な影響を与えるエラーがない（ 削除が必須 ）一方で、ビジネス上の問題の解決には影響しないエラーがあります：スペル、異なるフォントが存在する場所、 .d。 （ 排除することが望ましい ）。



操作中にユーザーが検出したエラーは、障害と呼ばれます。 エラーは、ユーザーの操作に転送する前に、ソフトウェアバージョンのリリースに関係する従業員によって発見されたものと見なされます。

低品質のソフトウェアにはどれくらいの費用がかかりますか？

パート1：欠陥の確認

ユーザーが欠陥を見つけると、サポートエンジニアに頼ります。 合弁エンジニアは、それを再現し、これが製造上の欠陥であることを確認しようとしています。 ここで最初のコストが発生し、そこから品質のコストが加算され始めます。

• ユーザー時間のコスト-1ユニット。
• 使用済みエンジニアの時間コスト-1ユニット。

エラーが体系的なものである場合、すべてが明らかですが、特定のロジックに従って機能の動作に関連している場合はどうですか？



ここで、ジョイントベンチャーエンジニアは、特定のユーザー要求を実行するときのシステムの標準的な応答がどのようなものであるかを説明するドキュメントが必要になります。 このドキュメントが利用できない場合、これが欠陥であるか新しい要件であるかを判断するために追加費用が必要です。



迅速な開発が行われている場合、ドキュメントの欠如は特に一般的です。 誰もが「実用的な製品は網羅的なドキュメントよりも重要です」と覚えていますが、「つまり、右側にあるものの重要性を否定することなく、左側にあるものを より大切にしている」ということを忘れています。



ジョイントベンチャーエンジニアは、真実を見つけるためにさらに努力し始めます。 プロダクトオーナー（存在する場合）またはこの機能を実行した開発エンジニア、またはこの機能モジュールを知っている開発エンジニアが調査に接続します。 それらのいずれかまたは両方が、これを行う対象の顧客を記憶または特定しようとしています。



システムユーザーは、システムが機能するための要件を作成した顧客であるとは限りません。 ユーザーにとっては、顧客にとっては正常ではないというのが普通です。



顧客と一緒に状況を話し合い、システムが正常に機能したか、異常に機能したかを判断しようとします。 顧客に健忘症があり、約3か月前に作業を注文した場合（これは6か月先の作業を伴う長いバックログ）に発生し、今すぐこの機能/機能を実行した場合、開発が行われたことに基づいて何らかの種類の文書または手紙を見つけようとしています。



質問に対する答えを見つけることができた場合、すべては次の費用で終わります。

• プロダクトオーナー-1ユニット
• 開発エンジニア-1ユニット。
• 顧客-1ユニット
• 使用済みエンジニアの時間コスト-1ユニット。

運が悪ければ、彼らはこれを欠陥とみなすかどうかを交渉されます。欠陥は自分の費用で解消されるか、顧客が支払う新しい要件です。 交渉することができなかったと仮定すると、顧客は売却しました。これを欠陥とみなし、自己負担で排除します。

• 評判の低下-1ユニット。 （欠陥があり、調査に顧客を関与させる必要があるという事実のため）
• ここで欠陥を除去するコストは考慮されませんが、少し後で追加されます。

小計：

1. ユーザー時間のコスト-1ユニット。
2. 使用済みエンジニアの時間コスト-2ユニット。
3. 製品所有者の時間コスト-1ユニット。
4. 開発エンジニアの時間コスト-1ユニット。
5. 顧客の時間費用-1ユニット。
6. 評判の低下-1ユニット。

品質コスト-7単位



Technical Writer-Analystによるユーザードキュメントの準備に事前に費やすことで、この部分のコストを最適化できます。これは次のようになります。

1. ユーザー時間のコスト-1ユニット。
2. 使用済みエンジニアの時間コスト-1ユニット。
3. テクニカルライター分析の時間コスト-1ユニット。
4. 評判の低下-0.5ユニット。 （欠陥があるため）

品質コスト-3.5ユニット



Tech。Writer-Analystが必要な瞬間を理解するには、SPエンジニア以外の追加の人が調査に関与した状況、彼らがそれに費やした時間、そのような論争の多い状況が欠陥になった回数、およびそれらを解決するのにどれくらいの費用がかかっているかを追跡する必要があります。 これらのコストの合計がTech。Writerの給与よりも大きくなったら、導入する時が来ました。

部品番号2：トラブルシューティング

各「ブロッキングエラー」により、個別の修正パッチアップデートがリリースされます。 このアップデートでは、新しいエラーが発生しないように標準のテスト手順が実施されます。 このエラーが見つかったソフトウェアのバージョンを使用するお客様への配布、および欠陥の「チケット」のクローズのために、JVエンジニアに引き渡されます。 費用：

• 開発エンジニア-1ユニット。
• テストエンジニア-1ユニット
• ジョイントベンチャーエンジニア-1ユニット

「必須エラー」は、次の計画されたリリース（バージョン）で削除されます。したがって、リリースとリグレッションテストのアセンブルのコストは新機能に落ち、エラーを削除するコストに該当しないため、削除のコストは低くなります。 また、チケットを閉じることを除き、JVエンジニアの作業に追加費用はかかりません。 費用：

• 開発エンジニア-0.5ユニット
• テストエンジニア-0.5ユニット

両方の場合の費用は、会社の利益から支払われます。

品質のコストは4ユニットです。

パート3：欠陥の防止（検査に基づく品質）

ユーザーが欠陥を見つけられないように、このためのテストエンジニアがいます。 彼らにとって、100％エラーの効率基準は0％欠陥です。



発見された欠陥に関する情報はテストエンジニアに送信され、テスト中に欠陥が欠落した理由を分析し、テスト方法とツールを変更します。 費用：

• テスターエンジニア-1ユニット

ここでの効率的な作業は、次の時間の浪費を無効にします

パート1：

1. ユーザー-1ユニット。
2. SPエンジニア-1ユニット
3. 評判の低下-0.5ユニット。

パート2：

1. 開発エンジニア-1.5ユニット
2. テストエンジニア-1.5ユニット
3. ジョイントベンチャーエンジニア-1ユニット

コスト-6.5単位。 添付ファイル-1ユニット。 節約-5.5単位。

パート4：トラブルシューティング

除去のコストはクライアントの最終コストに該当するため、それ自体で見つかったエラーごとに会社にコストはかかりません。



しかし、開発が多くの重大なミスを犯した場合、エラーを排除すると、製品のコストと作業のタイミングが増加し、テストとエラーの排除を2回以上実行する必要があります。 クライアントはこのすべてが好きではなく、特に比較するものがある場合はそうです。



開発が独自のニーズのために実行される場合、多数のエラーが開発への投資の経済を悪化させ、単位時間あたりのより有用な機能（機能）をリリースする可能性を減らします。これはすでに企業のビジネス全体の経済に悪影響を及ぼしています。



ここの費用：

1. 評判の低下-1ユニット。
2. 開発エンジニア-1ユニット。
3. テストエンジニア-1ユニット
4. 収入の損失-2単位。 （アイテム2 +アイテム3）

品質コスト-5単位。

パート5：間違いの回避（生産プロセスの開発に基づく品質）

製品の品質は、エラーの外観に直接影響を与える原因を防ぐために管理するだけでなく、管理する必要があります。



ミスは、分析のために開発マネージャー（ティムリード）に提出され、原因、より頻繁に発生する従業員、より頻繁に「病気の」製品を特定します。 この作業は、一連のコードレビューイベント、資格が不足しているトピックに関する開発エンジニア向けの追加トレーニングなどに変換されます。

• 開発マネージャーのコスト-1ユニット。
• 開発エンジニアの費用-1ユニット。

ここでの効果的な作業は、パート4の次のコストを無効にします。

1. 開発エンジニア-1ユニット。
2. テストエンジニア-1ユニット
3. 収入の損失-2単位。
4. 評判の低下-1ユニット。

コスト-5台。 添付ファイル-2ユニット。 節約-3ユニット。

品質コストの一般的な計算

通常、状況は次のようになります：開発し、ミスを犯し、時にはそれらを除去するのに2回以上の反復が必要であり、この作業にもかかわらず、ユーザーはソフトウェアの欠陥を発見します。これは追加の更新を発行して修正する必要があります。

費用タイプ	パート1	パート2	パート4	合計
ユーザーが費やした時間	1	-	-	1
使用時間エンジニアJV	2	1	-	3
製品所有者の支出	1	-	-	1
開発エンジニアの時間	1	1,5	1	3,5
顧客時間	1	-	-	1
テストエンジニアが費やした時間	-	1,5	1	2.5
評判障害	1	-	1	2
失われた収入	-	-	2	2
合計	7	4	5	16

テクニカルライターのリソースを1ユニット投資して完成した開発の事実に関するドキュメントを作成すると、3.5ユニットが節約され、品質のコストが16から12.5に減少します。 （コスト構造：文書化+欠陥確認+欠陥修復+エラー修正）



欠陥の防止を確保し、テストエンジニアが1単位の時間を費やして、品質のコストを12.5単位から7単位に削減します。 （コスト構造：ドキュメント+欠陥の防止+トラブルシューティング）



エラーを回避するには、開発エンジニアと開発マネージャーからそれぞれ1つずつ、2ユニットの投資が必要になり、品質のコストを7ユニットから4ユニットに削減します。 （コスト構造：ドキュメント+障害の防止+エラーの防止）



テクニカルライター-アナリストが、開発前にシステムがユーザーのビジネスタスクをどのように解決するかについてのユーザードキュメントの作成を開始するという事実に投資する場合、次の作業は不要です。

1. 欠陥であるかどうかを顧客と議論するだけでなく、欠陥について顧客と通信することもできます。
2. ソフトウェアターゲットのパフォーマンスのエラーがテスト段階でユーザーに伝わった理由を分析するため。
3. 開発者がプロ​​グラムを正常に機能させない理由を分析し、テストに提供した。
4. プロジェクト文書がなく、その不在を補うために何かを発明する必要がある場合、エラーと欠陥を防ぐための追加の対策に費やされます。

そして、これにはたった1ユニットのコストしかかかりません。 （ 製品設計プロセスの開発に基づく品質 ）

品質の責任者は誰ですか？

欧米の企業には、ソフトウェアリリースプロセス全体を担当し、品質保証の側面に焦点を当てた品質保証エンジニアの職があります。



当社では、 ソフトウェア品質保証はテストとして認識される前に誇張されており、品質保証エンジニアはテストエンジニアです。 しかし、これを行うことができる最大のテストエンジニアは、すべてのエラーを見つけてソフトウェアエンジニア （開発エンジニア）に返すことですが、それは外観に影響しません。



開発中の人は間違いを犯さないかもしれませんが、ロボットではありません。以前は存在しなかった何かを考え出す必要があり、その方法を検討する場所がない場合、それは創造的なプロセスです。



また、入力として不明瞭なステートメントを受け取るという事実によって複雑になることもあります。その理由は、顧客が自分の欲しいものを理解しておらず、誰かが開発前にこの要件を逃したか、顧客が自分の欲しいものを知っているが、それが「壊れた」ためです電話」と一部の要件が開発に到達しませんでした。



チームリーダー （開発マネージャー）は、開発エンジニアが自分の仕事をうまく行い、不足している能力と技術を習得する方法を学ぶのを助けることができますが、開発チームの内部テスターであってはならず、欠陥コードを次の段階で見逃さないようにそれぞれをチェックするべきではありません。 彼の仕事は、チーム内でプロセスを教えて構築し、欠陥のあるコードがないようにすることです。



所有者として製品責任者としての資格を持つ製品所有者もいます。 このため、 マーケティングプロダクトマネージャー （ プロダクトマネージャー ）とSoftware Deliveryマネージャー （ソフトウェアリリースマネージャー ）の2つのポジションに分かれている場合があります。 前者は市場の観点から製品の開発を担当し（顧客と要件との連携）、後者は製品の製造プロセスの開発を担当します。



リストの全員をよく見ると、誰も個人的に「品質」を生み出していないことがわかります。 品質は、プログラムに追加できるコンポーネントではありません。 同時に、それらはすべて、ユーザーのビジネス上の問題を解決し、エラーを含まない製品の作成に参加します。 品質はチームワークです。



ソフトウェア開発ライフサイクルの各段階の責任を共有することはできません。 この部門が始まるとすぐに、中間での非効率的な作業は、最初に行われた作業を即座に無意味にし、最後にいる人と生産チェーン全体の両方に追加の作業をロードし、そのエントリのエラーを排除します。

おわりに

これは、3つの方法に基づいた、業界の品質を操作するための古典的なアプローチです。

1. 完成品の検証による品質（テスト：エラーや欠陥の発見）
2. 生産プロセスの開発による品質（生産中のエラーの防止）
3. 製品設計プロセスの開発による品質（設計中に製品のスケルトンベースに生じるエラーの防止）

そして、主なメッセージ： 結果に取り組むよりも、原因に取り組むことにもっと注意を払う必要があります 。



これは、作業を設計および設計できる製品の開発に最適です。 また、製品の動作を設計する時間がなく、動作する方法の定義が動作バージョンの反復的なリリースを通じて（経験的に）発生する場合は適切ではありません。



急速な反復開発の開始時には、唯一の品質基準があります-製品は、それが作成されたビジネスタスクを満たします。 反復ごとに、顧客は、製品を使用してビジネス上の問題を解決する経験を向上させる新しい品質基準（製品からの期待）を追加します。



アジャイルの高速フレームワークでは、リリースの数に比例して、単位時間あたりのバグと欠陥の数が増加します。 より多くのことを行い、リリースすればするほど、より多くの間違いを犯します。 エラーが多ければ多いほど、エラーの修正や行われた変更に関連するチームの負荷の割合が大きくなります。



これは、すでに飛行中の航空機の完成に対する料金であり、完成した状態でどのように見えるか、環境条件にどのように反応するかはわかりません。



それをどうしますか？ -「アジャイル開発の未来」という記事に記載されている回答が気に入っています。

このトピックについて他に読むべきこと：

1. アジャイル開発の未来
2. ソフトウェアの品質とは何ですか？
3. プロジェクト品質管理
4. ITでのキャリア：ポジションQAエンジニア
5. 品質管理の第一人者とその概念：E.デミング、J。ジュラン、F。クロスビー、K。石川、A。フェイゲンバウム、T。田口

数分かけて3つの質問に答えてください。2017年8月1日のわが国のIT業界における態度とソフトウェア品質への注意の平均温度を診断するのに役立ちます。 この善行のためにカルマであなたに+1。