記事の翻訳：2015〜2019年のソフトウェア業界の25の目標

記事の翻訳：

2015〜2019年のソフトウェア業界の25の目標

著者の礼儀：ケッパージョーンズ



Caper Jones、副社長兼CTO Namcook Analytics LLC

バージョン5.0 2015年2月28日



短いレビュー

ソフトウェア産業の発展は、アルコール依存症の歩行に似ており、動きは同時に調整され、逆になります。 たとえば、柔軟な開発方法論は小規模プロジェクトの調整であり、ペアプログラミングはエンジンの役割には高すぎる後戻りです。



安定した前進運動がない理由の1つは、効果的な測定システムの痛みを伴う欠如です。 最も古く、最も一般的な2つのメトリクスである欠陥とプログラムラインのコストは、進捗を示さず、実際に現実を歪めます。 欠陥のコストの計算では品質が低下し、プログラムラインでは高レベルのプログラミング言語が拒否されます。



この短い記事では、2015年を出発点として、5年以内に達成できる25の実際の目標を示します。 いくつかの目標は、重大なエラーなしで経済的なパフォーマンスと品質を報告するのに有効な唯一の広く使用されているメトリックであるファンクションポイント（FP ）の観点から表されます。



別の適切な測定基準は欠陥除去効率（DRE ）です。これは、プログラムを使用して最初の90日間にユーザーが報告したエラーの数と比較して、開発中に発見および解決されたエラーの割合を示します。 開発者が95のエラーを発見し、ユーザーが3か月で5つのエラーを報告した場合、DREは95％です。 現在、米国の平均DREは約90％しか示されていませんが、各ソフトウェアプロジェクトが95％に達し、多くの人が99％に達することは技術的に可能です。

Web： www.Namcook.com

ブログ： Namcookanalytics.com

メール：Capers.Jones3@gmail.com

©Capers Jones、2014年〜2015年。すべての権利は保護されています。

2015〜2019年のソフトウェア業界の25のタスク。

はじめに

以下は、2015年から2019年までの5年間にわたる実装のためにNamcook Analytics LLCによって開発されたプログラミング開発の25の目標または目標の選択です 。 これらの目標の一部は2015年に既に達成可能ですが、すべての企業がそれらを達成できたわけではありません。 少数の選ばれた大手企業が、記載されている目標の一部を達成しています。

残念ながら、提示された目標のいずれかを達成したのは米国および多国籍企業の5％未満であり、ほとんどの目標を達成したのは1％未満です。 著者のクライアントは誰もすべての目標を達成できませんでした。



著者は、各主要ソフトウェア開発会社および政府機関が、提案されたリストを出発点として使用して、5年間の目標を独自に選択することを提案しています。

1.欠陥の除去（ DRE ）の効率を<90.0％から> 99.5％に上げます。 この目標は、業界にとって最も重要です。 テストだけでは達成できませんが、テスト前の制御と静的分析を使用する必要があります。 DREは、開発中に見つかったすべての欠陥を、最初の90日間に消費者が報告した欠陥と比較することで測定されます。 米国の現在の平均DREは約90％です。 ダイナミクスは約92％です。 欠陥防止、テスト前の欠陥除去、および数学的に設計されたテストケースと正式なピアレビューの完全なセットを使用し、資格のあるテストスペシャリストが関与している少数の主要企業のみが99％DREを達成できます。



2.ソフトウェアの欠陥の可能性の指標を、機能ポイントあたり4.0から機能ポイントあたり2.0未満に減らす。 欠陥確率インジケータは、技術要件、構成、設計、コード、ユーザードキュメント、および品質の低いパッチで見つかったエラーの合計です。 技術的および設計上のエラーは、多くの場合、コードエラーを上回ります。 現在、標準シリーズに10,000個の機能ポイントがある大規模システムでは、機能不良ポイントは機能ポイントあたり6.0に達する可能性があります。 この目標を達成するには、効果的な欠陥防止が必要です。これには、たとえば、 共同アプリケーション設計（JAD ）、 品質機能展開（QFD ）、公式に承認された再利用可能コンポーネントなどが含まれます。完全なソフトウェア品質管理。 この目標を達成するには、技術的要件、設計、およびソースコードに見られる一般的な欠陥の原因に関するトレーニングを改善する必要もあります。 欠陥の可能性を減らすための最も効果的な方法は、設計から顧客仕様への切り替えと、本質的にエラーが発生しやすい手動コーディングです。 公式に承認された再利用可能なコンポーネントを作成するように設計すると、ソフトウェアの欠陥の可能性を大幅に減らすことができます。



