個人ソフトウェアプロセス

パーソナル ソフトウェア プロセス( PSP )は、ソフトウェアエンジニアがソフトウェアの開発方法に規律をもたらし、コードの予測された開発と実際の開発を追跡することで、ソフトウェア エンジニアがパフォーマンスをよりよく理解し、改善できるように設計された構造化されたソフトウェア開発プロセスです。開発者に、製品の品質を管理する方法、適切な計画を立てる方法、およびコミットメントを行う方法を明確に示します。また、計画を正当化するデータも提供します。開発者は、開発時間、欠陥、およびサイズのデータ​​を分析およびレビューすることで、作業を評価し、改善の方向性を提案できます。PSP は、ソフトウェアエンジニアリング協会(SEI) の能力成熟度モデル(CMM)の基本原則を、個人開発者のソフトウェア開発プラクティスに適用するために、Watts Humphrey によって作成されました。PSP は、チーム ソフトウェア プロセス(TSP) チームで作業するために必要なプロセス スキルをソフトウェア エンジニアに提供すると主張しています。

「パーソナルソフトウェアプロセス」および「PSP 」はカーネギーメロン大学の登録サービスマークです。^{[1] [2]}

PSP は、ソフトウェア エンジニアに個人のソフトウェア開発プロセスを改善するための規律ある方法を提供することを目的としています。PSP はソフトウェア エンジニアが次のことを行えるよう支援します。

• 見積もりおよび計画スキルを向上させます。
• 守れる約束をしましょう。
• プロジェクトの品質を管理します。
• 仕事における欠陥の数を減らす。

PSP トレーニングは、進化的改善アプローチに従っています。つまり、エンジニアは PSP を自分のプロセスに統合する方法を学習する際に、最初のレベルである PSP0 から開始し、プロセスの成熟度に応じて最終レベルである PSP2.1 に進みます。各レベルには、詳細なスクリプト、チェックリスト、テンプレートが用意されており、エンジニアに必要な手順を案内し、エンジニアが自分のソフトウェア プロセスを改善できるように支援します。Humphrey は、熟練したエンジニアが自分の長所と短所を理解しながら、これらのスクリプトとテンプレートをカスタマイズすることを推奨しています。

プロセス

PSP への入力は要件であり、要件ドキュメントが完成してエンジニアに配信されます。

PSP0、PSP0.1 (プロセスの規律と測定を導入)

PSP0 には、計画、開発 (設計、コード、コンパイル、テスト)、事後検証の 3 つのフェーズがあります。現在のプロセス測定のベースラインが確立されます。プログラミングに費やされた時間、挿入/削除された障害、プログラムのサイズです。事後検証では、エンジニアはプロジェクトのすべてのデータが適切に記録され、分析されていることを確認します。PSP0.1 では、コーディング標準、サイズ測定、および個人プロセス改善計画 (PIP) の開発を追加することで、プロセスが前進します。PIP では、エンジニアは自分のプロセスを改善するためのアイデアを記録します。

PSP1、PSP1.1（見積もりと計画の紹介）

PSP0 および PSP0.1 で収集されたベースライン データに基づいて、エンジニアは新しいプログラムの規模を見積もり、テスト レポート (PSP1) を準備します。以前のプロジェクトから蓄積されたデータを使用して、合計時間を見積もります。各新しいプロジェクトでは、実際に費やされた時間が記録されます。この情報は、タスクとスケジュールの計画と見積もりに使用されます (PSP1.1)。

PSP2、PSP2.1（品質管理と設計について紹介）

PSP2 では、設計レビューとコード レビューという 2 つの新しいフェーズが追加されました。PSP2 では、欠陥の予防と除去に重点が置かれています。エンジニアは、開発の各フェーズでタスクにかかる時間と、挿入および除去する欠陥の数を測定することで、プロセスを評価および改善する方法を学びます。エンジニアは、設計およびコード レビュー用のチェックリストを作成して使用します。PSP2.1 では、設計仕様と分析手法が導入されています。

(PSP3 は、TSP に置き換えられたレガシー レベルです。)

PSP の中心的な側面の 1 つは、履歴データを使用してプロセス パフォーマンスを分析し、改善することです。PSP データ収集は、次の 4 つの主な要素によってサポートされています。

