ソフトウェアエンジニアリングの基本原則：段階的なライフサイクル計画による厳格な管理、段階的なレビューの主張、厳格な製品管理の達成、最新のプログラミング技術の使用、結果はレビューをクリアできるものでなければならない、開発チームはより少なく、より優れたものでなければならない、認識ソフトウェアエンジニアリングイベントの継続的な改善の必要性。

ソフトウェアエンジニアリングの基礎:方法、ツール、プロセス

ソフトウェアライフサイクル：実現可能性分析とプロジェクト開発計画、要件分析、概要設計（システムソリューションの選択、サブシステムの計画）、詳細設計（設計サブシステムの内部実装）、コーディング、テスト、保守

1. 情報システムのライフサイクル

システム計画段階：組織の環境、目標、現在のシステム状況の事前調査を実施し、組織の目標と開発戦略に従って情報システムの開発戦略を決定し、新しいシステム構築のニーズを分析および予測するタスクです。を検討し、新たなシステムの構築を検討します。システムが受けるさまざまな制約や、新たなシステム構築の必要性や可能性を検討します。ニーズと可能性に応じて、システムを製造および構築するための代替スキームが提供されます。

出力：実現可能性調査報告書、システム設計タスクブック

システム分析段階：システム設計タスクブックで定められた範囲に従って現在のシステムの詳細な調査を実施し、現在のシステムのビジネスプロセスを記述し、現在のシステムの限界と欠陥を指摘し、決定することです。新しいシステムの基本的な目標と論理機能要件、つまり、新しいシステムの論理モデルを提案すること。システム分析フェーズは、論理設計フェーズ（論理モデル）とも呼ばれます。この段階はシステム構築全体の重要な段階であり、情報システム構築と一般的なエンジニアリングプロジェクトとの重要な違いでもあります。

出力：システム仕様書（要求仕様書）

システム設計フェーズ: システム分析フェーズのタスクは、システムを「何をするか」という質問に答えることですが、システム設計フェーズで答えるべき質問は「どのように行うか」です。この段階のタスクは、システム仕様で規定されている機能要件に従って論理モデルを実装するための技術的ソリューションを具体的に設計すること、つまり、新しいシステムの物理モデルを設計することです。この段階は物理設計段階（物理モデル）とも呼ばれ、全体設計の「概要設計」と詳細設計の2段階に分けることができます。

出力：システム設計仕様書（概要設計、詳細設計仕様）

システム実装フェーズ：設計したシステムを実用化するフェーズです。この段階での作業には、コンピュータやその他の機器の購入、設置とデバッグ、プログラムの作成とデバッグ、人材トレーニング、データファイルの変換、システムのデバッグと変換などが含まれます。この段階の特徴は、相互に関連し、相互に制限し合う複数のタスクを同時に実行することであり、慎重に配置され、合理的に組織化される必要があります。システムの導入は、導入計画に従って段階的に完了し、導入進捗報告書を作成する必要があります。ステージごとに。システムテスト後にシステムテスト分析レポートを作成します。

出力:実装進捗レポート、システムテスト分析レポート

システムの運用・保守段階：システムの運用開始後は、頻繁に保守・評価を行い、システムの動作を記録し、一定のルールに従ってシステムに必要な修正を加え、作業品質や経済効果を評価する必要があります。システム

2. 能力成熟度モデル

能力成熟度モデル CMM

能力レベル	特徴	クリティカルプロセスエリア
初期レベル（初期）	ソフトウェアプロセスは、明確に定義された手順がほとんどなく、混乱と時には混乱を特徴とし、プロジェクトの成功は完全に個人の努力と英雄的な中心人物の役割にかかっています。
繰り返し可能 (繰り返し可能)	基本的なプロジェクト管理プロセスと実践は、同様のプロジェクトで以前の成功を繰り返すために必要なプロセス規律とともに、プロジェクトのコスト、スケジュール、機能を追跡するために確立されています。	ソフトウェア配布管理。ソフトウェアの品質保証、ソフトウェアの下請け管理、ソフトウェアプロジェクトの追跡と監督、ソフトウェアプロジェクトの計画、ソフトウェア要件の管理
定義済みレベル (定義済み)	管理ソフトウェアプロセスとエンジニアリングソフトウェアプロセスは両方とも文書化され、標準化され、ソフトウェア開発組織全体の標準ソフトウェアプロセスに統合されています。すべてのプロジェクトは、ソフトウェアの開発と保守に修正された標準ソフトウェアプロセスを使用します。	ピアレビュー、グループ間調整、ソフトウェア製品エンジニアリング、統合ソフトウェア管理、トレーニングプログラムの組織プロセス定義、組織プロセスの焦点
管理された	ソフトウェアのプロセスと製品の品質に関する詳細な指標が開発されます。ソフトウェアのプロセスと製品の品質を定量的に理解し、管理する	ソフトウェア品質管理と定量的プロセス管理
最適化された	定量分析が強化され、プロセス品質からのフィードバックや新しいアイデアや新技術からのフィードバックを通じてプロセスを継続的に改善できます。	プロセス変更管理、技術変更管理、および欠陥防止

