情報処理のWeb教科書―IPA情報処理試験対策のお供に!
トップ 情報処理の知識体系 テクノロジ系 技術要素 開発技術 システム開発技術
システム開発技術をテーマに要件定義、方式設計、詳細設計、構築、テスト、導入、受入れ、保守など、システムやソフトウェア開発の考え方、手順、手法、留意事項をまとめています。
この記事の目次になります。
1. システム要件定義・ソフトウェア要件定義
2. システム方式設計
3. ソフトウェア方式設計・ソフトウェア詳細設計
4. ソフトウェア構築
5. ソフトウェア結合・ソフトウェア適格性確認テスト
6. システム結合・システム適格性確認テスト
7. 導入
8. 受入れ支援
9. 保守・廃棄
システムとソフトウェア要件定義のあらましについてまとめています。
システム方式設計では、システムの最上位の方式確立、利用者文書(暫定版)の作成、システム方式の評価、システム方式設計の共同レビューを実施します。
共同レビューは、システムの利用者と開発者の間で、システムの設計書の記載内容が利用者の要求を 満たしていることを確認する場合などに実施します。
以下ではシステム方式設計に関連したIPA情報処理試験の過去問とその解説をまとめています。
ソフトウェア方式設計・ソフトウェア詳細設計について見ていきます。
ソフトウェア方式設計では、ソフトウェア構造とコンポーネントの方式設計、外部及びコンポーネント間のインタフェースの方式設計、 データベースの最上位レベルの設計、利用者文書(暫定版)の作成、ソフトウェア結合のためのテスト要件の定義、ソフトウェア方式設計の評価、 ソフトウェア方式設計の共同レビューを実施します。
ソフトウェア品目に対する要件を、最上位レベルの構造を表現する方式であって、かつ、ソフトウェアコンポーネントを識別する方法に変換するという作業がこの中に含まれます。
ソフトウェアライフサイクルプロセスにおいてソフトウェア実装プロセスを構成するプロセスのうち、ソフトウェア方式設計プロセスでは次のタスクを実施します。
〔タスク〕
以下ではソフトウェア方式設計のタスクに関連したIPA情報処理試験の過去問とその解説をまとめています。
JIS X 0129(ISO/IEC 9126)などで定義付けられているソフトウェア製品の品質特性を理解し、要件定義やシステム設計の際には品質特性を考慮します。
JIS X 25010:2013で規定されたシステム及びソフトウェア製品の品質副特性の説明では、信頼性の副特性について以下の特徴を示しています。
通常の運用操作の下で、システム、製品または構成要素が信頼性に対するニーズに合致している度合い
使用することを要求されたとき、システム、製品または構成要素が運用操作およびアクセス可能な度合い。
ハードウェアおよびソフト障害にも関わらず、システム、製品または構成要素が意図したように運用操作できる度合い。
中断時または故障時に、製品またはシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い。
以下ではJIS X 25010:2013に関連したIPA情報処理試験の過去問とその解説をまとめています。
ソフトウェア設計手法について見ていきます。
構造化設計について見ていきます。
構造化設計で用いられる手法としては、流れ図、DFD、構造化チャート、状態遷移図などがあります。
状態遷移図とは、英語でState Transition Diagramといい、状態の移り変わりを図で表したものです。 時間の経過や事象の発生に基づいて記述します。 なお、UMLでは状態遷移図のことをstate machine diagram(状態機械図)といいます。
状態遷移図は、システムが取り得る状態が有限個で、その状態がイベントをきっかけにして別の状態に遷移する様子を図示します。 変化するシステムの状態を論理的に表現できるという特徴があります。
また状態遷移図は、たとえば「温室制御システム」のような刻々と変化する状態に応じて対応が変わっていくシステムを表現するのに適しています。
以下では構造化設計に関連したIPA情報処理試験の過去問とその解説をまとめています。
オブジェクト指向(オブジェクト指向プログラミング)とは、オブジェクトという概念に注目し、これをモジュール化に役立てる手法です。 オブジェクト指向とはなど基本概念、オブジェクト指向設計の入門知識を解説しています。
モジュールの分割基準などモジュールの設計について見ていきます。
モジュールの独立性の評価基準として、モジュールの強度、結合度、それらと独立性との関係、分割量の評価基準、部品化と再利用のための評価基準があります。
モジュール結合度とは、複数のモジュール間の関連性の強さを表す尺度のことをいいます。
モジュールは、1つの機能だけを持たせることによってモジュールの強度が強くなります。 複数の機能を持たせると、それぞれの機能に関連性が出てきて、モジュールの強度が弱くなってしまいます。
一方、モジュール間のインタフェースを単純にすることで、モジュールの結合度を弱くすることが出来ます。 モジュール間のインターフェースが単純でないと、他のモジュールを意識する必要がでてきます。
モジュール結合度は、結合度が強い順に「内容結合>共通結合>外部結合>制御結合>スタンプ結合>データ結合」となります。
内容結合とは、あるモジュールがCALL命令を使用せずにJUMP命令でほかのモジュールを呼び出すときのモジュール間の関係をいいます。 あるモジュールが他のモジュールの内容を直接参照している状態をいいます。
共通結合とは、大域的なデータを参照するモジュール間の関係のことをいいます。 いくつかのモジュールが共通領域を参照している状態をいいます。
外部結合とは、大域的な単一のデータ項目を参照するモジュール間の関係のことをいいます。 いくつかのモジュールが共通データを参照している状態をいいます。
制御結合とは、実行する機能や論理を決定するために引数を受け渡すときのモジュール間の関係をいいます。 パラメータを渡してモジュールを実行している状態をいいます。
スタンプ結合とは、データの構造体を引数として受け渡し、呼ばれたモジュールでは、構造体の一部を使用するモジュール間の関係をいいます。 データ構造を変数化して受け渡す状態をいいます。
データ結合とは、処理に必要なデータだけを受け渡し、呼び出し側も呼ばれる側も機能的な関係はないモジュール間の関係をいいます。 データのみを引数として受け渡す状態をいいます。
以下ではモジュールの設計に関連したIPA情報処理試験の過去問とその解説をまとめています。
アーキテクチャパターンはソフトウェア構造のパターンです。 アーキテクチャパターンを利用する利点、留意事項を見ていきます。
ソフトウェアアーキテクチャパターンのうち、仕様の追加や変更による影響が及ぶ範囲を限定できるようにするために、 機能を業務ロジック、画面出力、それらの制御という、三つのコンポーネントに分けるものはどれか。
以下ではアーキテクチャパターンに関連したIPA情報処理試験の過去問とその解説をまとめています。
レビューについて見ていきます。
レビューには、プログラム設計レビュー、コードレビュー、テスト仕様レビュー、利用者マニュ アルレビュー、デザインレビューなどがあります。
デザインレビューとは、英語でDesign Review、省略してDRといい、開発における成果物を、複数の人にチェックしてもらう機会のことです。 設計工程において、設計内容を文書化して他の人にチェックしてもらうということを体系化したものです。
デザインレビューの目的は、成果物に入り込んだ欠陥の早期発見と除去です。
ウォークスルーとは、設計上の誤りを早期に発見することを目的として、開発担当者同士で実施するレビューのことをいい、 作成された仕様書などを開発担当者を含む複数の関係者で検討し、エラーを発見します。
以下ではレビューに関連したIPA情報処理試験の過去問とその解説をまとめています。
ソフトウェア構築では、ソフトウェアユニットの作成、テスト手順、テストデータの作成、ソフトウェアユニットのテストの実施、利用者文書の更新、 ソフトウェア結合テスト要件の更新、ソフトウェアコード及びテスト結果の評価を実施します。
単体テスト(ソフトウェアユニットのテスト)についてまとめています。 テストの目的、実施と評価、分岐網羅などのホワイトボックステストの観点やテスト手法について解説しています。
ソフトウェア結合では、ソフトウェア結合計画の作成、ソフトウェア結合テストの実施、利用者文書の更新、ソフトウェア適格性確認テストの準備、ソフトウェア結合の評価、 ソフトウェア結合の共同レビューを実施します。
スタブとは、英語でstubといい、複数のモジュールからなるプログラムのテスト時に下位モジュールの代用するモジュールのことです。 テスト対象のモジュールからの呼出し命令により、呼び出されたことを示すメッセージを表示する単純なものから条件に合わせて、値を返すものなどがあります。
以下ではソフトウェア結合・ソフトウェア適格性確認テストに関連したIPA情報処理試験の過去問とその解説をまとめています。
システム結合では、システム結合計画の作成、システム結合テストの実施、利用者文書の更新、システム適格性確認テストの準備、システム結合の評価、 システム結合の共同レビューを実施します。
システム又はソフトウェアの導入(インストール)では、システム又はソフトウェアの導入計画の作成、導入を実施します。
システム又はソフトウェアの受入れ支援では、取得者の受入れレビューや受入れテストの支援、納入、取得者への教育訓練及び支援を実施します。
保守の目的やサービスレベルなどの保守を受ける側の要求、保守を提供する側の実現性や費用を考慮して、保守要件を決定します。 また、保守では問題の発生、改善、機能拡張要求などへの対応として、既存システム又は既存ソフトウェアの安全性を維持しつつ修正や変更を行います。
ソフトウェア保守では、システム開発後にプログラムの修正や変更を行います。 またソフトウェア保守には稼働後にプログラム仕様書をわかりやすくするための改善なども含まれます。
移行など保守の手順について見ていきます。
システムの運用を開始する際に、移行計画の作成、システムの利用者への移行計画の通知、移行、新旧環境での並行運用、移行の評価などが必要です。
移行計画について見ていきます。
移行計画とは、システムを新しい環境などに移行する際の計画のことをいいます。
移行計画の英語は、migration plan あるいは migration planningとmigrationという言葉を使います。
移行計画書とは、システムの移行で行う移行作業などを記述した文書のことをいいます。
移行計画書には、以下が記載されている必要があります。
※以下が全てというわけではありません。
移行するデータ量が多いほど、移行本番でシステム停止したときに一気にデータを移行する「静止点移行」だけでは移行完了までに時間がかかり過ぎ、現実的ではなくなります。
移行データの容量や更新タイミングといった特性によって、データ移行作業の分割実施を検討する必要があります。
新旧で環境が共有されている場合、移行の確認に手間がかかります。
また、新旧で運用が重複されるほど移行コストがかかります。 「一括移行」「段階移行」「並行運用」という三つの移行方式の移行コストの関係は次のようになります。
「一括移行」 < 「段階移行」 < 「並行運用」
以下では保守・廃棄に関連したIPA情報処理試験の過去問とその解説をまとめています。
情報処理試験対策用のサイトオリジナル教科書をテーマにテクノロジ系の知識をまとめています。
Copyright (C) 2010-2023 情報処理のWeb教科書. All Rights Reserved. Loarding…