くまきち

長崎IT技術者会 勉強会（9/18）

「汝自身を知れ」

計測（見える化）大事

↓でも測るだけでホントに大丈夫？

測るだけでは改善されない

↓自分の弱点を見つけて改善していく

それがPSP

PSPとは

PSP（Personal Software Process）

カーネギーメロン大学ソフトウェアエンジニアリング研究所（CMU/SEI）のワッツ・ハンフリーさんが考案した自己改善プロセス

個人が、自分で行う作業の管理や、またその作業のやり方（プロセス）を改善するのを支援する仕組み

注：「ソフトウェアプロセス」という名前がついていますが、根本的な考え方は、他の作業に十分に展開可能です

見積りとスケジュール

ベースラインの確立

設計品質の改善

PSPの発展段階

PSP0• 現行プロセスの整理• 時間、欠陥の記録

PSP1• 規模と時間の見積もり• テスト報告

PSP2• 設計&コードレビュー

PSP0.1• 規模の計測• プロセス改善提案

PSP1.1• スケジュールの計画

PSP2.1• 設計テンプレート

ベースラインの確立

プロセスに沿った開発、データ収集の基礎

PSP0

単純なプロセス構造

時間の記録

欠陥の記録

計画 設計 コードコンパイ

ルテスト 事後分析

No フェーズ 開始時刻 中断時間 終了時刻 デルタ時間 備考

No 日付 欠陥型 作り込み 除去 修正時間 参照

No フェーズ 開始時刻 中断時間 終了時刻 デルタ時間 備考

1 Code 10:00 10min 11:00 50min TEL

No 日付 欠陥型 作り込み 除去 修正時間 参照

1 09/18 20 Code Compile 10min -

プロセスに沿った開発、データ収集の基礎 PSP0.1

規模の計測 「どこをどうやって測るか？」 どこを測る

どうやって測る コーディング標準の作成

規模計測標準の作成

ベースラインの確立

削除

無修正

修正 追加

再利用

新規再利用 計測の対象

ここを測る

プロセスに沿った開発、データ収集の基礎

PSP0.1

プロセス改善提案（PIP；Process Improvement Proposal）

ベースラインの確立

「のど元過ぎれば熱さ忘れる」

「元の木阿弥」

「問題は何か？」

「次はどうするか？」

個人としてスキルアップするために、次にどうするかを整理し、記録する。

そしてそれを実践する

見積もりとスケジュール

ベースラインの確立

設計品質の改善

PSPの発展段階

PSP0• 現行プロセスの整理• 時間、欠陥の記録

PSP1• 規模と時間の見積もり• テスト報告

PSP2• 設計&コードレビュー

PSP0.1• 規模の計測• プロセス改善提案

PSP1.1• スケジュールの計画

PSP2.1• 設計テンプレート

日付 週計画時間

累積時間

実績時間

累積時間

PV累積PV

タスク

EV累積EV

3/8 1 20 20

3/15 2 15 35

3/22 3 25 60

3/29 4 25 85

見積もり手法の採用とスケジュール計画

PSP1

PROBEを用いた規模と時間の見積もり（後述）

PSP1.1

自分自身のスケジュール計画立案

見積もりとスケジュール

日付 週計画時間

累積時間

実績時間

累積時間

PV累積PV

タスク

EV累積EV

3/8 1 20 20 0 0 A

3/15 2 15 35 38.5 38.5 AB

3/22 3 25 60 38.5 77.0 B

3/29 4 25 85 23.0 100.0 C

日付 週計画時間

累積時間

実績時間

累積時間

PV累積PV

タスク

EV累積EV

3/8 1 20 20 20 20 0 0 A

3/15 2 15 35 15 35 38.5 38.5 AB

3/22 3 25 60 20 55 38.5 77.0 B

3/29 4 25 85 20 75 23.0 100.0 C

日付 週計画時間

累積時間

実績時間

累積時間

PV累積PV

タスク

EV累積EV

3/8 1 20 20 20 20 0 0 A 0 0

3/15 2 15 35 15 35 38.5 38.5 AB 0 0

3/22 3 25 60 20 55 38.5 77.0 B 38.5 38.5

3/29 4 25 85 20 75 23.0 100.0 C 0 38.5

見積りとスケジュール

ベースラインの確立

設計品質の改善

PSPの発展段階

PSP0• 現行プロセスの整理• 時間、欠陥の記録

PSP1• 規模と時間の見積もり• テスト報告

PSP2• 設計&コードレビュー

PSP0.1• 規模の計測• プロセス改善提案

PSP1.1• スケジュールの計画

PSP2.1• 設計テンプレート

PSPにおける品質のポイント

役に立つソフトウェアとは欠陥がないこと

欠陥が混入しないソフトウェア開発はない。だから欠陥を取り除くしくみが必要

設計レビューとコードレビュー

テスト

欠陥を混入させた時点が、欠陥を除去できる最も良いタイミング

自分で自分が混入させた欠陥を除去するのが効率的

自分が混入させた欠陥の原因を判断する