能力成熟度モデルの統合 CMMI

これは、ソフトウェアだけでなく、複数のプロセスモデルの統合と改善であり、複数のエンジニアリング分野と分野をサポートし、現代のエンジニアリングの特性とニーズに適応し、プロセスの品質と作業効率を向上させることができる体系的で一貫したプロセス改善フレームワークです。
CMMI には 2 つの表現方法があります:
(1)ステージモデル: CMM と同様に、組織の成熟度に焦点を当てたもので、次の 5 つの成熟度モデルがあります。

能力レベル	特徴	主要なプロセス
初期レベル	プロセスが予測不能で制御ができない
管理された	プロセスはプロジェクトに役立つ	要件管理、プロジェクト計画、構成管理、プロジェクトの監視と制御、サプライヤー契約管理、測定と分析、プロセスと製品の品質保証
定義されたクラス	プロセスは組織に役立つ	要件開発、技術ソリューション、製品統合、検証、組織プロセスの焦点の確認、組織プロセス定義、組織トレーニング、統合プロジェクト管理、リスク管理、統合チーム、意思決定分析とソリューション、組織統合環境
定量的な管理	プロセスは測定され、制御されます	組織プロセスのパフォーマンス、定量的なプロジェクト管理
最適化レベル	プロセスの改善と最適化に重点を置く	組織改革とその実行、原因分析と解決

(2). 継続的モデル: 各プロセス領域の能力に焦点を当て、組織は異なるプロセス領域に対して異なるプロセス領域能力レベルを達成できます。

【例】 ( ) はシステム分析フェーズ後の成果物、( ) はシステムテストフェーズ後の成果物
A. システム設計仕様書 B. システム提案書 C. プログラム仕様書 D. 単体テストデータ
A. 受入テスト計画書B. テスト基準 C. システムテスト計画 D. 操作マニュアル
答え: BD

【例】CMMに関する以下の記述のうち、誤っているのは()です。
A. CMM は、ソフトウェアプロセス能力成熟度モデルを指します。
B. CMM は、ソフトウェアプロセスのさまざまな成熟度レベルに応じて 5 つのレベルに分けられます。その中で、レベル 1 が最も高い成熟度とみなされ、レベル 5 が最も低い成熟度とみなされます
。
C. CMMI タスク複数の既存の CMM モデルを組み合わせて「統合モデル」を構築することです
D. より成熟した CMM モデルを採用すると、一般的に最終製品の品質を向上させることができます
回答: B

3. ソフトウェアプロセスモデル

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

ウォーターフォールモデル (SDLC): ウォーターフォールモデルは、一般的にソフトウェア開発を実現可能性分析 (計画)、需要分析、ソフトウェア設計 (概要設計、詳細設計)、コーディング (単体テストを含む)、いくつかの要素に分割する古典的なソフトウェアライフサイクルモデルです。テスト、運用、保守などの段階。

ウォーターフォールモデルの特徴

このアクティビティの作業オブジェクトを前の開発アクティビティからの入力として受け入れます
この入力を使用して、アクティビティが達成すべきことを実装します。
このアクティビティの作業成果物を出力として次の開発アクティビティに渡します。
アクティビティの実施結果を確認します。作業結果が確認できた場合は次の開発作業に進み、確認できなかった場合は前の作業に戻り、場合によっては前の作業に戻ります。複数のステージ間の繰り返しを最小限に抑えます。比較的低コストでソフトウェアを開発できる