3. 品質コスト（COQ ）を開発コストの45.0％から開発コストの<15.0％に削減します。 50年以上にわたるトラブルシューティングは、これまでで最も費用のかかるプログラミング作業でした。 これを実現するには、欠陥防止、テスト前制御、静的分析の相乗的な組み合わせが必要です。 可能性のある結果は、トラブルシューティングの有効性が今日の平均から90％未満から99％に増加することです。 同時に、欠陥の可能性を、機能ポイントあたりの現在の平均4.0から機能ポイントあたり2.0未満に減らすことができます。 この組み合わせは、メンテナンスとテクニカルサポートのコストに強力な相乗効果をもたらします。 ちなみに、品質コストを下げると、技術的な負債も減ります。 ただし、2014年末時点で、技術的負債は標準的な指標ではなく、場所によって大きく異なるため、計算が困難です。



4.平均循環的複雑度を25.0から10.0に減らします。 この目標を達成するには、ソフトウェア構造の徹底的な分析と、もちろんすべてのモジュールの循環的複雑度の測定が必要です。 サイクロマティックツールは一般的であり、その一部はオープンソースであるため、各アプリケーションは例外なくそれらを使用する必要があります。



5.リスク、ルート、技術要件に関するテスト範囲を<75.0％から> 98.5％に増やします。 この目標を達成するには、テストケースを作成するために数学的設計手法を使用する必要があります。 このような方法は、たとえば、実験の計画です。 テストカバレッジの測定も必要です。 予測診断ツールも必要です。予測診断ツールは、機能スコア、コード量、循環的複雑度に基づいてテストケースの数を予測できます。 ソフトウェアリスク診断（SRM）独自のサービスプログラムは、18種類のテストのテストケースを予測するため、予想されるテスト範囲も予測できます。



6.大規模システムでエラーが発生しやすいモジュール（EPM）を排除します。 障害はランダムに分散されません。 この目標を達成するには、特定のモジュールのエラーを追跡できるソフトウェアツールを使用して、開発中およびリリース後にコードの欠陥を慎重に測定する必要があります。 IBMなどの一部の企業は、これを長年にわたって行っています。 エラーが発生しやすいモジュール（EPM）は通常、モジュールの総数の5％未満を占めていますが、すべてのエラーの50％以上を占めています。 予防が最善の解決策です。 レガシーアプリケーションの既存のエラーが発生しやすいモジュールは、外科的な取り外しと交換が必要になる場合があります。 ただし、静的分析は、認識されているすべてのEPMに適用する必要があります。 ある調査では、メインアプリケーションは425モジュールで構成されていました。 すべてのエラーの57％は、1つの部門でコンパイルされた31のモジュールでのみ見つかりました。 300以上のモジュールが完璧でした。 EPMは簡単に防止できますが、すでに作成されている場合は修正が困難です。 通常、外科的切除は避けられません。 EPMは、プログラミングの歴史の中で最も高価な成果物です。 EPMは天然poに似ています。 つまり、「ワクチン接種」と効果的な制御方法の助けを借りて完全に排除することはできません。 エラーが発生しやすいモジュールは、機能ごとに3.0エラーに達することが多く、ソフトウェアのリリース前に80％未満の量で削除されます。 また、サイクロマティックの複雑さの点で上位50位に入るよう努めています。 高レベルの循環的複雑さのために、テストを通じてより高いレベルで欠陥を除去することは困難です。



7.すべてのソフトウェアアプリケーションのセキュリティ上の欠陥を修復します。 サイバー犯罪がますます広がるにつれて、セキュリティツールを改善する必要性が高まっています。 この目標を達成するには、セキュリティステータスの監視、セキュリティシステムのテスト、およびセキュリティの欠陥を検出するための自動化ツールが必要です。 貴重な財務データや機密データを含むホストシステムを操作するには、倫理的なハッカーも必要になる場合があります。



8.サイバー攻撃の可能性を10.0％から0.1％に減らします。 この目標を達成するには、高度なファイアウォール、継続的なアンチウイルス制御、およびウイルスシグネチャの継続的な更新の相乗的な組み合わせが必要です。 また、基本的な構成とアクセス権の戦略を変更することにより、ソフトウェア自体の耐性を高めるように努力する必要があります。 両方のセキュリティレベルを上げるには、ハードウェアとソフトウェアの構成の改訂が必要になる場合があります。