• スクリプト
• 対策
• 標準
• フォーム

PSP スクリプトは、プロセス手順に従うための専門家レベルのガイダンスを提供し、PSP 対策を適用するためのフレームワークを提供します。PSP には 4 つのコア対策があります。

• サイズ – コード行数 (LOC) などの製品パーツのサイズ測定。
• 労力 – タスクを完了するために必要な時間。通常は分単位で記録されます。
• 品質 – 製品の欠陥の数。
• スケジュール – 計画された完了日と実際の完了日を基準に追跡されるプロジェクトの進行状況の尺度。

プロセスに標準を適用することで、データの正確性と一貫性を確保できます。データは通常、PSP ソフトウェア ツールを使用してフォームに記録されます。SEI は PSP ツールを開発しており、プロセス ダッシュボードなどのオープン ソース オプションも利用できます。

PSP ツールで収集される主要なデータは、時間、欠陥、およびサイズのデータ​​です。つまり、各フェーズに費やされた時間、欠陥が挿入、発見、修正された時間と場所、および製品部品のサイズです。ソフトウェア開発者は、パフォーマンスを理解し、改善するために、これら 3 つの基本的な測定基準から派生した他の多くの測定基準を使用します。派生した測定基準には次のものがあります。

• 推定精度（サイズ/時間）
• 予測間隔（サイズ/時間）
• 位相分布の時間
• 欠陥注入分布
• 欠陥除去分布
• 生産性
• 再利用率
• コストパフォーマンス指数
• 計画値
• 獲得価値
• 予測獲得価値
• 欠陥密度
• 相別の欠陥密度
• フェーズ別の欠陥除去率
• 欠陥除去レバレッジ
• レビュー率
• プロセス収率
• 位相降伏
• 品質不良コスト (COQ)
• 評価COQ
• 評価/不合格 COQ 比率

時間、欠陥、およびサイズのデータ​​をログに記録することは、履歴データが見積りの精度を向上させるために使用されるため、PSP プロジェクトの計画と追跡に不可欠な部分です。

PSP は、PROxy ベース見積(PROBE) 方式を使用して、開発者の見積スキルを向上させ、より正確なプロジェクト計画を実現します。プロジェクト追跡には、PSP は実績値方式を使用します。

PSP は相関、線形回帰、標準偏差などの統計手法も使用して、データを見積、計画、品質の向上に役立つ情報に変換します。これらの統計式は PSP ツールによって計算されます。

PSP は開発者が個人のプロセスを改善できるようにすることを目的としているため、PSP 開発者はプロセスを継続的に適応させて、個人のニーズを満たすようにする必要があります。

実際には、PSP スキルは TSP チーム環境で使用されます。TSP チームは、プロジェクトの責任分野に自発的に参加している PSP トレーニングを受けた開発者で構成されているため、プロジェクトはチーム自体によって管理されます。チームは、PSP スキルを使用して収集された個人データを使用して、計画、見積もりを作成し、品質を管理します。

PSP プロセス メソッドを使用すると、TSP チームはスケジュールの約束を守り、高品質のソフトウェアを作成できます。たとえば、Watts Humphrey の調査によると、ソフトウェア プロジェクトの 3 分の 1 が失敗しています^[3]。しかし、13 の異なる組織における 20 の TSP プロジェクトに関する SEI の調査では、TSP チームが目標スケジュールに遅れたのは平均でわずか 6% でした^{[4] 。}

スケジュールの約束を順守できたのは、履歴データを使用してより正確な見積もりを行い、プロジェクトを現実的な計画に基づいて実施できたからです。また、PSP 品質手法を使用することで欠陥の少ないソフトウェアを生産し、統合テストや受け入れテストなどの後の段階で欠陥を取り除くのにかかる時間を短縮できました。

PSP は、個々の開発者のニーズに合わせて調整できる個人的なプロセスです。特定のプログラミングまたは設計方法論に固有のものではないため、アジャイル ソフトウェア開発を含むさまざまな方法論で使用できます。

ソフトウェア エンジニアリングの手法は、予測型から適応型までさまざまです。PSP は予測型の手法で、アジャイルは適応型と考えられていますが、違いはあるものの、TSP/PSP とアジャイルは、特にチーム編成に関して、いくつかの概念とアプローチを共有しています。どちらも、チームに次のことを可能にします。

