【ゆる~い解説で頻出問題が頭に残る】ITパスポート~システム開発技術編~

どうも、娘さんの離乳食の残飯が自分のお昼になるメンマです。

現在、育休中で0歳の娘さんを育てながら細々とITパスポートの試験勉強をしております。

本シリーズでは社会人4年目、IT初心者の私が過去問を解く中で出てくる用語やシラバス改訂により追加された用語の内、

「この用語、意味分かりづら!」

「この問題、ちょっと待って!」

ってなるような用語や問題について試験に出るポイントを押さえながら、ゆる~く解説していきます。

こんな人に向けて!

ITパスポート
・勉強中だけど、箸休めしたい人
・問題を解いた後に、解説を飛ばしてしまう人
・具体的な試験内容を知りたい人

この記事を読むことで、「丸暗記が理解に変わる」ようになります。

今回のポイントは2つ!

理解に変わるポイント!

・過去問の具体例に慣れておく
・システム開発プロセスの全体像をつかむ

この記事では、上記2つのポイントを皆さんの代わりにメンマがまとめました!

それでは今回は「システム開発技術編」です。

目次

3つの要件定義

要件定義プロセス・システム要件定義・ソフトウェア要件定義

システム開発のプロセスの内、「要件定義」と付く項目が3つあります。

これが混同しやすいポイントであり、過去問でも出題率の高いところでもあります。

この3つの項目の共通点は文字通り、なにかを「決める」作業であること。

では、何を決める作業なのかを表で比較しましょう!

要件定義決定事項具体的な内容  
要件定義プロセス業務要件システム化する範囲
ソフトウェア要件定義ソフトウェア要件ソフトウェアの機能や性能
システム要件定義システム要件
システムに必要な機能と性能
メンマ<br>
メンマ

下の作業に行くにつれて、段々と決定する範囲が狭まってくるね

図で見る3つの要件定義の違い

では、今度はプロセスの流れのなかで、3つの要件定義の位置関係を見てみましょう。

業務という大きな括りを決める「要件定義プロセス」は、システム開発の5つのプロセスの1つで、3つの要件定義の中でも1番に取り掛かる作業です。

次に開発プロセスの工程となる「システム要件定義」でシステムに関する仕様、「システム設計」での「ソフトウェア要件定義」でソフトに関する仕様が決められていきます。

全体の流れが分かるプロセス図の中で、作業内容も暗記するとスムーズに覚えられるよ!

上流の工程で大きな枠組み(範囲)を決め、下流に行くほど細部の仕様を決める工程へ。

ソフトウェア受入れ

ソフトウェア受入れとは

開発プロセスの最後の行程となるのが、この「ソフトウェア受入れ」です。

ソフトウェア受入れは、開発したソフトウェアを発注者に納品する作業です。

この作業では、本番環境にソフトウェアをインストールする「ソフトウェア導入」と、ソフトウェア受入れテストを行う「ソフトウェア受入れ支援」が行われます。

メンマ
メンマ

「ソフトウェア受入れ支援」では、ユーザにベンダ(開発者)が使い方を指導しながら、テストを行うよ。
その際には、ソフトの取説となる「利用者マニュアル」が使われるんだ!

過去問で見るソフトウェア導入のポイント

問題 社内で開発したソフトウェアの本番環境への導入に関する記述のうち、最も適切なものはどれか。

ア. 開発したソフトウェアの規模によらず必ず導入後のシステム監査を行い、監査報告書を作成する必要がある。

イ. ソフトウェア導入は開発作業に比べて短期間に実施できるので、導入手順書を作成する必要はない。

ウ. ソフトウェア導入に当たって、実施者、責任者などの実施体制を明確にしておく必要がある。

エ. ソフトウェア導入はシステム部門だけで実施する作業なので、作業結果を文章化して利用部門に伝える必要はない。

( 出典:平成3年度秋期 第36問 )

システム監査はいらない

ソフトウェア導入では、システム監査を必須事項としていません。