9.品質の低いエラー修正の注入を7.0％から1.0％に減らします。 ソフトウェアエラーを修正しようとする試みの約7％が直接修正された領域に新しいエラーを導入することを知っている人はほとんどいません。 循環的複雑度が50に達すると、低品質のエラー除去の注入率が最大25％以上上昇する可能性があります。 低品質のエラー除去の注入を減らすには、循環的な複雑さを制御し、すべての欠陥修復領域に静的解析を使用し、すべての修正をテストし、それらを組み立てる前に重要な修正のすべての領域をチェックする必要があります。



10.技術要件の変動を1暦月あたり1.5％から1か月あたり0.25％未満に減らします。 技術的なドリフトは、50年以上にわたってソフトウェア業界に固有の問題でした。 プロトタイプ、動的な組み込みユーザー、および共同アプリケーション開発（JAD）が適切である限り、技術要件の自動化モデルを使用して技術要件の完全性を向上させることが技術的に可能です。 より良い方法は、パターンマッチングを使用して、開発中のものと同様のアプリケーション機能を識別することです。 先行技術は、2015年には実際には存在しなかったソフトウェアアプリケーション機能の有用な分類法ですが、焦点を絞った研究から数か月以内に開発できます。



11. 10.000機能ポイントの大規模プロジェクトでのプロジェクトの失敗またはキャンセルのリスクを、35.0％から<5.0％に減らします。 品質の低さ、変更管理のレベルの低さ、コストオーバーランによる大規模システムのキャンセルは、本質的に投資収益率（ROI）をプラスからマイナスに変えるため、ソフトウェア業界では風土病の問題であり、これはなくても可能です。 効果的な欠陥防止、テスト前制御、および静的分析の相乗的な組み合わせにより、このあまりにも一般的な問題の解決策がもたらされます。 手動計算よりも高い精度でリスク、コスト、およびスケジュールを予測できるパラメトリック評価ツールも推奨されます。



12.カレンダープランの遅延の可能性を50.0％から5％未満に減らす。 カレンダー計画の遅延の理由は品質の悪さと技術要件の過度のドリフトであるという事実により、このリストの上記の問題のいくつかの解決策は、カレンダー計画の遅延の問題の解決策としても役立ちます。 ほとんどのプロジェクトは、膨大な数のエラーがテストスケジュールを無限に伸ばし始めるテストが始まるまで、時間通りに完了するようです。 事前テストの静的分析と組み合わせた欠陥回避により、スケジュールの遅れイベントを削減または排除できます。 それは治療可能な状態であり、5年間除外することができます。



13.コストオーバーランの可能性を40.0％から3.0％に減らします。 ソフトウェアのオーバーランとスケジュールの遅延には、同様の根本原因があります。 つまり、低品質管理と低変更管理と技術的要件の過度のドリフトが組み合わされています。 事前予防の欠陥修復と組み合わされた優れた欠陥防止は、これらの固有のソフトウェアの問題の両方を解決するのに役立ちます。 楽観的な手動計算ではなく、正確なパラメトリック推定ツールを使用することも、コストオーバーランの削減に役立ちます。



14.アウトソーシング訴訟のケースを5.0％から1.0％に減らします。 この記事の著者は、契約違反に関する12件の訴訟の専門家証人でした。 これらすべてのケースには、低品質管理、低変更管理、非常に低いステータス追跡など、同様の主な理由があるようです。 契約に署名する前の早期のサイジングとリスク分析に加え、効果的な欠陥防止とテスト前の欠陥修正の相乗的な組み合わせにより、ソフトウェア業界での契約違反のケースを減らすことができます。



15.メンテナンスおよび修理コストを2015年の値と比較して75.0％以上に削減します。 2000年頃から、米国の保守プログラマーの数はソフトウェア開発者の数を超え始めています。 IBMは、効果的な欠陥防止と事前テストの除去が、最終的な欠陥の数を非常に低いレベルに減らし、メンテナンスコストを少なくとも45％、場合によっては最大75％まで削減できることを発見しました。 効果的なソフトウェア開発と効果的な品質管理は、開発よりも保守コストに大きな影響を与えます。 現在の平均と比較して、新しいアプリケーションのメンテナンスを60％以上削減することは技術的に可能です。 レガシーアプリケーションの分析とエラーが発生しやすいモジュールの排除、およびソースコードのわずかな再編成は、各レガシーアプリケーションのメンテナンスコストを最大約25％削減するのにも役立ちます。 技術的負債も削減されますが、技術的負債は標準的な指標ではなく、計算が難しいほど多様です。 静的分析ツールは、すべてのアクティブなレガシーアプリケーションに対して定期的に実行する必要があります。



