ソフトウェアデザイナー (ソフトウェアエンジニアリング)

ソフトウェア工学

• CMM (能力成熟度モデル)

  • 5つのレベル
    • 初期レベル (混乱していて混沌としており、明確に定義されたステップがなく、完了は英雄的な中心キャラクターの役割によって異なります)
    • 反復可能なレベル (プロジェクトのコスト、スケジュール、機能を追跡するための基本的なプロジェクト管理プロセスと実践方法を確立する)
    • 定義されたレベル (管理面とエンジニアリング面の両方のソフトウェア プロセスが文書化され、標準化され、標準ソフトウェア プロセスに統合されている)
    • 管理レベル（ソフトウェアプロセスの製品品質は開発組織のメンバーによって理解され、管理されます）
    • 最適レベル（プロセス品質フィードバックの受信、新しいコンセプト、新しい技術、継続的な改善）

• CMMI (能力成熟度モデルコレクション)

  • 段階的モデル
    • 初期プロセスは予測不可能で制御不能です
    • 管理されたプロセスがプロジェクトに貢献します
    • 定義されたプロセスは組織に役立ちます
    • 定量的な管理プロセスが測定および制御されます
    • プロセス改善への最適な焦点
  • 連続モデル
    • 不完全なプロセス領域が実行されなかった、または受信されなかった
    • 実行された識別可能な入力作業成果物が出力に変換される
    • 集中管理された管理プロセスの制度化
    • 定義されたプロセスを定義されたレベルで一元的に制度化する
    • 定量管理のための定量管理可能なプロセスの制度化
    • 最適化では、定量的な手段を使用してプロセス領域を変更および最適化します。

• ソフトウェアプロセスモデル

  • ソフトウェア開発のすべてのプロセス、活動、タスクの構造フレームワーク
  • ウォーターフォールモデル
    • 要件分析、設計、コーディング、テスト、運用保守
    • 前から後ろへの相互接続の順序が固定されているため、ある段階で前の段階を気にする必要がなく、必要な場合は振り返る必要があり、コストが非常に高くなります。
    • 利点: 理解しやすく、管理コストが低く、段階的な開発計画、需要調査、製品テストを重視します。
    • デメリット：顧客のニーズをしっかりと明確に表現し、プロジェクト終了までに実証する必要がある 初期段階の問題は後から発見でき、リスク管理能力が弱い
  • V モデルは、品質保証アクティビティとコミュニケーション、モデリング関連アクティビティ、および初期ビルド関連アクティビティの間の関係を記述するウォーターフォール モデルの変形です。
    • 初期のソフトウェア エンジニアリング作業に検証検証アクティビティを適用する方法を提供します。一連のテストがあります
  • インクリメンタルモード
    • 要件を一連の増分製品に分割し、それぞれを個別に開発可能
    • 最初の増分は多くの場合、コア製品 1.0 であり、将来的には新機能 2.0 3.0 が追加されます。
    • 利点: ウォーターフォール モデルのすべての利点により、最初の成果物バージョンに必要なコストと時間が非常に小さく、リスクが小さく、ユーザー要件の変更が軽減されます。
    • 短所: ユーザーの変更要件に対する計画がない、後の増分に対して不安定、初期の思考の安定性とは異なり、一部の増分は再開発が必要になる可能性がある、組織の能力を超える可能性がある
  • 進化モデル（プロトタイプモデルとスパイラルモデル）
    • これは、ソフトウェア開発者がより完全なソフトウェア バージョンを段階的に開発できるようにする反復プロセス モデルです。ソフトウェア要件の正確な知識が不足している場合に適用されます。
    • 試作モデル
      • ユーザーの要件が明確でなく、頻繁に変更する必要がある状況に適していますが、大規模なソフトウェアには適していません。
      • 目的は、プロトタイプを迅速かつ低コストで構築し、ユーザーにシステムの枠組みを迅速に示し、要件を提案することです。
      • コミュニケーション = "迅速な計画 = 迅速な設計モデリング = "プロトタイプの構築 = 導入の実施とフィードバック
    • リスク分析にスパイラルモデルを追加
      • 大規模、複雑、高リスクのシステムに適用可能、ユーザー ニーズの動的な変化をサポート
      • 開発者には広範な評価経験と専門知識が必要で、反復回数が多すぎるとコストが増加し、提出時間が遅れる
      • スパイラルサイクルの4つのステップ
        • 計画を立てる: ソフトウェアの目標を決定し、実装計画を選択し、プロジェクト開発の制約を明確にします。
        • リスク分析: 選択したオプションを分析し、リスクを特定し、リスクを排除します。
        • 実装エンジニアリング: ソフトウェア開発の実装、段階的な製品の検証
        • ユーザー評価: 開発作業を評価し、修正案を提案し、次のサイクルの開発計画を確立します。
    • 噴水モデル
      • ユーザーのニーズとオブジェクトによって駆動されるため、オブジェクト指向の開発手法に適しています。
      • 開発プロセスは反復的 (多くの場合、何度も繰り返される) であり、シームレス (明確な境界がない) です。
      • 開発アクティビティを交差させて反復できるようにする
      • メリット：ソフトウェアプロジェクトの開発効率が向上し、開発期間が短縮される デメリット：人員が多くなりプロジェクト管理が難しくなる、文書管理が厳しくなる、監査が難しくなる

