Recommended
More Related Content
Similar to PM勉強会2010
Similar to PM勉強会2010 (20)
More from Yoshihide Chubachi
Recently uploaded
Recently uploaded (7)
PM勉強会2010
- 1. プロジェクトマネジメント論ことはじめ （参考資料：大野とし郎先生の非公開作） 大岩研究室 松澤芳昭
- 2. はじめに プロジェクト管理は、ご承知のように、とても難しい。 実際、現場で納期遅延ともなれば、赤字や契約破棄に至 るから、受注側も発注側も首を賭してやるしかない。 昔から、プロジェクトリーダーは、辞表片手に取り組む しかないとしたものだった。3回辞表を出した経験がな いと、一丁前のリーダーにはなれないとも言われてきた。 実際のプロジェクトマネジメントにおいては， プロジェクトマネージャが好きな方法を取って よい．成功さえすれば．
- 3. ソフトウェアプロジェクト管理論の潮流 米国流大規模プロジェクト向け：CMMI・ PMBOK→ISO21500 軍（DoD米国国防総省）の調達モデルもどきで、形骸化 しやすい。 欧州流標準化タイプ：ISO10006（品質管理―プロ ジェクト管理における品質の指針） 標準化が陥りがちな文書倒れになりやすい。 コンサルタント提唱の実戦向け：アジャイルプロセ ス（例, XP：Extreme Programming） 現場の多様さに負けて，長続きしない傾きがある。
- 4. 現場の考え方を2つに分類すると （A）「ソフトウエア開発のプロジェクト管理は、 工学的活動であり、他の工学的管理（例えばフォー ドの自動車工場のアセンブリ方式）と同様に、プロ ジェクトは管理できる。」 → PMBOK, CMM （B）「ソフトウエア開発のプロジェクト管理は、 限られた資源のもとでの、創意工夫と意思疎通の企 業ゲームだ。」 → アジャイル系
- 5. (A)派の主張 （１）プロジェクトは管理可能であるべきだし、管理可能であると する。あるいは、少なくともその願望を大いにか密かにか抱いてい る。 （２）プロジェクト管理には、共通の方法や方法論がある。あるい はなければならない。だから、「私の提唱するこの方法をやってみ よ。見事にプロジェクトは収束するであろう」と言い張る。 （３）なぜ可能かといえば、プロジェクトは、仕様決め・設計・実 装・検査・保守のように順番に進む。つまり線形性を仮定して、仕 様は凍結できるし、凍結されなければならないとするからだ。 （４）だから、私の方法論は、職場の規則や標準になっていなけれ ばならない。どんなに分厚い標準マニュアルでも、プロジェクトメ ンバーはそれを遵守しなければならない。 （５）私の主張は、プロジェクトメンバーに教育を施せば、伝達可 能であり、実現可能だと仮定している。つまり、通達や命令は通じ るのだという変革モデルを、暗黙のうちに前提にしている。
- 6. (B)派の主張 （１）プロジェクトの管理は、工学的にできるものではない。創意 工夫と試行錯誤がその本質なのだ。 （２）したがって、すべてのプロジェクトに共通する方法や方法論 はまずないとしたものだ。プロジェクトは一つひとつみんな異なる。 特定の方法論でカバーできるわけがない。 （３）なぜ一般的方法論が難しいかというと、プロジェクトは手順 どおりには進まないのが、ふつうだからだ。つまり、線形性は現実 的でないから仮定できない。ただし、仕様がはっきりしているコン パイラの作成などは、それを凍結できる。 （４）したがって、規則や標準は固定したものであってはならず、 目前のプロジェクトに適合した、最小限の決め事であるべきである。 （５）通達や命令はメンバーにたやすく届くものではなくて、チー ムの信頼関係のもとに一緒に苦労をして、はじめて通じるものだ。 しかも、だれしも何かを習得するのに一挙にはいかなくて、一つひ とつ失敗をしながらひとつずつ習得していく。
- 7. 結論 大きく2つの考え方と方法論があることを念頭に置 いてPM論を捉えていく必要がある． 実際にはPM自身が様々なプラクティスを取捨選択し つつ，現場の状況をみて，そのプロジェクト専用の 手法を編み出すことになる． PM同士が会話をするための共通言語として， PMBOKは使える． 小規模，研究的，教育的開発ではXP的なプロセスを 多く取り入れる必要がある．
- 8. WBS(Work Breakdown Structure) 静岡大学情報学部 松澤芳昭
- 9. WBS Work Breakdown Structure WBSは，プロジェクト目標を達成し，必要な要素成果物 を生成するために，プロジェクト・チームが実行する作 業を，要素成果物を主体に階層的に要素分解したもので ある WBSはプロジェクト作業をより小さく，扱いやすい作業 単位に細分化したもので，レベルが一段下がるごとにプ ロジェクトの作業をより詳細に定義する
- 10. WBSの一例 カレーライス Lv.1 （夕飯）の作成 Lv.2 買出し 調理 片付け スーパーの Lv.3 下ごしらえ 皿洗い 選定 洗う Lv.4 買い物に行く 煮込み 乾燥 ゆすぐ 予算，仕様 ジャガイモ 味付け 品質の検討 皮むき 洗いもの ジャガイモを きる
- 11. WBS作成のステップ プロジェクトの目的を決める 顧客に提供するプロダクト，サービス，結果などの 成果物を具体的に決める そのほか，要素成果物や中間成果物のための項目や， 全成果物に共通する横断的な作業項目をもれなく特 定する 各項目を論理的な小単位に分解し，各要素の複雑さ やコストが，計画やコントロールをするうえで適切 な大きさ（ワークパッケージ）になるまで分解を続 ける
- 12. WBSの構成要素 プロジェクト フェーズ サブプロジェクト 要素成果物 ワークパッケージ ←→ アクティビティ
- 13. １００%ルール １００%ルール 下位の要素の総和が上位の要素と一致する MECE Mutually Exclusive and Collectively Exhaustive もれなく，ダブりなく
- 14. どれぐらい分解すればよいか アクティビティが規定できる粒度 要素成果物が規定されている必要がある 費用対効果の高いマネジメントができる程度 一般的に，細粒度にするほど，ボトムアップ見積もりの 精度は良くなる 一般的に，細粒度にするほど，マネジメントのオーバー ヘッドは大きくなる
- 15. ソフトウェア開発WBSの典型例 ソフトウェア・ プロジェクト システム 要求事項 分析 基本設計 詳細設計 導入 引渡 要求事項の プロセス システム・ 試験条件の データベース 要求分析 おおむねの把握 のモデル アーキテクチャ 作成 変換 利用者の インタフェース データ・ 実際の プログラムの システム インタビュー の要求事項 モデル データモデル コーディング 設置 要求事項の ハードウェア・ 実際の ユニット 機能記述 技術移転 検討 ソフトウェア プロセスモデル 試験 利用者用 インプット・ データベースの システム 管理システム 結合試験 文書の確認 アウトプットの定義 定義 マニュアル チェックポイント 利用者での システム・ 利用者の承認 妥当性の確認 妥当性確認 パフォーマンス
- 17. 進捗報告 進捗報告 プロジェクトの進み具合（進捗：しんちょく）を報告す る 目的 プロジェクトが無事に終わることをプロジェクトステー クホルダー（上司，組織，クライアント等に示す）
- 18. よくある進捗報告 まずい例 ～をしました なぜまずいか プロジェクトが無事に終わるかどうかが評価できない 作業を続けていればいつか終わるのか やってないからできない（環境に問題？）/やってるけど できない（方法に問題？計画に問題？）のかわからない
- 19. 何を進捗報告しなければならないか 総合的なプロジェクトの状況 青・黄・赤 計画に対する実績の状況 何ができている予定であるか どのくらいの時間（コスト）をかけてやったか 実績はどのようであったか 質的な分析 リスク対策
- 20. 進捗報告のためのEVM EVM (Earned Value Management) アーンドバリューマネジメント EVT (Earned Value Technique) アーンドバリュー法 Earned Value: （これまでに）稼いだ価値
- 21. EVT 基本概念 PV (Planned Value) アクティビティ，またはWBSの構成要素について，完了 するように予定した作業の予算コスト EV (Earned Value) スケジュール・アクティビティまたはWBSの構成要素に ついて，実際に完了した作業の予算コスト AC (Actual Cost) スケジュール・アクティビティまたはWBSの構成要素に ついて作業を完了するために発生したコストの合計
- 22. EVTで分かること コスト差異(CV: Cost Variant) CV = EV – AC スケジュール差異(SV: Schedule Variance) SV = EV – PV コスト効率指数 (CPI: Cost Performance Index ) CPI = EV / AC スケジュール効率指数 (SPI: Schedule Performance Index) SPI = EV / PV
- 23. 20 07 /1 0 20 40 60 80 100 120 140 160 180 20 0/ 07 4 /1 20 0/6 07 / 20 10 07 /8 /1 コスト差異 20 0/ 07 10 /1 20 0/1 07 2 /1 20 0/ 07 14 /1 20 0/1 07 6 /1 20 0/ 07 18 /1 20 0/2 07 0 /1 20 0/ 07 22 /1 20 0/2 07 4 /1 20 0/ 07 26 /1 20 0/2 07 8 /1 進度を示す（CV = EV - AC） 0/ 20 3 07 0 /1 20 1/1 07 /1 20 1/ 07 3 /1 20 1/5 07 CV /1 20 1/ 07 7 / 20 11 07 /9 /1 20 1/1 07 1 /1 20 1/ 07 13 /1 1/ 15 EV PV AC コスト（ソフトウェアでは≒かけた時間）に対する
- 24. 20 07 /1 0 20 40 60 80 100 120 140 160 180 20 0/ 07 4 /1 20 0/6 07 / 20 10 07 /8 /1 20 0/ 07 10 /1 20 0/1 07 2 /1 20 0/ 07 14 /1 20 0/1 07 6 /1 スケジュール差異 20 0/ 07 18 /1 20 0/2 07 0 /1 20 0/ 07 22 /1 20 0/2 07 4 /1 20 0/ 07 26 /1 20 0/2 07 8 /1 0/ 20 3 07 0 /1 20 1/1 スケジュールに対する進度を示す 07 /1 20 1/ 07 3 /1 20 1/5 07 /1 SV 20 1/ 07 7 / 20 11 スケジュール差異（期間） 07 /9 /1 20 1/1 1 SV = EV – PV （-遅れている/+進んでいる） 07 /1 20 1/ 07 13 /1 1/ 15 EV PV AC
- 25. 10 0 50 100 150 200 250 300 350 400 /4 10 /1 1 10 /1 8 10 /2 5 11 /1 11 /8 11 /1 5 11 /2 2 11 /2 9 12 /6 12 /1 3 12 /2 0 12 /2 7 1/ 3 1/ 10 1/ 17 1/ 24 1/ 31 2/ 7 2/ 14 2/ 21 学生プロジェクトの典型例（１） 2/ 28 EV AC PV（開始当初見積）
- 26. 0 50 100 150 200 250 300 350 400 450 500 07/10/4 07/10/11 07/10/18 07/10/25 07/11/1 07/11/8 07/11/15 07/11/22 07/11/29 07/12/6 07/12/13 07/12/20 学生プロジェクトの典型例（２） 07/12/27 08/1/3 08/1/10 08/1/17 08/1/24 08/1/31 EV PV AC
- 27. うまくいったプロジェクトの場合 PV,EV,AC,EAC推移 500.0 450.0 400.0 350.0 p 300.0 o i 250.0 n t 200.0 PV(point) 150.0 EV(point) 100.0 AC(point) BAC(point) 50.0 0.0 3 7 /4 /1 /8 /6 10 7 4 31 1 8 5 5 2 9 3 0 7 1/ 2 1 2 /1 /1 /2 /1 /2 /2 /1 /2 /2 9/ 10 11 11 12 1/ 1/ 1/ 1/ 10 10 10 11 11 11 12 12 12
- 28. 生産性の向上
- 29. 学生による差異
- 30. EVTの正確性 EVMの正確性は，計画(PV)の正確性に依存する プロジェクトのスコープ プロジェクトのWBSと見積もり
- 31. アーンド・バリューの測定方法 重み付けマイルストーン法 固定比配分法 出来高パーセント見積もり法 マイルストーンをゲートとする出来高パーセントの 組み合わせ法 完成作業の等価単位法 達成基準法
- 32. 重み付けマイルストーン法 ワークパッケージにマイルストーンを決め，その配 分を決める方法 例：掲示板の作成 技術調査が終わったら25% ファイル入出力無しバージョンができると50% ファイル入出力バージョンができたら75% テストが終わったら100%
- 33. 固定比配分法 配分ルールを決める重み付けマイルストーン法 例 着手で25％，完成で100％（25/75法）
- 34. 出来高パーセント見積もり法 作業の責任者が，出来高を定期的に見積もる方法 通例，見積もりは「主観」ベース マイルストーンをゲートとする出来高パーセントの 組み合わせ法 マイルストーンと出来高パーセントの組み合わせで主観 の信頼度を増す
- 35. 完成作業の等価単位法 全単位を対象に，その完成全ユニットのうち個々の ユニットに決められた計画価値を割り当てる 繰り返し作業をマネジメントする場合 例：テストケース50個のアーンドバリュー 一つあたり2% 質は考慮していない
- 36. 達成基準法 達成する基準をあらかじめ決めておき，それにした がって達成度を測る方法 実行すべきタスクのパフォーマンスに対して，等価単位 の基準値を事前に設定する
- 37. 間接作業のアーンドバリュー 勧められない 例：プロジェクトマネージャのEV 一般的に測定可能な，成果物としてのアウトプットを持 たない 実施される物理的作業が何であるかに関わらず，計画の 中で承認されたものはすべて，自動的にその計画価値が そのプロジェクトに対するアーンド・バリューとなって しまう つまり，物理的な作業が実施されたか否かにかかわらず， 常にEV計画価値に一致してしまう
- 38. ワークパッケージ：悪い例 悪い例 ミーティングを行う コミュニケーションを円滑に進めるためには必要 ヒアリングを行う 営業では，価値を持つ 良いワークパッケージとは 目的を表現しているもの 最終成果物に対して，どれだけの価値を持つ成果が得ら れたかが測れるもの
- 39. リスク・マネジメント リスク 不確定要素 プロジェクトにプラス，マイナスの影響を及ぼす リスクの属性 影響度 発生確率 リスク対策の重要度＝影響度×発生確率
- 40. リスク・マネジメント リスク識別 情報収集 ブレーンストーミング 文書レビュー 専門家による指摘 リスク分析 影響度と発生確率の分析→対応の優先順位付け リスク対応・マネジメント 重要なリスクは早めに対応して回避
- 41. まとめ 進捗方法の方法 目的：プロジェクトが確実に終了することを示す 量的な分析（EVTを用いて） 何ができている予定であるか(PV) 実績はどのようであったか(EV) どのくらいの時間（コスト）をかけてやったか(AC) 質的な分析 リスク対策はうまくいっているか 新規リスクの発生はないか
- 42. PMBOKの概説 (PMBOK:Project Management Body of Knowledge) 静岡大学情報学部 松澤芳昭
- 43. PMBOKの位置づけ 知識体系として，PM間の共通用語として使える． Full-specで扱うことはない．実際のプロセスに取り入れ るかはPMの判断次第である． 以下，p.77より引用 経験のあるプロジェクトマネジメント実務者のほとんどは，プ ロジェクトをマネジメントする方法が一通りでないと認識して いる．望ましいプロジェクト・パフォーマンスを達成するため には，プロジェクトマネジメントの知識，スキル，プロセス等 が様々な順序や厳格さの程度で適用される． ただし，特定のプロセスが必要でないと考えたとしても，その プロセスが適用されないということを意味するものではない． プロジェクトマネジャーおよびプロジェクトチームはすべての プロセスを検討し，プロジェクトごとに各プロセスを実行する 程度を決定しなければならない．
- 44. PMBOKの適用範囲 http://www.pmaj.or.jp/online/0511/pmp_bukai.html 人間関係のスキル コミュニケーション，リーダーシップ，ネゴシエーション，問題解決力 一般的なマネジメントの知識・スキル 定常業務の計画，実行（会計，業務計画，組織構造，キャリアパス，健康と安全，IT） プロジェクト環境の理解 文化的・社会的環境，国際的・政治的環境，物理的環境 適用分野の知識・標準・規則 いわゆる"業務知識"，技術的要素，産業の知識，業務知識
- 45. 1章 序論
- 46. PMBOKの構成 1章 序論 基本的な用語の説明 2章 単一プロジェクトのプロジェクトマネジメン ト標準 大まかな全体のマネジメントプロセスの説明 3章 プロジェクトマネジメント知識エリア ８つの知識エリアの詳細な説明
- 47. プロジェクトとは何か 有期性 ⇔定常業務 独自のプロダクト，サービス，所産 人工物の創造 段階的詳細化 プロジェクトの目標に関して理解が深まるにつれて，よ り明確，詳細に定義される
- 48. プロジェクトマネジメントとは何か 要求事項を特定すること 明確で達成可能な目標を確立すること 品質，スコープ，タイム，コストなど，競合する要 求のバランスを取ること 各種ステークホルダーの異なる関心と期待に対して， 仕様，計画，取り組み方法を適応させること
- 49. プロジェクトマネジメントとは何か （補足） Quality, Cost, Delivery + Risk 制約三条件 スコープ，タイム，コスト プロジェクトマネージャは上記のバランスをとる必要がある プロジェクトのリスク 不確実な事象（プラスかマイナス） プロジェクトマネージャは不確実性に対応しながらプロジェク トを進める必要がある
- 50. ステークホルダー プロジェクトに積極的に関与しているかプロジェクトの 実施あるいは完了の結果が自らの利益にプラスまたはマ イナスの影響を受ける個人や組織である． プロジェクトマネージャ 顧客・ユーザ 母体組織 プロジェクト・チーム・メンバー プロジェクトマネジメントチーム スポンサー 影響力者 ＰＭＯ
- 51. 組織構造 機能型組織 プロジェクト型組織 プロジェクト型 開発A 開発B 開発C 開発D 人事 機能型 営業 開発 マトリクス型
- 52. ＰＭＯ プロジェクトマネジメントオフィス 親組織またはクライアントの全体的なビジネス目標に関 連するプロジェクトおよびサブプロジェクトに対する計 画調整，優先順位設定，および実行 プロダクトマネジメント
- 53. ２章 単一プロジェクトのプロジェクトマ ネジメント標準
- 54. プロジェクトマネジメントプロセス 一般形 ＰＤＣＡ(Plan Do Check Action) サイクル (シューハートが定義し，デミングにより改訂されたもの ASQ Handbook, pages13-14, American Society for Quality, 1999)
- 56. 立ち上げプロセス群 プロジェクト憲章作成 プロジェクト・スコープ記述書暫定版作成
- 57. 計画プロセス群 プロジェクトマネジメント計画書作成 スコープ計画 リスク・マネジメント計画 スコープ定義 リスク識別 ＷＢＳ作成 定性的リスク分析 アクティビティ定義 定量的リスク分析 アクティビティ順序設定 リスク対応計画 アクティビティ資源見積もり 購入・取得計画 アクティビティ所要期間見積もり 契約計画 スケジュール作成 コスト見積もり コストの予算化 品質計画 人的資源計画 コミュニケーション計画
- 58. 実行プロセス群 プロジェクト実行の指揮・マネジメント 品質保証 プロジェクトチーム編成 プロジェクトチーム育成 情報配布 納入者回答依頼 納入者選定
- 59. 監視コントロールプロセス群 プロジェクト作業の監視コントロール 統合変更管理 スコープ憲章 スコープコントロール スケジュールコントロール コストコントロール 品質管理 プロジェクト・チームのマネジメント 実績報告 ステークホルダー・マネジメント リスクの監視コントロール 契約管理
- 60. 終結プロセス群 プロジェクト終結 契約終結
- 62. ３章 プロジェクトマネジメント知識エリ ア
- 63. 知識エリア 8つの知識領域，1つの統合領域
- 64. プロジェクト統合マネジメント プロジェクト憲章作成 プロジェクト・スコープ記述書暫定版作成 プロジェクトマネジメント計画書作成 プロジェクト実行の指揮・マネジメント プロジェクト作業の監視コントロール
- 65. プロジェクトスコープマネジメント スコープ計画 スコープ定義 ＷＢＳ作成 スコープ憲章 スコープコントロール システム化提案書 ソフトウェア要求仕様書
- 66. スコープ 成果物スコープ プロダクト，サービス，所産に特有の特性や機能 プロジェクトスコープ 規定された特性や機能を持つプロダクト，サービス，所 産等を生み出すために実行しなければならない作業
- 67. スコープ定義のアウトプット プロジェクト目標 成果物スコープ記述書 プロジェクトに対する要求事項 プロジェクトの境界 プロジェクトの要素成果物 成果物受け入れ規準 プロジェクトの制約条件 プロジェクトの前提条件
- 68. WBS Work Breakdown Structure プロジェクト フェーズ サブプロジェクト 要素成果物 ワークパッケージ アクティビティ
- 69. タイムマネジメント アクティビティ定義 アクティビティ順序設定 アクティビティ資源見積もり アクティビティ所要時間見積り スケジュール作成 スケジュールコントロール PERT図
- 70. コストマネジメント コスト見積もり コストの予算化 コストコントロール （ソフトウェアの場合は貢献時間 （人月）） EVM
- 71. 品質マネジメント 品質計画 品質保証 品質管理 レビュー，インスペクション，テスト単位
- 72. 人的資源マネジメント 人的資源計画 プロジェクトチーム編成 プロジェクトチーム育成 プロジェクトチームのマネジメント 組織 コーチング
- 73. コミュニケーションマネジメント コミュニケーション計画 情報配布 実績報告 ステークホルダーマネジメント 環境分析 情報媒体の選定
- 74. リスクマネジメント リスクマネジメント計画 リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 リスクの監視コントロール リスク=不確定要素
- 75. 調達マネジメント 購入・取得計画 契約計画 納入者回答依頼 納入者選定 契約管理 契約終結
- 76. まとめ プロジェクトの性質 有期性，独自性 プロジェクトマネジメント QCD+R PCDAプロジェクトマネジメントプロセス PMBOK ９つのマネジメント領域 スコープマネジメント タイムマネジメント コストマネジメント 品質マネジメント ＨＲマネジメント コミュニケーションマネジメント 調達マネジメント リスクマネジメント 統合マネジメント
- 77. XP eXtreme Programming by Kent Beck 第3版 CreW Creative Workspace
- 78. 題材 XP エクスストリーム・プログラミング入門 ソフトウエア開発の究極の手法 ケントベック著 Embrace Change - 変化ヲ抱擁セヨ 訳および参考： http://www.objectclub.jp/community/XP- jp/xp_relate/xp-intro CreW Creative Workspace
- 79. XPとは ライト級 優れている 低リスク 融通が利く 予期可能 科学的 楽しく行える CreW Creative Workspace
- 81. 4つの変数 コスト 時間 品質 スコープ CreW Creative Workspace
- 82. スコープに着目する スコープは変動の大きい変数 最初のうちは要求は決して明確でない．ユーザは 決して欲しいものを正確に伝えてはくれない ソフトウエアの一部分が完成すると，要求は変 わっていく スコープは4つの変数のうちで最も管理しやすい もの やりすぎないようにすることで，必要な品質を時間 通りに生産する能力を温存する CreW Creative Workspace
- 83. ４つの価値 コミュニケーション プロジェクトの問題とは，重要なことを他の誰かに相談 しないことから起こる シンプル 動作させるために，もっともシンプルなものは何か フィードバック 私に聞くな，システムに聞け もうあれのテストケースは書いたのか 勇気 膿の除去 コードを捨て去る CreW Creative Workspace
- 84. 基本原則 瞬時のフィードバック シンプルの採用 インクリメンタルな変更 変化を取り入れる 質の高い作業 CreW Creative Workspace
- 85. 質の高い作業 学ぶことを教える 少ない初期投資 オープンで正直なコミュニケーション 人の本性に背かず，本性に沿った仕事 責任の受容 現状への適用 軽い旅 役に立つ測定 CreW Creative Workspace
- 86. 12のプラクティス 計画ゲーム(The Planning Game) 小さなリリース(Small Releases) メタファー(Metaphor) シンプルデザイン(Simple Design) テスティング(Testing) リファクタリング(Refactoring) ペアプログラミング(Pair Programming) 共同所有権(Collective Ownership) 継続的インテグレーション(Continuous Integration) 週40時間(40-Hour Week) オンサイト顧客(On-Site Customer) コーディング標準(Coding Standards) CreW Creative Workspace
- 87. 計画ゲーム ビジネス優先度と技術的見積により次回リリース の範囲を早急に決める． スコープ プライオリティ リリースの構成 リリースの日付 見積もり 結果 プロセス 詳細なスケジュール CreW Creative Workspace
- 88. 小さなリリース 新バージョンを非常に短いサイクルでリリー ス． (スパイラル型，イテレーション型) CreW Creative Workspace
- 89. メタファー システムの動きを示すメタファーを共有． コトバの共有 CreW Creative Workspace
- 90. シンプルデザイン シンプルに設計．余分な複雑さは悪． 正しいソフトウエア設計は以下のものである すべてのテストが通る 重複したロジックがない．並列のクラス階層のような隠 れた重複に気をつける． プログラマにとって重要な意図がすべて述べられてい る． クラスの数とメソッドの数が最低限になっている CreW Creative Workspace
- 91. テスティング プログラマは継続的にユニットテストを書く． 顧客は機能テストを書く。 すべてのメソッドに対してテストを書く必要はな い．ブレイクされる可能性のある運用対象の コードだけでよい CreW Creative Workspace
- 92. リファクタリング システムの動作を変えることなくシステムを 再設計． 1分しかかけないひどいコード vs 10分かけたよいコード CreW Creative Workspace
- 93. ペアプログラミング コードは２人のプログラマにより一台のマシ ンで． このアプローチ全体はうまくいくのか． うまくいかない他のテストケースは何か． 現在の問題を解決するためにシステム全体を シンプルにする方法はあるのか． CreW Creative Workspace
- 94. 共同所有権 誰でもどのコードでも修正できる。 コードに価値を付加できることに気づいた 人が，いつでも修正を行える． CreW Creative Workspace
- 95. 継続的インテグレーション 一日に何回もビルドし，テストを 100% パ スさせる． テストを100％実行することができないのなら， やったことを放り投げて，最初からやり直すべ きだ．なぜなら，プログラムの機能を実装する だけの十分な知識が無かった，ということだか らだ．（次は十分理解しているだろう） CreW Creative Workspace
- 96. 週40時間 週４０時間以上の仕事はよい結果を生まな い． CreW Creative Workspace
- 97. オンサイト顧客 顧客をフルタイムでチームに加える． 本当のユーザを加える 本当のユーザというのは，運用されるシステムを実 際に使う人のことである CreW Creative Workspace
- 98. コーディング標準 全プログラマがコーディング標準に従う． 規約はチーム全体に自発的に採用されないと いけない． CreW Creative Workspace
- 99. その他 管理戦略 測定値 コーチング トラッキング 介入 ファシリティー戦略 ホワイトボードなど，アナログ道具 CreW Creative Workspace
- 102. 参考文献 パーソナルソフトウエアプロセス入門 チームソフトウェア開発ガイド―Team Software Processによる開発のすべて http://www.atmarkit.co.jp/aig/04biz/cmm.html http://www1k.mesh.ne.jp/tdc/techno/info/2001/7/c mm_1.htm
- 103. はじめに CMM CMM（Capability Maturity Model） ソフトウェア能力成熟度モデル もともとは、 ワッツ・S・ハンフリー（Watts S. Humphrey）教授が著 した「Managing the Software Process」を下敷きに、 カーネギーメロン大学のマーク・C・ポーク（Mark C. Paulk）氏、ビル・カーティス（Bill Curtis）氏らが改良を 加えて作られた、ソフトウェア開発能力の成熟度を測る 「ソフトウェア能力成熟度モデル：SW-CMM」 が元祖である。
- 104. CMM 成熟度モデル ●レベル１（最低レベル） 組織的管理が何もなされていない。 組織的な開発プロセスや管理プロセスが存在しないため、プロ ジェクト管理は個人の能力に任せられてしまう。 ●レベル２ プロジェクトを計画し、それに基づいて実行している。 つまり、管理している状態で、あるプロジェ クトで経験したことが次のプロジェクトに生かせる 体制が整備されているという状態です。 ＜実行を求められる内容＞ １．要件管理 ２．プロジェクト管理 ３．ソフト進捗管理 ４．ソフト外注管理 ５．ソフト品質保証 ６．構成と変更管理 ●レベル３ ● 定義をしている。 組織の標準プロセスがあり、それを適宣変更しながらプロジェクトを実行し、 組織的にプロセスを 改善している。つまり、ソフト開発のプロセスを向上させるために社員を啓蒙するプロセスを 定義・ 確立し、訓練することに重点を置いてます。 ● レベル４ 定量的に管理されている。 プロセスを定量的に把握でき、プロジェクトに即座にフィードバックできる。 ● レベル５ 最適化している。 レベル自発的にプロセスを改善できる。
- 105. PSP（Personal Software Process）とは？ 自分のソフトウェア開発の手順を特徴づけるための 計測と分析の枠組 自分のパフォーマンス（効率・遂行能力）を改善す る手続き
- 106. 1. PSP（Personal Software Process） ソフトウェア技術者の仕事 作業計画を立案する この計画に従って作業を行う 最高の品質の製品を開発するよう努力する PSPを身につけると 以下のことができるようになる 仕事の見積もりと計画 コミットメントの遵守 無理なコミットメントを押し付けられることへの抵抗 また，自分の能力を理解するようになり，能力改善がよ り上手にできるようになる ※コミットメント（Commitment）：～するという約束
- 109. 改善プロセス
- 110. PSPのステップ① PSP3 循環的開発 PSP2 PSP2.1 コードレビュー 設計テンプレート 設計レビュー PSP1 PSP1.1 タスク計画立案 規模見積り スケジュール計画立案 テスト報告t PSP0 PSP0.1 ｺｰﾃﾞｨﾝｸﾞ標準 現行プロセス 規模測定 時間記録 プロセス改善提案 (PIP) 欠陥記録 欠陥型標準
- 111. PSPのステップ② PSP0 - パフォーマンスの，計測されたベースライン を確立する PSP1 - 規模，資源，およびスケジュールの計画をす る PSP2 - 欠陥管理と摘出率管理を実習する PSP3 - PSP手法をより大規模なプロジェクトにス ケール アップする
- 112. PSP0のプロセス 現在使っている設計開発方法を使用する 仕事に関して，以下のデータを収集する 工程毎に使用した時間 コンパイルおよびテストで発見された欠陥の数 プロジェクト計画概要を作る
- 113. 3. 時間の追跡 時間記録ログ
- 114. 時間の追跡：補足 単位には分を使用する
- 115. 4. 期間計画と製品計画
- 116. 6. 製品の規模 LOC = Line ofCommand (命令行，次のスライドで解説）
- 117. LOC（Line Of Command）について補足 空白行・コメント行を含めないプログラムの行数 以下のプログラムは7LOCとなる /** * 引数に与えられた文章の単語数を計算する */ private int wordCount(String text) { // 例文から，1文字ずつ切り出して処理する for (int i = 0; i < text.length(); i++) { char ch = text.charAt(i); // 切り出す1文字 processCharacter(ch); } return numberOfWords; }
- 118. 規模見積もり
- 119. 9. スケジュール管理
- 120. （実績）
- 121. 12. 欠陥の記録
- 122. 欠陥の記録 補足 作りこみ →作りこんだ工程 除去 →除去した工程 修正中の欠陥 →無視してよい
- 123. 欠陥型 型番号 型名 説明 10 文書 コメント，メッセージ 20 構文 スペル，区切り記号，タイプミス，命令形式 30 ビルド，パッケージ 変更管理，ライブラリ，バージョン管理 40 割り当て 宣言，重複名，スコープ，限度 50 インタフェース 手続きの呼び出しと参照，I/O，ユーザ書式 60 チェック エラーメッセージ，不適切なチェック 70 データ 構造体，内容 80 機能 論理，ポインタ，ループ，反復，演算，機能欠陥 90 システム 構成，タイミング，メモリ 100 環境 他の支援システムの問題
- 124. プロジェクト計画
- 125. まとめ PSPとは 自分のソフトウェア開発の手順を特徴づけるための計測と分析 の枠組 自分のパフォーマンス（効率・遂行能力）を改善する手続き PSPのプロセス 時間の追跡 欠陥の追跡と分析 規模見積もりと測定（LOC） スケジュール管理 プロジェクト計画（見積もり） 注意点 PSPは記録を取ることだけではなく，記録を分析をして改善し ていくプロセス全体をさしている．
- 126. 1 2006/05/07(sat) Rational Unified Process 大岩研究会Ⅱ 勉強会 担当： 杉浦 学（政策メディア研究科 博士課程）
- 127. 2 読んでおくとよい本 • UMLによる統一ソフトウェア開発プロセス – I.ヤコブソン，G.ブーチ，J.ランボー – 翔泳社 2000年 • ラショナル統一プロセス入門 ～第２版～ – F.クルーシュテン – ピアソン・エデュケーション 2001年 • オブジェクト指向とコンポーネントによるソフ トウェア工学 – P.スティーブンス – ピアソン・エデュケーション 2000年
- 128. 3 勉強会の学習目標 • ソフトウェア開発プロセスとは何かを説 明できる • RUPの3つの特徴（の概要）を説明でき， 簡単な開発例で実践することができる • 過去に経験したソフトウェア開発プロセ スとRUPの違いを比較検討できる
- 129. 4 勉強会の流れ • 1.ソフトウェア開発プロセスとRUP – 1.1 ソフトウェア開発プロセスとは何か – 1.2 RUPとは何か • 2. RUPの3つの特色 – 2.1 特色の概略 – 2.2 基本概念の整理 – 2.3 「ユースケース駆動」とは何か – 2.4 「アーキテクチャ中心」とは何か – 2.5 「反復的でインクリメンタル」とは何か
- 130. 5 1.ソフトウェア開発プロセスとRUP
- 132. 7 東京タワーの作り方 • 東京タワーの作り方 – 設計 – 基礎工事 – 土台のアーチ部分 – 上部の塔 – アンテナ設置 ※下から上へ • 力学法則に逆らわない – ではソフトウェアは？
- 133. 8 ソフトウェアの作り方 • ソフトウェアはどのように開発しても良い？ – ソフトウェア開発には力学法則の制約がない • だからこそ，どう開発するかが重要 • 上手くいくソフトウェア開発の典型例がある – 多くのソフトウェア開発において上手くいった作り 方のパターンが見つかってきた • ベストプラクティス • 体系的ソフトウェア開発プロセスに従う – 失敗することなく高品質のソフトウェアが作れる
- 134. 9 こんな経験はありませんか？ 1. ソフトウェアを作ろうとしたが，そもそ も完成しなかった 2. 完成したソフトウェアを動かしたときに， バグが出た 3. グループで開発したときに，役割分担が 上手くいかなかった 4. 開発したソフトウェアを誰も使ってくれ なかった
- 135. 10 開発プロセスとは何か？ • ソフトウェア開発プロセスのモデル化 – 全てのソフトウェア開発に当てはまるメタモデル Process Input Output 要求 開発プロセス 成果物 資源 Resource
- 136. 11 「要求」の定義 • 要求（requirements）の定義 – 特定の問題を解決するために開発，あるいは 適用するシステムで実現すべき性質 • システムを使用する人の仕事の一部を自動化 • 既存のシステムの欠陥の修正 • デバイスの制御 など ※松本訳：「ソフトウェアエンジニアリング基礎知識体系：SWEBOK」より
- 137. 12 「要求」の種類 • 要求は大きく2つに分類できる – 1. プロダクトパラメータ • システムの機能要求 – 文書を整形する，信号を調節する・・・ • システムの非機能要求 – 性能，保守容易性，安全性要求，信頼性要求・・・ – 2. プロセスパラメータ • システム開発に対する制約 – プログラミング言語，納期，予算・・・
- 138. 13 「成果物」の定義・種類 • 成果物（artifacts）の定義 – ソフトウェア開発プロセスで作成する全ての もの • 成果物の種類 – 文書 • 自然言語で記述する各種の文書 – モデル • オブジェクト指向開発ではUMLを用いて記述する – ソフトウェア • ソースコード，実行ファイル，設定ファイル
- 139. 14 「資源」の定義・種類・性質 • 資源（resources）の定義 – ソフトウェア開発プロセスで使用する全ての もの • 資源の種類 –人 – ハードウェア，ソフトウェア • 資源の性質 – 資源を利用するとコストが発生する
- 140. 15 1.2 RUPとは何か
- 141. 16 個人によるソフトウェア開発 • 日曜大工プログラミング 要求は 頭の中 デザイン 成果物はソ フトウェア 資源は プログラミング 個人 ※参考：羽生田 http://www.atmarkit.co.jp/fjava/devs/process01/process01.html
- 142. 17 大規模ソフトウェア開発 • ウォーターフォール型 要求分析 成果物と 要求を「仕様 設計 して文書 書」にする工程 を作成 実装 資源は 試験 大人数 運用
- 143. 18 ウォーターフォール型の問題 • ウォーターフォール型開発ではフェーズを後戻 りすることができない • 結果，リスクコントロールができない – フェーズ毎に正しい成果物を出さなくてはならない • 誤った成果物からは誤った成果物が生まれてしまう – 開発の途中で起こる外部環境の変化に対応できない • 技術の進歩，要求の変化・・・
- 144. 19 ソフトウェア開発手法の重要性 • ソフトウェアが大規模で、複雑になった – コンピュータの性能向上 • マルチメディア、インターネット – ユーザの期待の増大 • 新しいソフトウェアを早く手に入れたい • ソフトウェア「開発手法」が非力である – 『ほとんどのソフトウェアの開発には、25年近くも 前に使われていたのと同じ方法が用いられている』 – この方法を刷新する必要がある
- 145. 20 必要なプロセス • ソフトウェア開発のアプローチ – チームが守るべき開発手順のガイドラインを 提供する – 個々の開発者やチーム全体の作業を指示する – 開発すべき成果物を規定する – プロジェクトの最終成果物と作業を監視およ び測定するための基準を提供する
- 146. 21 UPの概要 • ソフトウェア開発「プロセス」とは？ – ユーザーからの要求をソフトウェアシステムに変換するために 必要な、一連の作業のこと • 統一プロセス – 汎用のプロセスフレームワーク – コンポーネントベース – UMLを使用する • 特色 – ユースケース駆動 – アーキテクチャ中心 – 反復的でインクリメンタル
- 147. 22 RUPとUPの違い • RUPはスリーアミーゴによる汎用的なプロセス であるUPを具体化し，詳細に肉付けしたもの – UPは概念的である • RUPはIBMの商用製品 – RationalをIBMが買収したため • この勉強会ではRUP≒UPとして扱う
- 148. 23 UPの沿革 • オブジェクト指向のスリーアミーゴ – G.ブーチ，J.ランボー，I.ヤコブソン • UMLの標準化（1997年） – スリーアミーゴが提唱していたそれぞれのオブジェクト指向モ デリングの「表記法」を統一 • どう記述するか≠どう開発するか • 統一プロセス（1998年） – スリーアミーゴがRational社に結集して構築した開発プロセス • オブジェクト指向でソフトウェアをどう開発するか
- 149. 24 オブジェクト指向のスリーアミーゴ Ivar Jacobson ユースケースの提唱 Grady Booch James Rumbaugh Booch法の提唱 OMT法の提唱
- 150. 25 UPの成立まで • 1987年 Objectory AB社 – エリクソン（電話・通信技術で有名）の技術者だっ たヤコブソンが独立して設立 • ユースケースの概念を含むObjectoryプロセスを開発 • 1995年 Rational社がObjectoryを買収 – Rational社のブーチがヤコブソンを招き入れる • ランボーは1994年にRational社へ – Rational Objectory Processの商品化 • アーキテクチャ中心主義，反復型開発の導入
- 151. 26 UMLの成立とUP • 1997年 UMLバージョン1.1標準化 – Rational Objectory ProcessにもUMLを導入 • 1998年の6月 – Rational Unified Process（RUP）のリリース
- 152. 27 開発プロセスの硬軟比較 • 伽藍（がらん）とバザール – Eric S. Raymond: ``The Cathedral and the Bazaar’’ • 伽藍型 – 大聖堂を建てるように、ソフトウェアを中央集権的に開発する 方式 • バザール型 – 『誰もが開発に参加できるようにソースを公開し、外部の優秀 なエンジニアたちを大勢巻き込み、みんなで騒々しくソース コードをいじり倒して、わーっと作っていくやり方』 （参考：津田 http://www.atmarkit.co.jp/farc/rensai/build01/build01.html）
- 153. 28 エクストリームプログラミング • エクストリームプログラミング（XP）とは – Kent Beckが体系化したソフトウェア開発のベストプラクティ ス集 • Agile（俊敏な）開発 – 小さなプロセス＝プラクティスの集合 – プロセスよりも人間的側面を重視 • コミュニケーション，シンプルさ，フィードバック，勇気 • 特徴 – 変化ヲ抱擁セヨ（embrace change） – 最初にテスト（test first）
- 154. 29 なぜ統一プロセスなのか？ • ソフトウェア開発の現実 – バザール型開発が上手くいくのは，ソフトウェアの 利用者が開発者自身であるとき – XPが上手くいくのは優秀な開発者のみでチームを組 む幸運に恵まれたとき • 統一プロセスを学ぶ利点 – 開発プロセスのデファクトスタンダード • 将来，皆さんが使用する可能性が高い – プロセス定義の柔軟性 • 目的に応じて大規模・小規模の両方に対応
- 155. 30 演習 No.1 • これまで経験したソフトウェア開発プロ セスを振り返ってまとめてみましょう • どんなソフトウェアを開発した？ • 何人で開発した？ 役割分担は？ • 納期は？ • どんな成果物を作った？ • どんな手順でどんな作業をした？
- 156. 31 2. RUPの3つの特色
- 157. 32 2.1 特色の概略
- 158. 33 UPの3つの特色 • 1. ユースケース駆動 • 2. アーキテクチャ中心 • 3. 反復的でインクリメンタル
- 159. 34 ソフトウェアとユーザー • ソフトウェアシステム – ユーザーにサービスを提供することが目的 – ユーザが何を希望し、何を必要としているか？ • ユーザー – 開発対象のシステムと相互作用する人またはもの • ユースケース – ユーザに価値のある結果をもたらすシステムの機能 の一つ – すべてのユースケースをまとめたものがユースケー スモデル
- 160. 35 機能仕様書とユースケース • 機能仕様書 – 「システムは何を行なうものなのか」という質問に 対する回答 • ユースケース – 「【各ユーザに対して】システムが何を行なうもの なのか」という質問に対する回答 – ユーザにとっての「価値」に留意する • ユースケースの目的 – 開発プロセスそのものを駆動する • システムの要求を定義する • ユースケースを満足するように、設計、実装、テストをする
- 161. 36 アーキテクチャ • アーキテクチャとは？ – ビル（建築物）のアーキテクチャ • 構造、サービス、暖房装置、下水道、電気など – 橋のアーキテクチャ • つり橋、めがね橋、浮橋、など • ソフトウェアアーキテクチャ – 詳細を省いた設計全体の重要な特徴をより明 確に表したもの • システムの最も重要である、静的・動的な側面を 具体的に表現したもの
- 162. 37 ユースケースとアーキテクチャ • ユースケースとアーキテクチャは密接する – ユースケース⇔アーキテクチャ 相互に影響 • どのような製品にも機能と形状がある – ユースケースは機能 – アーキテクチャは形状 • 両者は共に進化する – ユースケースを実現するために、アーキテクチャに 当てはめる – アーキテクチャは、将来求められることが予想され るユースケースを実現できる拡張性を備える必要が ある
- 163. 38 アーキテクトの作業 • アーキテクトが行なう作業 – アーキテクチャのアウトラインを、ユース ケースに関連しない部分から決定 • ソフトウェアのドメインを深く理解し、一般性の あるアーキテクチャを決定する – システムの鍵となる機能を表す一部のユース ケースを詳細化する • ユースケースの詳細を定義することにより、アー キテクチャのより深い部分が明確になる – アーキテクチャが安定になったと思えるまで、 このプロセスを続ける
- 164. 39 反復的でインクリメンタル • 商用ソフトウェアの開発は大規模である – 開発期間は数ヶ月～1年以上 – 小さなかたまり（ミニプロジェクト）に分割 する • ミニプロジェクトとは「拡張変更差分」 を産み出す反復 – 反復・・・ワークフローを構成する作業フ ローの集合 – 拡張変更差分・・・ソフトウェアの機能追加 部分
- 165. 40 反復で行なうこと • 各反復で何を実装するか？ – ユースケースを追加する – 最も重大なリスクの解決 • 反復における作業 – 関連するユースケースを定義 – 選択したアーキテクチャに基づき設計図を作成 – 設計をコンポーネントで実装 – コンポーネントがユースケースを満たすか確認する →次の反復へ
- 166. 41 反復を管理する利点 • 管理しながら反復する利点 – １回の反復における拡張変更差分に要する費用リス クを削減できる • 見込み違いの反復をしてもその労力だけが損失となる – 製品をスケジュールどおり投入できる • 開発の初期にリスクを洗い出すことで，切迫感の少ないプロ ジェクトの前半にリスクを解決ができる • 従来のアプローチでは大変な問題が試験工程で露呈 – 短期で目標の明確な反復を管理の単位にできる • 長期間にわたる，遅延しがちなスケジュールではなく – 前もって確定していないユーザのニーズに対応でき る • 変化する要求に追随できる
- 167. 42 統一プロセスの開発サイクル • ソフトウェアのライフサイクル – ソフトウェアは誕生（最初のリリース）から死（使 用を止める）までのライフサイクルがある • サイクルとリリース – 統一プロセスではライフサイクルを細かい「サイク ル」に分けて管理する • 各サイクルはソフトウェアを「リリース」すると終了 • サイクルとフェーズ – 一つのサイクルは，4つのフェーズからなる • 方向付け，遂行，作成，移行 • フェーズと反復 – 一つのフェーズで，何回か反復を行なう
- 168. 43 サイクルと反復
- 169. 44 フェーズとワークフロー
- 170. 45 方向付けと推敲フェーズ • 方向付けフェーズ – アイディアを最終的な製品の構想へと展開し，開発 企画書を提示する • 主要なユーザに対してシステムが主に行なうことは何か？ • システムのアーキテクチャはどのようなものか？ • 製品を開発するための計画はどのようなもので，その費用は どの程度か？ • 推敲フェーズ – 製品のユースケースの大半を詳細に渡って定義し， システムアーキテクチャを設計する • アーキテクチャベースラインの確定 • このフェーズの終わりにプロジェクト管理者は作業の計画を 立案し，プロジェクトを完成させるのに必要なリソースを見 積もる
- 171. 46 作成と移行フェーズ • 作成フェーズ – 製品を構築する • 骨格（アーキテクチャ）に筋肉（ソフトウェアの完成形）を肉付け する • 必要なリソースの大半をこのフェーズで消費する • 製品がユーザのニーズを満たした段階で終了する – ベータリリース • 移行フェーズ – ベータリリースを少数ユーザで試用し，欠陥と障害を発見する • より広範囲な一般ユーザ向けに対するリリースを目指す • 製造と書きゃ臭いどの担当者のトレーニング，ヘルプデスクの開設， 欠陥の修正 • マイルストーンとは？ – 各フェーズが終了する期日
- 172. 47 製品とはなにか？ • ソフトウェアの利害関係者 – 顧客，ユーザー，分析者，設計者，実装担当者，テ スト担当者，管理職 • リリースする製品 – ソフトウェアとマニュアル，付属品 – その他，全ての利害関係者のニーズを満たすもの • 製品には次の開発サイクルに必要となるものを 全て含むようにする – ソフトウェアを取り巻く環境変化に対応するために
- 173. 48 統一プロセスで作成するモデル ※この他に「ビジネスモデル」を含む場合もある
- 174. 49 2.2 基本概念の整理
- 175. 50 プロジェクトに関連する用語 • 開発要員 – ソフトウェアプロジェクトの主な原動力 • アーキテクト，開発者，テスト担当者，管理職 • ユーザ，顧客，その他の利害関係者 • プロジェクト – ソフトウェアを管理する組織要素 • 製品 – プロジェクトの存続中に作成する成果物 • プロセス – 要求を製品へと変換するために必要な作業のテンプレート • ツール – プロセスを自動化するために使うソフトウェア
- 176. 51 開発要員に与える影響 • プロジェクトの編成と管理は開発要員に影響を与える – 実現可能性 • 実現不可能と思われるプロジェクトは開発要員のモチベーションを 下げる – リスク管理 • リスク分析を行なわないと開発要員は不安になる – チーム編成 • ６～８人の小さいグループが効果的 – スケジュール • 現実的なスケジュールを組まないと人の意欲が低減する – 理解しやすさ • 自分が何をしているのかを分かるようにする – 達成感 • 速い作業ペースと作業のフィードバックを得ることにより，メン バーの達成感が高まる
- 177. 52 開発プロセスと開発要員 • ソフトウェアの高度化 – 効果的で標準的な開発プロセスが必要 • 市場への投入時間，品質，コスト • ユーザーニーズの満足 • 経済性の高さ • より複雑なシステム • ソフトウェア開発の中心は開発要員 – 開発を進めるガイダンスが必要 • 複雑なビジネスを理解して支援するには多くの開発者が共同 作業を行なうことになる • 首尾一貫した方法
- 178. 53 リソースからワーカーへ • ワーカーとは？ – 開発要員が果たす役割のこと – 割り当てられた一連の作業全体に対して責務を担う • 情報共有と，他のワーカーとの役割分担を理解しておく必要 がある • リソースからワーカーへ – リソース（現実の開発要員）のスキルを，プロジェ クトで必要とするワーカーの能力と照合する • 必要に応じてトレーニングを行なう
- 179. 54 ワーカーを実現するリソース • ワーカーは個人又はグループによって実現 – ワーカー＝クラス – 個人又はグループ＝インスタンス
- 180. 55 プロジェクトパターンの認識 • 開発プロジェクトの構造パターン – プロジェクトチームはソフトウェアライフサイクル において発生する構造的パターンを認識しておく必 要がある • パターンの認識 – 一連の変更 • 各サイクル，フェーズ，反復で何が変わるのか – 一連の反復 • 各反復で実施するワークフローは何か – 構造的なパターン • プロセスが必要とするワーカーの種類と成果物
- 181. 56 ソフトウェアシステムとは？ • 統一プロセスが定義するシステム – ソフトウェア（バイナリ及びソースコード） – 設計（ＵＭＬによるモデルなどの成果物） – その他（要求，テスト，販売，製造，導入，運用） • システムとは，システムを統一プロセスのワーカーに対 して説明するための全ての成果物である – マシンに対して・・・ツール，コンパイラ，コンピュータ – ワーカーに対して・・・管理職，アーキテクト，テスト担当者， 市場調査担当者，システム管理者，その他 – 利害関係者に対して・・・資金の提供者，ユーザー，販売担当 者，プロジェクト管理者，工程管理者，製造担当者，調査機関
- 182. 57 統一プロセスの成果物 • 成果物（artifact）の例 – UMLによる図と文書，ユーザーインタフェイ スのスケッチ，プロトタイプ，テスト計画書， テストプロシージャー・・・ • 成果物の種類 – エンジニアリング成果物 • 統一プロセスの開発プロセスの各フェーズの成果 – 管理成果物 • 開発企画書，開発計画書，開発要員割り当て計画， 作業割り当て計画，開発環境の仕様書
- 183. 58 複数のモデルでシステムを記述 • システムの異なる全ての側面をさまざまなモデルを使っ て記述する – ワーカーによってシステムを捉える観点が異なる – 使用するモデルの決定は最重要決定事項の一つである • モデルとは？ – システムを抽象化したものであり，対象にするシステムを一定 の視点及び一定の抽象レベルで表したもの • モデルの視点の例 – 機能要求をモデリングするワーカーは，システムの外部にユー ザがあり，システムの内部にユースケースがあるとしてシステ ムを眺める – 設計を担当するワーカーは，サブシステムやクラスといった構 造的要素について考える
- 184. 59 自己充足したビューとは？ • モデルの自己充足とは – モデルを理解しようとした場合に他の情報を必要と しないこと • モデルで記述してあるイベントがトリガーされたときに，シ ステムで起こりうる解釈が１つだけしかないこと • システムの外界との相互作用が記述してあること • ビューを表すモデルの自己充足 – ユースケースモデルの場合 • アクターからの外部刺激によって何が起こるか示すビュー – 設計モデルの場合 • サブシステムとクラスがどのように相互作用するのか示す ビュー
- 185. 60 モデルの構造 • あるモデルは別のモデルを格納する – 最上位サブシステムのモデル • 最上位サブシステムのユースケースはシステム全 体を表現する – 最上位サブシステムは下位の複数のサブシス テムからなる • サブシステム毎に設計モデルがある • 全てのモデルには関係がある – 関連に従い，各モデルを追跡することができ る
- 186. 61 プロセスとプロジェクト • 統一プロセスにおけるプロセスとは？ – ソフトウェア開発ビジネスの中の鍵となる 「ビジネスプロセス」 • ソフトウェアを開発し，サポートする活動 • プロセスとテンプレート – プロセスとは概念としての雛形であり，イン スタンスを作成することによって再利用でき る • プロセスのインスタンス＝具体的なプロジェクト
- 187. 62 ワークフローとプロセス • ワークフローは一連の作業 – プロセスはワークフローからなる • ワークフローはサブプロセスではない • ワークフローの定義 – ワーカーは誰か？ – ワーカーは何を作成するのか？ • 成果物を定義 ※「どう作成するのか（＝サブプロセス）」に ついては定義しない
- 188. 63 要求ワークフローの例
- 189. 64 プロセスの特化 • 何にでも適用できる開発プロセスはない – さまざまな状況，さまざまなタイプのシステム，さ まざまな制約・・・ – ソフトウェア開発プロセスは特定のプロジェクトや 組織，ニーズを満たすように構成できなくてはなら ない • 異なるプロセスになる要因 – 組織，領域，ライフサイクル，技術 • 統一プロセスの特化 – ワーカーや成果物を組織に合わせて変更する • 簡略化，詳細化，追加，削除など
- 190. 65 プロセスの利点 • 開発チームがプロセスを共有することで， – チーム全員が，製品を開発するために何をすべきか 理解できる – 時間的，地理的制約などを超えてほかの開発者が何 をやっているかが理解できる – 指導者や管理者が，アーキテクチャの図面を見るこ とで開発者が何をしているか理解できる – 部門間の移動が容易になる – トレーニングを標準化できる – 確度の高いスケジュールとコストを見積もることが できる
- 191. 66 プロセスに不可欠なツール • ツールのサポートがあることで， – プロセスを形式化（定型化）できる – ツールなしでは不可能な新しい作業が導入で きる – 正確な作業が実施できる • プロセスとツールのバランス – プロセスを理解しないでツールを使っても無 駄 – プロセスを支援するツールはプロセスを促進 する
- 192. 67 ツールの活用 • UMLのビジュアルモデリング – ツールはUMLの構文規則を反映する • 一般のグラフィックソフトには備わっていない – モデリングツールを使うだけではプロセスは 実施できない • ユーザがプロセスを知ることで，ツールを使いこ なせる • 開発ライフサイクル全体のサポート – 要求管理，ビジュアルモデリング，プログラ ミングツール，品質保証
- 194. 69 統一プロセスの目標 • 顧客のニーズを満たすシステムを開発者が効率 的に実装し、導入できるようにする – プロジェクトに関与するすべての人に、ユーザーの ニーズを明確にする – ニーズを機能的に満たすソフトウェアを設計する – ソフトウェアがニーズを満たしていることをテスト する • 上記目標を達成するための「ユースケース駆 動」とはいかなるものか？
- 196. 71 UPにおける要求把握とは？ • 「要求把握」とは何か？ – ソフトウェアに対する真の要求を見つけ出す • ユーザの期待をうらぎらない価値ある機能 – 要求をユーザー、顧客、開発者に分かるように記述 する • ユースケースモデルで要求を把握する – システムに関与するアクター – アクターに価値をもたらすユースケース • アクターとユースケースの相互作用を記述 – ユーザとシステムとの間に起こる一連のアクション
- 197. 72 良い／悪いユースケース • 良いユースケースとは？ – システムを配備したビジネスに最高の価値をもたら すもの • 悪いユースケースとは？ – ユーザーが行なってはならないようなことを可能に する • 濫用ケース（abuse case） – だれも使わない機能 • 不要ケース（use-less case） • 「機能リスト」の問題 – 機能リストには、悪いユースケースが含まれる可能 性がある
- 198. 73 ユースケースモデルの性質 • 簡単である – ユースケースモデルの表記は簡単である – 詳細を自然言語を用いて記述することができ る • 完全な仕様書である – システムの利用方法の全てを表現できる • 顧客との契約書の一部として使うことができる – システム境界を定義する
- 199. 74 ユースケースの実現 • ユースケースの実現（realization）の過程 – 要求ワークフロー • ユースケースモデルを作成する – 分析ワークフロー • ユースケースモデルから分析モデルを作成する – 設計ワークフロー • 分析モデルから設計モデルを作成する • 分類子（classifier） – 分析・設計モデルを記述するための表記法 • ユースケースの実現とは？ – ユースケースを分類子を用いて実現すること
- 200. 75 分類子とは？ • 分類子はクラスと同じ性質を持つ – 属性と操作がある – ステートチャートで振る舞いを記述できる – インスタンスを作成でき、コラボレーション に参加できる ∴分類子とは、分析・設計モデルを記述す るためのクラスの特別なビューである
- 201. 76 ユースケースモデルの例 • ATMシステムのユースケース – 「銀行顧客」アクターは、現金自動預払機（ATM）システムを 使って、講座の現金の引き出しと預け入れ、口座間の振り替え を行ないます。
- 202. 77 システムの環境としてのアクター • アクターで記述するもの – システムのユーザ – システムと相互作用するほかのシステムや外部ハー ドウェア • アクターは「役割」である – 一つのアクターは物理的に多数の人を示す • 例）銀行顧客アクターは何千人もいるはず – 物理的に一人の人が複数のアクターになりうる • アクターとシステムの相互作用 – アクターはシステムに対してメッセージを送受信す る
- 203. 78 「現金を引き出す」ユースケース • 現金を引き出す 1. 銀行顧客は、システムに自分が誰であるの か証明する 2. 銀行顧客は、システムで現金を引き出す口 座を選択し、その金額を指定する 3. システムは、銀行顧客に現金を払い出す
- 204. 79 機能外要求の定義 • 機能外要求とは – 性能、可用性、正確さ、安全性 • ユースケースは機能を定義すると同時に、 機能外要求の定義場所として使用できる • 「現金を引き出す」の場合 – 『銀行顧客が、引き出す金額を選択してから 現金を受け取るまでの応答時間は、９５％の ケースで３０秒以内であること』
- 205. 80 1. 分析モデルを作成する • インクリメンタルな分析モデル作成 – 各反復毎に、分析するユースケースを選ぶ – 選択したユースケースモデルの分析モデルを 作成する • 分析モデルによるユースケースの実現 – ユースケースを分類子の静的な構造として示 す – 分類子の動的なコラボレーションを定義する
- 206. 81 分析モデルの分類子 バウンダリ システムとアクターとの境界に位置するクラス コントローラ システム内で他のクラスを制御するクラス エンティティ システム内で永続性のある情報を表すクラス
- 207. 82 UCモデルと分析モデルの関係
- 208. 83 ATMの分析モデル
- 209. 84 コラボレーションによるUCの実現
- 210. 85 イベントフローによる記述 • 現金を引き出すユースケース（正常時） 1. 「銀行顧客」は、「現金出納インターフェイス」を 起動する 2. 「銀行顧客」は、「現金出納インターフェイス」に 自分の身元を証明し、口座と金額を指定する 3. 「現金出納インターフェイス」は、「引き出し」に 身元確認とトランザクションを依頼する 4. 「引き出し」は、「口座」に身元確認を依頼し、身 元が確認できたら、金額を引き出す 5. 「引き出し」は、「現金自動支払機」に対して金額 の払い出しを許可する 6. 「銀行顧客」は、「現金自動支払機」から現金を受 け取る
- 211. 86 イベントフローによる記述（補足） • 現金を引き出すユースケース（異常時） 1. 「銀行顧客」は、「現金出納インターフェイス」を 起動する 2. 「銀行顧客」は、「現金出納インターフェイス」に 自分の身元を証明し、口座と金額を指定する 3. 「現金出納インターフェイス」は、「引き出し」に 身元確認とトランザクションを依頼する 4. 「引き出し」は、「口座」に身元確認を依頼し、身 元が確認できなかったら、処理を中止する 5. 「引き出し」は、「現金出納インターフェイス」に 対して身元が確認できなかったことを伝える 6. 「銀行顧客」は、「現金出納インターフェイス」か ら身元確認ができなかったことを知る
- 212. 87 2. 設計モデルを作成する • 設計モデルで分析モデルを更に詳細化する • 分析モデルに対して技術要素を加味する – GUIの実装はどうするか？ – データベース管理システムは？ – ネットワークは？ – 既存システムの再利用は？ • 分析モデルと設計モデルの比較 – 分析モデルは概念的 • ユースケースという概念を実現する概念 – 設計モデルは物理的 • システムを実装する環境に適合する
- 213. 88 設計モデルの分類子 <<subsystem>> サブシステム クラスまたは他のサブシステムの グループ インターフェイス サブシステム同士を接続する点 アクティブクラス プロセスやスレッドなど，実際に活 動するクラス ※通常のクラスに比較して枠線が太い
- 214. 89 分析モデルと設計モデルの関係
- 215. 90 設計モデルのクラス図
- 216. 91 設計モデルのシーケンス図
- 217. 92 サブシステムによるグループ化 • 設計モデルの段階で大量のクラスが出現 することになる – サブシステムという単位を導入する • サブシステムとは？ – 設計クラスを意味的に分類したもの – 同じように変化する傾向のあるクラスをまと めたもの – オプション機能の管理単位
- 218. 93 サブシステムの例
- 219. 94 3. 実装ワークフロー • 実行可能なシステムを開発する – ファイルコンポーネント • ソースコード • スクリプト • バイナリコード – テーブルコンポーネント • データベース要素 • コンポーネントとは？ – 定義したインターフェースに基づき実装した，置換可能な物理 システム 注）UP（UML）におけるコンポーネントという用語の粒度 は，他のコンポーネントベース開発における粒度よりも 細かいので注意．他のコンポーネントベース開発では， 前述のサブシステムをコンポーネントと呼ぶことが多い
- 220. 95 実装モデル内のコンポーネント
- 221. 96 4. ユースケースに基づくテスト • ユースケースに基づくテストとは？ – システムがユースケースモデルの通りに動作 するか確認すること • テストモデル – テストケース • テスト入力，実行条件，予想結果の集合 – テストプロシージャ • 特定のテストケースの準備，実行，評価の実施方 法
- 222. 97 テストケースの例 • 現金を引き出すユースケースのテストケース – 入力 • 口座12-121-1211の残高は350ドルである • 銀行顧客の身元は正しいものとする • 銀行顧客は口座から200ドル引き出す • ATMには現金が200ドル以上ある – 結果 • 口座の残高は150ドルに減る • 銀行顧客はATMから200ドル受け取る – 条件 • このテストケースの途中には，他のどのユースケースもこの 口座にアクセスしない
- 223. 98 2.3 「ユースケース駆動とは」何か のまとめ • ユースケースはプロセスを駆動する – 要求はユースケースで表現する – 反復はユースケースを単位とする • ユースケースの実現 – 分析・設計では分類子（クラス）を用いて ユースケースを実現する – 拡張変更差分のコンポーネントを実装する – ユースケースに基づき，テストを行なう
- 224. 99 演習 No.2 • 配布した開発構想から，ユースケース駆 動で設計作業までを実践してください – UCを作成する – 分析モデルを作成する – 設計モデルを作成する
- 226. 101 アーキテクチャについて • システムにはアーキテクチャが必要である – ユースケースだけでは不十分 • UPにおけるアーキテクチャの位置づけ – 全ワーカーが同意できる共通の開発構想 – 最も重要なモデル要素で構成 • サブシステム、依存関係、インターフェイス、コラボレー ション、ノード、アクティブクラス • アーキテクチャは反復により開発されるもの – 方向付け・遂行フェーズの成果物 – 実行可能な「アーキテクチュラルベースライン」を 作成
- 227. 102 アーキテクチャを記述する • 建築物のアーキテクチャを記述 – 建物全体をいろいろな方向から見た図面を用いる • 建築物のアーキテクチャの例 – つり橋 • ベイブリッジ ・・・ 一般図 • 鶴見つばさ橋 ・・・ 一般図 • レインボーブリッジ ・・・ 一般図 – 他の橋 • アクアライン ・・・ 一般図 • ソフトウェアのアーキテクチャを記述 – システムのモデル全体をいろいろな観点から表現し たビューを用いる
- 228. 103 ソフトウェアアーキテクチャの特徴 • ソフトウェアのアーキテクチャの特徴 – 我々が生きている三次元世界のものではない ため、想像するのが困難 – 前例のない、独特のケースがある – 立証されていない技術や奇妙に融合した技術 – 将来的に大幅な変更がありえる
- 229. 104 例：Hibernateアーキテクチャ • Hibernateアーキテクチャの（非常に）高 いレベルからのビュー http://www.hibernate.org/hib_docs/reference/ja/html/architecture.html