自分が混入させる欠陥を予防することを学ぶ

タイミングはこの２つしかない

設計品質の改善

戦略的な設計とレビュー

PSP2 セルフレビュー

自分自身の欠陥経験をもとに個人用チェックリストをカスタマイズして使用したとき、最も効果的 チェックリスト項目を選択するために、自分自身のデータを

使用する

レビュー時にデータを収集し、分析する

チェックリストを洗練させる

<POINT>改善が定着し、同様の欠陥が発生しなくなったら、リストから外す

プロキシベースの見積もり

カテゴリ 非常に小さい

小さい 中規模 大きい 非常に大きい

計算 2 5 11 25 50

データ 3 5 9 26 30

入出力 9 12 16 22 30

論理 8 11 16 23 35

（合計）

プロキシベース見積もり

PROBE見積もりのステップ

1. 概念設計

要求をもとに、必要な部品（プロキシ）を洗い出す

2. 追加部品の規模を見積もるカテゴリ 非常に小

さい小さい 中規模 大きい 非常に大

きい

計算 2 5 11 1 25 1 50

データ 3 2 5 9 26 30

入出力 1 9 12 16 22 30

論理 8 1 11 3 16 23 35

（合計） 9 21 48 25 50

プロキシベース見積もり

PROBE見積もりのステップ

3. 再利用部品とベースプログラムの修正規模を見積もる

他のライブラリ等から利用する部品の規模を確認①

将来再利用可能な部品の規模を確認②

ベースとなるプログラムの修正行数を見積もる③

プロキシ規模の見積もり値を求める

削除

無修正

修正③ 追加(2)

再利用①

新規再利用②

プロキシベース見積もり

PROBE見積もりのステップ

4. 追加・修正規模見積り

蓄積されたデータをもとに、線形回帰によりプロキシ規模（実績）から追加・修正規模を見積もる

y = 1.2494x + 3.1938R² = 0.9912

0

50

100

150

200

250

0 50 100 150 200

追加・修正規模（実績）

プロキシ規模見積もり

プロキシベース見積もり

ポイント

規模（ライン数）そのものではなく、プロキシ（代替）で見積もる

最初からライン数では見積もれない

プロキシはライン数と相関関係にあるものがいい。たとえば、機能数、ファンクションポイント数、クラス数など

見積もりには必ずバイアス、偏りがあるので、データに基づいて補正する

データの計測、蓄積が大事！

TSPの紹介

TSPとは

TSP（Team Software Process）とは

PSPエンジニアで構成されるチームが、ソフトウェア開発作業を行うためのプロセス

チーム構築を行うための定義されたプロセス

チームワーキングの枠組み

支援を提供するためのマネジメント環境

TSPのコンセプトは「自律したチーム」

作業計画はチームメンバが自分で作成する

すべてのチームメンバが何らかの役割を引き受ける

チームリーダはチームメンバ支援に徹する

TSPの開発戦略ラウンチ 要求分析

インスペクション

事後分析

リラウンチ 外部設計インスペク

ション事後分析

リラウンチ 詳細設計 レビューインスペク

ションコード

レビュー コンパイル 単体テストインスペク

ション事後分析

リラウンチ 結合テストシステムテ

スト事後分析

PSPの部分

TSPのポイント

チームラウンチ（立ち上げプロセス）

役割マネージャの割り当て

TSPコーチによるリーダ支援

週次ミーティング

チームメンバによるクイックな負荷平準

PIPによるチームプロセスの改善

象を食べるには？

よくある疑問１

時間計測の粒度は？

現状が把握でき、改善効果が見える単位ということであれば、分単位が妥当です

計測が面倒くさいんですけど

作業時間計測のフリーツールなどがあります

あとは慣れる必要があります。あくまで時間は改善効果を確かめる指標なので、少々精度が悪くてもよいと思います

よくある疑問２

すでに開発プロセスがあるのですが…

PSPは個人の開発プロセスがない組織にインストールすることができるように、フルセットで記述されています

すでに個人の開発プロセスがあるなら、取り入れられるところからやっていけばよいです

概念設計にUSDMを取り入れる

PIPにKPTを採用する

計画立案にEVMを採用する

よくある疑問３

開発言語がバラバラです

ここがPSPのウィークポイントかも

PSPは「データを蓄積して自分の能力を把握する」という考え方なので、初めての経験についてはちょっと苦手です

新しいことをする場合には、事前のトライアルから計測を開始するとよいかもしれません

最後のまとめ

PSPとは

個人が、自分で行う作業の管理や、またその作業のやり方（プロセス）を改善するのを支援する仕組み

自分自身の（今の）実力がベース

計測したデータがすべて

自分の実力を把握するところからひとつづつ始める

「象を食べるには一口ずつ食べる」

参考資料

PSPガイドブック

ソフトウェアエンジニア自己改善（ワッツ・ハンフリー著、秋山義博監訳、JASPIC TSP

研究会訳、翔泳社）

パーソナルソフトウェアプロセス入門（ワッツハンフリー著、PSPネットワーク訳）