EuDs

ソフトウェア工学入門復習#

第 0 章#

• ソフトウェア工学提唱の年：1968 年

  1968 年、北大西洋条約機構 (NATO) の計算機科学者が
  西ドイツで国際会議を開催し、
  ソフトウェア危機の問題を議論し、「ソフトウェア
  工学」を正式に提唱した。

第 1 章#

• ソフトウェアの本質
  開発 / 悪化 / カスタムビルド / 複雑

第 2 章#

• ソフトウェア工学の定義

  1. ソフトウェアの開発、運用、保守に対する体系的、規律的、定量的アプローチの適用；すなわち、ソフトウェアに対する工学の適用。
  2. (1) のアプローチの研究。

• ソフトウェアプロセス

  • 理由：タイムリーなフィードバックが必要
  • プロセスフレームワーク
    • フレームワーク活動
      • コミュニケーション
      • 計画
      • モデリング
        1. 要件分析
        2. 設計
      • 構築
        1. コード
        2. テスト
      • デプロイメント
    • 傘活動
      • ソフトウェアプロジェクトの追跡と管理
      • リスク管理
      • ソフトウェア品質保証
      • 技術レビュー
      • 測定
      • ソフトウェア構成管理
      • 再利用管理
      • 作業成果物の準備と生産

• ソフトウェアライフサイクル

  • ソフトウェアには、誕生、成長、成熟、
    衰退の生存プロセスがある。このプロセスは
    コンピュータソフトウェアのライフサイクル（生存周期）である。
  • なぜ必要か
    • 時間的観点からソフトウェア開発と保守の複雑な問題を分解し、ソフトウェアの生存の長い周期をいくつかの段階に分け、それぞれの段階に相対的に独立したタスクを持たせ、段階ごとのタスクを順次完了させるため。
    • ソフトウェア人に共通のフレームワークを提供し、相互交流を促進するため。

第 4 章#

• 進化モデル
  • プロトタイプ
    • タイプ
      • 探索型プロトタイピング
      • 実験型プロトタイピング
      • 演化型プロトタイピング
    • 特徴
      • 実際に動作可能
      • 固定の生存期間はない。捨てられるか、最終製品の一部として使用される可能性がある。
      • 異なる目的のためにプロトタイプを作成可能
      • 迅速かつ安価
      • ユーザーの評価後に修正、実行を繰り返す反復プロセスの一部である。

第 5 章#

• アジャイル宣言
  • 個人と対話をプロセスとツールより重視
  • 動作するソフトウェアを詳細な文書より重視
  • 顧客との協力を契約交渉より重視
  • 変化への対応を計画の遵守より重視

第 7 章#

要件工学#

• 発端
• 引き出し
• 詳細化
• 交渉
• 仕様
  • 要件調査と要件分析の結果に基づいて、正確な製品要件をさらに定義し、「製品要件仕様書」を作成する。
• 検証
• 要件管理

品質機能展開#

1. 機能展開 —— システム機能の価値を特定
2. 情報展開 —— データオブジェクトとイベントを特定
3. タスク展開 —— システムの動作を特定
4. 価値分析 —— 要件の優先順位を特定

非機能要件#

• 品質属性
• パフォーマンス属性
• セキュリティ属性
• 一般的なシステム制約

図#

ユースケース / クラス / 状態 / 活動

第 11 章#

• 分析モデル
  • 必要なデータ、機能、動作を記述することに焦点を当てる

設計モデル#

• ソフトウェアのデータ構造、アーキテクチャ、インターフェース、コンポーネントに関する詳細を提供
• 4 種類
  • データ / クラス設計 —— 分析クラスを実装クラスとデータ構造に変換
  • アーキテクチャ設計 —— 主要なソフトウェア構造要素間の関係を定義
  • インターフェース設計 —— ソフトウェア要素、ハードウェア要素、最終ユーザーがどのように通信するかを定義
  • コンポーネントレベル設計 —— 構造要素をソフトウェアコンポーネントのプロセス記述に変換する。

概念#

• アーキテクチャ - ソフトウェアの全体構造
  • システムのモジュール化、抽象化、情報隠蔽、インターフェース設計を反映
  • 例
    • クライアント - サーバーアーキテクチャ
    • マイクロサービスアーキテクチャ
    • イベント駆動アーキテクチャ
    • 階層アーキテクチャ
