ソフトウェア エンジニアリング - 試験の重要ポイントの概要

概要

• ソフトウェアエンジニアリングとは何ですか? エンジニアリング手法を使用してソフトウェアを開発することです

• ソフトウェアエンジニアリングの目標: 十分に優れたソフトウェアを作成すること

• ソフトウェア エンジニアリングの定義: ソフトウェア エンジニアリングは、コンピューター ソフトウェアの開発とメンテナンスを指導する工学分野です。高品質のソフトウェアを経済的に開発し、効果的に保守するために、エンジニアリングの概念、原則、技術、および方法を使用してソフトウェアを開発および保守し、長年の実績と実証済みの正しい管理手法と現在利用可能な最良の技術的手法を組み合わせます。

• ソフトウェア エンジニアリング プロセスとは、ライフ サイクルにおける特定の目標を達成するための一連の関連アクティビティを指します。

• ソフトウェアエンジニアリング手法には、ソフトウェア開発手法、ソフトウェア測定手法、ソフトウェア管理手法、ソフトウェア環境手法が含まれます。

• ソフトウェア = プログラム + データ + ドキュメント

• ソフトウェアの本質的な特性: 複雑さ、変動性、不可視性、一貫性

• ソフトウェアクライシス: コンピュータソフトウェアの開発と保守において遭遇する一連の深刻な問題

• ソフトウェア開発プロセス: 問題定義、要件開発、ソフトウェア設計、ソフトウェア構築、ソフトウェアテスト

• ソフトウェアのライフサイクル：実現可能性調査とプロジェクト開発計画、要件分析、概要設計、詳細設計、ソフトウェア構築、テスト、保守

 

ウォーターフォールモデル

明確かつ完全なユーザー要件があり、大きな変更がないソフトウェア プロジェクト開発に適しています

ドキュメント駆動モデルであり、タスクの各段階が完了すると、対応するドキュメントが生成されます。

開発、初期計画と需要調査、製品テストの各段階に重点を置き、各活動で実施された作業をレビューします。

デメリット：理想的なリニア開発モデルであるため、要件が不明確または変化する問題を解決できない

 

ラピッドプロトタイピングモデル

これは、ユーザーが要件を完全かつ正確に説明できない場合や、開発者がアルゴリズムの有効性、オペレーティング システムの適応性、人間とコンピューターの対話形式を判断できない場合の多くの状況に適しています。ユーザーの一連の基本的なニーズに応じて。

ステップ 4: 簡単な分析

建設プロトタイプ

プロトタイプを実行して評価する

修正と改善

インクリメンタルモデル

段階的に洗練されたソフトウェア リリースを段階的に開発するためのモデル。開発するソフトウェア システムをモジュール化し、各モジュールを増分コンポーネントとして扱い、これらの増分コンポーネントをバッチで分析、設計、コーディング、テストします。

完全な機能が構築されるまで、新しいリリースごとに段階的に機能を追加します

 

 

アドバンテージ：

• 製品全体は多くの増分コンポーネントに分解されており、開発者はそれらを段階的に開発できます。

  • 作業の一部を短期間で完了できる製品をユーザーに提出し、バッチで段階的に提出します。ユーザーは、最初の成果物が配信されたその日から役立つ作業を行うことができます。

• コンポーネント単位で開発することでソフトウェア開発のリスクを軽減します。1 つの開発サイクル内のエラーは、ソフトウェア システム全体には影響しません。

• 開発順序は柔軟です。開発者はコンポーネントの実装順序に優先順位を付け、安定した要件を持つコアコンポーネントを最初に完成させることができます。コンポーネントの優先順位が変更された場合、実装順序を適時に調整できます。

• 製品の機能を徐々に増やすことで、ユーザーが新製品を学習して適応するための時間を増やすことができるため、新しいソフトウェアが顧客組織に与える影響を軽減できます。

困難：

• 新しい増分コンポーネントをそれぞれ既存のソフトウェア アーキテクチャに統合する場合、最初に開発された製品を破壊してはなりません。さらに、ソフトウェア アーキテクチャは、このように拡張を容易にするように設計する必要があり、既存の製品に新しいコンポーネントを追加するプロセスはシンプルかつ便利でなければなりません。つまり、ソフトウェア アーキテクチャはオープンでなければなりません。

