現場で役立つシステム設計の原則 ch9 オブジェクト指向の開発プロセス
- 開発の進め方はオブジェクト指向で変わったのか
- ドメインモデルを中心にしたソフトウェア開発の進め方
- ソースコードを第一級のドキュメントとして活用する
- 分析と設計が一体になった開発のやり方をマネジメントする
開発の進め方はオブジェクト指向で変わったのか
開発の基本はV字モデル
従来の手続き型アプローチ | オブジェクト指向アプローチ | |
---|---|---|
V字の各工程 | フェーズ 月・年単位 |
作業の単位 1日で全部やったりする |
工程の担当者 | フェーズごとに異なるチーム | 同じ人間/チーム |
短期間で開発し修正と拡張を繰り返すことが重要になった
- 従来のアプローチ
- 要件定義や基本設計に数カ月〜年単位の時間をかける
- そんなにじっくり時間をかけられなくなってきた
- ビジネスは変化する
- 短期間の開発と変更を繰り返すのが重要に
- そのための、変更を楽で安全にするオブジェクト指向
オブジェクト指向の開発はうまくいっているのか/どちらのやり方でも変更がやっかいなソフトウェアが生まれやすい
- OOPやモデリング言語を取り入れても、オブジェクト指向らしくない開発はできてしまう
- V字を短いサイクルで繰り返さない
- 分析モデルと設計モデルとが乖離していびつになりがち
- 分析や設計に時間をかけずにとにかくプログラミングしてしまう
- ちょっと規模が大きくなるとすぐに手を付けられなくなる
- 【所感】前職がこれでした
- V字を短いサイクルで繰り返さない
- 分析と設計を一体にやるオブジェクト指向らしい開発を
ドメインモデルを中心にしたソフトウェア開発の進め方
業務ロジックに焦点を当てて開発を進める
ソースコードを第一級のドキュメントとして活用する
多くのドキュメントは不要になる
- 従来の開発手法のドキュメントの役割
- 決定事項の記録(確認手段)
- 伝達手段
- 進捗の管理
- オブジェクト指向らしい開発では…
- 前提: 分析モデルと設計モデルとが一致していること
重要になる活動
- 分析と設計を同じ技術者が進めるためにより重要になる活動
- 初期の分析段階からコードでの表現を重視する
- 正式なドキュメントは、可能な限りソースコードに集中する
更新すべきドキュメント
- 非技術者にとってはやはりドキュメントが必要
全体を俯瞰するドキュメントを作成して共有する
- システムの基本的な目的や方向性を共有するための情報
- システム概要説明
- プレスリリースに記載したセールスポイント
- リリースノート
- 利用者ガイド
- 営業ツールのキャッチフレーズ
- ボトムアップを基本とするオブジェクト指向の分析設計に芯を通す
技術方式のドキュメントもソースコードで表現する
非機能要件はテストコードで表現する
- 多くはテストコードとして自動化・自己文書化できる
- 完全に自動化できないものも、半自動化の余地はある
- テストのログとして確認項目や手順をログとして書き出す等
分析と設計が一体になった開発のやり方をマネジメントする
見積もりと契約
フェーズモデル | オブジェクト指向 | |
---|---|---|
分析・基本設計 | 準委任 | 準委任 |
詳細設計・実装 | 請負 | 準委任 |
- オブジェクト指向の開発のやり方では、開発初期から分析し、設計し、実装も始まる
- フェーズモデルでいえば準委任契約の段階
- 開発者がコードを書き始めているけれども、まだ分析の段階
- オブジェクト指向の変更容易性をより効果的に活かすには、開発後半も準委任にすべき
- 仕様の変更や開発の優先順位を変えたいときに柔軟に対応できる
- cf. 請負は契約に縛られて柔軟に対応できない。発注側も受注側もリスクが多い
進捗の判断
- ドメインモデルのソースコードで判断できる
- 小さな単位、業務の関心事の単位で進捗判断可能
- パッケージ、クラス、メソッド
- cf. フェーズモデルだと進捗管理が難しい
- とくにデータクラスと機能クラスに分割していて、かつクラスが巨大な設計の場合
- 小さな単位、業務の関心事の単位で進捗判断可能
品質保証
- 思わぬ勘違いや致命的な抜け漏れが起きにくい
- 業務を理解している技術者が分析を行い、プログラムを直接書いているため
- 技術者と業務の言葉で会話することが試金石
- うまくしゃべれていれば高品質
- ミスや見落としがあってもきっと軽微
- ぎくしゃくしていると危険信号
- 大きな欠陥やとんでもない勘違いの疑いあり
- うまくしゃべれていれば高品質
要員と体制
- 育てるべき人材
- プログラミングが一定レベルでできること
- 業務要件に関心を持つこと