• 統合プロセス (UP) モデル

  • UML 手法とツールによってサポートされる、ユースケースとステーク主導、アーキテクチャ中心の反復的 (5 つのコア ワークフロー) および増分開発プロセス
  • ポケット プロジェクト: 計画、分析と設計、構築、統合とテスト、社内および社外のリリース
  • 4つのテクニカルステージ
    • 開始フェーズ: ライフサイクルの目標
    • 詳細化フェーズ: ライフサイクル アーキテクチャ
    • 構築段階: 初期機能
    • 引き継ぎフェーズ: 製品リリース
  • 統合プロセスの代表的なものは RUP です。RUP は UP の商用拡張であり、UP と完全な互換性がありますが、UP よりも完全で詳細です。

• アジャイルな手法

  • 価値あるソフトウェアをできるだけ早く継続的に提供する 顧客を満足させる 各アプローチは一連の原則に基づいています（アジャイルマニフェスト）

  • エクストリーム プログラミング XP

    • 4 つの部分: 価値観、原則、実践、行動
      

  • 結晶法クリスタル

    • Crystal Legal では、プロジェクトごとに異なる戦略、慣例、方法論のセットが必要です

  • パラレルクエスト方式 スクラム

    • 30 日ごとの反復をスプリントと呼びます

  • 適応型ソフトウェア開発 ASD
    

  • アジャイル統合プロセスAUP

    • 継続的な大規模と反復的な小規模の原則を使用してソフトウェア システムを構築する
    • 反復実行アクティビティ: モデリング、実装、テスト、展開、構成およびプロジェクト管理、環境管理

• ソフトウェア要件
  

• システムデザイン

  • システム設計の成果物は、情報システムを実現するための重要な基盤となる一連のシステム設計書です。
  • 概要設計フェーズ
    • ソフトウェア システム構造の設計: 複雑なシステムを機能に応じてモジュールに分割します: 各モジュールの機能を決定します。モジュール間の呼び出し関係を呼び出します。モジュール間のインターフェイスとモジュール間で送信される情報を決定します。モジュール構造の品質を評価します。概要設計の重要なステップであり、次の段階の詳細設計やコーディングの作業に直接影響します。
    • データ構造とデータベース設計 データベース設計: 概念、論理、物理設計
    • 概要設計文書を作成します。文書には、概要設計仕様、データベース設計書、ユーザー マニュアル、および修正されたテスト計画が含まれます。
    • レビュー：要件で規定された機能や性能の実現、設計手法の実現可能性、内部および外部インターフェース定義の正しさをレビューします。
  • きめ細かなデザイン
    • 各モジュールの詳細なアルゴリズム設計
    • モジュール内のデータ構造を設計する
    • データベースの物理設計とは、データベースの物理構造を決定することを意味します。
    • その他の設計： コード設計 入出力フォーマット設計 ユーザーインターフェイス設計
    • 詳細な設計仕様書を作成する
    • 復習: 処理アルゴリズムとデータベースの物理構造の両方を復習します。

• システムテスト

  • 意味: バグを見つけるためにプログラムを実行するプロセス。テストが成功すると、これまで発見されていなかったバグが発見されます。
  • 目的: 最小限の人員と時間で潜在的なエラーや欠陥を発見したいと考えています。一般に、ソフトウェア テストは
  • システムの品質と信頼性を確保するための重要なステップであるシステム分析システム設計の最終レビューは、次の原則に従います。
    • 早期かつ継続的にテストする
    • テスト作業は専門の担当者が実施する必要があり、より客観的かつ効果的になります。
    • テスト計画を設計するときに、実際の出力結果と期待される結果を比較することで、テスト オブジェクトが正しいかどうかを明らかにできます。
    • テストケースを設計するときは、合理的なものと不合理なものの両方をテストに入力する必要があります
    • プログラムをテストするときは、冗長な作業がないか確認してください
    • テスト計画に厳密に従ってください
    • メンテナンスを容易にするために、テスト計画とテスト ケースをソフトウェア ドキュメントの不可欠な部分として適切に保存します。
    • テスト ケースは、再テストや追加のテストを容易にするために慎重に設計されています。
    • システムテストフェーズのテスト目標は、要件分析フェーズから得られます。