• パターン
  • パターンの目標：再利用が容易。
  • タイプ：
    • アーキテクチャパターン
      • B/S, C/S
    • デザインパターン
    • イディオム
      • プログラミング言語に特有の低レベルパターン
• 機能的独立性
  • 内聚
    • モジュールの相対的な機能強度の指標
    • 機能内聚、層内聚、通信内聚、順序内聚、プロセス内聚、時間内聚、実用内聚（高から低に並べる）
  • 結合
    • モジュール間の相対的な相互依存性の指標
    • 非直接結合、データ結合、ラベル結合、制御結合、外部結合、共有結合、内容結合（低から高に並べる）
  • 目標：高い内聚、低い結合

第 12 章 行動モデル#

• 何
  システムの構造、ソフトウェアコンポーネント、これらのコンポーネントの外部的に見える特性、およびそれらの間の関係を構成する。
• アーキテクチャの重要性
  • すべての関係者（ステークホルダー）間のコミュニケーションのため
  • 初期の設計決定を強調
  • 比較的小さく、知的に把握可能なモードを構成
• アーキテクチャの用途
  • 規定された要件を満たす設計の有効性を分析
  • 設計変更を行う際にアーキテクチャの代替案を考慮するのが容易
  • ソフトウェア構築に関連するリスクを低減

アーキテクチャスタイル#

• 定義内容
  • システムが必要とする機能を実行するコンポーネントのセット
  • 「通信、調整、コンポーネント間の協力」を実現する接続器のセット
  • システムを形成するためのコンポーネントの統合方法を定義する制約
  • 設計者がシステムの全体的な特性を理解するために、システム構成要素の既知の特性を分析するための意味モデル
• 種類
  • データフローアーキテクチャ —— バッチ処理、パイプとフィルター
  • 呼び出しと戻りアーキテクチャ —— メインプログラム / サブプログラム、オブジェクト指向システム、階層システム
  • 独立コンポーネントアーキテクチャ —— イベントシステム、トリガー、モニター
  • 仮想マシンアーキテクチャ —— インタープリタ、ルールベースのシステム
  • リポジトリアーキテクチャ —— データベースシステム、ブラックボードシステムなど

第 13 章 コンポーネントレベル設計#

• モジュール化され、デプロイ可能で、交換可能なシステムの一部であり、実装をカプセル化し、一連のインターフェースを公開する。

基本設計原則#

1. 開閉原則（OCP）—— モジュール [コンポーネント] は拡張に対して開かれているべきだが、修正には閉じているべき。
2. リスコフ置換原則（LSP）——「サブクラスはその基底クラスを置き換えられるべきである。」
3. 依存性逆転原則（DIP）—— 抽象に依存する。実体に依存してはいけない。
   • 高レベルモジュールは抽象（インターフェースまたは抽象クラス）に依存すべき。
   • 抽象は具体的な実装に依存すべきではなく、具体的な実装は抽象に依存すべき。
4. インターフェース分離原則 (ISP)—— 多くの専用インターフェースは 1 つの一般的なインターフェースよりも良い。
5. 公開再利用等価原則 (REP)—— 再利用の粒度は公開の粒度である。
6. 共通閉合原則（CCP）—— 同時に修正されるクラスは一緒に置くべき。
7. 共通再利用原則（CRP）—— 同時に再利用できないクラスは一緒に置くべきではない。

第 14 章 ユーザーインターフェース設計#

• 黄金のルール
  • ユーザーが操作を制御する
  • ユーザーの記憶負担を減らす
  • インターフェースの一貫性を保つ

第 15-16 章 ソフトウェア品質#

• ソフトウェア品質とは何か
  効果的なソフトウェアプロセスが、その適用方法によって有用な製品を生み出し、それを生産する人々と使用する人々に測定可能な価値を提供すること。

• マッコールの品質三角形

  • 製品の修正
  • 製品の移転
  • 製品の運用

• 品質のコスト

  • テストと保守段階でのエラーや欠陥の修正コストが急激に増加する。
  • 種類：
    1. 予防コスト（COP）
    2. 評価コスト（COA）
    3. 内部失敗コスト
    4. 外部失敗コスト

第 17-19 章 テスト戦略と技術#