16.公式に承認された再利用可能な素材の量を<15.0％から> 75.0％に増やします。 顧客の仕様および手動コーディングに従って設計することは、どの技術を使用しても、本質的にエラーが発生しやすく、非効率的です。 プログラミングを工芸から現代の職業に変える最良の方法は、公式に承認された再利用可能な資料のライブラリからアプリケーションを設計することです。 つまり、再利用可能な技術要件、設計、コード、および試験材料を使用します。 使用することを目的としたすべての再利用可能なマテリアルをレビューし、コードセグメントを検証し、一連の静的解析を開始する必要があります。 そのため、再利用可能なコードには、再利用可能なテスト資料と、循環的複雑度やユーザー情報などの関連情報を添付する必要があります。



17.平均開発効率を1か月あたり<8.0機能ポイントから> 16.0機能ポイントに改善します。 パフォーマンス要因は、サイズ、複雑さ、チームの経験、テクニック、およびその他のいくつかの要因によって異なります。 ただし、すべてのプロジェクトをまとめて検討すると、平均パフォーマンスは通常の月あたり8.0機能ポイントを下回ります。 この比率を2倍にするためには、より良い品質管理を、公式に承認された再利用可能な材料のはるかに大量と組み合わせる必要があります。 おそらく50％以上。



18.機能スコアを16.5から<8.25に短縮して、労働時間を短縮します。 目標17とこの目標は基本的に同じですが、異なる指標を使用します。 ただし、重要な違いが1つあります。 毎月の労働時間は、各国で同じ数値ではありません。 たとえば、月に116労働時間のオランダのプロジェクトは、月に186労働時間の中国のプロジェクトと同じ労働時間になります。 しかし、中国のプロジェクトはオランダのプロジェクトよりも少ない暦月を必要とします。



19. 1000の機能ポイントで、通常の月あたり最大100の機能ポイントまで最大パフォーマンスを改善します。 現在、2015年の初めの時点で、1000機能ポイントあたりのパフォーマンス係数は、通常の月あたり約5〜12ポイントの範囲にあります。 実際、顧客の仕様に応じた設計と手動コーディングを使用して、通常の月に100機能ポイントを達成することは不可能です。 標準の再利用可能な標準コンポーネントのライブラリの構築によってのみ、このような高いパフォーマンス係数を実現できます。 ただし、再利用可能な材料の量を増やすことは可能です。 上記の製品には、ソフトウェア機能の優れた分類、再利用可能な材料カタログ、および新しい再利用可能な材料を追加するための認証プロセスが必要です。また、再利用可能な素材にエラーがある場合や変更が必要な場合は、リコール方法を適用する必要があります。



20. 2015年の平均と比較して、平均的なソフトウェア開発スケジュールを35％以上に削減します。情報技術ディレクター（CIO）およびCFO（CFO）のレベルでのソフトウェアクライアントと企業マネージャーの最も一般的な不満は、ソフトウェアプロジェクトには時間がかかるということです。この時間を短縮することは難しくないことは驚くべきことです。より優れた欠陥防止、事前テストの静的分析と制御、および公式に承認された再利用可能な材料の相乗効果の組み合わせにより、スケジュール間隔を大幅に短縮できます。今日の世界では、機能スコアが0のソフトウェアアプリケーションのサイズを増やしています。4は、暦月での計画期間の便利な近似値を提供します。ただし、既存の技術では指数を0.37に減らすことができます。度が0.4で機能点が1000個増えると、15.8暦月のグラフを示します。 0.37の度合いで1000機能ポイントが増加した場合、12.9暦月のみのグラフを示しています。このようなより短いスケジュールは、効果的な欠陥防止の使用により可能になり、事前テスト制御と静的分析により強化されます。再利用可能なソフトウェアコンポーネントは、指数を0.3または7.9暦月に下げることができます。カレンダー計画の遅れは今日today延していますが、治療可能であり、排除することができます。ただし、既存の技術では指数を0.37に減らすことができます。度が0.4で機能点が1000個増えると、15.8暦月のグラフを示します。 0.37の度合いで1000機能ポイントが増加した場合、12.9暦月のみのグラフを示しています。このようなより短いスケジュールは、効果的な欠陥防止の使用により可能になり、事前テスト制御と静的分析により強化されます。再利用可能なソフトウェアコンポーネントは、指数を0.3または7.9暦月に下げることができます。カレンダー計画の遅れは今日today延していますが、治療可能であり、排除することができます。ただし、既存の技術では指数を0.37に減らすことができます。度が0.4で機能点が1000個増えると、15.8暦月のグラフを示します。 0.37の度合いで1000機能ポイントが増加した場合、12.9暦月のみのグラフを示しています。このようなより短いスケジュールは、効果的な欠陥防止の使用により可能になり、事前テスト制御と静的分析により強化されます。再利用可能なソフトウェアコンポーネントは、指数を0.3または7.9暦月に下げることができます。カレンダー計画の遅れは今日today延していますが、治療可能であり、排除することができます。0.37の度合いで1000機能ポイントが増加した場合、12.9暦月のみのグラフを示しています。このようなより短いスケジュールは、効果的な欠陥防止の使用により可能になり、事前テスト制御と静的分析により強化されます。再利用可能なソフトウェアコンポーネントは、指数を0.3または7.9暦月に下げることができます。カレンダー計画の遅れは今日today延していますが、治療可能であり、排除することができます。0.37の度合いで1000機能ポイントが増加した場合、12.9暦月のみのグラフを示しています。このようなより短いスケジュールは、効果的な欠陥防止の使用により可能になり、事前テスト制御と静的分析により強化されます。再利用可能なソフトウェアコンポーネントは、指数を0.3または7.9暦月に下げることができます。カレンダー計画の遅れは今日today延していますが、治療可能であり、排除することができます。再利用可能なソフトウェアコンポーネントは、指数を0.3または7.9暦月に下げることができます。カレンダー計画の遅れは今日today延していますが、治療可能であり、排除することができます。再利用可能なソフトウェアコンポーネントは、指数を0.3または7.9暦月に下げることができます。カレンダー計画の遅れは今日today延していますが、治療可能であり、排除することができます。