• 目標と基準を定義します。
• 作業を見積もり、スケジュールします。
• 現実的かつ達成可能なスケジュールを決定します。
• 計画を立て、プロセスの改善を行います。

アジャイルと TSP/PSP はどちらも、チーム メンバーが自分の仕事に責任を持ち、協力して現実的な計画に合意し、信頼と説明責任の環境を作り出すという考え方を共有しています。ただし、TSP/PSP は、プロセスの文書化と、プロジェクト スケジュールの予測と定義のためのデータの使用に重点を置いている点で、アジャイルとは異なります。

高品質のソフトウェアは PSP の目標であり、品質は欠陥の観点から測定されます。PSP の場合、品質プロセスはユーザーのニーズを満たす欠陥の少ないソフトウェアを作成する必要があります。

PSP フェーズ構造により、PSP 開発者は早期に欠陥を発見できます。早期に欠陥を発見することで、PSP はテストなどの後のフェーズに費やす時間を削減できます。

PSP 理論では、欠陥が注入された場所と時間にできるだけ近い場所で欠陥を除去する方が経済的かつ効果的であるため、ソフトウェア エンジニアは開発の各フェーズで個人レビューを実施することが推奨されています。したがって、PSP フェーズ構造には 2 つのレビュー フェーズが含まれます。

• デザインレビュー
• コードレビュー

効果的なレビューを行うには、構造化されたレビュー プロセスに従う必要があります。PSP では、開発者が一貫して秩序立った手順に従うことができるように、チェックリストを使用することを推奨しています。

PSP は、人がミスをした場合、そのエラーは通常予測可能であるという前提に従っているため、PSP 開発者は、自分のよくあるエラーを対象にチェックリストをカスタマイズできます。ソフトウェア エンジニアには、プロセス改善提案を完了して、現在のパフォーマンスの弱点を特定し、改善対象とすることが求められます。時間の浪費や欠陥の導入箇所を明らかにする過去のプロジェクト データは、開発者が改善すべき領域を特定するのに役立ちます。

PSP 開発者は、自分の作業が同僚またはチームによるレビューを受ける前に、個人によるレビューを実施することも求められます。

PSP に関する認定は、カーネギーメロン大学の SEI によって提供されています。SEI 認定 PSP 開発者になるための手順は、PSP を学習し、認定試験を受け、資格を維持することです。PSP 開発者試験は、PSP 知識体系^[5]にある概念に基づいています。SEIは認定に関するFAQ ^[1]を維持しています。

• アジャイルソフトウェア開発
• 能力成熟度モデル統合(CMMI)
• カーネギーメロン大学
• プロキシベースの推定(PROBE)
• ソフトウェアエンジニアリング研究所(SEI)
• チームソフトウェアプロセス（TSP）
• ワッツ・ハンフリー

• 「定義され測定されたパーソナル ソフトウェア プロセスの使用」、Watts S. Humphrey著、 IEEE Software 誌、1996 年 5 月、77 ～ 88 ページに掲載。
• PSP: ソフトウェア エンジニアのための自己改善プロセス、2005 年。
• TSP(SM) と Six Sigma によるプロジェクトの成功: チーム ソフトウェア プロセスの実装に関する実践ガイド、Mukesh Jain、2008 年。
• 「新しいチームの課題を乗り越えて成功するプロジェクトを実現する」Mukesh Jain (http://www.sei.cmu.edu/tspsymposium/2009/2006/deliver.pdf)、2006 年 9 月。
• ソフトウェアエンジニアリング：実践者のアプローチ第7版。Roger S Pressman。McGraw-Hill Higher Education。2009年。ISBN 0-07-337597-7、ISBN 978-0-07-337597-7、57～58ページ。  
• カーネギーメロン大学のソフトウェアエンジニアリング研究所による「パーソナルソフトウェアプロセス (PSP) 知識体系」の記事。
• 「パーソナル ソフトウェア プロセスによるパーソナル品質管理」の記事。

• ソフトウェア プロセス ダッシュボード、オープン ソース ( GPL3 ) PSP および TSP ツール。独自の SEI スクリプトの有無にかかわらず提供され、後者には無料の SEI 登録が必要です。