システムの開発と運用

1. 一部の装置の故障がシステム全体の停止につながることが多い。
2. 機能の拡張や業務量の増大に対応したシステムの拡張などが困難である。
3. 機密保護やセキュリティの確保が容易である。
4. システム全体を効率よく運用するための運用管理が煩雑になりやすい。

解答：

1. クライアントとサーバの関係のように、プロセッサ間で階層または従属関係が存在する。
2. システムの効率を向上させるために、同じアプリケーションを実行するいくつかのプロセッサ間で負荷を分散する。
3. 単独でも機能する複数のコンピュータシステムを、ほぼ対等な関係でネットワークに接続し、データを含めてリソースを共有する。
4. 負荷を分散するために、アプリケーションごこに、ネットワーク内のどのプロセッサで実行するかをあらかじめ決めておく。

解答：

1. ２階層構造に比べ３階層構造では、GUIツールの利用によって比較的簡単にプログラムを作成でき、プロトタイピング開発やエンドユーザーコンピューティングに適する。
2. ２階層構造に比べ３階層構造では、階層間の依存度が少ないので、階層ごとに並行して開発しやすい。
3. ２階層構造に比べ３階層構造では、業務処理のロジックに変更が生じた場合、全てのクライアントに対し、インストールされたプログラムの入れ替えが必要になる場合が多い。
4. ２階層構造に比べ３階層構造では、クライアントのアプリケーションの機能追加によって、クライアントとサーバ間のデータベースアクセス要求が増加し、レスポンスが悪化する場合が多い。

解答：

1. WWWブラウザをクライアントとサーバの双方に導入し、インターフェイスを統一することによって、コストの削減を図る。
2. アプリケーションにおけるデータの追加処理をクライアントとサーバで分担することによって、コストの削減を図る。
3. クライアント側にアプリケーションを持たせ、サーバは共通データの管理だけを行うことによって、コストの削減を図る。
4. クライアント側はユーザーとのヒューマンインタフェイスだけを担当することによって、コストの削減を図る。

解答：

1. 他のモジュールとデータ項目を共有するためにグローバルな領域を使用する。
2. 他のモジュールを呼び戻すときに、呼び出されたモジュールの論理を制御するための引数を渡す。
3. 一つのモジュールに機能を数多く入れる。
4. 二つのモジュール間で必要なデータ項目だけを引数として渡すようにする。

解答：

1. 外部結合は、異種のデータ項目を大域的データとして受け渡す。
2. 共通結合は、同種のデータ項目を大域的データとして受け渡す。
3. 制御結合は、異種のデータ項目を引数として受け渡す。
4. データ結合は、同種のデータ項目を引数として受け渡す。

解答：

1. 機能的強度を持つモジュールと情報的強度を持つモジュールだけで構成されるプログラムを、最も望ましいものとして普及させるため。
2. どのようなプログラムも、機能的強度を持つモジュールと情報的強度を持つモジュールだけで構成できることを証明するため。
3. どのレベルまでモジュールを細分化したらよいかについて、設計の標準を提供するため。
4. モジュール強度の強弱を認識して、設計者がモジュールを作成したり利用したりできるようにするため。

解答：

1. 各工程の作業手順を定義することが容易になり、開発・保守時の作業ミスを防止することができる。
2. 各工程での作業予定と実績を関連づけて管理することが可能になり、作業の進捗管理が容易になる。
3. 各工程での生産物を一元管理することによって、用語の統一化、さらには修正作業の自動化が可能になり、開発・保守作業の効率を向上させることができる。
4. 各工程での発生不良を管理することが可能になり、ソフトウェアの品質分析が容易になる。

解答：

1. CGI
2. POP
3. SMTP
4. SNMP

解答：