21.メンテナンスタスクの範囲を<1,500機能ポイントから5,000機能ポイントに拡大。 「保守タスクの範囲」というメトリックは、1人の保守プログラマーが暦年を通じて機能モードで保守および保守できる機能ポイントの数を指します。範囲は、欠陥および複雑なソフトウェアの<300機能ポイントから、効果的な品質管理の下でリリースされた最新のソフトウェアの5000機能ポイントまでです。現在の平均は約1,500機能ポイントです。これは、顧客の仕様と企業ポートフォリオに基づいて、両方のプロジェクトの技術的保守の人的支援を予測するための重要な指標です。この目標を達成するには、効果的な欠陥防止、欠陥の効果的な事前テスト除去、および数学計算に基づくテストケースの最新の設計手法を使用した効果的なテストが必要です。この目標を達成するには、低レベルの循環的複雑度も必要です。静的分析は、開発中のすべてのアプリケーションと、レガシーアプリケーションで実行する必要があります。レガシーアプリケーションでも同様です。レガシーアプリケーションでも同様です。



22.今日の静的および厳格な技術要件、構成、および設計方法を、パターンマッチングと組み合わせた一連のアニメーションデザインツールに置き換えます。作業中、ソフトウェアアプリケーションは、人類がこれまでに作成した中で最速のオブジェクトです。開発中、ソフトウェアアプリケーションは日々成長し、変化します。設計方法が静的であり、テキストブロックのスコアなどのテキスト、またはフローチャートや統合モデリング言語（UML）の図などの非常に原始的で限定的な図で構成されることはほとんどありません。フルカラーおよび3次元のグラフィックツールを使用してアニメーションデザインの新しい方法を作成するための技術は、2014年以来、すでに存在しています。キャラクターセットを開発し、デザインプロセスのアニメーションを開始するだけです。



23.大規模なインタラクティブゲームテクノロジーに基づいたプログラミング用のインタラクティブ学習ツールを開発します。新しいプログラミングの概念はほぼ毎日登場しています。新しいプログラミング言語は毎週リリースされます。ソフトウェアは、医学、法律、およびその他の形式の工学を継続的な学習に非難します。しかし、ライブ学習は費用がかかり、不便です。トレーニングプログラムの組み込み計画機能を備えたインタラクティブな学習ツールが必要です。現在、このようなツールを開発することが可能です。ゲームエンジンのライセンスを取得することにより、アバターがクラスに参加して相互に通信できるプログラミング大学のモデルを作成することが可能になります。



24.ソフトウェアアプリケーションの開発を示す動的なアニメーションプロジェクト計画および評価ツールのセットを開発します。現在、すべてのソフトウェア評価ツールの出力は、いくつかのグラフに裏打ちされた静的テーブルの形式で提示されています。ただし、ソフトウェアアプリケーションは開発中に1か月あたり1％以上開発され、1か月あたり8％以上のリリース後も引き続き開発されます。明らかに、ソフトウェアの計画および評価ツールには、経時的な機能の成長を示すことができる動的モデリング機能が必要です。また、技術的な要件、設計、構成に起因するエラーまたは欠陥の到着（および検出）を示す必要があります。コードおよびその他の欠陥の原因。今日の技術的に達成可能な究極の目標は、技術要件の最初の日から使用25周年までのアプリケーションの成長を示すグラフィカルモデルです。



