このコラムはブロガーの個人的なメモであり、主な目的は、断片的な時間を利用してソフトエンジニアリングの知識ポイントを暗記することです、ここに宣言します!
記事ディレクトリ
1. ソフトウェア エンジニアリングという分野はなぜ存在するのですか?
4. ソフトウェア危機にはどのような問題が含まれていますか?
12. ソフトウェアエンジニアリングの方法論/パラダイムの定義?
13. ソフトウェアエンジニアリング方法論の 3 つの要素は何ですか? そしてそれぞれの役割は何でしょうか？
16. オブジェクト指向の手法を使用する理由は何ですか? (従来の方法論の欠点)
18. オブジェクト指向メソッドのよく知られた方程式は何ですか?
19. 従来の方法論とオブジェクト指向の方法論のプロセスの比較は何ですか?
20. ソフトウェアのライフサイクルとは何ですか? 段階は何ですか?
22. ウォーターフォール モデルとラピッド プロトタイピング モデルの主な違いは何ですか?
23. 最も広く使用されているプロセスモデルであるウォーターフォールモデルの特徴は何ですか?
27. ラピッドプロトタイピングモデルが直線的に開発できる理由は何ですか?
28. ラピッドプロトタイピングモデルの長所と短所は何ですか?
32. ファウンテンモデルはどのタイプのプロセスモデルに属しますか? 特徴は何ですか? なぜそう言えるのですか？
35. Microsoft のプロセスに該当するシナリオは何ですか?
36. Rational 統合プロセスの長所と短所について議論してみますか? そしてどの項目が該当するのでしょうか？
37. ソフトウェアエンジニアリングの本質的な特徴は何ですか?
1. ソフトウェア エンジニアリングという分野はなぜ存在するのですか?
ソフトウェアをより効果的に開発および保守し、ソフトウェアの危機を排除する方法を研究するために、ソフトウェアエンジニアリングの分野が形成されました。
2. ソフトウェアの段階は何ですか?
- 特定のアプリケーションごとに特別に作成された小規模なプログラムでは、プログラム リストのみが保存されます。
- ソフトウェアワークショップ
- ソフトウェアエンジニアリング段階
3. ソフトウェア危機の定義?
ソフトウェア クライシスとは、コンピュータ ソフトウェアの開発と保守において遭遇する一連の深刻な問題を指します。ほぼすべてのソフトウェアには、程度の差こそあれ、これらの問題が存在します。
4. ソフトウェア危機にはどのような問題が含まれていますか?
- 増大するソフトウェア需要を満たすソフトウェアを開発する方法
- 増え続ける既存のソフトウェアを維持する方法
- ソフトウェア危機は長期にわたる不明確な症状を特徴とします
5. ソフトウェア危機の典型的な兆候は何ですか?
- ソフトウェア開発コストとスケジュールの見積もりは非常に不正確であることがよくあります
- 完成したソフトウェアシステムにユーザーが不満を抱くことがよくあります。
- ソフトウェア製品の品質は信頼できないことが多い
- ソフトウェアは保守できないことが多い
- ソフトウェアは適切に文書化されていないことがよくあります
- コンピュータシステムの総コストに占めるソフトウェアコストの割合は年々上昇しています
- ソフトウェア開発の生産性向上のスピードは、コンピュータアプリケーションの急速な普及と深化の傾向に遠く及ばない
6. ソフトウェア危機の理由は何ですか?
- ソフトウェア自体の複雑さの特性に関連する(根本原因)
- ソフトウェア開発とメンテナンスの間違った方法に関連する(主な理由)
7. ソフトウェア開発と保守に関する誤解と慣行?
主なパフォーマンスは、ソフトウェア要件分析の重要性を無視すること、ソフトウェア開発はプログラムを書いて実行させようとすることであると考えること、ソフトウェアのメンテナンスを軽視することなどです。
8. ソフトウェア製品の構成は何ですか?
主にプログラム、ドキュメント、データが含まれます
プログラムとは、あらかじめ決められた機能や性能を実現する、実行可能な一連の命令です。
データは、プログラムが情報を適切に処理できるようにするデータ構造です。
ドキュメントは、プログラムの開発、使用、保守に必要なグラフィックおよびテキスト情報です。
9. ソフトウェアエンジニアリングの定義は何ですか?
- ソフトウェアの開発、運用、保守のプロセスに体系的で標準化された測定可能なアプローチを適用する、つまりソフトウェアにエンジニアリングを適用する
- 研究 1 で言及された経路
10. ソフトウェア危機を解決するための対策は何ですか?
- 実際に要約されたソフトウェア開発の成功した技術と方法は促進され、使用されるべきであり、より良い、より効果的な技術と方法は研究され、探究されるべきです。
- より良いソフトウェアツールを開発して使用する必要がある
- 必要な組織管理措置が必要である
11. ソフトウェアエンジニアリングの基本原則は何ですか?
- 段階的なライフサイクル計画で厳密に管理
- ステージレビューに従う
- 厳格な製品管理の実施
- 最新のプログラミング技術を使用する
- 結果は明確に精査可能である必要があります
- 開発チームはもっと少ないが、より良いチームになるべきだ
- ソフトウェアエンジニアリングの実践を継続的に改善する必要性を認識する
簡単なメモ: 分割、コメント、制御、提示、調査、少ない、必須
12. ソフトウェアエンジニアリングの方法論/パラダイムの定義?
通常、ソフトウェアのライフサイクルのプロセス全体で使用される一連の技術手法の集合は方法論と呼ばれ、パラダイムとも呼ばれます。
13. ソフトウェアエンジニアリング方法論の 3 つの要素は何ですか? そしてそれぞれの役割は何でしょうか？
ソフトウェアエンジニアリングの 3 つの要素とは、方法、ツール、プロセスを指します。
メソッドとは、ソフトウェア開発のさまざまなタスクを完了するための技術的方法であり、 「それをどのように行うか」という質問に答えます。
ツールは、メソッドを適用するための自動または半自動のソフトウェア エンジニアリングサポート環境です。
プロセスは、高品質のソフトウェアを入手するために完了する必要がある一連のタスクのフレームワークであり、各タスクを完了するための作業手順を指定します。
14. 伝統的な方法論とは何ですか?
従来の方法論は、ライフ サイクル方法論または構造化パラダイムとも呼ばれ、構造化テクノロジーを使用してソフトウェア開発のさまざまなタスクを完了し、適切なソフトウェア ツールまたはソフトウェア エンジニアリング環境を使用して構造化テクノロジーの使用をサポートします。
15. 文書の役割は何ですか?
- ドキュメントはコミュニケーションツールです
- 書類はメモとしても機能する
- ドキュメント化によりソフトウェア開発プロセスの可視性が向上します
- ドキュメントには開発プロセスに関する情報が記録されます
- 文書は、段階的な作業の結果と完了の兆候として使用できます。
短いメモ: 合格、準備、学位、記録、マーク
16. オブジェクト指向の手法を使用する理由は何ですか? (従来の方法論の欠点)
欠点: 従来の方法論はデータ指向か処理指向のいずれかであり、ソフトウェアの規模が大きい場合、またはソフトウェアの要件が曖昧である場合、または時間の経過とともに変化する場合、従来の方法論を使用したソフトウェア開発は失敗することが多く、保守が困難です。
利点: ソフトウェアのライフサイクルはいくつかの段階に分かれており、各段階のタスクは比較的独立していて比較的単純であるため、分業とさまざまな担当者の協力が容易になり、それによってソフトウェア開発プロセス全体の難易度が軽減されます。従来の方法論を採用すると、ソフトウェア開発の成功率と生産性を大幅に向上させることもできます。
17. オブジェクト指向手法の長所と短所は何ですか?
アドバンテージ：
- ソフトウェア製品の複雑さの軽減
- ソフトウェアの理解しやすさの向上
- ソフトウェア開発とメンテナンスの簡素化
- ソフトウェアの再利用を促進します
欠点:
- オブジェクト指向の方法論とその独自の継承、ポリモーフィズム、その他のメカニズムにより、オブジェクト指向のテストとデバッグが困難になります
- オブジェクト指向アーキテクチャの設計は難しく複雑であり、システムに無理があるなどの問題が発生する可能性があります。
- オブジェクト指向の開発コストは高く、初心者の開発には向きません
18. オブジェクト指向メソッドのよく知られた方程式は何ですか?
オブジェクト指向方式 =オブジェクト + クラス + 継承 + メッセージ通信
19. 従来の方法論とオブジェクト指向の方法論のプロセスの比較は何ですか?
従来の方法論では、ソフトウェア開発タスクの各段階をトップダウンで順番に完了することに重点が置かれていました。
オブジェクト指向は、積極的に複数回反復される進化のプロセスであり、その独自の継承と多態性により、オブジェクト指向ソフトウェアの再利用性がさらに向上します。
20. ソフトウェアのライフサイクルとは何ですか? 段階は何ですか?
ソフトウェアのライフサイクルとは、ソフトウェア製品の開始からソフトウェアが削除されるまでのプロセス全体を指します。
問題定義、実現可能性検討、需要分析、全体設計、
詳細設計、コーディングと単体テスト、総合テスト、ソフトウェア保守
21. ソフトウェアプロセスとは何ですか?
ソフトウェア プロセスは、高品質のソフトウェアを取得するために完了する必要がある一連のタスクの枠組みであり、各タスクを完了するための作業手順を指定します。
22. ウォーターフォール モデルとラピッド プロトタイピング モデルの主な違いは何ですか?
ユーザーのニーズを得るさまざまな方法
23. 最も広く使用されているプロセスモデルであるウォーターフォールモデルの特徴は何ですか?
- フェーズ間のシーケンスと依存関係
- 実現の延期の観点
- 品質保証の視点
24. 実際のウォーターフォールモデル?
実際のウォーターフォール モデルは「フィードバック ループ」であり、ドキュメント駆動型のモデルであり、これが長所でもあり短所でもあります。
25. ウォーターフォールモデルの長所と短所は何ですか?
アドバンテージ：
- 開発者に規律あるアプローチの採用を強制する
- 各段階で提出しなければならない書類を厳密に規定する
- 各段階で引き渡されるすべての製品は、品質保証チームによって慎重に検証される必要があります。
欠点:
- 実際のプロジェクトのほとんどは、モデルによって与えられた順序に従うことが難しく、このモデルの反復は間接的であるため、小さな変更によって大きな混乱を引き起こしやすいです。
- 顧客が本当のニーズを表現するのは難しいことがよくありますが、このモデルではそれが必要であり、曖昧さの存在は歓迎されません。
- 顧客は、開発サイクルの後半になるまでプログラムの実行テスト バージョンを見ることはできません。この時点で重大なバグが発見されると、顧客はパニックを引き起こし、壊滅的な結果を招く可能性があります。
- ドキュメント駆動モデルです
26. ラピッドプロトタイピングモデルの本質とは何ですか?
ラピッドプロトタイピングモデルの本質は「フィードバックループ」を持たない「迅速さ」であり、開発は基本的に線形順序で実行され、ユーザーの真のニーズを確実に満たすことができるという利点があります。
27. ラピッドプロトタイピングモデルが直線的に開発できる理由は何ですか?
- プロトタイプ システムはユーザーと対話することによって検証されており、結果として得られる仕様書にはユーザーのニーズが正確に記載されており、後で作り直されることはありません。
- 開発者はシステムのプロトタイプを作成することで多くのことを学び、設計およびコーディング段階で間違いを犯す可能性が低くなります。
28. ラピッドプロトタイピングモデルの長所と短所は何ですか?
アドバンテージ：
- プロトタイプ システムはユーザーと対話することによって検証されており、結果として得られる仕様書にはユーザーのニーズが正確に記載されており、後で作り直されることはありません。
- 開発者はシステムのプロトタイプを作成することで多くのことを学び、設計およびコーディング段階で間違いを犯す可能性が低くなります。
- プロトタイピングにより、ユーザーによるシステムへの早期アクセスが可能になります
- プロトタイピング システムを使用してリスクを特定し、軽減できる
欠点:
- 製品に固有の欠陥。開発者は実装時に妥協する必要があり、プロトタイプをできるだけ早く完成させるために不適切なオペレーティング システムやプログラミング言語を使用する可能性があるためです。
- コストが高く、要件が確認されるとプロトタイプは廃棄され、資金の無駄になります。
- 開発プロセス管理に対する高い要件
29. インクリメンタル モデルの長所と短所は何ですか?
アドバンテージ：
- 部分的に完成した製品を比較的短期間でユーザーに届けることが可能
- 製品の機能を徐々に増やして、ユーザーが学習して適応するのに十分な時間を確保し、新しいソフトウェアによる影響を軽減します。
欠点:
- 開発者と顧客は完全版がリリースされるまでずっと絡み合いました
- ソフトウェア要件が不明確なソフトウェアプロジェクトや、一定のリスクを伴う設計スキームに適しています
- このアプローチを使用すると、開発プロセス全体を注意深く監視しない限り、コンポーネントが統合されず、プロジェクト全体が台無しになるリスクが生じます。
30. スパイラルモデルの構成は何ですか?
スパイラル モデルは、計画、リスク分析、実装エンジニアリング、顧客評価の 4 つの部分で構成されます。
スパイラル モデル = ウォーターフォール モデル + リスク分析用のラピッド プロトタイピング モデル
別の言い方: スパイラル モデル = ウォーターフォール モデル + リスク分析の増分モデル
31. スパイラルモデルの長所と短所は何ですか?
アドバンテージ：
- 既存のソフトウェアの再利用を容易にする
- ソフトウェア開発とソフトウェア保守を区別できないようにする
- ソフトウェア開発の重要な目標としてソフトウェアの品質に貢献する
- 過少テストのリスクを軽減
欠点:
- リスク分析と評価にはかなりの専門知識が必要であり、成功はそれに依存します。
- スパイラルモデルは、異なる世代が経験する 4 つの側面の内容と強調点の違いを特定していません。
- スパイラル モデルは、反復プロセスの最後に提供される増分プロトタイプの特定の要件には対応していません。
32. ファウンテンモデルはどのタイプのプロセスモデルに属しますか? 特徴は何ですか? なぜそう言えるのですか？
ファウンテン モデルは、典型的なオブジェクト指向ソフトウェア プロセス モデルであり、反復的かつシームレスです。
ファウンテン モデルがオブジェクト指向ソフトウェア開発プロセスのシームレスで反復的な特性をよく体現している理由は、オブジェクト指向手法を使用してソフトウェアを開発する場合、すべての段階で統一された概念とシンボルが使用されるため、開発プロセス全体がすべて一貫性のある、またはシームレスに接続されているため、当然のことながら、各開発ステップの繰り返しの実装が容易になり、理解を徐々に深めることができ、ファウンテン モデルはオブジェクト指向ソフトウェア開発の反復プロセスをよく反映しています。
33. RUP とアジャイル プロセスとは何ですか?
RUP (Rational Unified Process) は2 次元のライフサイクル モデルです
アジャイル プロセスは、より効率的に作業し、変化に迅速に対応するためのプロセスであり、エクストリーム プログラミングは最も有名なプロセスの 1 つです。
境界とは、優れた開発慣行を極限まで追求することです
34. RUPとエクストリームプログラミングの比較?
- RUP は2次元のライフサイクル モデルですが、エクストリーム プログラミングは1次元です。
- エクストリーム プログラミングは、需要の変化や不確実性に対してより迅速に対応し、高い開発速度を維持できます。
- RUP は極端なプログラミングよりも包括的です
35. Microsoft のプロセスに該当するシナリオは何ですか?
Microsoft のプロセスは、リソースや開発時間の制約が限られている商用環境のプロジェクトに適しています。
Microsoft プロセスの手法、ツール、製品に関する議論は、RUP やアジャイル プロセスほど包括的ではありません。
36. Rational 統合プロセスの長所と短所について議論してみますか? そしてどの項目が該当するのでしょうか？
アドバンテージ：
- チームの生産性を向上させ、反復的な開発プロセス、要件管理、コンポーネントベースのアーキテクチャ、ビジュアル ソフトウェア モデリング、ソフトウェア品質の検証、およびソフトウェア変更の管理に関するすべての主要な開発活動に必要なツールを各開発メンバーに提供します。ガイドライン、テンプレートすべてのメンバーが同じ知識ベースを共有できるようガイドし、確実に共有するためのツール
- 開発プロセスの汎用性を高めるために、簡潔かつ明確なプロセス構造が確立されています。
欠点:
- RUP は単なる開発プロセスであり、ソフトウェア プロセスのすべての内容をカバーしているわけではありません。たとえば、ソフトウェアの操作やサポートに関する内容は含まれていません。
- 複数のプロジェクトをサポートする開発構造を持たないため、開発組織内で広範に再利用される可能性が若干低下します。
適用可能なプロジェクト:要件が変化する大規模で複雑なソフトウェア システム プロジェクトに適しています
37. ソフトウェアエンジニアリングの本質的な特徴は何ですか?
- ソフトウェアエンジニアリングは大規模なプログラムの構築に関係します
- ソフトウェア エンジニアリングの中心的なトピックは、複雑さを制御することです
- ソフトウェアは頻繁に変更されます
- ソフトウェア開発の効率は非常に重要です
- 調和のとれた開発がソフトウェア開発の鍵です
- ソフトウェアはユーザーを効果的にサポートする必要があります
- ソフトウェア エンジニアリングの分野では、通常、ある文化的背景を持つ人々が、別の文化的背景を持つ人々のために製品を作成します。
章の最後にまとめ
この章では、コンピュータ ソフトウェア エンジニアリングの概要を簡単に説明します。
まず、コンピュータ システム開発の簡単な歴史を振り返ることで、ソフトウェア開発の誤った方法や概念がどのように形成されるかを説明します。次に、これらの間違った方法によってもたらされる深刻な問題 (ソフトウェア危機) を列挙し、いくつかの混乱した概念を明確にします。ソフトウェアの開発と保守の科学技術は、コンピュータ システムの進歩的な開発のために慎重な研究を必要とします。コンピュータソフトウェアの歴史的な経験と教訓を総括し、他のエンジニアリング分野の管理手法を参考にして、ソフトウェアエンジニアリングの新しい分野を徐々に発展させ、改善する必要があります。
この章は、読者がソフトウェア エンジニアリングの基本原理と方法を一般的かつ本質的に理解できるようにすることを目的としています。ライフ サイクル方法論では
、ソフトウェア ライフ サイクルをいくつかの比較的独立した段階に分割し、各段階でいくつかの明確なタスクを完了し、
最終的なソフトウェア構成の 1 つまたは複数のコンポーネント (ドキュメントまたはプログラム)を提供します。基本的に、それは順番構造化されたテクノロジーと適切なソフトウェア ツールを
使用して完了し、各段階は厳密な技術レビューと管理レビューによって完了します。ソフトウェアの規模が大きい場合や、ソフトウェアの要件が曖昧で変更しやすい場合、ライフサイクル手法の開発は失敗することが多く、近年、多くのアプリケーション分野でライフサイクル手法にオブジェクト指向手法が急速に置き換えられています。オブジェクト指向の方法論には 4 つの主要なポイントがあり、これらは次の方程式で要約できます:オブジェクト指向の方法 = オブジェクト + クラス + 継承 + メッセージ通信。つまり、オブジェクト指向とは、オブジェクトとクラスや継承などの仕組みを併用する方式であり、オブジェクト同士はメッセージの受け渡しのみで通信することができます。
オブジェクト指向の手法により、ソフトウェアの開発と保守が簡素化され、ソフトウェアの再利用性が向上します。ソフトウェア ライフ サイクルの全プロセスで完了するタスクの性質に応じて、ソフトウェアライフ サイクルは、問題定義、実現可能性調査、需要分析、全体設計、詳細設計、コーディングと単体テスト、総合テストに
分類できます。ステージは全部で8つあります。実際にソフトウェア開発を行う場合、ソフトウェアの規模や種類、開発環境、技術的手法などが段階分けに影響します。ソフトウェア プロセスは、高品質のソフトウェア製品を取得するために完了する必要がある一連のタスクのフレームワークです。各タスクを完了するための作業手順を指定します。すべてのソフトウェア プロジェクトに適用できる一連のタスクは存在しないため、科学的かつ効果的なソフトウェア プロセスは、実行されるプロジェクトの特性に適した一連のタスクを定義する必要があります。ソフトウェア プロセス モデルは通常、ソフトウェア プロセスを簡潔に記述するために使用され、ソフトウェア ライフ サイクルのフェーズと各フェーズの順序を規定します。この章では、8 つの代表的なソフトウェア プロセス モデルを紹介します。
ウォーターフォール モデルには長い歴史があり、よく知られており、規範的でドキュメント主導のアプローチであることが長所ですが、
このモデルの問題は、開発された最終ソフトウェア製品がユーザーが本当に望むものではない可能性があることです。
ラピッド プロトタイピング モデルは、ウォーターフォール モデルの欠点を克服するために提案されました。コンピュータ上で動作するシステムのプロトタイプを迅速に構築し、実際に試用してフィードバックを収集することで、ユーザーの真のニーズを把握します。
インクリメンタル モデルには、投資収益率が明らかであり、ソフトウェア開発の初期段階でのメンテナンスが容易であるという利点がありますが、
ソフトウェアにオープンな構造を要求することが、このモデルの使用に固有の困難を伴います。
リスク主導のスパイラル モデルは、社内で開発された大規模なソフトウェア プロジェクトに適していますが、開発者が
リスク分析とリスク排除の経験と専門知識を持っている場合にのみうまく使用できます。
ファウンテン モデルは、オブジェクト指向ソフトウェア開発プロセスのシームレスで反復的な特性をよりよく反映しており、典型的なオブジェクト指向
ソフトウェア プロセス モデルの 1 つです。
1998年に初めて発売Rational Unified Process (RUP) は、優れた利点を持つソフトウェア プロセス モデルであり、理想的な開発環境で完全かつ完璧なソフトウェア プロセス モデルを
提供しプロジェクトのソフトウェア開発の良いスタートとして使用できます。エクストリーム プログラミング (XP)に代表される 近年導入されたアジャイル プロセスは、変化や不確実性に対してより迅速かつ機敏に対応できるため、ビジネス競争環境における小規模プロジェクトの限られた要件によりよく適応できます。限られた開発時間は RUP の補足や改善として利用できますが、ソフトウェア プロセス モデルとしては、アジャイル プロセスは RUP よりも包括的で完全ではありません。 長年にわたる実務経験により、 Microsoft のプロセスが非常に成功し、効果的であることが証明されています。一方で、 Microsoft プロセスは、RUP の必要最低限の構成バージョンとみなすことができます。プロセス全体には、3 つのライフ サイクルの継続的な進行サイクルが含まれています。各ライフ サイクルは 5 つのステージで構成され、各ステージは次のように簡略化されています。一方で、Microsoft プロセスは、各ライフ サイクルの各段階の特定のワークフローを拡張するアジャイル プロセスの拡張バージョンとみなすことができます。
次章: ソフトウェアエンジニアリング——第 2 章 実現可能性調査の知識ポイントの整理
繰り返し、地に足を着いて、決して忘れることなく、響き渡るでしょう！