• 開発者はソフトウェア システムを全体としてだけでなく、矛盾する独立したコンポーネントとしても考える必要があります。複数のコンポーネントが並行して開発されるため、統合できないリスクがあります。

• インクリメンタル モデルを使用するには、ウォーターフォール モデルやラピッド プロトタイピング モデルよりも慎重な設計が必要ですが、設計フェーズでの余分な労力はメンテナンス フェーズで報われます。

スパイラルモデル

• 大規模で複雑なシステムに適しています。

• リスク主導型

• スパイラル モデルはウォーターフォール モデルと増分モデルを組み合わせ、リスク分析を追加します。

• スパイラルモデルの基本的な考え方はリスクを軽減することです

各フェーズの前にリスク分析プロセスを追加するラピッドプロトタイピングモデルとして見ることができます

スパイラル モデルでは、開発プロセスを計画、リスク分析、実装エンジニアリング、顧客評価に分割します。

噴水モデル

主にオブジェクト指向開発プロセスをサポートするために使用され、反復的

ユーザーのニーズとオブジェクトによって推進される

反復モデル

最初に完全なシステムを提出し、後続のリリースで各サブシステムの機能を補完および改善します

 

 

RUP (Rational Unified Process、統合プロセス モデル)

• RUP は一連のサイクルを繰り返し、各サイクルはユーザーに製品が届けられることで終了します。

• 各サイクルは、開始、改良、構築、引き継ぎの4 つのフェーズに分かれており、各フェーズは 9 つのコア ワークフローを中心に繰り返されます。

• コア サポート ワークフロー:環境、プロジェクト管理、管理、および変更管理

• コアプロセスのワークフロー:導入、テスト、実装、分析と設計、ビジネスモデリング

1. 初期フェーズ: 問題定義を実行し、対象システムの範囲を決定し、その実現可能性を評価して、主要なリスクを軽減します。**3 セグメントのライフサイクル モデルにおける計画期間に相当します。

2. 改良段階:主にドメインの問題分析とソフトウェア設計を完了し、さまざまなリソースを構成し、システム アーキテクチャ (さまざまなビューを含む) を確立します。

3. 構築フェーズ:このフェーズは製品の製造プロセスであり、システムの実装とテストに重点を置き、コスト、スケジュール、品質を最適化するためのリソースの管理と運用の制御に重点を置きます。

4. 引き継ぎフェーズ: * *製品の発売、インストール、ユーザー トレーニング。**エンド ユーザーがソフトウェアを確実に使用できるようにすることに重点が置かれています。

特徴: ユースケーステクノロジーに基づいた、リスク主導型、アーキテクチャ中心型、反復的かつ構成可能なソフトウェア開発プロセス

アジャイル開発

人間中心、循環的反復、変化への対応などの特徴を活かし、お客様にご満足いただける実用的なソフトウェアを高品質かつ迅速に提供することに重点を置いています。

開発プロセスはドキュメント中心ではなくコード中心です

アジャイル開発では、ソフトウェア ライフ サイクル全体を複数の小さな反復 (2 ～ 4 週間) に分割します。各反復は小規模なウォーターフォール モデルであり、最後に安定した検証済みのソフトウェア バージョンを生成する必要があります。

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

コーディングを中心としたソフトウェア開発への柔軟なアプローチ

XPの目標: 曖昧で変化するユーザー ニーズを、可能な限り短期間でユーザーの要件を満たすソフトウェア製品に変換すること

RUP と XP の違い:

RUP は管理レベルを重視し、XP は実装レベルを重視します。この2つは相互に補完し合い、補い合う関係にあります。

RUP 管理フレームワークの下でのみ、XP を反復実装プロセスに採用し、XP の「高速な」役割を果たすことができます。

実現可能性調査

技術的実現可能性、社会的実現可能性、経済的実現可能性

3 つの結論: 実現可能、基本的に実現可能、実現不可能

ソフトウェア要件の分析

• ビジネスニーズ

• ユーザーのニーズ

• システム要件

• 機能要件

