1. ソフトウェアとソフトウェア危機

1. ソフトウェア開発は、プログラム設計、プログラムシステム、ソフトウェアエンジニアリングの 3 つの段階を経ます。

2. ソフトウェアの概念: ソフトウェアは、プログラム、データ、および関連ドキュメントの完全なコレクションを含む、コンピューターシステムとハードウェアの相互依存関係のもう 1 つの部分です。ソフトウェア = プログラム + データ + ドキュメント

data : プログラムが情報を適切に処理できるようにするデータ構造
プログラム: 所定の機能および性能を達成することができる実行可能な一連の実行
ドキュメント: プロセスプログラムロックの開発、使用、保守に必要なグラフィック資料

3. ソフトウェアの特徴:

ソフトウェア自体の複雑さ
ソフトウェアは高価です
ソフトウェア開発でも手動開発が不要になったわけではない
ソフトウェアの保守はハードウェアとは根本的に異なるため、保守が困難
ソフトウェア開発には従来のハードウェア製造プロセスが導入されています
ソフトウェアは論理的なエンティティであり、摩耗性はありません

4. ソフトウェア危機の概念:コンピュータソフトウェアの開発および保守の過程で遭遇する一連の深刻な問題。2 つの側面:

増大するソフトウェア需要を満たすソフトウェアを開発する方法
増え続ける既存のソフトウェアを維持する方法

5. ソフトウェア危機のパフォーマンス:

ソフトウェア開発コストとスケジュールの不正確な見積もり
ユーザーは完成したソフトウェアに不満を抱いている
ソフトウェアの品質が信頼できない
適切な文書がない
コンピュータシステムに占めるソフトウェア費用の割合は年々増加しています
ソフトウェア開発の生産性が低い

6. ソフトウェア危機の理由:

主観的な理由

ニーズ分析を無視する
ソフトウェアのメンテナンスを軽視する
プログラムはソフトウェアの一部にすぎないことを理解していない
ソフトウェア開発は、長いソフトウェアライフサイクルの中で比較的小さな段階にすぎないことを認識していない
変更の導入が遅くなるほどコストが高くなる

客観的な理由:

ソフトウェアは論理的なエンティティであり、可視性に欠けており、管理と制御が困難です
ソフトウェアは磨耗せず、メンテナンスは元の設計を変更することを意味しますが、メンテナンスは困難です
ソフトウェアの規模は巨大であり、規模が大きくなるにつれてプログラムの複雑さは指数関数的に増加します

7. ソフトウェア危機を解消する方法:

コンピュータソフトウェアについて正しく理解する
人類が長年にわたってさまざまなエンジニアリングプロジェクトに従事してきた原理、概念、技術、手法から学ぶ
コンピュータ支援開発ツールの累積的な開発と使用
より優れた効果的な管理手段と、開発プロセスを制御および管理する手段を検討する

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

1.定義:ソフトウェアの開発と保守にエンジニアリングの概念、原則、技術、および方法を使用し、長年の実績と実証済みの正しい管理技術と現在利用可能な最高の技術的方法を組み合わせ、ソフトウェアを高経済的にを開発し、保守する

2. ソフトウェアエンジニアリングの本質的な特徴:

大規模なプログラムの構築に重点を置く
中心的な問題は複雑さを制御することです
ソフトウェアは頻繁に変更されます
開発効率は非常に重要です
開発者間の調和のとれた協力が鍵です
ソフトウェアはユーザーを効果的にサポートする必要がある
ソフトウェア開発者は他の分野の人材に代わって製品を作成します

3. 基本原則:

ソフトウェアのライフサイクルに応じて段階的に計画を策定し、慎重に実装します。
ステージレビューに従う
厳格な製品管理を遵守します
最新のプログラミング技術を使用する
結果を明確にレビューできる
使用量は少なくても効果的
ソフトウェアエンジニアリングの実践を継続的に改善する必要性を認識する

4. ソフトウェアエンジニアリングの方法論:

ソフトウェアのライフサイクルのプロセス全体で使用される一連の技術手法の集合は方法論と呼ばれ、ジェネリックとしても知られています。