• 検証と妥当性確認
  • 検証：ソフトウェアが特定の機能を実現できることを確認すること（製品を正しく構築する）。
  • 妥当性確認：ソフトウェアが顧客の要件に追跡可能であることを確認すること（正しい製品を構築する）。
• テスト戦略 —— 小から大へ
  • ユニットテスト
  • 統合テスト
  • システムテスト
  • 受け入れテスト
    • α テスト 開発者サイトで最終ユーザーによって行われる。
    • ß テスト 最終ユーザーサイトで行われる。

テスト戦略のユニットテスト#

• 内容：
  • インターフェース
  • 局所データ構造
  • 境界条件
  • 独立パス
  • エラーハンドリングパス
• スタブ —— 下層の代替
• ドライバー —— 上層の代替
  • 入力パラメータ、環境、ユニットを実行するためのフレームワークを提供。

テスト戦略の統合テスト#

• トップダウン統合
  • 利点
    • プログラムの骨組みバージョンが早期に存在し、デモが可能。
    • 設計エラーが早期に発見される可能性がある。
    • テストドライバーの必要性が減少する。
    • 故障位置の特定が容易になる傾向がある。
  • 欠点
    • スタブの構築が高価になる可能性がある。
• ボトムアップ統合
  • 利点
    • オブジェクトと再利用に特に有用。
    • 構造設計情報を必要としない。
  • 欠点
    • 最後のモジュールが追加されるまでプログラム全体が存在しない。
    • テストドライバーが必要で、テストスタブは必要ない。

テスト戦略のシステムテスト —— コンピュータベースのシステムを十分に活用#

• 目的：
  • 実際の運用環境でシステム全体をテストする。
  • システムが全体的な作業要件を満たしていることを確認する。
  • システム機能以外の側面もテストする。
  • 結果は時々システム受け入れに使用される。
  • ソフトウェアユーザーマニュアルを検証する。
  • 信頼性と保守性を評価する。

テスト方法#

• ブラックボックステスト（機能）
• ホワイトボックステスト（構造）

第 21 章 ソフトウェア構成管理#

SCM プロセス#

1. 識別
2. 変更管理
3. バージョン管理
4. 構成監査
5. 報告

• ソフトウェア構成アイテム

第 22 章 プロジェクト管理の概念#

4 p#

• 人
• 製品
  • 範囲
    1. コンテキスト
    2. 情報目標
    3. 機能とパフォーマンス
• プロセス
  • プロジェクトの特性を考慮する。
  • 必要な厳格さの程度を決定する。
  • 各ソフトウェア工学活動のタスクセットを定義する。
• プロジェクト
  1. 正しい基盤から作業を開始する —— まず解決すべき問題を理解し、現実的な目標と期待を設定することによって実現する。
  2. モチベーションを維持する —— プロジェクトマネージャーはインセンティブを提供し、離職率を最低限に抑え、チームは実行する各タスクで品質を強調し、上級管理者はチームからできるだけ離れるべき。
  3. 進捗を追跡する —— 品質保証活動の一環として、作業成果物（モデル、ソースコード、テストケースセットなど）の生成と承認（正式な技術レビューを使用）に伴い、進捗が追跡される。
  4. 賢明な決定を下す —— プロジェクトマネージャーとソフトウェアチームの決定は「シンプルさを保つ」べき。
  5. 事後分析を行う —— 各プロジェクトの教訓を引き出すための一貫したメカニズムを確立する。

W5HH#

1. なぜシステムが開発されているのか？—— なぜ
2. 何が行われるのか？—— 何をするか
3. いつ達成されるのか？—— いつ行うか
4. 誰が責任を持つのか？—— 誰が責任を持つか
5. 他の人の組織はどこにあるのか？—— 他の人の組織はどこにあるか
6. 技術的および管理的に仕事はどのように行われるのか？—— 技術的および管理的にどのように行うか
7. 各リソース（例：人、ソフトウェア、ツール、データベース）にはどれだけ必要か？—— 各リソースにはどれだけ必要か

タスクセット =#

• ソフトウェア工学タスク
• 作業成果物
• 品質保証ポイント
• マイルストーン

ソフトウェア工学活動#

• 要件分析
• 設計
• ソフトウェア開発
• ソフトウェアデプロイメント
• ソフトウェア保守
• プロジェクト管理
• 品質保証
• 構成管理
• ドキュメント作成