プロセス: 要件の取得 -> 分析とモデリング -> 文書作成 -> 要件の検証 -> 要件の変更

UML

構成する

ビュー: ユースケースビュー、デザインビュー、プロセスビュー、実装ビュー、デプロイメントビュー

写真：

• ユースケース図

• 静的図: クラス図、オブジェクト図、パッケージ図

• 動作図: 状態図、アクティビティ図

• 相互作用図：シーケンス図、連携図

• 実装図: コンポーネント図、展開図

モデル要素: 基本要素、ステレオタイプ要素

一般的なメカニズム

ユースケース図

 

ユースケース間の関係

1. 含む

　　包含関係とは、ユース ケースが他のユース ケースの動作を単純に包含し、それに含まれるユース ケースの動作を自身の動作の一部として使用できることを意味します。UML では、包含関係は、矢印と単語 <> を付けた点線セグメントで表され、矢印は基本ユース ケース (Base) から含まれるユース ケース (Inclusion) を指します。

　　包含関係を扱う場合の具体的な方法は、複数のユースケースの共通部分を抽象化して新しいユースケースにすることです。包含関係の使用が必要となる主な状況は 2 つあります。

• まず、複数のユース ケースが同じ動作を使用する場合、この共通の動作を 1 つのユース ケースに抽象化し、他のユース ケースにこのユース ケースを含めることを許可できます。

• 2 つ目は、特定のユース ケースの機能が多すぎてイベント フローが複雑すぎる場合、記述を簡素化するために、特定のイベント フローを含まれるユース ケースに抽象化することもできます。

　　

　　

1. 拡大

　　一定の条件下で既存のユースケースに新たな動作を追加し、得られた新たなユースケースを拡張ユースケース(Extension)、元のユースケースを基本ユースケース(Base)と呼び、拡張ユースケースから拡張ユースケースへの関係を表す。基本的な使用例は拡張関係です。基本ユース ケースには 1 つ以上の拡張ユース ケースを含めることができ、これらの拡張ユース ケースは一緒に使用できます。

3. 一般化

　　ユース ケースの一般化とは、親ユース ケースを特殊化して複数のサブ ユース ケースを形成できることを意味し、親ユース ケースとサブ ユース ケースの関係が一般化関係となります。ユースケースの一般化関係では、子ユースケースは親ユースケースのすべての構造、動作、関係を継承し、子ユースケースは親ユースケースの特別な形式です。サブケースは、継承された動作を追加、上書き、変更することもできます。UML では、ユース ケースの汎化関係は、子ユース ケースから親ユース ケースを指す三角形の矢印で表されます。

　　一般的な例: 銀行預金には 2 つの方法があり、1 つは銀行窓口預金、もう 1 つは ATM 機械預金です。ここで、銀行窓口預金と ATM 機預金はどちらも特別な入金方法であるため、「預金」が親ユースケースで、「銀行窓口預金」と「ATM 機預金」が子ユースケースです。

例：

クラス図

クラス図の主な目的は、クラスの構造 (属性、操作) とクラス間の関係を反映することであり、ソフトウェア システムの構造を記述する静的モデリング手法です。

クラス図の「クラス」は、現実世界の物事を抽象化したオブジェクト指向言語の「クラス」の概念に対応します。

仕様

1. 単一の単語の属性名を小文字にします。

2. 属性名が複数の単語で構成されている場合は、最初の単語を除いて複数の単語を結合します。他の単語の最初の文字は大文字にします。

3. 属性の構文: VisibilityName:Type=DefaultValue[ConstraintCharacteristics]

