ソフトウェア危機
ソフトウェア危機の定義
ソフトウェアの開発や保守の過程で遭遇する一連のトラブル
ソフトウェア危機の兆候
- 高コスト
- ソフトウェアの品質は保証されません
- 制御不能な進歩
- 維持するのが非常に難しい
ソフトウェア危機には 2 つの問題が含まれています
- 増大し、ますます複雑化する要件を満たすソフトウェアを開発する方法
- 増え続けるソフトウェア製品を維持する方法
ソフトウェア危機の原因
- 高い複雑さ
- 大規模な
- ソフトウェアの生産性と品質に影響を与える要因は複雑です
- 効果的なシステムの原則、原則、方法、ツールによる指導と支援の欠如
ソフトウェア危機に対する技術的解決策
- 1968年にソフトウェア工学の概念と思想が提案された
- 1970 年代の構造化されたソフトウェア開発手法
- 1980年代のオブジェクト指向ソフトウェア開発手法
ソフトウェアエンジニアリングの定義
ソフトウェアエンジニアリングは、ソフトウェア開発とソフトウェア管理を研究する工学分野です。
ソフトウェアエンジニアリングの基礎
- ソフトウェアライフサイクルの各段階の計画に基づいて厳密に管理します
- ステージレビューに従う
- 厳格な製品管理の実施
- 最新のプログラミング技術を使用する
- 開発チームのメンバーは少なくても良い方がよい
- 結果は明確に精査可能である必要があります
- ソフトウェアエンジニアリングの実践を継続的に改善する必要性を認識する
ソフトウェアのライフサイクル
ソフトウェアライフサイクルの意味を提案する
- ソフトウェア開発プロジェクト全体の難易度を軽減します。
- 分業と異なる担当者間の協力を促進する
- あらゆる段階で先進的な開発手法とテクノロジーの導入を促進します。
- ソフトウェア開発プロセス全体の組織化と管理を促進します。
ソフトウェアプロセスの定義
ソフトウェア プロセスは、高品質のソフトウェアを構築するために完了する必要があるタスクのフレームワークです。つまり、中間製品、リソースの役割、メソッド、ツールなどを含む、ソフトウェア製品を形成するための一連の手順です。
ソフトウェア機能成熟度モデル (CMM)
(1) 初期レベル
作業に順序が狂い、
プロジェクトの途中で当初の計画が放棄されることが多い (2) 再現可能なレベル
管理が制度化され、基本的な管理システムと手順が確立され、管理作業に従うべきルールがある
(3)定義されたレベルが
確立されている 完璧なトレーニングシステムと専門家によるレビューシステムが確立されており、すべての技術活動と管理活動が管理されている
(4) 管理レベル
製品とプロセスが定量的な品質目標を確立し、プロセスデータベースが確立されており、プロジェクトの製品とプロセスの管理が達成されている
(5) ) 最適化レベル
新しい技術や手法を採用してプロセスを改善することに集中できる
ウォーターフォールモデル
特徴
- 順序と依存関係
- 実現の延期の観点
- 文書主導で、各段階で所定の文書を完成させる必要があります
- エラーを早期に修正するために、各フェーズが終了する前にドキュメントのレビューを完了します。
欠点がある
- 柔軟性の欠如、要件フェーズではすべての要件が必要になる
- プログラムの実行バージョンは、プロジェクト開発の後期段階でのみ入手できます。
- 線形モデルを使用してプロジェクト開発を組織すると、開発チームのスタッフが混雑することがよくあります
該当シーン
- 製品要件が決定され、技術的ソリューションが成熟している
- 開発チームの技術力が弱く、経験も浅い
- 品質要件はコスト要件やスケジュール要件よりも高い
ラピッドプロトタイピングモデル
プロトタイプ
ソフトウェア開発プロセスにおいて、最終システムのいくつかの重要な特性を反映するソフトウェアの初期の作業バージョン
試作モデルの分類
- 使い捨てプロトタイプ
- 進化のプロトタイプ
アドバンテージ
- 行うことによって学びます
- 顧客関係を改善する
- 主要な要件が正確であることを確認する
- ウォーターフォール モデルの欠点を克服し、不確実な要件によって引き起こされる開発リスクを軽減します。
- プロセスの文書化を削減
欠点がある
- 実行中に変更を加えることになりやすい
- プロトタイプの構築には 10% の追加料金がかかります
- プロトタイプの反復サイクルを制御するのが難しい
該当シーン
- プロジェクトの要件はプロジェクトの開始時点では明確ではありません
- 新製品の開発と技術的実現可能性の検証
インクリメンタルモデル
最初にシステム サブセットの開発を完了し、次に同じ開発手順に従ってシステム サブセットを増やし、すべてのシステム要件が満たされるまでこれを繰り返します。
インクリメント
ユーザーのニーズの一部を満たし、特定の機能を完了できる小さいながらも使用可能なソフトウェアです
各増分はウォーターフォール モデルの重要なコンポーネントです
アドバンテージ
- お客様はシステム全体が実装されるまで待つ必要はありません
- 初期の増分をプロトタイプとして使用して、後の増分で経験を積むことができます
- プロジェクト失敗の全体的なリスクは比較的低い
- システム アーキテクチャは最も多くのテストを受けます
欠点がある
- 開発するソフトウェアシステムはモジュール化できることが求められる
該当シーン
- ほとんどの要件はプロジェクトで指定されていますが、要件は変更される可能性があります
- 市場やユーザーを正確に把握しておらず、できるだけ早く市場に参入したいと考えている
スパイラルモデル
スパイラル モデルは、従来のウォーターフォール モデルとラピッド プロトタイピング モデルの利点を組み合わせ、リスク分析
ウォーターフォール モデル + ラピッド プロトタイピング モデル + リスク分析を追加します。
アドバンテージ
- サポート要件の動的な変更
- ソフトウェアのバグを早期に検出する
- リスク分析をサポート
欠点がある
- リスク分析にはリスク評価に関する豊富な知識と手法が必要です
該当シーン
- 要件が明確でない、または変更される可能性がある大規模で複雑なソフトウェア システム
- 広い視野でプロセス指向とオブジェクト指向の開発手法をサポート
統合プロセスモデル RUP
最新のソフトウェア開発のベスト プラクティスをキャプチャします。
問題定義
問題定義とは何ですか
- プロジェクトの範囲を確立し、開発する新しいシステムの問題領域を特定する
- プロジェクトの機能分割
問題定義に関する重要な質問
- 問題の解決方法
- 問題の主要な問題を自然言語で明確に説明する
- 問題定義の例
問題定義レポート
実現可能性調査
実現可能性調査の前提条件
- 問題の定義が明確であると仮定すると、
- すべての問題に対する解決策はあるのでしょうか?
実現可能性調査の目的
- 最小限のコストで最短時間で問題に実行可能な解決策があるかどうかを判断する
実現可能性検討内容
- 経済的実現可能性
- 技術的な実現可能性
- 運用可能性
- 社会的実現可能性
フィージビリティスタディの特徴
- 問題を解決するのではなく、解決可能かどうかを判断する
- 総費用の5%～10%
- 実現可能性調査は通常、システム アナリストによって行われます。
実現可能性調査の手順
- システムの規模と目標を確認する
- 現在使用されている研究システム
- 新しいシステムの高レベルの論理モデルを決定する
- 問題を再定義する
- 推奨される行動方針
- ソフトウェアプロジェクト開発計画の草案
- 実現可能性調査レポートを作成し、レビューのために提出します
システムフローチャート
システム フロー図 SFD は、実現可能性検討段階でシステムの物理モデルを記述するために使用されます。
費用便益分析
費用便益分析では、新しいシステムを開発することが経済的な観点から費用対効果が高いかどうかを分析し、顧客組織の担当者がソフトウェア開発に投資するかどうかの正しい判断を支援します。
原価見積
- ソフトウェアの原価は主に人件費であるため、原価見積は主に作業量を見積もる
- ソフトウェアの開発や保守の作業量を見積り、各職種の作業量の割合を算出し、各職種の給与総額を算出し、人件費を算出します。
需要分析
需要の問題
- 要件はソフトウェア プロジェクトの成功または失敗の鍵です
- 要件のエラーが早く見つかるほど、修正も早くなり、コストも低くなります。
- 要件とは、システムが備えなければならない機能です
- 良い要件の特徴: 明確、完全、一貫性、テスト可能、確実、追跡可能、正確、
要件定義
- 問題を解決したり目標を達成したりするためにユーザーが必要なもの
- システムまたはシステムコンポーネントが契約、標準、仕様、またはその他の正式に指定された文書を満たすために必要な条件
- 上記の両方の条件を反映するドキュメント
需要の性質
- 必要
- 明確な
- 測定可能な
- 追跡可能
ニーズの分類
- ビジネスニーズ
- ユーザーのニーズ
- ソフトウェアの機能要件
- 非機能要件
ビジネスニーズ
- 上位レベルの目標として表現された、システム確立の戦略的出発点
- システムに備えるべき機能
- 関係者全員が共通のビジョンを構築する
- システムの範囲を制限する
ユーザーのニーズ
- ユーザー要件とは、ソフトウェアを使用するときにユーザーが完了する必要があるタスクとその完了方法の説明を指します。
- 通常、ビジネス要件の定義に基づいて、ユーザーインタビューやアンケートを通じて、ユーザーが使用するシナリオを整理し、ユーザーの視点で要件を確立します。
- ユーザー要件は要件をキャプチャした結果です
機能要件
- ソフトウェアの機能要件は、システムの動作に直接マッピングでき、システムに実装する必要がある機能を定義し、開発者が達成する必要があるものを記述します。
- ユーザー要件をソフトウェアの機能要件に変換するプロセスは複雑なプロセスです
非機能要件
- スピード
- 容量
- スループット
オブジェクト指向の提案
- 第一段階：計算を中心に、
プログラムの動作効率やアルゴリズムのメリット・デメリットを中心に分析・設計を行う - 第 2 段階: プロセス中心
データ フローを中心に分析と設計が実行され、ビジネス プロセスがデータ フローによってシミュレートされます。プロセス指向設計は、ソフトウェア構造を構築するためのプログラム モジュールに基づいています
代表的なモデル: ER 図、データ フロー図、状態遷移図、デシジョン テーブル、デシジョン ツリー
オブジェクト指向の利点
- 認知の観点から見ると、オブジェクト指向の方法は、人々が客観的な世界を理解する法則に準拠しています。
- オブジェクト指向手法で開発されたソフトウェアシステムは保守が容易で、アーキテクチャの理解、拡張、変更が容易です。
- オブジェクト指向方式の継承メカニズムはソフトウェアの再利用を強力にサポートします