試作モデル

プロトタイピングモデルの最初のステップは、プロジェクトの利害関係者とプロトタイプを操作する将来のユーザーのニーズを満たすことができるラピッドプロトタイプを作成し、その後、関連する利害関係者と十分に議論および分析して、最終的に現在のシステムのニーズを把握することです。十分に理解した上で、プロトタイプを基にユーザーが満足する製品を開発します。

プロトタイプ手法では、ユーザーのニーズを一度に十分かつ正確に提示することが難しい場合、プロトタイプが持つべき特性は次のとおりであると考えています。

実現可能
最終システムの本質的な特性を備えている
構造は便利で、速く、そして低コストです。プロトタイピング手法の特徴は、ユーザーのニーズに動的に対応し、徐々にプロトタイピング手法を取り入れていくことです。

スパイラルモデル

スパイラルモデルは、プロトタイプ実装の反復特性と線形逐次 (ウォーターフォール) モデルの制御された体系的な側面を組み合わせた進化的なソフトウェアプロセスモデルです。スパイラルモデルでは、ソフトウェア開発は一連の段階的なリリースです。

開発プロセスはスパイラル状に周期的に繰り返されます。4 つの象限は、各サイクルの 4 つのフェーズ (計画、リスク分析、実装エンジニアリング、顧客評価) を表します。スパイラルモデルは、特に大規模で複雑な高リスクシステムのリスク分析を重視します。

Vモデル

Vモデルは左右の側面からなり、全体としてV字型の構造に見えます。左側の下線は、それぞれ要件分析、全体設計、詳細設計、コーディングを表します。右側の上の線は、単体テスト、結合テスト、システムテスト、および受け入れテストを表します。

Vモデルの特徴は以下の通りです。

単体テストの主な目的は、コーディングプロセス(単一コンパイル)に存在する可能性のあるさまざまなエラーを対象とすることです。
統合テストの主な目的は、詳細設計(セットの詳細)で発生する可能性のある問題に対処することです。
システムテストは主に概要設計を目的としており、システム全体（システム概要）が効率的に動作するかどうかを確認します。
受け入れテストは通常、製品が本当にユーザーのビジネスのニーズ (要件) を満たしていることを確認するために、ビジネスの専門家またはユーザーによって実施されます。
V モデルは、要件が明確であり、要件が頻繁に変更されない場合に使用されます。

インクリメンタルモデル

インクリメンタルモデル：最初にコアモジュールの機能を開発し、次にユーザーに確認し、次にサブコアモジュールの機能を開発します。つまり、毎回一部の機能を開発し、ユーザーのニーズを確認し、最終的にプロジェクトを完了します。最も優先度の高いサービスが最初に提供されます

インクリメンタルモデルの特徴：ただし、システム全体の観点から各モジュールを計画していないため、モジュール分割が難しく、顧客ニーズをどのように複数のインクリメントに分割するかが
難しい。プロトタイプとは異なり、インクリメンタルモデルの各インクリメンタルバージョンは、独立して動作可能な作品として使用できますが、プロトタイプの構築は一般にデモンストレーション用です。

噴水モデル

ファウンテンモデル:ユーザーのニーズとオブジェクトによって駆動されるモデルであり、オブジェクト指向開発手法に適しています。開発プロセスを反復的かつシームレスにする

コンポーネントベースの開発モデル CBSD

コンポーネントベースの開発モデル CBSD:事前にパッケージ化されたコンポーネントを使用してアプリケーションシステムを構築します。コンポーネントは、組織の内部で開発されたコンポーネントであっても、商用化された完成したソフトウェアコンポーネントであってもよい。

再利用性の向上が特徴で、システム開発の過程で、他のシステムで再利用できるコンポーネントライブラリが構築されるため、信頼性の向上、時間とコストの節約が可能です。

形式的手法モデル

形式的手法モデル:厳密な数学に基づくソフトウェア開発手法。その主な活動は、コンピュータソフトウェアの形式化された数学的仕様を生成することです。

エクササイズ