• ソフトウェアテスト

  • 単体テスト（モジュールテスト）
    • ホワイトボックス テストは、モジュールの作成後に実行でき、コンパイル エラーは発生しません。
    • テスト内容：単体テストでは主にモジュールの以下の5つの特性を確認します。

      • モジュール インターフェイス: テスト モジュールのデータ フローが正しく流入および流出することを確認します。
        

      • ローカルデータ構造

        • 変数の説明が適切かどうか
        • 未割り当てまたは初期化されていない変数を使用するかどうか
        • 変数の初期値またはデフォルト値が正しいかどうか
        • 変数名が間違っていませんか？

      • 重要な実行パス

      • エラー処理

      • 境界条件

    • 単体テストのプロセス
      • モジュールは独立して実行されず、モジュール間には呼び出し間関係が存在します。モジュールをテストする場合は、2 つのモジュールを開発する必要があります。
        • ドライバーモジュール：テスト例のデータを受信し、テストモジュールに送信し、テスト結果を出力します
        • スタブモジュール: 少量のデータ処理を内部で実行できます。その目的は、エントリのチェック、呼び出し、および戻り情報の出力です。
  • 統合テスト
    • トップダウンの統合テスト
      • ソフトウェア アーキテクチャを構築するためのインクリメンタルな手法。最上位はドライバー モジュール (メイン コントロール モジュール) で、これがスタブ モジュール (抽象から具体) に置き換えられ、深さ優先または幅優先の方法で徐々に下降します。
      • ドライバーモジュールを書く必要はなく、スタブモジュールを書く必要があります
    • ボトムアップ統合テスト
      • スタブモジュールを記述する必要はなく、ドライバーモジュールを記述する必要があります
      • 一番下のスタブ モジュールを接続してクラスターになります。ドライバー モジュールを作成します。クラスターをテストします。ドライバー モジュールを削除して、クラスターへの接続を続けます。
    • 回帰試験
      • 変更によって望ましくない副作用が伝播しないように、すでに行われた処理の一部を再実行します。
      • 変更によって意図しない動作や追加のエラーが発生しないようにする
    • 煙テスト
  • 確認テスト
  • システムテスト

• 試験方法

  • 静的テスト: マシン上では実行しないでください。
    • 手動検出
    • コンピュータ支援静的解析
  • 動的テスト
    • ブラックボックステスト
      • 同値クラス分け：有効同値クラス50、無効同値クラス101 0-100
      • 境界値解析：0～100入力 0～1 100 101
      • 誤算: 感覚によるもの
      • デシジョンテーブルに変換された特性要因図
      • ps: 両方の入力が不合理な場合、それは不合理なテストケースです
      • マッケイブ測定
        • ループ数の公式: V(g)=m-n+2 m は G の有向円弧、n は節点の数または閉領域 + 1
    • ホワイトボックステスト
      • 原則: すべての独立したパスが少なくとも 1 回実行される; true または false の両方のケースが少なくとも 1 回実行される; ループは境界および一般条件で 1 回実行される; プログラムの内部データ構造の妥当性をテストする
      • ロジックカバレッジ
        • ステートメントの対象範囲
          • テスト対象プログラムの各ステートメントが少なくとも 1 回実行されるように十分なテスト データを選択することは、論理カバレッジが弱いことになります。
        • 意思決定カバレッジ（支店カバレッジ）
          • true ブランチと false ブランチの両方を 1 回実行する必要があります
        • 条件の適用範囲
          • 各ステートメントの各論理条件の各可能な値が少なくとも 1 回満たされる (判定ステートメント内の各条件の真値と偽値が満たされる必要がある)
        • 判定・条件オーバーライド
          • 上記２つの組み合わせ
        • 条件の組み合わせの適用範囲
          • 決定条件の可能な値のすべての組み合わせが少なくとも 1 回発生します
        • パスのカバレッジ
          • テスト対象プログラム内のすべての可能なパスをカバーする強力な論理カバレッジ
      • ループ カバレッジ: ループ内のすべての条件が検証されるように、十分なテスト ケースが実行されます。
      • 基本的なパステスト