ソフトウェアエンジニアリングの方法論は、メソッド、ツール、プロセスの 3 つの要素で構成されます。

方法:ソフトウェア開発のさまざまなタスクを達成するための技術的方法
ツール:メソッドを適用するための自動または半自動のソフトウェアエンジニアリングサポート環境
プロセス:高品質のソフトウェアを入手するために完了する必要がある一連のタスクのフレームワーク

5. ソフトウェアのライフサイクル

3、ソフト

ファイルプロセス

ソフトウェアプロセスは、高品質のソフトウェアを入手するために完了する必要がある一連のタスクのフレームワークです。

ソフトウェアプロセスは通常、ソフトウェアライフサイクルモデルによって記述されます。

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

ソフトウェアライフサイクルのさまざまな取得は、いくつかの作業段階を一定の順序で接続することとして規定されており、最終的にソフトウェアが取得されます。

特徴：

フェーズ間のシーケンスと依存関係
実現の延期の観点
品質保証の視点
1. 必要な書類は各段階で完成する必要があります
2. エラーを早期に修正するために、各フェーズが終了する前にドキュメントのレビューを完了します。

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

実行可能なプログラムを迅速に構築し、完成させる関数は多くの場合、最終製品の関数のサブセットになります。

インクリメンタルモデル

分析、設計、コーディング、テスト、納品を段階的に分割します。各段階は完全なプロセスです。最初にシステムのサブセットの開発を完了し、次に同じ開発手順に従って機能を追加し、すべてのシステム要件を満たすまで繰り返します。満たされています。

利点: 一部の機能は短期間で送信して完了でき、メインキーにより製品の機能が向上し、ユーザーは製品にすぐに慣れることができます。

デメリット：段階的に構築する分割・統合が難しく、途中で修正するモデルに変質しやすい

よりリスクの高い増分モデルもあります。つまり、並行して実行すると効率が高くなりますが、組み合わせるのが難しい場合もあります。

スパイラルモデル

リスク分析プロセスのラピッドプロトタイピングモデルは、リスク分析のラピッドプロトタイピングモデルとして各段階の前に追加されます。

アドバンテージ：

ソフトウェア開発目標としてソフトウェアの品質を促進する
テストを減らす
保守と開発は分離されていない

デメリット：リスクの見積もりが難しい

噴水モデル

反復的でシームレスな機能を具体化した、典型的なオブジェクト指向ソフトウェアプロセスモデル

4. 実現可能性調査

目的: 問題を最小限のコストで最小限の時間で解決できるかどうかを判断する

本質: システム分析および設計プロセスは大幅に圧縮および簡素化され、システム分析および設計プロセスはより高いレベルで比較的抽象的な方法で実行されます。

プロセス：

問題定義を分析して明確にする
システムの論理モデル (データフロー図とデータディクショナリ) をエクスポートします。
論理モデルに基づいていくつかの代替ソリューションを検討する
各ソリューションの実現可能性を調査する
1. 経済的実現可能性: 経済的便益が開発コストを上回るかどうか
2. 技術的実現可能性: 既存の技術で実現可能
3. 運用可能性：システムの運用方法が実現可能かどうか
4. その他の実現可能性: 法的、社会的利益

費用対効果分析：新システムの開発が経済的な観点から採算がとれるかを分析し、ユーザー部門が投資すべきかどうかの正しい判断を支援します。

5. ソフトウェア設計段階

設計プロセス

全体設計は概要設計、予備設計とも呼ばれます。

タスク：

システムの各プログラムがどのモジュールで構成されているか、およびこれらのモジュール間の関係を決定します。
プログラム、ファイル、データベース、ドキュメントなどの物理的要素を分割します。

設計プロセスにはシステム設計フェーズと構造設計フェーズが含まれます

設計原理