第 23 章 プロセスとプロジェクトメトリクス#

• 意義
  1. 進行中のプロジェクトの状態を評価する。
  2. 潜在的なリスクを追跡する。
  3. 問題が悪影響を及ぼす前にリスクを発見する。
  4. ワークフローやタスクを調整する。
  5. プロジェクトチームがソフトウェア作業成果物の品質を管理する能力を評価する。

プロセス測定#

• プロセス中に得られた一連のデータまたはソフトウェア工学タスクの特性に基づいて測定を行う。
• ソフトウェアプロセス改善（SPI）
• 5 つのメトリクス
  • 品質関連
  • 生産性関連
  • 統計的 SQA データ
  • 欠陥除去効率
  • 再利用データ

プロジェクトメトリクス#

• 3 つの側面
  • 予定通り
  • 品質
  • コスト

第 24-25 章 プロジェクト見積もりとスケジューリング#

範囲#

• 範囲は、プロジェクトの製品を作成するために関与するすべての作業と、それらを作成するために使用されるプロセスを指す。何が行われ、何が行われないかを定義する。
• プロジェクト範囲の内容
  • 最終ユーザーに提供される機能と特性
  • 入力と出力のデータ
  • ソフトウェアの使用によってユーザーに提示される「内容」
  • パフォーマンス、制約、インターフェース、およびシステムの信頼性に関する制約

作業分解構造（WBS）#

• WBS を行う 5 つの方法
  1. ガイドラインの使用：いくつかの組織が提供するガイドライン
  2. 類似法：類似プロジェクトの WBS をレビューし、私たちのプロジェクトに合わせてカスタマイズする。
  3. トップダウンアプローチ：プロジェクトの最大のプロジェクトから始め、それらを分解する。
  4. ボトムアップアプローチ：詳細なタスクから始め、それらをまとめる。
  5. マインドマップアプローチ：非線形形式でタスクを書き下し、その後 WBS 構造を作成する。

見積もり方法#

• コード行に基づく見積もり
  • 利点：測定が容易、自動化が容易
  • 欠点：コードに限られ、設計には使用できず、言語に依存し、機能の複雑性を考慮していない、設計の良し悪しに依存する。
• 機能ポイントに基づく見積もり
  • 利点：
    1. 最初の要件段階で使用可能
    2. プログラミング言語、製品設計、開発スタイルに依存しない
    3. 実装ビューではなく、ユーザービュー
    4. コーディング以外の活動を測定するために使用可能
    5. 大量の歴史データが存在する
    6. 証拠がある
  • 欠点：
    1. 既存製品（ソースコード）の FP 内容を直接計算できない
    2. 自動化が難しい
    3. FP は言語、設計、スタイルの違いを反映しない
    4. FP は商業データ処理アプリケーションの見積もり用に設計されている
    5. 主観的なカウント

プロジェクトスケジューリング#

1. プロジェクトが遅れる理由
   非現実的な締切
   要件の変更
   作業量の過小評価
   予測不可能なリスク
   技術的な課題
   人的な困難
   コミュニケーションの不全
   プロジェクトが計画から遅れていることを認識できず、問題を修正する行動を取らないこと。
2. スケジューリングの原則
   分割 —— 異なるタスクを定義する。
   相互依存性 —— タスク間の関係を明確にする。
   作業量確認 —— 人的資源が利用可能であることを確認する。
   責任の特定 —— 責任を持つ者を明確にする。
   出力結果の明確化 —— 活動が生み出す結果を特定する。
   マイルストーンの特定 —— 品質レビューを行う。
3. スケジューリングのステップ
   1. タスクセットを定義する ——WBS
   2. 活動をスケジュールする。
   3. プロジェクトネットワーク図を描く。
   4. クリティカルパス分析。
   5. ガントチャートを使用してスケジュールする。
   6. 進捗を追跡する。

第 26 章 リスク管理#

• 反応的リスク管理

• 積極的リスク管理

  • 公式なリスク分析が実施される。
  • リスクの根本原因を修正する。

• リスク管理パラダイム

  1. リスクの識別
  2. リスク分析
  3. リスク計画
  4. リスク監視

• RMMM

  • 緩和
  • 監視
  • 管理

よく使われる図#

• ユースケース図
• クラス図
• 活動図
  • 変形：スイムレーン図
• シーケンス図