• システムメンテナンスの概要

  • ソフトウェア メンテナンスはソフトウェア ライフ サイクルの最終段階であり、システム開発プロセスの一部ではありません。

  • システム保守性の概念

    • 保守者がソフトウェアを理解し、修正、変更、改善することがいかに簡単であるか。
    • 保守性指標
      • 理解しやすさ、テストしやすさ、修正しやすさ
    • ハードウェア保守、ソフトウェア保守、データ保守

  • ソフトウェアのメンテナンス

    • ドキュメントはソフトウェアの保守性を決定する要素であり、非常に重要です
    • 通常、メンテナンス期間は開発よりもはるかに長く、投資も多額になります。
    • 保守性はあらゆるソフトウェアが持つべき特性であり、開発段階でソフトウェアの保守性を確保する必要があり、各段階で保守性の向上を検討する必要があります。
    • 品質保証レビューを実施すると、ソフトウェア品質を測定するための重要な特性であるソフトウェア製品の保守性が向上します。
    • メンテナンス内容
      • 正確性の維持: 誤りを正す 17 ～ 21%
      • 適応型メンテナンス: 情報テクノロジーと管理ニーズの変化に適応するための変更の 18 ～ 25%
      • 完全性維持：機能拡張や性能向上を目的とした修正が50～60％
      • 予防メンテナンス: 予防的な新機能を積極的に追加する 4%

  • ソフトウェアのドキュメント

    • ドキュメントもソフトウェア製品の一部であり、ドキュメントのないソフトウェアはソフトウェアとは言えません
    • 高品質のドキュメントを作成すると、ソフトウェア開発の品質が向上します
    • ソフトウェアドキュメントの準備は、ソフトウェア開発作業において重要なアドレスとかなりの作業量を占めます。
    • 高品質のドキュメントはソフトウェア製品の利点にとって非常に重要です
    • 一般に、ソフトウェアのドキュメントは優れている必要があり、ソフトウェアのドキュメントが良くないと言う選択肢は間違っています

  • ソフトウェアの品質特性
    

  • 通信経路

    • マスター プログラマ: n-1 マスター プログラマなし: n(n-1)/2

• ソフトウェアプロジェクトの見積り

  • COCOMO モデル: 正確で使いやすいコスト見積もりモデルです。
    • 基本の COCOMO モデルは静的な一変量モデルです
    • 中間 COCOMO モデルは、システムとコンポーネントに分割された静的多変量モデルです。
    • システム、サブシステム、モジュールに分割された詳細な COCOMO モデル
  • COCOMOⅡモデル（サイズ推定用の選択）
    • アセンブリ モデルの適用 (オブジェクト点)
    • 設計初期段階のモデル (機能ポイント)
    • アーキテクチャフェーズモデル (コード行)

• スケジュール管理

  • ガントチャート（ガントチャート）
    • 各タスクがいつ開始され、どこで終了するか、タスクの進行状況、および各タスク間の並列性を明確に説明します。
    • タスク間の依存関係が明確に反映できない、プロジェクトの要点を見極めるのが難しい、計画の潜在的な部分を反映できない
  • PERTチャート（プロジェクト計画レビューテクニカルチャート）
    • 有向グラフ、矢印はタスクを示し、タスクに必要な時間をマークできますが、タスクの並列関係を反映することはできず、依存することができます。
    • ノードに流入するタスクは終了、ノードから流出するタスクは開始、ノードはイベントであり、それが終わって初めて開始できる
    • 開始ノード: それを指すタスクはありません。最も早い時間は 0 です。複数存在する可能性があります。
    • 終了ノード: 指摘しているタスクはなく、最新時刻が最古時刻と同じ日で、タスクが 1 つだけあります。
    • 最も早い時間: この時間より前にこの時間にタスクを開始することはできません。前の時間にタスクの時間を加えた最も早い時間です。複数ある場合は、最大値の最も早い時間を採用します。
    • 最遅時間: 出発タスクは遅くともこの時間に開始されます。そうでない場合、プロジェクトはスケジュールどおりに完了できません。前回の最遅時間からタスク時間を減算し、複数の最小値に達した場合
    • 余裕時間 = 最も遅い瞬間 - 最も早い瞬間、複数の項目は個別に計算する必要があります
    • クリティカルパス：スラックタイムが0のパス
  • プロジェクト活動図
    • 頂点はプロジェクトのマイルストーン、頂点を接続するエッジはアクティビティを表し、エッジの値はアクティビティを完了するのに必要な時間を表します。
    • クリティカル パスの長さは、終了頂点の最新の瞬間に等しい