基本単位
- モジュール: 個別に名前を付け、境界要素によって定義できる一連のプログラム要素は、プログラムの基本的な構成要素です。
- モジュール化: プログラムを独立して名前が付けられ、独立してアクセス可能なモジュールに分割します。各モジュールはサブ機能を完了し、これらのモジュールを統合して全体を形成し、ユーザーのニーズを満たすために指定された機能を完了できます。
抽象化: トランザクションの本質的な特徴を、当面は詳細を考慮せずに抽象化します。
段階的な改良: 根底にある詳細を徐々に明らかにします
情報の隠蔽とローカリゼーション
- 情報隠蔽: モジュールに含まれる情報を指し、この情報を必要としないモジュールはアクセスできません。主にモジュールの実装詳細を指します。
- ローカリゼーション: いくつかの密接に関連するソフトウェア要素を物理的に互いに近くに配置することを指し、これにより情報の隠蔽が実現されます。
モジュールに依存しない
- モジュールの独立性は、モジュール性、抽象化、情報の隠蔽、ローカリゼーションの概念の直接的な結果です。
- モジュールの独立性は優れた設計の鍵であり、設計はソフトウェアの品質を決定する重要な要素です
- メトリクス:結合、凝集

カップリング:ソフトウェア構造内の異なるモジュール間の相互接続プログラムの測定。カップリングの強さは、モジュールインターフェイスの複雑さ、インターフェイスを通過するデータなどによって異なります。結合度が高くなるほど、モジュールの独立性は弱くなります

カップリング分類 (低位から高位):

直接結合なし → データ結合 → マーカー結合 (機能結合) → 制御結合 → 外部結合 → パブリック結合

凝集性:モジュール内の各要素が緊密に統合されていることです。

凝集度の分類 (低度から高度):

偶発的凝集 → 論理的凝集 → 時間的凝集 → プロセスの凝集 → コミュニケーションの凝集 → 逐次的凝集 → 機能的凝集

他のモジュールと強く結合しているモジュールは結合力が弱いことを意味し、結合力が強いモジュールは他のモジュールと疎結合していることを意味します。

設計目標:高い凝集性、低い結合性

ヒューリスティックルール

ソフトウェア構造の改善とモジュールの独立性の向上

モジュールのサイズは適度である必要があります

深さ、幅、ファンインとファンアウトは適切である必要があります

Depth : ソフトウェア構造における制御の層の数を示します。
幅: ソフトウェア構造内の同じレベルにあるモジュールの総数の最大値。
ファンアウト: モジュールによって直接制御される (呼び出される) モジュールの数。過剰なファンアウトは、モジュールが複雑すぎることを意味します。一般に、適切に設計された典型的なシステムの平均ファンアウトは 3 または 4 であり、ファンアウトの上限は 5 ～ 9 です。
ファンイン: 上位レベルのモジュールがそれを呼び出す数を指します。ファンインが大きい場合は、モジュールを共有する上位レベルのモジュールの数を示します。ソフトウェア構造のトップレベルのファンアウトは比較的高く、中間のファンアウトは、レベルのファンアウトは比較的小さく、最下位モジュールのファンインは高くなります。

モジュールのスコープは制御ドメイン内にある必要があります

スコープ:モジュール内の決定によって影響を受けるすべてのモジュールのコレクションを指します。
制御ドメイン: モジュール自体と、そのモジュールに直接または間接的に従属するすべてのモジュールです。

モジュールインターフェイスの複雑さを軽減するよう努めます

入口と出口が 1 つずつあるモジュールを設計する

モジュールの機能は予測可能である必要があります

6. テスト段階

ソフトウェアのライフサイクルにおけるコーディングとテストは、実装と総称されます。

ソフトウェアテストは、バグを見つけるためにプログラムを実行するプロセスです

コーディングフェーズ (単体テスト)
テストフェーズ（各種総合テスト）

ソフトウェアテストの方法:

ブラックボックステスト：ソフトウェアを内部構造や処理プロセスに関わらずブラックボックスとみなして、仕様書に従ってのみ、ソフトウェアが入力データを正しく受け取り、正しい出力データを生成できるかどうか、つまりテストプログラムが正しいかどうかをテストします。正しく実装された関数
ホワイトボックステスト:プログラムの内部構造と処理アルゴリズムを完全に認識しているため、プログラムを透明なホワイトボックスとみなすことができ、プログラムの論理構造に従って、プログラム内のメイン実行パスが機能するかどうかをテストします。所定の要件に従って正確に構造試験を行う

ソフトウェアエンジニアリング | 最終レビュー