【例】ソフトウェア会社が顧客とソフトウェアシステムの開発契約を結び、システムの機能が明確で、顧客の納期要求が厳しい場合、最適な開発方法は何か
。システムは
A、ウォーターフォールモデル B、プロトタイプモデル C. V モデル D. スパイラルモデル
答え: A
分析: 機能が明確である、つまり要件が比較的明確であるこのようなキーワードはすべてウォーターフォールモデルに関するものであり、メモリのキーワードです概要を念頭に置いておく

【例】スパイラルモデルに関する次の記述のうち、誤っているのは()
A. スパイラルモデルはリスク主導型であり、開発者はリスク評価に関する豊富な知識と経験を必要とする
B. 過剰なテストまたは不十分なテストの影響を軽減できるC. 保守サイクルが含まれるため、
保守と開発に本質的な違いはないD. 大規模なソフトウェア開発
には不向き

4. 情報システムの開発手法

構造化されたアプローチ

構造とは、システム内のさまざまなコンポーネント間の相互接続および相互作用のフレームワークを指します。

ライフサイクル法とも呼ばれる構造化手法は、構造化分析 (Structured Analysis、SA)、構造化設計 (Structured Design、SD)、および構造化プログラミング (Structured Programming、SP) で構成される伝統的な情報システム開発手法です。 3 つの部分の組み合わせ。その本質はトップダウン、進歩的な改良、モジュール設計です。

構造化アプローチの主な特徴

開発目標の明確さ。システム開発への構造化されたアプローチは「ユーザー第一」の原則に基づいています
ステージ開発作業。各段階の作業が完了したら、段階の作業の目標と要件に従ってレビューする必要があります。これにより、各段階の作業が秩序正しく機能し、プロジェクトの管理と制御が容易になります。
開発ドキュメントを標準化します。構造化メソッドの各段階が完了したら、各作業段階の接続とシステム保守作業の横断を確実にするために、要件に従って対応する文書を完成させる必要があります。
設計アプローチは構造化されています。システムの分析・設計では、全体や全体の状況を考慮し、上から下へ分解していきますが、システムの実装では、設計要件に従って、最初に具体的な機能モジュールをそれぞれ記述し、その後、システム全体を下から上へ段階的に実現していきます。

構造化アプローチの欠点と限界

長い開発サイクル: ユーザーがシステムを使用できるようになる前に実装段階が終了するまで、段階を順番に通過します。
要件の変化への適応の難しさ: 要件が不明確であったり、頻繁に変更されるプロジェクトには適していません。
Tiger データ構造をほとんど考慮しない: 構造化手法はプロセス指向、データフロー指向の開発手法であり、データ構造をほとんど考慮しません。

構造化メソッドの共通ツール

構造化手法では、一般にグラフィックスを使用してユーザーのニーズを表現します。一般的なツールには、データフロー図、データディクショナリ、構造化言語、デシジョンテーブル、デシジョンツリーなどが含まれます。

オブジェクト指向開発手法

オブジェクト指向 (Object-Oriented、00) メソッドは、客観的な世界はさまざまなオブジェクトで構成され、すべてがオブジェクトであり、各オブジェクトは独自の運動法則と内部状態を持ち、特定のオブジェクトクラスに属していると考えます。オブジェクトクラスの。複雑なオブジェクトは、さまざまな比較的単純なオブジェクトから特定の方法で構築でき、異なるオブジェクトの組み合わせと相互作用によってシステムが構成されます。

オブジェクト指向アプローチの特徴

00法で構築されたシステムは再利用性が高く、包括的かつ合理的で統一されたモデル（ユースケースモデルと分析モデル）の確立が鍵となる
00メソッドも段階に分かれていますが、システム分析、システム設計、システム実現の3つの段階の間に「ギャップ」はありません。つまり、この 3 つの段階の境界が曖昧になり、ある作業を前段階または後段階で完了させることができ、前段階の作業が十分に詳細でない場合は後段階で補うことができます。ステージ。
オブジェクト指向手法は、さまざまな情報システムの開発に一般的に適用できます。

オブジェクト指向手法の欠点は、
特定のオブジェクト指向技術サポートに依存する必要があり、大規模プロジェクトの開発には一定の制限があるシステム分析の前に開発プロセスに参加できない

現在、一部の大規模情報システムの開発では、構造化手法と 00 手法を組み合わせて開発するのが一般的です。まず構造化手法を用いてトップダウンで全体を分割し、次に00手法を用いてボトムアップで開発します。したがって、構造化手法と 00 手法は、システム開発の分野において依然として相互依存しており、代替不可能な 2 つの手法です。

