第 3 章 ソフトウェアプロセスモデル
3.1従来の「ソフトウェアライフサイクル」理論とは? その欠点は何ですか？従来のソフトウェア工学理論では、これらのプロセスの活動を「段階」と見なすことが多く、ソフトウェア開発の 3 つの期間、すなわち、ソフトウェア定義期間(問題定義、実現可能性調査、需要分析)、ソフトウェア開発期間(一般設計、詳細設計
) に分けられます。設計、コーディング、単体テスト、統合テスト) および運用保守期間(すべての保守は、本質的に単純化された定義および開発プロセスです)。欠点は、保護活動が明示的に含まれていないことと、プロセス内の活動を同時に実行できないことです。3.2ソフトウェアプロセスモデルとは? なぜプロセスの抽象的な表現なのか? ソフトウェア プロセス モデルは、プロジェクト アクティビティを編成する一般的な方法であり、実際の開発プロセスを抽象的に表したものです。抽象表現プロセスは、効果的に開発品質を向上させ、開発の進行をスピードアップし、開発コストを削減できます。3.3線形シリーズ モデルとは? エボリューションシリーズのモデルは？線形系列モデルには、線形逐次モデル、ウォーターフォール モデル、および RAD モデルが含まれます。一連の進化モデルには、モデルの構築と修正、増分モデル、スパイラル モデル、および RUP モデルが含まれます。3.4線形順序モデルの短所は何ですか?
線形シーケンシャル モデルは、従来のライフ サイクル モデルとも呼ばれます。欠点は、プロジェクトの「線形」プロセスの仮定が理想的すぎること、および複雑なプロセスが単純化されていること、さまざまなアクティビティが並行していないため、プロジェクトで「ブロッキング状態」が頻繁に発生し、膨大な人的資源と労力の浪費を引き起こしていることです。プロジェクト時間が長くなる; 開発者はユーザーとうまく対話できない; 分析段階で要件を完全に取得できない.
3.5ウォーターフォール モデルの長所と短所は何ですか?
利点: 一定のフィードバック性がある; 各段階で提出しなければならない成果物が厳密に規定されている; 各段階が終了する前に、正式なレビューが必要である.
短所: 開発者はユーザーとうまくやり取りできず、フィードバック効果は限定的です。
3.6 RAD モデルの「RAD」は何を意味しますか? RADモデルが線形秩序モデルから「一般化された」「高速」バリアントであると言われるのはなぜですか? RAD モデルの長所と短所は何ですか? どのようなプロジェクトに適していますか?
RAD モデル: ラピッド アプリケーション開発 (Rapid Application Development) は、
モデルが非常に短い開発サイクル内でソフトウェア開発を迅速に完了することを重視しているため、「高速」と呼ばれます。
利点: 迅速な開発、再利用の促進。
短所: システムを適切にモジュール化することが困難な場合、複数の開発チームを編成して並行して開発することは困難です。プロジェクトの初期段階で要件を完全に/正しく取得できない場合、開発タスクを完了することは困難です。時間通り; 過去に同様のプロジェクトでの経験が不足している場合、システムを迅速に設計することは困難です. RADはハイテクリスクのプロジェクトには適していません.
RAD モデルは、要件が完全かつ明確であり、設計が正確で明確であり、モジュール化の程度が高く、技術的なリスクが低く、同様のシステムでの経験があり、十分な人的資源があり、そして開発サイクルを短くする必要がある (60 ～ 90 日など) 完成したソフトウェア プロジェクト。
3.7 モデルの構築と修正の欠点が明白であると言われるのはなぜですか?
プロジェクトの実装前の要件分析と設計作業の重要性が否定されます。プロジェクトの時間とコストを制御できないと、開発コストが高くなります。終わりのない変更は、しばしばシステムの再構築につながります。3.8増分モデル
とは? インクリメンタル モデルの利点は何ですか? 難しさは何ですか？増分モデルは進化モデルです。これは、ソフトウェア開発プロセスが一度に 1 つの部分で開発されることを指定します。増分モデルは、開発スケジュールが進行するにつれてずらされる線形シーケンスを採用します. 各線形シーケンスは、線形順次モデルのシーケンスとまったく同じです. 違いは、各線形シーケンスがリリース可能な作業バージョンを生成できることです. これらの作業バージョンは以前の作業バージョンに基づいており、いくつかのインクリメントが行われています。利点: 開発プロセス中にユーザーとうまくやり取りできる; 開発リスクを軽減する; 実験的な製品の開発を容易にする; 「締め切り」に対処する方法. 難しいのは、統一されたソフトウェア アーキテクチャを作成する必要があることです.このアーキテクチャによれば、適切な反復開発計画を立てる必要があり、新しい機能を比較的小さなコストで簡単に拡張できます。さらに、プロジェクト マネージャー、デザイナー、インテグレーターなどの関係者には、より高いレベルが求められます。3.9 スパイラルモデルを提案したのは誰? スパイラルモデルの長所と短所は何ですか? BW Boehm は、有名なアメリカのソフトウェア エンジニアリングの専門家です。利点: 常に調整された開発計画は、ソフトウェア開発の実際の状況に沿っており、ソフトウェア開発のリスクが軽減され、実験的な製品の開発に役立ち、「期限」に対処する方法です。難点: より高度なリスク評価手法が必要です。モデルが新しいため、ウォーターフォール モデルやインクリメンタル モデルほど広く使用されていません。3.10 RUPモデルの「反復ライフサイクル」を理解するには?
プロジェクトの品質を確保するために、より柔軟な方法は、各開発ワークフローを複数回実行して、要件をよりよく理解し、強力なフレームワークを設計し、開発組織を設定し、最終的に一連の実装結果を提供することです。これは反復ライフサイクルと呼ばれます。
3.11 RUP は、ソフトウェア開発プロセスをどの主要段階に分割しますか?
インセプション、エラボレーション、ビルド、トランジション。
3.12 RUP における開発サイクルと進化サイクルの違いは何ですか?
開発サイクルでは、反復ごとに作成される成果物の最終的な目標は、この製品を作成することです。製品がユーザーに届けられた後, 次の世代を開発することができます. 製品は、同じシーケンスのインセプション, エラボレーション, 構築, 移行フェーズを繰り返すことによって、次世代の新製品に進化することができます. これらの後続のサイクルは呼ばれます進化サイクル。
3.13 RUP モデルの横軸と縦軸、およびグラフのさまざまな曲線は何を表していますか?
横軸は開発サイクルの時間を表します。
縦軸は、ビジネス モデリング、要件、分析と設計、実装、テストと展開の 6 つの基本的な活動と、構成と変更管理、プロジェクト管理、および環境の 3 つの保護または支援活動を表します。
さまざまな曲線が、開発サイクルの各反復における各アクティビティの労力を表しています。
3.14 RUP の利点は何ですか?
完全なシステム、成熟した理論、強力な実用性、調整可能、拡張可能。
第 4 章 問題定義と実現可能性調査の方法
4.1問題定義の目的は何ですか?
ユーザーがソフトウェア システムで解決する必要がある基本的な問題と、プロジェクトに必要なリソースと資金を見つけます。
4.2問題定義レポートの内容は?
プロジェクトの現在の問題点、プロジェクトの目的、プロジェクトの範囲、予備的なアイデア、推定投資額、開発サイクルなど。
4.3 実現可能性の5つの側面を列挙する
技術的実現可能性（技術が成熟しているかどうか）、運用可能性（ユーザーが操作方法を受け入れることができるかどうか）、経済的実現可能性（収益性があるかどうか）、スケジュール実現可能性（指定された期限を完了することができるかどうか）を検討してください。 、その他の実行可能な実行可能性(社会的実行可能性、市場実行可能性、競争力のある実行可能性など)。
4.4プロジェクト計画が経済的に実現可能かどうかの根拠は何ですか?
達成される利点は、提案されたシステムの起動および運用コストと同等またはそれ以上でなければなりません。4.6 プロジェクトの開始費用と運用費用は
いくらですか? プロジェクトの運用上の利点は何ですか? プロジェクトの立ち上げ費用とは、新しいシステムを確立するために支払う一時的な費用を指します。プロジェクトの運用コストとは、システムの運用を維持するために発生する費用を指します。プロジェクトの運用利益は、システムが正式に運用された後に生成できる収入を指します。4.7 ROI分析とは？この方法の欠点は何ですか？
投資回収分析は、新しいシステムによって生み出される経済的利益がその開発コストを超えるまでの時間を決定するための手法です。
不利な点は、資金の時間要素が完全に無視されることです。
4.8 正味現在価値法とは？この方法の利点は何ですか？
投資プログラムの資金の正味現在価値は、結果として生じる経済的利益の現在価値の合計からプロジェクトへの投資の現在価値を差し引いたものとして定義されます。
利点: 資金の現在価値を使用すると、お金の時間価値が認識され、さまざまなコストと経済的利益を持つ投資を比較できます。
4.9 オンライン ペット ストア システムを開発するときに、2 つのスキーム、すなわちスキーム A とスキーム B が提案され、どちらも実行可能であると仮定します。スキーム A の開発費は 20 万元、5 年間の年収は 6 万元、スキーム B の開発費は 80 万元、5 年間の年収は 20 万元です。最低許容割引率を 10% と仮定すると、どのオプションが許容可能ですか?
100/110=0.909
プラン A の初見
NPV
=6 0.909+6 0.909 0.909+... (合計 5 年間) -20=5.454+4.958+4.507+4.096+3.724-20
=2.739
純資本現在価値係数=2.739/ 20=0.137
そしてプラン B を見る
NPV=20 0.909+...-80=18.18+16.526+15.022+13.655+12.412-80=-4.205
純資本現在価値係数=-4.205/80=-0.052
なのでプランAも可。
4.10実現可能性調査報告書何が含まれていますか？
各バージョンの変更日、バージョン番号、変更内容、変更者を記載、レポート冒頭に本書の説明、本製品の位置付け、各ユーザーの状況を記載、製品概要、プログラム説明、実現可能性比較、推奨スキームのリスク評価、本レポートに対する顧客や開発者からの意見の照合、製品マーケティング計画およびソフトウェア開発計画。
4.11 実現可能性調査報告書では、システム計画にどのような側面を含める必要がありますか?
ソリューションのハードウェア環境 ソリューションの技術戦略 ソリューションのソフトウェア モデルとそのモデルの説明 ソリューションの採用後、顧客の投資コスト、運用コスト、および運用上の利益 開発者のリソース割り当て計画ソリューションのリスクと欠陥。
4.12 少なくとも 5 つの単語を含むオンライン ペット ストアの用語集を提出してください。
ログイン認証、ショッピングカート、お気に入り、ペットの種類、商品価格
第五章 需要分析の方法
5.1要件収集と要件分析のワークロードは、プロジェクト開発の異なる時期にどのように変化しますか?
初期の頃は、要件収集の作業負荷は比較的大きく、要件分析の作業負荷は比較的小さかった. プロジェクトの発展に伴い、要件収集の作業負荷は徐々に減少し、要件分析の作業負荷は徐々に増加しています。
5.2 需要分析活動において、トップダウンおよびレイヤーごとの分解の原則を採用する必要があるのはなぜですか?
多くの場合、大規模で複雑なシステムを一度に完全に理解することはできません。詳細に行き詰まるのが早すぎると、要件が不完全になり、システムのより重要な部分を無視することさえあります。
5.3 なぜモデルを通じて要件を表現する必要があるのですか?
わかりやすく、便利で、整理されています。(私自身も理解しています..)
5.4要件分析において、システムの実装をあまり考慮してはならないのはなぜですか?
現在の技術のために存在するいくつかの要件を文書化したり、新しい製品に適していない可能性のある技術を使用したり、実装方法を制限したりすることは避けてください。
5.5 なぜ要件は検証可能でなければならないのですか?
要件が「検証」に合格した場合にのみ、開発されたシステムが顧客とユーザーの要件を満たしていることを示すことができます.検証できない
要件は、要件に対する主観的な欲求にすぎず、設計やテストなどの活動には意味がありません
.システムの実装は、要件の検証基準を通じて測定できます。
5.6 大学の学生ステータス管理システムの使いやすさの要件は、「システムがユーザーフレンドリーであること」です。この要件の受け入れ基準を設計してください。
例：
合格基準①：利用者が初めて製品を使用する際、データのダウンロード、アップロード等の権限内で1時間以内に操作を習得できること。
受入れ基準②：開発者がトレーニングサービスを提供した後、管理者はトレーニング営業日 3 日以内にシステムのすべての機能を習得し、独立して作業できるようになります。
5.7 なぜ要件は追跡可能でなければならないのですか?
変換プロセス中に、多くの問題が発生したり、さまざまな理由で要件が変更されたりする可能性があります。トレーサビリティ リンクのいずれかの端で要件が失敗すると、その要件に関連付けられているすべてのリンクに疑わしいというフラグが立てられます。潜在的な変更の影響を分析したり、システムを実装することによってすべての要件が満たされていることを確認したりするのに役立ちます。
5.8状態遷移図の 2 つの主な記号は?
状態と遷移。
5.9要件分析活動でデータ辞書を使用する意義は何ですか? データ ディクショナリで定義されている4 つの? 分けて説明してください。
データディクショナリは、プロジェクト内のデータの定義と形式を統一し、開発者間のコミュニケーションを促進し、組織内でのデータ共有を確実にし、データの不一致による理解の違いを回避し、結果としてマンパワーの無駄と遅延を回避します。建設スケジュール。
データ要素: ソフトウェア システムにおけるデータの最小単位であり、データベースを構成し、システム モジュール間でデータを交換する最小単位。
データフロー: 外部エンティティとシステム間およびシステムの内部処理間のデータ交換の基本的なデータ単位であり、関連するデータ要素から構成されるデータ構造です。
データストレージ：データ構造も定義し、データフロー図のデータ構造のキャリアです。データフローと比較すると、静的なデータ構造です。
処理: 処理定義には、処理名、説明、必要なすべての入出力、アクセスするデータベース、および処理に対応する構造図のモジュール番号を含める必要があります。
5.10デシジョンテーブルとデシジョンツリーはどのような問題を解決しますか?
複雑な条件の組み合わせ問題 (プロセス定義では、複数のネストされた状況が存在する場合もあります) では、処理プロセスを直感的かつ明確に表現できます。
5.11 モデリングの観点から、UML はどのタイプのクラスに分割されますか?
ユース ケース モデル、オブジェクト動作モデル、オブジェクト リレーショナル モデル。
5.12 一般化、関連、集約、合成、依存の概念をそれぞれ説明してください。
一般化: 1 つのスーパークラスといくつかの直接のサブクラスで構成される 2 レベルの構造。
関連付け: モデル要素間のセマンティック リンク。
集約: 集約は、クラス間の全体および部分的な関係を表すために使用される特別な関連付けです。
合成: クラス間の全体と部分の関係も表す、より特別な種類の集約。しかし特別なことは、それは一種の強力な集約であり、結合関係にあるクラスは同じ存続期間を持つということです。つまり、主オブジェクトが存在しない場合、含まれるオブジェクトも存在しません。
依存性: クラス間の弱い関係. クラス A の定義を変更すると、クラス B の定義が変更される可能性がある場合、クラス B はクラス A に依存していると言われます.
5.13 汎化関係を特定する際に考慮すべき問題は何ですか?
ドメイン知識に基づく一般化の特定; 上から下への一般化の特定; 関係; サブクラス間の違いがスーパークラスの属性値を変更することによって実現されるかどうかの決定; サブクラスが独自の属性と操作を持っているかどうかの決定; のみがあるかどうかの決定親クラスの下に 1 つのサブクラス。
5.14 一方向の関連付けと双方向の関連付けの違いは何ですか?
一方向の関連付けには矢印があり、双方向の関連付けは矢印のない直線で表されます。
一方向の関連付け A→B は、A は B の属性とメソッドを使用できますが、B は A の属性とメソッドを使用できないことを意味します。
5.15 集約関係と複合関係の違いは何ですか?
コンポジションは、クラス間の全体と部分の関係も表す、より特別な種類の集約です。しかし特別なことは、それは一種の強力な集約であり、結合関係にあるクラスは同じ存続期間を持つということです。つまり、主オブジェクトが存在しない場合、含まれるオブジェクトも存在しません。
5.16 依存関係がよく現れるのはどのような状況ですか?
クラスは、クラスにメッセージを送信します。クラスは、別のクラスの 1 つまたはいくつかの操作のデータ メンバー型です。クラスは、別のクラスの操作のパラメーター モデルです。
5.17 相互作用図とは?
相互作用図は、ソフトウェア システムの動的な動作をモデル化するために使用され、アクターとオブジェクトが通信してユース ケースやその他の機能の各ステップを完了する方法を示します。