25. . , « » (The Social Transformation of American Medicine). 1982 . , , , . . 75 , 10 . 5- , 2015 .

この記事で使用される機能スコアメトリックは、International Functional Score Based Metric User Group（IFPUG）の定義における機能スコアを指すことに注意してください。COSMIC、FISMA、NESMA、未解決などを含む機能スコアの他の定義も使用できますが、他の定量的な結果が得られます。



2015年に利用可能な多くのテクノロジーは、これらの25の目標のそれぞれを達成するのに十分です。これらの25の目標に関連する技術には、次のものが含まれますが、これらに限定されません。

ターゲットを絞ったプログラミング設定を実装するための有用なテクノロジー

• , , , , , Namcook (SRM).
• , . (COCOMO, CostExpert, ExcelerPlan, KnowledgePlan, SEER, SLIM, Software Risk Master (SRM) True Price) , , .
• , , , (JAD) (QFD).
• , , , , , , . .
• , . 100% .
• SANS .
• FOG FLESCH , . .
• , , , .
• .
• .
• , , XP , RUP TSP . , , , TSP.
• .
• .
• , , . .
• 3.0%.
• , , .
• SEMAT ( ), . SEMAT , .

, . , , .



上記の25の目標は、企業や政府機関が達成するために努力しなければならない前向きな目標です。ただし、「ソフトウェアエンジニアリングエンジニアリング」には、使用を回避または除外すべき悪意のある方法も数多くあります。それらのいくつかは非常に有害であるため、職業上の過失とは見なされません。以下に、6つの危険なソフトウェア設計方法を示します。そのうちのいくつかは、その有害性を十分に認識せずに50年以上にわたって継続的に使用されています。

避けるべき6つの危険なソフトウェア設計方法

1.「欠陥コスト」を通じて品質経済を測定しようとするのをやめます。このメトリックは、最も完全なソフトウェア障害に対して常に最小値を示すため、品質が低下します。また、このメトリックは、ソフトウェアの真の経済的価値を数百パーセント過小評価します。この測定基準は、標準的な経済的仮定に違反しており、品質の経済性を測定する際の専門的な過失とみなすことができます。品質のコストを測定する最良の方法は、「機能スコアで欠陥を修正するコスト」を計算することです。欠陥コストは、テストケースの作成と実行の固定コストを考慮していません。これは、製造経済のよく知られた原則であり、プロセスで固定費の割合が高い場合、単位あたりの費用が増加します。ソフトウェアのリリース後、根拠のない前よりもエラーを修正するのに100倍以上かかるという都市のバイク。適切に計算すれば、費用はほぼ同じです。



2. コード行を使用したソフトウェアパフォーマンスの測定の試行を停止-LOCメトリック）このメトリックは、高レベルのプログラミング言語を拒否します。また、この測定ツールは、コーディング以外の作業、たとえば技術的な要件や設計などを計算に反映しません。このメトリックは、多数のプログラミング言語が関係する経済分析において、専門的な過失と見なすことができます。ソフトウェアのパフォーマンスを測定する最良の方法は、定期的な月の機能スコアと機能ポイントの稼働時間を計算することです。これらの値の両方の測定値は、一般的なプロジェクトだけでなく、活動レベルでも使用できます。このメトリックは、たとえば技術的な要件や設計など、コード外の作業を測定するためにも使用できます。 LOCメトリックは、コード自体に比べて機能が制限されていますが、しかし、プロジェクト全体の大規模な経済研究に危険をもたらします。 LOCメトリックは、通常はコード自体のコストを超える技術要件、設計、およびドキュメントのコストを考慮しません。



3.「設計、コード、および単体テスト」または（設計、コード、および単体テスト-DCUT）測定を停止します。ガイダンス、仕様、設計、コーディング、アセンブリ、ドキュメント、すべてのテストなどを含むプロジェクト全体を測定します。DCUT測定は、ソフトウェア開発プロジェクトの総コストの30％未満をカバーします。ソフトウェアプロジェクトの一部のコストを測定すると、専門家の混乱が生じます。



4. « ». , . , , , . 17% . (COQ) .