プロトタイピング方法

プロトタイピング方法は、ラピッドプロトタイピング、または単にプロトタイピングとも呼ばれます。ユーザーの初期ニーズに基づいて情報システムを迅速に開発する方法であり、システム開発ツールを使用してシステムモデルを迅速に確立してユーザーに表示し、これに基づいてユーザーとコミュニケーションし、最終的にユーザーのニーズを実現します。

機能を実現するかどうかによる分類：水平プロトタイプ（動作プロトタイプ、機能ナビゲーション）、垂直プロトタイプ（構造プロトタイプ、機能の実現部分）に分ける

最終結果による分類:: 廃棄プロトタイプと進化プロトタイプに分類

プロトタイプ手法の特徴
プロトタイプ手法は、システム開発のサイクルを短縮し、コストとリスクを低減し、スピードを速め、より総合的な開発メリットを得ることができます。

プロトタイピング手法はユーザー中心のシステム開発であり、ユーザーの参加度が大幅に向上し、開発されたシステムがユーザーのニーズを満たしているため、ユーザーの満足度が向上し、システム開発の成功率が向上します。システム
開発のプロセスシステムの機能や構造が理解しやすく、受け入れやすいため、システムの引き継ぎや運用・保守が容易になります。

プロトタイプ方式の欠点は、
開発環境に高い要件が要求されることです。高度な管理が求められます。

上記の分析から、プロトタイプ手法の利点は、ユーザーのニーズをより効果的に確認できることであることがわかります。直感的な観点から見ると、プロトタイピング手法は要件が明確でないシステム開発に適しています。実際、プロトタイピング手法は、分析レベルでは難しいが技術レベルでは難しいシステムに適しています。

厳密に言えば、現在のプロトタイピング手法は独立したシステム開発手法ではなく、開発アイデアであり、システム開発の初期段階でのシステムプロトタイプの迅速な生成をサポートするだけであり、プロトタイプ構築にどの手法を使用する必要があるかについては規定されていません。プロセスのやり方。したがって、それは完全な意味での方法論的体系ではありません。つまり、プロトタイピング手法は他の情報システム開発手法と組み合わせて使用する必要があります。

アジャイル開発