• ソフトウェア構成管理

  • 構成データベース: 開発リポジトリ、制御リポジトリ、実稼働リポジトリ
    

• ソフトウェアリスク管理

  • 不確実性と損失

    • プロジェクトリスク: プロジェクト計画に対する脅威、不確実なプロジェクトの複雑さ、規模、構造もこれに属します。
    • 技術的リスク: 開発されたソフトウェアの品質と納期に対する脅威。その理由は、問題の解決が私たちが思っているよりも難しいからです
    • ビジネス リスク: ソフトウェア開発の実行可能性に対する脅威であり、多くの場合、プロジェクトまたは製品を危険にさらします。5 つのプロジェクト リスク: マーケティング、戦略、販売、管理、予算

  • リスクの特定

    • プロジェクト計画（見積もり、スケジュール、リソース配分など）に対する脅威を体系的に指摘し、特定した上で可能な限り回避し、リスクをコントロールする（完全に回避できない場合は、可能な限り回避する）。それが不可能な場合は、リスクを軽減するために介入することしかできません

    • リスク エントリ チェックリストでは、次の種類のリスクが特定されます。
      

    • リスク要因には、パフォーマンス、コスト、サポート、スケジュールが含まれます
      

  • リスク予測 (リスク推定): リスクの確率と結果の両方の観点からリスクを評価し、高から低までのリスク テーブルの重大度を作成します 1 2 3 4
    

    • リスクの影響を評価する: リスクの性質、範囲、タイミングがリスクの結果に影響します。
    • リスクエクスポージャー RE=P*CP 確率 C 結果

  • リスクアセスメント

    • リスク評価に役立つ手法 リスク参照レベルを定義します (コスト、スケジュール、パフォーマンスが典型的なリスク参照レベルです) トリプレット (リスク、確率、結果)

  • リスク管理

    • プロジェクト チームがリスクに対処する戦略を確立できるよう支援します。
    • リスクに対処する最善の方法は、リスクを積極的に回避することです。
    • リスク監視: プロジェクト マネージャーは特定の要因を監視します。
    • RMMM 計画 (リスク管理戦略): ソフトウェア プロジェクト計画に含めることができます。原点を見つけてください。

• ソフトウェアの品質

  • ISO/IEC9126 ソフトウェア モデル: 品質特性の第 1 層、品質サブ特性の第 2 層、および指標の第 3 層
    

• Mc Call ソフトウェア品質モデル:

• ソフトウェアのレビュー

  • ユーザーの要求を満たすデザインの仕様をデザイン品質といいます
    • ソフトウェアの仕様がユーザーの要求を満たしているかどうかを評価する
    • 信頼性：入力異常、単独故障、ソフトウェア故障による故障を回避できるか
    • ソフトウェアの再利用性、テスト容易性、変更可能性、拡張性、互換性、移植性をレビューします。
    • パフォーマンス、セキュリティ対策、運用機能の実装のレビュー
  • プログラムが設計仕様に従って正しく実行されることをプログラム品質と呼びます
    • ソフトウェア自体の構造、動作環境のインターフェース、変更の影響に基づいてアクティビティをレビューします。
    • 構造：機能構造、機能の一般性、モジュールの階層（静的）、モジュール構造、処理の構造
      • モジュール構造: 制御クラス構造、データフロー構造、モジュール構造、関数構造間の直接対応
    • と動作環境の構造
      • ハードウェアとのインターフェース、ユーザーとのインターフェース
    • 正式な技術レビューの目的は、ソフトウェアのバグを見つけることです。

• ソフトウェアフォールトトレランステクノロジー

  • フォールト トレランスを実現する主な手段は冗長性です。構造的冗長性 (静的動的冗長性、ハイブリッド冗長性)、情報冗長性、時間冗長性、および冗長追加テクノロジです。
    

• ソフトウェアツール

  • ソフトウェアの開発、運用、保守、管理、サポートのプロセスにおける活動を支援するために使用されるソフトウェア
  • ソフトウェア開発ツール
    • 要件分析ツール、設計ツール、コーディングおよびデバッグ ツール、テスト ツール
  • ソフトウェアメンテナンスツール
    • バージョン管理ツール、ドキュメント分析ツール、開発リポジトリ ツール、リバース エンジニアリング ツール、リエンジニアリング ツール

• 拡大

  • オブジェクト指向方式には、Booch 方式、Coad 方式、OMT 方式が含まれます。
  • ソフトウェアの複雑さの指標: サイズ、構造、難易度、インテリジェンス
  • ソフトウェアエンジニアリングの基本要素: 手法、ツール、プロセス