1. CGIスクリプトはクライアント側で動作するので、サーバ負荷軽減につながる。
2. CGIスクリプトを記述するのに使用できる言語は、Perlだけである。
3. CGIを使えば、セキュリティに関する問題は発生しない。
4. CGIを使えば、ユーザーからの要求に応じてデータベースサーバなどに処理を依頼し、その結果をWWWブラウザに返すことができる。

解答：

1. Javaコンパイラがソースコードをバイトコードに変換し、Java仮想マシンがバイトコードを実行する。
2. Javaで開発したプログラムを実行するためには、ブラウザが必要である。
3. Javaで開発したプログラムを別のプラットフォームで実行するためには、再コンパイルが必要である。
4. アプレットは、セキュリティ上の理由から、ブラウザが動いているマシン以外とは通信できない。

解答：

1. インターネットで用いられる通信プロトコル
2. インターネット用の閲覧ソフトウェア（ブラウザ）
3. オブジェクト指向のプログラム言語
4. カラー静止画像の符号化方式

解答：

1. インスタンス
2. カプセル化
3. クラス化
4. メッセージ

解答：

1. オブジェクトは、そのデータに対して定義されたメソッドによってだけ、アクセス可能である。
2. オブジェクトは、抽象データ型の要素でなければならない。
3. 親クラスに定義されたメソッドは、実行時に子クラスだけに引き継がれる。
4. 同一メッセージでも、実行時には受信クラスに基づきメソッドが束縛される。

解答：

　　　　　　　　　　　　　　　　　　　　　　自動車
　　　　　　　　　　　　　　　　　　　　　　　　|
　　　　　　　　　　　　－－－－－－－－－－－－－－－－
　　　　　　　　　　　　|　　　　　　|　　　　　|　　　　　|　　　　　　|
　　　　　　　　　　　バス　　トラック　　セダン　　バン　　　　・・・

1. "自動車"のデータは"バス"、"トラック"などのクラスで引き継ぐことをインスタンスという。
2. "自動車"は、"バス"、"トラック"などのクラスから見て、サブクラスといえる。
3. "バス"、"トラック"などのクラスの共通部分を抽出して、"自動車"のクラスとして定義することを汎化という。
4. "バス"、"トラック"などのそれぞれのクラスの違いを、"自動車"のクラスとして定義することを特化という。

解答：

1. A氏所有のスポーツカー、B氏所有のセダン、C氏所有のワゴン→乗用車
2. X社のバス、Y社のバス、Z社のバス→企業の所有する自動車
3. 駆動装置、車体、車輪→自動車
4. 自動車、バス、トラック→自動車

解答：

1. 最初に最適なアクセスパスを一つ用意しておけば、データ量が増加しても効率は悪化しない。
2. すべての読み取りアクセスは、必ずインデックスを使うアクセスパスにするほうが効率がよい。
3. データの追加や削除の頻度が高い列に対しては、インデックスを設けないほうが効率がよい。
4. 同時に多くのトランザクションが処理されても、排他制御機能があるので、効率には影響しない。

解答：

1. ２相コミットを使用するときは、２相ロックを使用しなければならない。
2. 新たなロックを獲得する前に、すでに獲得したロックを解放することによってデッドロックを回避できる。
3. コミットまたはロールバックが実行されるまでロックを解放しない。
4. トランザクションが獲得するロックの数は、単調に増加し、単調に減少するだけであり、増減を繰り返すことはない。

解答：

1. ソフトウェアまたはハードウェアの障害などによって、データベースが破壊されることがある。このような場合に、データベースを復元するための機能を、再構成機能という。
2. データの不当な漏洩や改ざんを未然に防止するために、アクセスを制御する機能を排他制御機能という。
3. データベースに対する変更操作が繰り返されると、データの物理的な格納位置が不規則になったり、削除領域が利用できない状態になったりする。これを修復し、アクセス性能を向上させるための機能を、再編成機能という。
4. 複数の利用者が同じ情報を更新する場合、適切な制御がないとデータベース内のデータに矛盾が生じることがある。このような矛盾を防止するための制御機能を、優先制御機能という。