アジャイル開発は、人間中心の反復的で段階的な開発手法です。「非アジャイル」従来のソフトウェア開発手法と比較して、プログラマーチームとビジネスエキスパートの間の密接なコラボレーションと対面でのコミュニケーションに重点が置かれています (文書化されたドキュメントよりも効果的であると考える）、新しいソフトウェアバージョンを頻繁に提供し、コンパクトで自己組織化し、要件の変化にうまく適応できるコード作成とチーム編成方法を採用し、ソフトウェア開発における人々の役割にもっと注意を払う

アジャイルソフトウェア開発に関する公式声明:

プロセスやツールを超えた個人と相互作用
実用的なソフトウェアは包括的なドキュメントよりも優れています
契約交渉よりも顧客の協力が大切
計画に従うよりも変化に対応する方が良い

アジャイル開発の 5 つの手法

適応的発達

アダプティブ開発:開発手法の適応性を重視します(アダプティブ)。多くの具体的な実践方法がある他の手法とは異なり、ソフトウェアの重要性についての最も基本的な基盤を提供し、開発手法がより高い組織および管理レベルから適応できる理由を説明することに重点を置いています。

結晶法

クリスタルメソッド:プロジェクトごとに、異なる戦略、規則、および方法論のセットが必要です。

機能駆動型開発

機能駆動開発:中小規模のソフトウェア開発プロジェクト向けの一連の開発モデルです。これはモデル駆動型の迅速な反復開発プロセスであり、シンプルさ、実用性、開発チームによる受け入れやすさを重視しており、要件が頻繁に変化するプロジェクトに適しています。

エクストリームプログラミング XP

エクストリームプログラミング XP:コミュニケーション、シンプルさ、フィードバック、そして勇気がその核心です。計画が変更に決して追いつかないことを知っているXP では、開発者がソフトウェアの開始時に大量のドキュメントを作成する必要がありません。XP では、将来バグが発生する可能性を最小限に抑えるために、最初にテストすることを推奨しています。

スクラム方式 SCRUM

スクランブル方式 SCRUM：選択と生成を段階的に行うプロセスであり、期間（30日）に1回の繰り返しを「スプリント」と呼び、要求の優先度に応じて製品を実現する多重自己組織化と自律化チームは製品を段階的に並行して実装します。

統合プロセス (RUP)

開発組織内でタスクと責任を割り当てるための規律あるアプローチを提供します。その目標は、予測可能なスケジュールと予算内でエンドユーザーのニーズを満たす高品質の製品を保証することです。

3 つの特徴的な機能:ユースケース主導、アーキテクチャ中心、世代別および増分

4 つのプロセス:開始、精緻化、構築、納品。各フェーズの終わりには、フェーズの目的が達成されているかどうかを判断するための技術レビューが予定されています。

適用性:さまざまなソフトウェアシステム、さまざまなアプリケーションドメイン、さまざまな組織タイプ、さまざまなパフォーマンスレベル、さまざまなプロジェクトサイズに使用できる一般的なプロセスフレームワーク。

ペアプログラミング

ペアプログラミング: 1 人のプログラマーが開発し、もう 1 人のプログラムがコードを観察してレビューします。これにより、コードの品質を効果的に向上させ、開発中にコードの予備レビューを実施し、コードに対して共同で責任を負います。

【例】構造化開発手法に関する以下の記述のうち、誤っているのは、
A. 一般的な指針はトップダウンのレイヤーごとの分解である
B. 基本原理は機能の分解と抽象化である
C. それオブジェクト指向開発手法と一致している
D、データ処理分野でのプロジェクト分析に特に適しています
: 除外手法を使用でき、構造化開発手法はデータフローを指向し、上から下、層に分解されます。ただし、オブジェクト指向開発手法は大規模で複雑なプロジェクトにより適しているため、オブジェクト指向開発手法は徐々にオブジェクト指向開発手法に置き換えられています。

【例】アジャイルプロセスの開発手法において、（）は反復型手法を採用しており、期間（30日）ごとに1回の繰り返しを「スプリント」と呼び、その優先度に応じて製品を実現していきます。需要、数自己組織的かつ自律的なチームが、製品A、エクストリームプログラミング XP B、結晶
法 C、並置法 D、適応型ソフトウェア開発を段階的に実装します。適応型ソフトウェア開発は適応性を重視し、エクストリームプログラミングは 4 コアやテストファーストなどの理論を重視します。。

システム分析と設計の概要

ソフトウェア要件

ソフトウェア要件:機能、動作、パフォーマンス、設計制約の観点からシステムに対するユーザーの期待を指します。問題を解決したり目標を達成したりするためにユーザーが必要とする条件や機能、および契約、標準、仕様、その他の正式に規定された文書、およびそれらを反映した文書の説明を満たすためにシステムまたはシステムコンポーネントが備えなければならない条件や機能を指します。これらの条件または能力。

これは、次のように、要件開発と要件管理の2 つのプロセスに分かれています。

システムデザイン

システム設計の主な目的：システムの青写真を作成し、さまざまなテクノロジーと実装方法の長所と短所を比較検討し、慎重に設計し、さまざまなリソースを合理的に使用し、最後に新しいシステムの詳細な設計方法の概要を決定します。

システム設計手法：構造化設計手法、オブジェクト指向設計手法

システム設計の主な内容は、全体設計、詳細設計です。

概要設計の基本的なタスク:全体システム構造設計とも呼ばれ、システムの機能要件をソフトウェアモジュールに割り当て、各モジュールの機能と呼び出し関係を決定し、ソフトウェアのモジュール構造図を形成します。つまり、システム構成図です。

詳細設計の基本作業：モジュールでのアルゴリズム詳細設計、モジュールでのデータ構造設計、データベースの物理設計、その他の設計（コード、入出力フォーマット、ユーザーインターフェース）、詳細設計指示書作成、レビュー

システム実践の基礎

抽象化
トップダウンの段階的な改善
情報隠蔽。
モジュールの独立性 (高い凝集性、低い結合性)

システム設計の原則

モジュールのサイズを適度に保つ
呼び出しの深さを可能な限り最小限に抑える
ファンインが増加し、ファンアウトが減少
単一の入口、単一の出口
モジュールのスコープはモジュール内にある必要があります
関数は予測可能でなければなりません

【例】システム設計とは、システム分析の結果をもとにシステム構築を完成させるプロセスです。システム設計の主な内容には ( ) が含まれます。システム全体の構造設計の主なタスクは、システムの機能要件をソフトウェアモジュールに割り当て、各モジュールの機能と呼び出し関係を決定してソフトウェアを形成することです ( ) A 、概要設計と詳細設計 B
、アーキテクチャ設計とオブジェクト設計
C. 導入設計とユースケース設計 D. 機能設計とモジュール設計
A. ユースケース図 B. モジュール構成図 C. システム配置図 D. クラス図の
答え: A B

[例] ソフトウェアシステムのモジュール構造設計に関する以下の記述のうち、正しいものは( )Aです。
モジュールのファンアウトが大きすぎる場合、下位モジュールをさらに複数のサブモジュールに分解する必要があります。 B.モジュール
のファンアウトが小さすぎる場合は、中間の制御モジュールを適切に追加する必要があります。
C. モジュールのファンインが大きく、モジュールの複雑さが高いことを示しています。
D. ファンモジュールの in が大きいことは、モジュールの再利用度が高いことを示しています。
回答: D

システム設計の基本原則:

システム設計の基本原則: 抽象化、モジュール化、情報隠蔽、モジュールの独立性。

モジュールの独立性の度合いを測定するには、結合と結合という 2 つの基準があります。

凝集度は低いものから高いものまで次のようになります。

一貫した分類	意味	キーワードを覚える
偶然の凝集	モジュール内の処理要素間には関係がありません	直接的な関係はありません
論理的な一貫性	論理的に類似したいくつかの関数がモジュール内で実行され、どの関数がパラメータを通じてモジュールによって決定されます。	論理類似性、パラメータ決定
時間内に集合	同時に実行する必要があるアクションを組み合わせて形成されるモジュール	同時実行
プロセスの凝集	モジュールは複数のタスクを完了します。これらのタスクは指定されたプロセスに従って実行する必要があります	指定された処理シーケンス
通信内聚	モジュール内のすべての処理要素は同じデータ構造で動作するか、各プロセスは同じ入力データを使用するか、同じ出力データを生成します。	同じデータ構造、同じ入力と出力
連続的な凝集	モジュール内の各処理要素は同じ機能に密接に関連しており、順番に実行する必要があります。前の機能要素の出力は次の機能要素の入力になります。	順次実行、入力を出力として
機能的な凝集	最も強力な結合力。モジュール内のすべての要素が連携して機能を完了し、不可欠な要素です。	完全な相乗効果、不可欠な

低結合から高結合までの結合度を以下の表に示します。

結合分類	意味	キーワードを覚える
直接結合なし	2 つのモジュール間には直接的な関係はなく、それぞれ異なるモジュールの制御と呼び出しに従属しており、いかなる情報も渡しません。	直接的な関係はありません
データ結合	2 つのモジュール間には呼び出し関係があり、転送はデータ値の単純な転送であり、高級言語での値の転送と同等です。	データ値の呼び出しを渡す
タグカップリング	2 つのモジュール間で渡されるデータ構造	データ構造を渡す
制御カップリング	モジュールが別のモジュールを呼び出すとき、制御変数が渡され、呼び出されたモジュールは制御変数の値を通じてモジュール内の特定の関数を選択的に実行します。	変数を制御し、機能の実行を選択します
外部カップリング	ソフトウェア以外の環境を介してモジュールが結合される場合（モジュールを特定のデバイス、フォーマット、通信プロトコルに結合する I/O など）。	ソフトウェア外部環境
パブリックカップリング	共通のデータ環境を通じて対話するモジュール間の結合	パブリックデータ構造
コンテンツカップリング	モジュールが他のモジュールの内部データを直接使用する場合、または異常エントリにより他のモジュールに転送する場合	モジュールの内部関連付け

[例] モジュール内の各処理要素は同じ機能に密接に関連しており、順番に実行する必要があります。前の処理要素の出力は次の処理要素の入力になります。このとき、このモジュールの結合タイプは ( ) 結合 A となり
ます
。、プロセス B. 時間 C. 順序 D. ロジック
答え: C

[例] モジュール A がデータ構造 X をモジュール B に送信することがわかっている場合、これら 2 つのモジュールの結合タイプは ( )
A、データ結合 B、パブリック結合 C、外部結合 D、マーク結合
答え: D
分析: 特殊命令はデータではなくデータ構造です、データ構造はタグ結合です

構造化された開発

结构化分析与设计方法是一种面向数据流的传统软件开发方法，它以数据流为中心构建软件的分析模型和设计模型。结构化分析 (StructuredAnalysis，SA)、结构化设计 (Structured Design，SD) 和结构化程序设计 (structured Programming Design，SPD) 构成了完整的结构化方法结构化方法的分析结果由以下几部分组：一套分层的数据流图、一本数据词典、一组小说明（也称加工逻辑说明）、补充材料。

数据流图DFD

基本图形元素：外部实体、加工、数据存储、数据流

数据流：由一组固定成分的数据组成，表示数据的流向在DFD 中，数据流的流向必须经过加工

加工：描述了输入数据流到输出数据流之间的变换，数据流图中常见的三种错误如图所示

加工3.1.2有输入但是没有输出，称之为“黑洞”
加工3.1.3 有输出但没有输入。称之为“奇迹”
加工3.1.1中输入不足以产生输出，我们称之为“灰洞'

数据存储：用来存储数据

外部实体（外部主体）：是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地（源）和系统所产生的数据的归宿地（宿）

数据字典

数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。

数据字典有以下4类条目：数据流、数据项、数据存储和基本加工

符号	含义	举例及说明
=	被定义为
+	与	x=a+b，表示 x 由 a 和 b 组成
[...\|...]	或	x=[a\|b]，表示 x 由 a 或 b 组成
{......}	重复	x={a}，表示 x 由 0 个或多个 a 组成

加工逻辑也称为 “小说明” 。常用的加工逻辑描述方法有结构化语言、判定表和判定树3种

【例题】在结构化分析中，用数据流图描述 ( )。当采用数据流图对一个图书馆管理系统进行分析时，( )
一个外部实体
A、数据对象之间的关系，用于对数据建模
B、数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能
建模
C、系统对外部事件如何响应，如何动作，用于对行为建模
D、数据流图中的各个细成部分
A、读者 B、图书 C、借书证 D、借阅
答案：BA

系统运行与维护

遗留系统

遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统，它通常具有以下特点:

(1) 系统虽然完成企业中许多重要的业务管理工作，但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。

(2) 系统在性能上已经落后，采用的技术已经过时。例如多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。

(3) 通常是大型的软件系统，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难

(4) 没有使用现代信息系统建设方法进行管理和开发，现在基本上已经没有文档，很难理解

系统转换

系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换计划：

直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂.或者现有系统已经不能使用的情况。优点是节省成本。

并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。

分段转换: 分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

数据转换与迁移：将数据从旧数据库迁移到新数据库中。有三种方法: 系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成

系统维护

系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下:

易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能
易改变性。软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改
稳定性。软件产品避免由于软件修改而造成意外结果的能力。
易测试性。软件产品使已修改软件能被确认的能力。
维护性的依从性。软件产品遵循与维护性相关的标准或约定的能力

系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下

正确性维护：发现了bug而进行的修改。
适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级
完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更高，更加完善。
预防性维护：对未来可能发生的bug进行预防性的修改

【例题】对于遗留系统的评价框架如下图所示，那么处于"高水平、低价值"区的遗留系统适合于采用的演化策略为 ( ）

A、淘汰 B、继承 C、改造 D、集成
答案:D

【例题】以下关于软件维护和可维护性的叙述中，不正确的是 ( )
A、软件维护要解决软件产品交付用户之后运行中发生的各种问题
B、软件的维护期通常比开发期长得多，其投入也大得多
C、进行质量保证审查可以提高软件产品的可维护性
D、提高可维护性是在软件维护阶段考虑的问题
答案:D

【例题】某企业由于外部市场环境和管理需求的变化对现有软件系统提出新的需求，则对该软件系统进行维护。的维护属于（）维护
A、正确性 B、完善性 C、适应性 D、预防性
答案: C

ソフト試験ノート - 9. ソフトウェアエンジニアリング