ソフトウェアエンジニアリングプラクティス
一般的に、日々の業務で必要とされる概念、原則、手法、ツールの集合
最も重要な目的は、ステークホルダーの要求を満たす機能やフィーチャを備えた、高品質で運用しやすいソフトウェアを計画通りに提供すること
1. 問題を理解する (コミュニケーションと分析)
2. 解決策を計画する (モデリングとソフトウェア設計)
3. 計画を実行に移す (コード実装)
4. 結果が正しいことを確認する (テストと品質保証)
ソフトウェアエンジニアリングプラクティス全般に対する 7 つの原則 (『Seven Principles of Software Development』 より)
1. システムが存在する唯一の理由はユーザーに価値を提供すること
3. ビジョンを持ち歩け
4. あなたが作ったものを他人が使用する
5. 未来へオープンであれ
6. 再利用に先駆けて計画せよ
7. 考えよ
プロセスの指針となるコア原則 (core principles)
2. あらゆる段階で品質を重視せよ
3. 変化に備えよ
4. 優れたチームを築け
5. コミュニケーションと調整を仕組み化せよ
6. 変更をマネジメントせよ
7. リスクを評価せよ
8. 他者にとって価値ある成果を生み出せ
プラクティスの指針となるコア原則
1. 分割して統治せよ : 関心事を分割すること (SoCs : Separation of Concerns)
2. 抽象化を理解して使いこなせ
3. 一貫性を保つことに努めよ
4. 情報伝達を重視せよ : ソフトウェアとは情報を伝達するものであり、インターフェイスが重要
5. 意味のあるモジュール性を備えたソフトウェアを構築せよ
6. デザインパターンを学習せよ
7. できるだけ様々な観点から問題とその解決方法を検討せよ
8. ソフトウェアには保守担当者がいることを忘れるな
フレームワークアクティビティの指針となる原則
コミュニケーションの原則
1. 傾聴する
2. コミュニケーションの前に準備する
4. 対面コミュニケーションが最善である
5. メモをとり、決定事項をドキュメントにする
6. コラボレーションのために努力する
7. 論点に集中し、議論を切り分ける
8. 何かが不明確であれば、図を描く
9. (a) 何かに合意したら次に進む、(b) 何かに合意できなくても次に進む、(c) 不明確な機能やフィーチャをその場で明確にできなくても次に進む
10. 交渉は論争や試合ではない。 両者の勝利だけが成功である
計画の原則
1. プロジェクトのスコープを理解する : スコープは目的地を示す
2. ステークホルダを計画アクティビティに巻き込む : ステークホルダーは優先順位や制約を定める
3. 計画は反復的であることを認識する
4. わかっていることから見積りをする : 曖昧で信頼できない情報に基づく見積りは、信頼できない
5. リスクを考慮する
6. 現実的に考える
7. 精度を調整する : 精度が高いと頻繁な追跡とコントロールが必要。 直近のものと先のものとで精度を変える
8. どのように品質を保証するか決める
9. どのように変更に対応するか決める
10. 頻繁に追跡し、必要に応じて調整する
『Agile Modeling』 で紹介される原則？
ソフトウェアを作ることが目的なので、それに必要ないモデルは作らないこと
簡潔で変更しやすいモデルを作ること
など
構築の原則
現代のコーディングには、ソースコード記述のほかに、コンポーネント設計からのソースコード自動生成や Unreal 4 や Blueprints のような第 4 世代プログラミング言語で実行可能コードを自動生成する活動も含まれる
コーディングの原則
テストの原則
全てのテストは顧客要求まで遡れる必要がある
エラーの 80 % はプログラムコンポーネント全体の 20 % に起因する
静的テストの技法は素晴らしい結果をもたらす
回帰テスト (リグレッションテストケース) を揃えておくことが重要
デプロイの原則
デプロイアクティビティには、出荷、サポート、フィードバックの 3 つのアクション
ソフトウェアに対する顧客の期待の管理をすべし (
期待マネジメントってやつだ)