5.ペアプログラミングを避けます。ペアプログラミングは、制御解析と静的解析の組み合わせよりも高価で効率が低くなります。ペアプログラミングに関する文献、特に、ペアプログラミングを回避するために特に仕事を辞めたプログラマーのレポートに精通してください。ペアプログラミングを支持する文献は、プログラミング研究の一般的な弱点も示しており、ペアプログラミングと方法を、制御や静的分析などの実績のある品質結果と比較していません。ツール、メソッド、コントロールなどについて議論せずに、ペアとシングルプログラマーのみを比較します。



6. , . 85% . , , , , DRE > 99%, .



ソフトウェアエンジニアリングエンジニアリングは、古くて成熟したエンジニアリングの形態とは常に大きく異なっています。ソフトウェアエンジニアリングと従来のエンジニアリングの最も大きな違いの1つは、ソフトウェアエンジニアリングの測定経験が非常に乏しく、固体の経験的データではなく主観的な情報が多すぎることです。



この短い記事では、25種類の定量的目標を選択することを提案しています。その目標は、ソフトウェアの品質とその有効性の両方で大きな進歩に貢献します。ただし、重要なメッセージは、ソフトウェアの品質の低さは、パフォーマンス、スケジュール、コスト、および経済性を改善するために改善する必要がある重要な要素であるということです。

参照資料

アレーン、アラン。ソフトウェア推定モデル; Wiley-IEEE Computer Society; 2015

アレーン、アラン。ソフトウェアメトリックスおよび計測; Wiley-IEEE Computer Society; 2010

アレーン、アラン。ソフトウェアメンテナンス管理：進化と継続的な改善。 Wiley-IEEE Computer Society、2008; Beck、Kent;テスト駆動開発;マサチューセッツ州ボストン、アディソン・ウェスリー。 2002; ISBN 10：0321146530; 240ページ。

ブラック、レックス;テストプロセスの管理：ハードウェアおよびソフトウェアのテストを管理するための実用的なツールと手法。ワイリー2009; ISBN-10 0470404159; 672ページ。

チェス、ブライアンとウェスト、ジェイコブ。静的解析による安全なプログラミング。マサチューセッツ州ボストン、アディソン・ウェスリー。 20007; ISBN 13：978-0321424778; 624ページ。

コーエン、ルー;品質機能の展開-QFDを機能させる方法。ニュージャージー州アッパーサドルリバーのプレンティスホール。 1995; ISBN 10：0201633302; 368ページ。

クロスビー、フィリップB。品質は無料です。 New American Library、Mentor Books、ニューヨーク、ニューヨーク。 1979; 270ページ。

エベレット、ジェラルドD.、およびマクラウド、レイモンド。ソフトウェアテスト; John Wiley＆Sons、ホーボーケン、ニュージャージー州。 2007; ISBN 978-0-471-79371-7; 261ページ。

Gack、Gary;ブラックホールの管理：ソフトウェアプロジェクトリスクに関するエグゼクティブガイド。ビジネスエキスパートパブリッシング、トムソン、ジョージア州。 2010; ISBN10：1-935602-01-9。

Gack、Gary;ソフトウェア実装プロジェクトへのシックスシグマの適用。software.isixsigma.com/library/content/c040915b.asp。

ギルブ、トム、グラハム、ドロシー。ソフトウェア検査; Addison Wesley、レディング、MA; 1993; ISBN 10：0201631814.

ハロウェル、デイビッドL。シックスシグマソフトウェアメトリックス、パート1。software.isixsigma.com/library/content/03910a.asp。

IFPUG（52人の著者）; ITおよびソフトウェア測定に関するIFPUGガイド。アウエルバッハ出版社; 2012年。

国際標準化機構; ISO 9000 / ISO 14000; www.iso.org/iso/en/iso9000-14000/index.html。

ジェイコブセン、アイバー; Ng Pan-Wei;マクマホン、ポール。イアン・スペンス;リドマン、スヴェンテ;ソフトウェア工学の本質：SEMATカーネルの適用。アディソン・ウェスリー、2013。

ジョーンズ、ケーパーズ。ソフトウェア工学の技術的および社会的歴史。アディソン・ウェスリー、20124。

ジョーンズ、ケーパーズ。 「コードメトリックの行の短い履歴」。 Namcook Analytics LLC、ナラガンセット、RI2014。ジョーンズ、ケーパーズ。 「欠陥あたりのコストメトリックの短い履歴」。 Namcook Analytics LLC、ナラガンセットRI2014。

ジョーンズ、ケーパーズ。ソフトウェア工学の技術的および社会的歴史。アディソンウェスリーロングマン、ボストン、ボストン、マサチューセッツ。 2014年。