導入手順書=利用者マニュアル

導入手順書とは、つまり取説なので「利用者マニュアル」と置き換えていいでしょう。

利用者マニュアルを使いながら、ユーザを指導するのもソフトウェア受入れの時に行います。

メンマ
メンマ

必ずしも問題文で、「利用者マニュアル」という表現が使われるわけじゃないんだね。

ソフトウェアを使うのはシステム部とは限らない!

導入したソフトウェアを使うのが、システム部とは限りませんよね。

営業用のソフトだったら営業部門、諸経費に関するものであれば経理部門が実際のユーザになります。

ソフトウェア受入れの際には、ユーザとなる部門が利用者マニュアルを見ながら開発者から指導を受ける必要があります。

メンマ
メンマ

「実際の業務内容にあったソフトになっているか」、
ユーザに確認してもらう場でもあるんだよ。

ということで、正解は「エ」になります。

ややこしいプロセス問題

「3つの要件定義」でも感じるように、実際に何かを「作成」するよりも「調査(評価)・決定」をするプロセスが多いのです。

そのため、それぞれの用語説明を読んで違いを理解したつもりでも、問題で具体例に置き換えられたときに「どれに該当するのか」が分かりにくいことも、しばしば。。。

ということで、実際に過去問を見ながら、どのプロセスの説明か確認していきましょう!

過去問でみるプロセス問題のポイント

問題 業務パッケージを活用したシステム化を検討している。情報システムのライフサイクルを、システム化計画プロセス、要件定義プロセス、開発プロセス、保守プロセスに分けたとき、システム化計画プロセスで実施する作業として、最も適切なものはどれか。

ア. 業務パッケージの標準機能だけでは実現できないので、追加開発が必要なシステム機能の範囲を決定する。

イ. システム運用において発生した障害に関する分析、対応を行う。

ウ. システム機能を実現するために必要なパラメタを業務パッケージに設定する。

エ. 機能、性能、価格などの観点から業務パッケージを評価する。

( 出典:平成3年度秋期 第36問 )

では、見分けるポイントにマーカーを引いて、チェックしていきますよ!

「ア. ~追加開発が必要なシステム機能の範囲を決定する」

→「要件定義プロセス」です。システム化する範囲を決めます。

「 イ. ~障害に関する分析、対応を行う

→「保守プロセス」です。運用中のシステムの維持管理を行います。

「 ウ. システム機能を実現するのに必要なパラメタを業務パッケージに設定する 」

→「開発プロセス」です。開発プロセスの工程である「システム要件定義」にて、システムに必要な機能や性能を設定します。

「 エ. 機能、性能、価格などの観点から業務パッケージを評価する。 」

→「システム化計画プロセス」です。業務パッケージとは業務に必要な機能をまとめたソフトウェアで、そのシステムを「機能・性能・価格の点で評価する」というポイントで、システム化計画プロセスと判断できます。

よって、正解は「エ」になります。

図で見る調査・決定を行うプロセス

過去問以外にも図とセットで覚えると、よりプロセスの流れがつかめます。

「調査(評価)・決定」を行うプロセスをピックアップしましたので、下の図で確認してみてください。

まとめ

・ソフトウェア受入れのポイント
 利用者マニュアルを使ったユーザへの指導
 システム監査はいらない

【調査・決定を行う作業】
・システム化構想の立案プロセス
・システム化計画の立案プロセス
・システム方式設計
+3つの要件定義
・要件定義プロセス: システム化の範囲を決定
・ソフトウェア要件定義: ソフトウェアの機能や性能を決定
・システム要件定義: システムに必要な機能と性能を決定

いかがでしたでしょうか。

今回は文章を読むよりも、図を見た方が断然、理解がすすむ回だと思います。

また、プロセス問題は過去問でどこが判断基準になっているか確認しておくことも大切でしょう!

よかったらシェアしてね!

コメント

コメントする

CAPTCHA


目次
閉じる