解答：

1. 原因結果グラフ
2. 限界値分析
3. 同値分割
4. 判定条件網羅

解答：

1. 入力データを同値分割法に基づいて分析し、テストデータを作成する。
2. プログラムのアルゴリズムなど内部構造に基づいてテストデータを作成する。
3. プログラムの機能に基づいてテストデータを作成する。
4. プログラムの入力と出力の関係に基づいてテストデータを作成する。

解答：

1. スタブ
2. ダイナミックテスト
3. デバッガ
4. ドライバ

解答：

1. ブラックボックステスト、トップダウンテスト
2. ブラックボックステスト、ボトムアップテスト
3. ホワイトボックステスト、トップダウンテスト
4. ホワイトボックステスト、ボトムアップテスト

解答：

1. 0　20　40
2. 0　1　30　31
3. 0　20　30　40
4. 0　1　20　30　31

解答：

　　〔稼働率の合格基準〕
　　　テスト期間中の連続する３週間において、次の条件を満たしているときに合格とする。
　　　（１）各週の稼働率は、0.980を下回らないこと
　　　（２）３週間の通算の稼働率は、0.995を下回らないこと

　　〔運用記録のサマリ〕
　　　テスト期間｜システム運転時間｜障害の修復の履歴
　　　－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
　　　　第１週　　|　　１２０時間　　　　|　火曜日午前９時～１２時まで３時間停止
　　　　第２週　　|　　１２０時間　　　　|　金曜日午前４時～５時まで１時間停止
　　　　第３週　　|　　１２０時間　　　　|　金曜日午前４時～４時３０分まで０．５時間停止
　　　　第４週　　|　　１２０時間　　　　|　障害なし

1. 第３週を終わった時点で合格の判定をしてもよかった。
2. 第４週を終わった時点で合格の判定をしてもよい。
3. 第４週を終わった時点で不合格であり、今後１週間は運用テストを続ける必要がある。
4. 第４週を終わった時点で不合格であり、今後２週間は運用テストを続ける必要がある。

解答：

1. 新たなシステムを確実に稼動させるために、旧システムからの切り替えにかかわるプロセスを、安全性・効率性の観点から事前に確認する。
2. 既存システムのデータベースのコピーを利用して、新たなシステムでも十分な性能が発揮できるかを確認する。
3. 既存のプログラムと新たに開発したプログラムのインターフェースの整合性を確認する。
4. スタブやドライバを準備し、新たに移行されるプログラムの論理仕様を確認する。

解答：

　　　　　　　　　　　　　　　－－B－→（３）－－E－－
　　　　　　　　　　　　　　　｜　　　　　　｜　　　　　　↓
　　　　　　　（１）－－A－→（２）             D　　　　　　（５）－－G－→（６）
　　　　　　　　　　　　　　　｜　　　　　　↓　　　　　　↑
　　　　　　　　　　　　　　　－－C－→（４）－－F－－

　　　　　　　　　　　　　　　　作業　　所要時間（日）
　　　　　　　　　　　　　　　　　A　　　　　　3
　　　　　　　　　　　　　　　　　B　　　　　　6
　　　　　　　　　　　　　　　　　C　　　　　　5
　　　　　　　　　　　　　　　　　D　　　　　　3
　　　　　　　　　　　　　　　　　E　　　　　　4
　　　　　　　　　　　　　　　　　F　　　　　　5
　　　　　　　　　　　　　　　　　G　　　　　　3

1. 7
2. 9
3. 12
4. 13

解答：

解答：

1. エラー、仕様の不一致を早期に発見し、手戻り工数の削減を図る。
2. 開発規模の見積もりの最適化を図る。
3. 単体テスト項目を同時に洗い出し、テスト作業の効率化を図る。
4. レビューの結果から、コードレビューの実施を省略できるかどうかを判断する。

解答：

