1. ソフトウェアエンジニアリングの概要
1. 選択します
ソフトウェアが実行可能か制御不能かどうか
ソフトウェアエンジニアリングは工学分野です
一般的なソフトウェア ライフ サイクル モデル: スパイラル モデル、インクリメンタル モデル、ウォーターフォール モデル、プロトタイプ モデル、フュージョン モデル、迅速なアプリケーション開発モデル、アジャイル モデル
ソフトウェアのライフサイクルで最も長いフェーズはメンテナンスフェーズです
ウォーターフォール モデルはソフトウェア ライフサイクル モデルです
構造化されたライフサイクルアプローチを採用しており、その特徴的な側面から一般にウォーターフォールモデルと呼ばれます
構造化ウォーターフォール モデルでは、要件分析フェーズで定義された基準が、ソフトウェア テストのシステム テスト フェーズの目標になります。
2. 短答式の質問
ソフトウェア危機とは何ですか? ソフトウェア危機の兆候は何ですか?
回答: 具体的には、ソフトウェア危機の原因は次のように要約できます。
- ソフトウェア開発の初期段階では要件分析を無視します。
- 開発プロセスには、統一および標準化された方法論的なガイダンスが欠如しています。
- 不完全または不正確なドキュメント。
- ユーザーや開発チームのメンバーとのコミュニケーションを無視する
- テストの重要性を無視します。
- 上記の理由により保守を怠ったり、保守作業が困難になったりする場合
- ソフトウェア開発に従事する専門家は、業界に関する知識と経験が不十分です
- 完璧な品質保証システムは存在しない
具体的には、ソフトウェア危機の兆候は次のように要約できます。
- ソフトウェア開発のコストとスケジュールは制御不能です。
- ソフトウェアシステムによって実現される機能が実際のニーズと一致していない
- ソフトウェアの信頼性が低い
- ソフトウェアの保守が難しい
- ソフトウェアは適切に文書化されていないことがよくあります
- コンピュータシステムの総コストに占めるソフトウェアコストの割合は依然として高く、年々増加しています
- ソフトウェアの生産性向上のスピードは、コンピュータアプリケーションの急速な普及と深化の傾向に大きく遅れています。
(4) ソフトウェアのライフサイクルとは何ですか? 何期に分かれているのでしょうか？ステージは何段階ありますか？
回答: ソフトウェア ライフ サイクルとは、製品設計の構想から、ソフトウェア要件の決定、ソフトウェア設計、ソフトウェア実装、製品のテストと受け入れ、使用、および製品バージョンの継続的な更新に至るまでの期間を指します。市場による最終的な製品の排除、プロセス全体。ソフトウェアのライフサイクルは、ソフトウェア定義、ソフトウェア開発、運用保守の3つの期間で構成され、問題定義、実現可能性検討、需要分析、全体設計、詳細設計、ソフトウェア実装と単体テスト、総合テストの8つの段階に分かれています。 、および運用保守。 _
(5) ソフトウェア ライフ サイクル モデルとは何ですか? 主なソフトウェア プロセス モデルは何ですか?
回答: ソフトウェア ライフサイクル モデルは、ソフトウェア プロセス モデルとしても知られ、ソフトウェア プロジェクトの要件の定義からソフトウェアの運用と保守に至るまで、ライフ サイクル全体にわたるシステム開発、運用、保守で実装されるすべてのプロセス、アクティビティ、およびタスクの構造的なフレームワークです。メンテナンス。代表的なものには、ウォーターフォール モデル、ラピッド プロトタイピング モデル、インクリメンタル モデル、スパイラル モデル、統合プロセス、アジャイル プロセスなどが含まれます。
2. ソフトウェアの問題定義と実現可能性分析
1. 空白を埋めてください
実現可能性調査の目的は、最小限のコストで可能な限り最短の時間で問題を解決できるかどうかを判断することです。
経済的実現可能性調査の範囲には、投資利益分析、企業運営の長期戦略、開発に必要なコストとリソース、潜在的な市場の見通しが含まれます。
実現可能性分析の目的は、ソフトウェア プロジェクトが開発する価値があるかどうかを検討することです。
実現可能性分析は本質的に、要件分析と設計プロセスをさらに簡素化し、圧縮するものです。
費用対効果分析は、開発するシステムの開発コストを見積もることから始まり、それと考えられるメリットを比較検討します。
費用対効果分析の目的は、ソフトウェア プロジェクトが経済的な観点から実現可能かどうかを評価することです。
実現可能性分析の具体的な手順 最後の手順は、実現可能性レポートを作成することです
実現可能性調査は主に、技術的実現可能性、経済的実現可能性、社会的要因の実現可能性、運用上の実現可能性の側面に焦点を当てます。
実現可能性分析のコストには直接コストと間接コストが含まれ、便益には有形および無形の便益が含まれます。
システムの経済性は、新しいシステムの使用による収益の増加と、新しいシステムの使用による運用コストの削減に等しくなります。
システムの経済的利益は、お金の時間価値、回収期間、純利益などの指標によって測定できます。
純利益とは、システムの累積的な経済的利益とソフトウェアのライフサイクル中の投資との差額を指します。
回収期間とは、蓄積された経済的利益が初期投資と等しくなるまでに必要な期間です。
ソフトウェア計画を策定するプロセスでは、ソフトウェアの作業範囲の決定、開発に必要なリソースの見積もり、ソフトウェアのコストとスケジュールの見積もりが必要です。
ソフトウェアの範囲には、ソフトウェア システムの機能、ソフトウェア システムのパフォーマンス、インターフェイス、信頼性が含まれます。
データ フロー図は、「データ フロー図」またはバブル図とも呼ばれます。
データ フロー図のいくつかの補助図。記号 * は隣接するデータ ストリームのペアが同時に出現することを示し、+ は隣接するデータ ストリーム A または B、または A と B が同時に出現することを示します。円は、2 つのデータ ストリームがそのうちの 1 つだけを取得することを示します。
データ フロー図を描画する場合、各プロセスには少なくとも 1 つの入力データ フローと 1 つの出力データ フローがあります。
データ フロー グラフを描画する場合、データ フロー サブグラフはその上位層のプロセスに対応する必要があります。データ フロー図の各要素には名前が必要です
データ ディクショナリには、データ フロー、データ項目、データ ストレージ、基本処理、データ ソースとデータ宛先の 5 種類のエントリがあります。
2.選択します
実現可能性とは、システムソリューション実現の可能性です。
経済、技術、運営、法律、社会的便益などの側面から実現可能性調査を実施します。
ソフトウェア開発時のソフトウェア開発者の生産性にとって重要なのは、プログラマーの数です。
ソフトウェアの実現可能性分析では、ソフトウェアの機能の観点から実現可能性を考えることが技術的実現可能性であり、技術的リスクの問題を解決する必要がある
実現可能性調査で実行される要件分析と設計は、簡素化および圧縮される必要があります。
ソフトウェアシステムの実現可能性調査には、経済的実現可能性、技術的実現可能性、社会的実現可能性が含まれます
ハードウェア リソースの可用性の調査は、運用可能性調査の実施の 1 つの側面です
データフローグラフ、コンピュータによって処理されるコンポーネントは制御フロー、データフロー、ノードです
構造化分析手法で使用される記述ツールのデータ辞書は、データ フロー図の各グラフィック要素を定義します。
階層型 DFD は記述方法であり、その最上位のグラフはシステムの入力と出力を記述します。
データ ストレージとデータ フローはどちらもデータであり、状態が異なるだけです
データ ディクショナリでは、通常、次のオプションのソース エントリと宛先エントリは含まれません。
データ フィールドはデータ定義情報の集合であり、データ フィールドによって定義されるオブジェクトにはすべてデータ フロー図が含まれています。
3. 短答式の質問
実現可能性調査の主な問題は何ですか?
実現可能性調査の仕事は、ソフトウェアプロジェクトを行うか否かを決定し、技術的実現可能性、経済的実現可能性、社会的実現可能性、開発計画の実現可能性、運用可能性などを分析することです。
3. 需要分析
1. 選択します
需要分析にはさまざまなツールが使用できますが、PADは適用できません
ER 図には、エンティティ、属性、関係などの基本コンポーネントが含まれています
ソフトウェア仕様の内容には、アルゴリズムの詳細な説明を含めないでください。
構造化要件分析手法の基本的な考え方は、上から下へ徐々に分解することです
ソフトウェアの問題は要件分析段階で送信され、修理コストが最も低くなります
2. 短い答え
ニーズ分析のステップ
要件分析には、取得、モデリング、記述、検証の 4 つのステップが必要です。要件の取得は基本的に要件収集のプロセスであり、十分な調査と研究が必要です。通常、現在のシステムに含まれるデータを分析し、情報処理における現在のシステムの欠陥、ユーザーが改善したい主な問題と緊急性などを分析することから始まります。要求事項の収集方法としては、アンケート調査、ヒアリング、フィールド運用、プロトタイプ構築などが一般的であり、収集される要求事項には主に機能要求、性能要求、信頼性要求、ユーザビリティ、マンマシンインターフェース要求、制約条件、エラー処理などが含まれます。需要分析の中核となるタスクは、分析モデルを確立することです。つまり、ユーザーからの需要情報の分析、抽出、誘導、抽象化を通じてターゲット システムを記述するモデルを確立することです。従来のプロセス指向のソフトウェア エンジニアリング手法では、主にデータ フロー図を使用してターゲット システムの論理モデルを確立します。要件定義とは、要件分析の段階でさまざまな文書を作成することを指します。一般に、大規模で複雑なソフトウェア システムの場合、要件分析の段階で、システム定義文書 (ユーザー要件を記述するために使用されるレポート)、システム要件仕様、およびソフトウェア要件仕様の 3 つの文書が、それぞれ異なる観点とレベルで作成されます。プロジェクト開発の要件。単純な小規模ソフトウェア システムの場合は、SRS をコンパイルするだけで済みます。要求分析の結果はその後の開発の重要な基礎・基礎となるため、ソフトウェア製品の最終品質を向上させ、開発コストを削減するには、要求分析結果を完全性、一貫性、有効性、現実性の4つの側面から分析する必要があります。正確性の検証と要件変更の遡及管理により、エラーの原因を追跡できないことによる混乱を回避します。
4. 全体のデザイン
選ぶ
データフロー指向のソフトウェア設計手法では、情報の流れは一般に変換フローとトランザクションフローに分けられます。
モジュラーテクノロジーを使用する利点は、テストとデバッグが容易で、ソフトウェアの信頼性の向上、保守性の向上、およびソフトウェア開発ファクトリーの組織化と管理に役立つことです (すべて選択)
ソフトウェア設計の基本原則は、モジュールのサイズは適度であること、情報の隠蔽とローカリゼーションであることです。
データフロー指向の設計手法は、情報フローをソフトウェア構造にマッピングすることです。
ソフトウェアの全体的な構造設計では、トップレベルのファンアウトの上限は5 ～ 9です。
5. 詳細設計
1. 空白を埋めてください
構造化プログラミングアプローチの基本は、シーケンス、選択、ループ構造を使用することです
構造化されたフローチャートを生成するには、3 つの基本的な制御構造を順番に組み合わせるか、完全にネストして構成する必要があります。
PADは右に広がる2次元のツリー構造で、図の縦線がプログラムの階層線です。
詳細設計段階において、プログラムの論理構造を記述するツールがプログラムフローチャートです。
プロセスを詳細に説明するには、グラフィック、言語、テーブルという3 つのツールが一般的に使用されます。
PDL には、制御構造、データ構造、およびモジュール インターフェイス設計を定義するための厳密なキーワード外部構文があります。
モジュール内のアルゴリズムを設計することに加えて、モジュール内のデータ構造も設計する必要があります。
プロセス設計の最も一般的な方法は、構造化設計、トップダウン、段階的な改善です。
SPと呼ばれる構造化プログラミング手法、問題分析図
NS図は構造化されたプログラムロジックしか表現できません
システムの詳細設計段階で作成される文書が詳細設計仕様書です。
2.選択します
プログラミングの効率と品質を高めるために使用される手法が構造化プログラミングです。
PADの制御実行の流れは上から下、左から右です。
ソフトウェアの詳細設計で使用される主な手法は構造化設計です。
PDL は次の言語の擬似コードです
データ フロー指向の設計手法によりデータ フローをソフトウェア構造にマッピング
SC_ _
詳細設計のタスクは、各モジュールのアルゴリズムを決定することです。
詳細設計工程で使用しない記述ツールはDFD
PDLはソフトウェア開発プロセスで詳細設計を行うために使用されます
ソフトウェア複雑さのメトリクスのパラメータにはサイズが含まれます
詳細設計段階でよく使われるツールはPAD
ジャクソングラフの上層と下層の関係は合成関係です
ジャクソン法は、データ構造に基づいてプログラム構造を導出する方法です。
6. ソフトウェアのコーディングとテスト
1. 選択します
テスト効率を高めるためには、エラーが見つかる可能性が高いデータをテストデータとして選択する必要があります
ソフトウェアテストの目的は、ソフトウェアエラーを見つけることです
単体テストは一般にホワイトボックスに基づいており、テストの基礎はモジュールの機能仕様です
ソフトウェアの統合テストは、ソフトウェア開発グループに属していないソフトウェア設計者によって実行されるのが最適です。
テストにはユーザー代表の参加が必要です
ソフトウェアのテストケースは主に入力データと期待される出力結果で構成されます
ブラックボックステストにおいて、入力条件の組み合わせをチェックすることに重点を置いた手法が因果グラフ法です。
ブラックボックステストはユーザーの観点からのテスト、ホワイトボックステストは開発者の観点からのテストです
ロジック カバレッジ法とも呼ばれるホワイト ボックス テスト法は、主に単体テストに使用されます。
境界値分析テストはホワイトボックス テスト手法ではありません
ホワイトボックステストは、プログラムの内部ロジックに基づいてテストケースを設計する方法です。
ソフトウェア デバッグの目的は、エラーがどこにあるかを見つけて修正することです。
2. 短答式の質問
ソフトウェアのテストはいくつかの段階に分ける必要がありますが、各段階の主要なテスト内容は何ですか?
ソフトウェアテストは、単体テスト、結合テスト、システムテスト、受け入れテストの4つの段階に分けることができます。
単体テストは、モジュール テスト、論理テスト、構造テストとも呼ばれ、ソフトウェア設計の最小単位であるプログラム モジュールや機能モジュールが正しいかどうかをテストするテストです。その目的は、各プログラム単位が詳細な設計仕様にあるモジュールの機能、パフォーマンス、インターフェイス、および設計制約の要件を正しく実装できることを検証し、各モジュール内に存在する可能性のあるエラーを見つけることです。
結合テストは、アセンブリテスト、総合テスト、共同テストとも呼ばれます。通常、すべてのプログラム モジュールは、単体テストに基づいて順次かつ段階的にテストされます。統合テストは、プログラム単位またはコンポーネントのインターフェイス関係を検証し、概要設計の要件を満たすプログラムコンポーネントまたはシステム全体にそれらを段階的に統合することです。
システム テストは、システムが本来の目的を達成していることを検証および確認するための、統合されたハードウェアおよびソフトウェア システムのテストです。システムテストは、完全なプログラムシステムが正しく構成され、システム (コンピュータハードウェア、周辺機器、ネットワークおよびシステムソフトウェア、サポートプラットフォームなどを含む) に接続できるかどうかを、実際のまたはシミュレートされたシステム動作環境下でユーザーのニーズを満たすかどうかを確認することです。 。システムテストの主な基礎となるのは「システム要件仕様書」という文書です。
受け入れテスト(納品テストとも呼ばれます) は、ソフトウェアの単体テスト、統合テスト、システム テストが完了した後、製品リリース前に実行されるソフトウェア テスト活動です。受け入れテストはさらにアルファテスト（Aテスト）とベータテスト（Bテスト）に分かれており、アルファテストはユーザーが開発環境で実施するテスト、または社内のユーザーが実際の運用環境を模擬して実施する統制テストです。 , ベータテストとは、ソフトウェアの複数のユーザーが1人以上のユーザーの実使用環境で実施するテストのことです。
7、オブジェクト指向技術とUML
1. 選択します
アクターの言っていることの間違いは、アクターがユースケース図の重要な部分であり、したがってターゲット システムの一部であるということです。(実際には、アクターはターゲット システムの不可欠な部分ではなく、ターゲット システムと対話する外部エンティティです。アクターは、目標を満たすためにターゲット システムと対話する人、組織、デバイス、またはその他のシステムなどです。ニーズまたは目標を達成する）
状態図で表現できない概念はクラスです
コンピュータとコンピュータ内の CPU、RAM などの関係は集計関係です。
クラス図はシステムのクラスとその相互関係を表現した図であり、オブジェクト指向設計の核となるものです。
継承はクラス間の階層関係を反映し、合成は全体の部分の関係を反映します。
UML 構造の一部ではないオブジェクトは対話型です
オブジェクト指向の機能:抽象化、カプセル化行。継承、ポリモーフィズム
UML 図では実現関係が破線で示されており、白い三角形は次のことを指します。
構成図は、分散システムを構成するノードの集合とノード間の接続を表す図です。
ユースケースとクラスの比較では、クラスはシステムの内部構造を記述しますが、ユースケースはシステムの内部構造を記述することもできます（ユースケースはシステムの動的な動作ビューを記述します）。
インスタンス リンクはオブジェクト間の静的な関係を記述します。
2. 応募に関する質問
航空機は翼、胴体、コックピットの組み合わせ関係で構成されており、関係図は以下のとおりです。
以下のクラス図では、Service インターフェイスに 3 つのメソッドが定義されています。このうち、ClientAはmethodAメソッドのみを使用し、ClientBはmethodBメソッドのみを使用し、ClientCはmethodCメソッドのみを使用する。インターフェース分離の原則に従ってクラス図を再設計する
集約（Aggregation）と結合（Composition）の関係を例を挙げて簡単に説明します。
ガチョウの形成は野生のガチョウで構成され、集合関係に属します
1羽の雁には2枚の羽があり、結合関係に属します
八、オブジェクト指向分析
選ぶ
カプセル化とは、オブジェクトのプロパティと操作を組み合わせて独立したオブジェクトを形成することです
UML には依存関係、一般化、関連性、実現という 4 つの関係があります。
ユースケースモデル図はユーザーと繰り返しコミュニケーションして確認する必要があります
ユースケース間の関係は依存関係ではありません
e コマース サイトのユースケースとして適していないオプションは、ショッピング カートです。
ユースケースのモデリングはユーザーと繰り返しコミュニケーションし、検証する必要がある
ユースケースの詳細な説明にはアクティビティ図を使用する必要があります
UML のシステム分析でさらに確立される 3 つのシステム モデルは、オブジェクト静的モデル、オブジェクト動的モデル、およびシステム機能モデルです。
クラスとオブジェクトの両方に属性があり、クラスは属性のタイプを記述し、オブジェクトの属性には特定の値が必要です。
シーケンス図とコラボレーション図は主に、ユース ケース図の制御フローをモデル化し、ユース ケース図の動作を説明するために使用されます。
シーケンス図のモデリング要素には、オブジェクト、メッセージ、チェーンなどが含まれます。
シーケンス図は、一連のオブジェクト間でメッセージが受け渡される順序を記述します。
シーケンス図では、返信メッセージの記号は破線の矢印です。
状態図は、オブジェクトの存続期間中の動作、経験した一連の状態、および状態遷移を引き起こすイベントを表すことができます。
状態図は、さまざまなイベントによって駆動されるオブジェクトによって送信される状態遷移を記述します。
9 つのオブジェクト指向設計
選ぶ
システム アーキテクチャは、部品の構造、インターフェイス、通信に使用するメカニズムを記述するために使用されます。
UML は、ハードウェア間の相互接続とハードウェア ユニット上のソフトウェアシステムの配布を記述することができます。
ソフトウェア システム アーキテクチャは、システム ユース ケース クラス オブジェクト インターフェイスと相互作用と協力を記述したものです。
ハードウェア システム アーキテクチャは、システムの構築、ノード、構成を記述したものです。
コンポーネントは、ソフトウェア システム アーキテクチャで定義された概念と機能を物理システムで実現したものです。
配置図はノードとノード間の接続で構成され、プロセッサ、デバイス、ソフトウェア ビルド ランタイムのアーキテクチャを記述します。
配置図の基本要素はノードです。メンバー。物体。接続。による
パッケージは要素をグループに編成するための一般的なメカニズムです
UML システム分析フェーズ中に作成されたパッケージ図は、システムのシステム アーキテクチャ階層を説明します。