ジョーンズ、ケイパーズアンドボンシニョール、オリヴィエ;ソフトウェア品質の経済学。マサチューセッツ州ボストン、アディソン・ウェスリー。 2011; ISBN 978-0-13-258220-9; 587ページ。

ジョーンズ、ケイパーズ。ソフトウェアエンジニアリングのベストプラクティス。ニューヨーク、マグロウヒル。 2010; ISBN 978-0-07-162161-8; 660ページ。

ジョーンズ、ケイパーズ。 「プログラミングの品質と生産性の測定」。 IBM Systems Journal巻17、No。 1; 1978; pp。 39-63。

ジョーンズ、ケイパーズ。プログラミングの生産性-80年代の問題。 IEEE Computer Society Press、カリフォルニア州ロスアラミトス。 1981年初版; 1986年第2版。 ISBN 0-8186-0681-9; IEEE Computer Society Catalog 681; 489ページ。

ジョーンズ、ケイパーズ。 「ITTプログラミングテクノロジーセンターの10年間の回顧展」ソフトウェア生産性調査、マサチューセッツ州バーリントン。 1988年。

ジョーンズ、ケイパーズ。応用ソフトウェア測定; McGraw Hill、第3版2008; ISBN 978 = 0-07-150244-3; 662ページ。

ジョーンズ、ケイパーズ。ソフトウェア測定の重大な問題。情報システム管理グループ、1993; ISBN 1-56909-000-9; 195ページ。

ジョーンズ、ケイパーズ。今日のソフトウェア生産性と品質-世界的な視点。情報システム管理グループ、1993; ISBN -156909-001-7; 200ページ。

ジョーンズ、ケイパーズ。ソフトウェアリスクの評価と制御。プレンティスホール、1994; ISBN 0-13-741406-4; 711ページ。

ジョーンズ、ケイパーズ。ソフトウェア管理の新しい方向;情報システム管理グループ。 ISBN 1-56909-009-2; 150ページ。

Jones, Capers; Patterns of Software System Failure and Success; International Thomson Computer Press, Boston, MA; December 1995; 250 pages; ISBN 1-850-32804-8; 292 pages.

Jones, Capers; Software Quality – Analysis and Guidelines for Success; International Thomson Computer Press, Boston, MA; ISBN 1-85032-876-6; 1997; 492 pages.

Jones, Capers; Estimating Software Costs; 2nd edition; McGraw Hill, New York; 2007; 700 pages..Jones, Capers; “The Economics of Object-Oriented Software”; Namcook Analytics; Narragansett, RI; 2014.

Jones, Capers; “Software Project Management Practices: Failure Versus Success”; Crosstalk, October 2004.

Jones, Capers; “Software Estimating Methods for Large Projects”; Crosstalk, April 2005.

菅、スティーブンH。;ソフトウェア品質工学のメトリックとモデル、第2版。

マサチューセッツ州ボストン、アディソン・ウェスリー・ロングマン。 ISBN 0-201-72915-6; 2003; 528ページ。

土地、スーザンK;スミス、ダグラスB;ワルツ、ジョンZ;リーンシックスシグマソフトウェアプロセス定義の実用的なサポート：IEEEソフトウェアエンジニアリング標準の使用。 WileyBlackwell; 2008; ISBN 10：0470170808; 312ページ。

モズレー、ダニエルJ。; MISアプリケーションソフトウェアテストのハンドブック。 Yourdon Press、Prentice Hall;ニュージャージー州イングルウッドクリフ; 1993; ISBN 0-13-907007-9; 354ページ。

マイヤーズ、グレンフォード。ソフトウェアテストの技術。ジョン・ワイリー＆サンズ、ニューヨーク; 1979; ISBN 0-471-04328-1; 177ページ。

Nandyal; Raghav; Making Sense of Software Quality Assurance; Tata McGraw Hill Publishing, New Delhi, India; 2007; ISBN 0-07-063378-9; 350 pages.

Radice, Ronald A.; High Quality Low Cost Software Inspections; Paradoxicon Publishingl Andover, MA; ISBN 0-9645913-1-6; 2002; 479 pages.

Royce, Walker E.; Software Project Management: A Unified Framework; Addison Wesley Longman, Reading, MA; 1998; ISBN 0-201-30958-0.

Starr, Paul; The Social Transformation of American Medicine; (Pulitzer Prize in 1982); Basic Books, 1982;

Strassman, Paul; The Squandered Computer; The Information Economics Press, New Canaan, CT; 1997; 426 pages.

Wiegers, Karl E.; Peer Reviews in Software – A Practical Guide; Addison Wesley Longman, Boston, MA; ISBN 0-201-73485-0; 2002; 232 pages.