1. 過去の不良事例を活用するためには、その発生要因よりも技術的観点でまとめたほうが活用しやすい。
2. 工程線表上に実施時期を明記しないで、設計者が必要な都度実施するのが望ましい。
3. 使用されるドキュメントは、本来デザインレビュー用に用意するのではなく、設計作業時に作られるべきである。
4. ドキュメントに記述された内容をレビューするのであって、記述されていない事柄を指摘することは好ましくない。

解答：

1. 開発工程におけるWBSごとに作業工数を積み上げてコストを見積もるモデルである。
2. 開発の専門家が過去の経験から類推してソフトウェアの規模を見積もるモデルであり、デルファイ法によってその見積り値を収束していく。
3. ソフトウェアの機能を入出力の数やマスタファイルの数でとらえ、難易度を考慮しながらソフトウェアの規模を見積もるモデルである。
4. ソフトウェアの規模を入力変数として、コスト誘因とそれに対する係数を考慮しながら開発工数を計算してコストを見積もるモデルである。

解答：

1. 業務システム開発の総コスト
2. システム導入から運用・保守・教育までんを含む総コスト
3. システム導入時の総コスト
4. 通信・ネットワークの総コスト（ハードウェア、ソフトウェアを含む）

解答：

1. デッドロックはCPUを複数持つシステムで発生するが、CPUが１個のシステムでは発生しない。
2. デッドロックは、常に２つのプロセス間で発生するものであり、３つ以上のプロセス間で発生することはない。
3. 複数の資源に対する割当と解放の順序をあらかじめ決めておき、すべてのプロセスがこのルールを守れば、デッドロックは発生しない。
4. ２つのプロセスに同じ資源を参照モードで割り当てる場合でも、デッドロックが発生する場合がある。

解答：

1. アプリケーションサーバAから監視用サーバXへのICMP宛先到達不能（Destination
   Unreachable）メッセージ。
2. アプリケーションサーバAから監視用サーバXへのSNMP
   Trap PDU。
3. 監視用サーバXからアプリケーションサーバAへのFinger。
4. 監視用サーバXからアプリケーションサーバAへのPING。

解答：

1. TCP SYNの大量発生が起こった。
2. マクロ感染型のコンピュータウィルスに感染した。
3. メール爆弾が投入された。
4. 論理爆弾が組み込まれていた。

解答：

　　a　トランザクション処理途中の矛盾
　　b　トランザクションコミット後の媒体障害
　　c　トランザクション処理途中のデッドロック

1. a（ロールバック）b（ロールバック）c（ロールフォワード）
2. a（ロールバック）b（ロールフォワード）c（ロールバック）
3. a（ロールフォワード）b（ロールバック）c（ロールフォワード）
4. a（ロールフォワード）b（ロールフォワード）c（ロールバック）

解答：

　　　　　　　　　　　　　　　チェックポイントt1　　　　　　　　　　　　　　システム障害発生t2
　　　　－－－－－－－－－－－－－－－－－－－－－－－－－－→
時間
　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　｜
　　　　　開始　TR1　コミット
　　　　　　|———–|
　　　　　　　　　　　　　　　
　　　　　　　　　　　開始　TR2　コミット
　　　　　　　　　　　　|———–|
　　　　　　　　　　　　　　　　　 
　　　　　　　　　　　　　　開始　　　　　　　　TR3
　　　　　　　　　　　　　　　|—————————–
 　　　　　　　　　　　　　　　　　 
　　　　　　　　　　　　　　　　　　　　開始　TR4　コミット
　　　　　　　　　　　　　　　　　　　　　|———–|
 　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　開始　TR5
　　　　　　　　　　　　　　　　　　　　　　　　　　　　|————
　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　｜

1. TR1とTR2
2. TR2とTR3
3. TR2とTR4
4. TR3とTR4

解答：