• 可視性は、属性がクラス外の要素に表示されるかどうかを示します。一般的に使用されるのは、パブリック (+)、保護された (#)、およびプライベート (-) です。

• Name は属性の名前を示す文字列です。

• Type は属性の種類 (基本タイプまたはカスタム タイプ) を定義します。

• デフォルト値は、属性の初期値を表します。

制約プロパティ表現は、属性の制約を記述します。

クラス図の内容

(1種類

1. 上からクラス名、属性、操作の 3 つの部分に分かれています。クラス名は必須です

2. クラスに属性がある場合、各属性には名前が必要です。また、可視性、データ型、デフォルト値などの他の説明情報も含めることができます。

3. クラスにオペレーションがある場合、各オペレーションには名前もあり、その他のオプション情報には、可視性、パラメータ名、パラメータのタイプ、パラメータのデフォルト値、オペレーションの戻り値のタイプなどが含まれます。

(2) インターフェース

一連の操作。操作の宣言のみで実装はありません。

(3) 抽象クラス

インスタンス化できないクラスには、通常、少なくとも 1 つの抽象操作が含まれています。

(4) テンプレートクラス

コンパイル時にテンプレート パラメーターをさまざまなデータ型にバインドし、さまざまなクラスを生成するパラメーター化されたクラス

3. クラス図における関係と説明

(1) 関連関係 - クラスの構造間の関係を記述します。方向、名前、役割、多重度などの情報があります。一般的な関連付けのセマンティクスは弱いです。

また、集約と結合という 2 つの強力なセマンティクスもあります。

1. 集約関係 - 集約 (全体) とそのコンポーネントの間の関係を示す特別な関連関係

   

2. 構成関係 - より強力なセマンティクスを持つ集合体、部分と全体が同じライフサイクルを持つ

(2) 一般化関係——※オブジェクト指向では、親クラスとサブクラス、親インターフェースとサブインターフェースの間に存在する一般に継承関係と呼ばれます。

(3) 実装関係 - クラスとインターフェースの関係に相当

(4) 依存関係 - ※ は、クラスの変更が、そのクラスに依存するクラスに影響を与える状況を示します。束縛（束縛）、友人（ともだち）など様々な表現があります。

例：

状態図

イベントに応じてオブジェクトが存続期間中に経験する一連の状態と、それらのイベントに対するオブジェクトの応答について説明します。

フローチャート

シーケンス図は、ユースケースにおけるアクションのシーケンスを表すために使用されます。シーケンス図内の各メッセージは、ユースケース動作の実行時にステート マシンに遷移を引き起こすクラス操作またはイベントに対応します。

 

 

連携図

コラボレーション図は、メッセージを送受信するオブジェクト間の組織構造を強調する対話図であり、コラボレーション図を使用してシステムのダイナミクスを示します。

アクティビティ図

例：

オブジェクト指向ソフトウェアエンジニアリング手法

• オブジェクト指向分析 (OOA)

• オブジェクト指向設計 (OOD)

• オブジェクト指向プログラミング (OOP)

• オブジェクト指向テスト (OOT)

オブジェクト指向手法でソフトウェアを開発するには、通常、次の 3 種類のモデルを確立する必要があります。

• システムの機能を説明する機能モデル

• システムのデータ構造を記述するオブジェクト モデル

• システムの制御構造を記述する動的モデル

ソフトウェア設計

ソフトウェア設計には、構造設計と詳細設計の 2 つの部分があります。

• システムの構造設計（アーキテクチャ設計）は、全体設計、概要設計とも呼ばれます。(データ/クラス設計、ソフトウェアアーキテクチャ設計、インターフェース設計を含む)

• システムの手順設計は、詳細設計（コンポーネントレベルの設計を含む）とも呼ばれます。

概要設計（全体設計、構造設計）：

システム全体の設計書と各モジュールの概要設計書を含みます。要求仕様書に基づいて、システムのアーキテクチャ、機能モジュールの分割、モジュールインターフェースの定義、ユーザーインターフェースの設計、データベースの設計などを記述します。

詳細設計（工程設計）：

概要設計に基づくモジュール分割に応じて、各モジュールのアルゴリズム設計を実現し、ユーザーインターフェース設計、フォーム、必要なデータ、データ構造設計などの洗練を実現します。

オブジェクト指向設計

主な特徴は次のとおりです。メンテナンスが簡単

データの永続性

ふたつのやり方：

• データベース管理システム (DBMS)

• ファイルストレージモード

MVC構造

モデルオブジェクト

ビュー (VIew) オブジェクト

コントローラー(コントロール)オブジェクト

 

オブジェクト指向の詳細設計

ここでは主に、次のようなコンポーネント内の各クラスについて詳しく説明します。

• 属性のデータ構造設計

• メソッド設計

• インターフェースの実装に必要なメカニズムの設計

プログラムフローチャート

 

例：

 

NS図（わかる）

 

判定表

 

デシジョンツリー

 

ノート

に分け：

• プリアンブル コメント (プログラムの冒頭) には次のものが含まれます。

  1. 番組タイトル。

  2. このモジュールの機能と目的の説明。

  3. メインアルゴリズム;

  4. インターフェイスの説明: 呼び出しフォーム、パラメータの説明、サブルーチン リストを含む。

  5. 関連データの説明: 重要な変数とその使用法、制約または制限、およびその他の関連情報。

  6. モジュールの場所: どのソース ファイル、またはどのソフトウェア パッケージに属しているか。

  7. 開発履歴書: モジュール設計者、レビュー担当者、レビュー日

• 機能コメント（プログラム本体内）

プログラムまたはステートメントが何を行うのかを説明する

データが示している

 

1 つのステートメントで複数の変数名を宣言する場合は、変数をアルファベット順にリストする必要があります。

ソフトウェアテスト

ソフトウェア テストは、ソフトウェア開発のライフ サイクル全体を通じて実行されます。

テストではプログラムのバグを見つけることしかできませんが、バグが見つからなかった場合、プログラムにバグがないことを証明することはできません。

バグを見つけることはソフトウェア テストの最終目標ではありません。テスト段階の基本的な目標は、ソフトウェア内の隠れたエラーをできるだけ多く見つけて、最終的に高品質のソフトウェア システムをユーザーに提供することです。

ソフトウェア テストの目的は、ソフトウェアのエラーと欠陥を見つけて修正し、適切なテスト ケースを設計し、できるだけ多くのソフトウェア エラーを見つけるためにできるだけ少ないテスト ケースを使用することです。

分類：

• 単体テスト（プログラムモジュールの正当性のテスト）（単体）

• 統合テスト（増分統合法と非増分統合法）（一部）

• システムテスト（全体）

• 受け入れテスト (積極的なユーザー参加、またはユーザー中心のテストが必要) (ユーザー参加)

 

ソフトウェア製品を分析するプロセスは静的テストと呼ばれ、ソフトウェアを実行するテスト プロセスは動的テストと呼ばれます。

検証によって製品が正しいことが確認され、検証によって正しい製品が製造されたことが確認されます。

 

静的テスト

手動分析またはプログラムの正しさの証明によってプログラムの正しさを確認します。

机上検査、コードトリアージ、歩行検査

動的テスト

データを入力し、ソフトウェアを実行し、実行ステータスと結果を観察することにより、ソフトウェアの動的な動作と実行結果の正確さを検証します。

ホワイトボックステスト (製品の既知の内部作業プロセス):

 

ブラックボックステスト（既知の製品機能）

等価分類法: プログラムの内部構造に関係なく

境界値解析方法（テストデータとして境界値と完全に等しい、境界値より大きい、または小さいを選択）

悪い推測: 経験的

因果関係グラフ法（複数の入力条件の組み合わせを記述し、それに応じて複数のアクションを生成してテストケースを設計し、最終的にデシジョンテーブルを生成する）

統合テスト

非増分テスト:

システムを統合するためのワンステップ方式を採用し、各モジュールの単体テストに基づいて、設計要件に従ってすべてのモジュールを組み立てます

増分テスト:

トップダウンの組み合わせ: ドライバー モジュールを作成する必要はなく、スタブ モジュールのみを作成する必要があります。

ボトムアップの組み合わせ: ドライバー モジュールを記述するだけで済みます

アルファテストとベータテスト

• アルファテスト: 開発者は、間もなく発売されるソフトウェア製品をテストするためにユーザーをシミュレートします。開発者は、使用中に見つかったエラーや発生した問題を記録する必要があり、テストは制御された環境で実行されます。

• ベータテスト: 1 つ以上の顧客サイトでソフトウェアのエンド ユーザーによって実施されます。ベータ テストは、開発者の制御を超えた環境でのソフトウェアの「実際の」アプリケーションです。ユーザーは、ベータ テスト中に発生したすべての問題 (現実または想像) を記録し、これらの問題を定期的に開発者に報告します。ベータ テスト中に報告された問題を受け取った後、開発者はソフトウェア製品に必要な変更を加え、最終ソフトウェア製品をすべての顧客にリリースする準備をします。

回帰試験

• 回帰テストは、デバッグやその他の理由による変更が予期しないソフトウェアの動作や追加のエラーにつながらないことを確認するために使用されるテスト活動です。

• 回帰テストとは、変更によって意図しない副作用が生じていないことを確認するために、すでに行われたテストのサブセットを再実行することを指します。

オブジェクト指向テスト

ストラテジー：

• クラス内テスト: クラス内のメソッド テストとクラス動作テストを含む、単体テストに相当します。

• クラス間テスト: 統合テストに相当し、独立クラスと依存クラスを含むクラス間の関係に従って組み立てる必要があります。

• シナリオベーステスト：確認テストやシステムテストに相当します。

ホワイトボックステストとブラックボックステスト手法はオブジェクト指向テストにも適用可能

ソフトウェアのデバッグ

デバッグは、テストでエラーが見つかった後にエラーをトラブルシューティングするプロセスです

方法：

• 残忍な方法 --- ポイントバイポイント (シングルステップ) 追跡

• バックトラッキング --- 制御の流れに沿ってエラーのポイントからバックトラッキングします。

• 原因の除去 --- 二分探索、帰納、演繹

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

ドキュメントはソフトウェアの保守性に影響を与える決定要因です

メンテナンスプロセス:

 

タイプ：

• 修正メンテナンス (ソフトウェアのエラーを特定して修正し、ソフトウェアのパフォーマンスの欠陥を修正し、実装時の誤用を排除するため)

• 適応型メンテナンス (変更に適応するためにソフトウェアを変更する)

• 拡張と整合性維持（ユーザーによる新機能・性能要件の提案）

• 予防保守 (ソフトウェアの保守性と信頼性を向上させるために、将来のソフトウェアのさらなる改善に向けた良い基盤を築きます) (ソフトウェア リエンジニアリングとも呼ばれます)

非構造物メンテナンス

• ソフトウェアの構成にはソース コードのみが含まれます。

• 分析・設計書がないのでプログラムの機能を逆に辿ることはできず、他人のコードを理解するのは非常に骨が折れます。

• 構成にはテストに関するドキュメントがないため、保守されているコードは回帰テストできません。その結果、プログラムの構造が常に破壊され、メンテナンスの品質が保証されなくなります。

構造メンテナンス

• 保守対象のソフトウェアの設定が完了しました。

• ユーザーが提出したメンテナンス申請は、フォワードトラッキングにより分析設計書からコードまで容易に追跡できるため、メンテナンス者はコードのメンテナンスポイントを容易に特定できます。したがって、このメンテナンスによってソフトウェアの構造が破壊されることはありません。

• 計画的なメンテナンスは、メンテナンスの負荷を軽減するだけでなく、メンテナンスの品質を向上させることができます。

ソフトウェア システムのドキュメントの種類

• ユーザードキュメント: 主にシステムの機能と使用方法について説明しており、それらの機能がどのように実装されているかは問われません。

• システム ドキュメント: システムの設計、実装、テストのあらゆる側面について説明します。

ソフトウェアのリエンジニアリング

予防保守はソフトウェア リエンジニアリングとも呼ばれます。機能を変更せずに既存のシステムの一部または全体をリファクタリングまたは書き換えることを指します。

目的：

• システムをより保守しやすくするために、システムを再構築し、文書化する必要があります。

• リスクの軽減: 稼働中のシステムの再開発は非常に危険であり、開発上の問題、人材の問題、仕様上の問題が発生する可能性があります。

• 低コスト: リエンジニアリングのコストは、ソフトウェアの再開発のコストよりもはるかに小さくなります。

リファクタリング

ソフトウェアの既存の機能を変更しないことに基づいて、プログラムコードを調整することによってソフトウェアの品質とパフォーマンスが向上し、プログラムの設計モードと構造がより合理的になり、ソフトウェアの拡張性と保守性が向上します。改善されています。

リファクタリングでは次の 2 つの点に注意する必要があります。

1. システムの核となる価値を変えずに維持する

2. リスクに注意する