1. 業務処理上の誤りによってデータベースの誤更新が行われた場合、ジャーナルファイルの更新後情報を用いて最新の状態に回復する。
2. ディスクアクセス時に回復不能なエラーが発生した場合、最新のバックアップファイルとジャーナルファイルの更新情報を用いて回復する。
3. データベースの回復処理に備えて、定期的にバックアップファイルを作成するとともに、オンライン稼動中にはジャーナルファイルに更新前後の情報を記録する。
4. データベースの回復処理に備えて、入力されたトランザクション、更新前後のデータベースレコードおよびその際の処理プログラムを含むジャーナルをとる。

解答：

　　　データベースを実際に更新する前後に（　a　）をとる。あるトランザクションの処理が途中で中止されたときは、（　a　）に記録された（　b　）情報をもとにして、データベースをトランザクション処理前の状態に戻す。この操作を（　c　）という。

1. a（バックアップ）b（更新後）c（ロールバック）
2. a（バックアップ）b（更新前）c（ロールフォワード）
3. a（ログ）b（更新後）c（ロールフォワード）
4. a（ログ）b（更新前）c（ロールバック）

解答：

1. データベース全体のファイルダンプは、トランザクション内に設定したチェックポイントで定期的に取得されているか。
2. 変更直前の値(ビフォアイメージ）のジャーナルは取得されているか。
3. ロールバック処理は、DBMSの開始状態に戻すことができるか。
4. ロールフォワード処理は、トランザクションのアボート処理に対して機能するか。

解答：

1. ネットワーク構成の変更は、失敗の際の影響が大きいので、構築時に十分な構成の検討を行い、運用開始後は変更しないようにすることが重要である。
2. ネットワーク構成の変更は、必要に応じていつでも行うことができるように、機器台帳・管理台帳などの更新をタイムリーに実施することが重要である。
3. ネットワーク構成を変更する場合は、ネットワークセキュリティを確保するため、すべてのユーザー業務を停止させてから実施する必要がある。
4. ネットワーク構成を変更する場合は、変更規模が大きくなるほど担当者の経験やスキルを生かし、ネットワーク管理ソフトウェアによる自動的な更新を避ける必要がある。

解答：

1. ネットワーク構成の変更は、失敗の際の影響が大きいので、構築時に十分な構成の検討を行い、運用開始後は変更しない。
2. ネットワーク構成の変更は、比較的頻繁にあるので、機器台帳・管理台帳などの更新をタイムリーに実施することが重要である。
3. ネットワーク構成を変更する場合は、機密保護および安全確保の観点からユーザー業務を必ず停止させてから実施する。
4. ネットワーク構成を変更する場合は、範囲を分割し変更規模を小さくしたうえで、担当者の経験を生かし、ネットワークソフトウェアによる自動的な変更は避ける。

解答：

1. システム資源の構成を把握し、新設・増設・移転・撤去などに対応する。
2. システム資源の利用状況に応じてコストを計算し、利用部門に賦課する。
3. システム資源の利用状況を分析し、システムの性能上の問題点を摘出し対策をとる。
4. データ量の増加予測に対して、システム資源の増設計画を立案し実施する。

解答：

1. 地震災害の対策として、重要なデータやプログラムは遠隔地のバックアップセンターにも重複して保管・管理することである。
2. システム負荷について現状分析と将来予測を行い、サービス水準の維持のためにシステム資源を適切に管理することである。
3. 日常の業務処理についてシステムの監視や操作の標準化を行い、処理の信頼性向上とシステムの効率的運用および管理をすること。
4. バックログ解消のために、システム開発要員を適切に採用、訓練、配置し、管理することである。

解答：

1. 障害記録、ジョブごとの処理時間、プログラムステップ数。
2. 障害記録、ジョブの優先順位、必要なシステム資源。
3. ジョブごとの処理時間、ジョブの相互関係、ジョブの優先順位。
4. ジョブの相互関係、ジョブの優先順位、プログラムステップ数。

解答：