ここからはマネジメント編に入るっす。とはいっても話しは前回のストラテジ編の続きで、ソフトウェアライフサイクルの開発プロセスっす。
ITパスポートって、非エンジニアの人を対象とした資格って言ったよね？開発のことなんて勉強する必要あるの？
それではまず、その辺の話からしていくっすよ。
| 目標 | ・システム開発のプロセスの基本的な流れを理解する。 ・システム開発における見積りの考え方を理解する。 |
| 説明 | ・システムがどのようなプロセスを経て開発されるかを理解するために，要件定義，設計，プログラミング，テストなどのプロセスの流れを知り，見積りやレビューの考え方を理解する。 |
目次 非表示
開発プロセスを知っておく意味
イントロダクションの「ITパスポートって役に立つの？～勉強する意義について～」では、ITパスポートは非エンジニア、非IT系の人たちを対象とした資格だと説明しました。それではなぜ、開発に関することまで勉強しなければならないのでしょうか？
今では、規模や業種、業態に関わらず、何らかのシステムを利用している企業がほとんどだと思います。もし、システム開発を依頼する側やシステムを運用する側にシステムやITに関する知識がなければ、ベンダーとの意思疎通が難しかったり誤解が生じるなどして、様々なトラブルが生じる原因になることもあります。
また、システム開発は依頼元とベンダーが意思疎通しながら協力して進めるプロセスもあるため、依頼元に最低限のシステム開発に関する知識があった方が、効率的に開発を進めることができます。これは依頼元とベンダー双方に利益をもたらします。
なので、非エンジニアの人も基本的なことぐらいは知っとこうね、という意味があるんすよ。
相手の状況を理解していないっていうところからトラブルが生まれたりするからね。
システム開発のプロセス
今回の学習内容はソフトウェアライフサイクルの開発プロセスです。開発プロセスは次のような工程で行われます。
このページでは①要件定義と②システム設計について学習し、それ以降は次のページで扱います。
| 工程 | 主な学習内容 |
|---|---|
| ①要件定義 | ソフトウェア要件定義、システム要件定義、品質特性 |
| ②システム設計 | システム方式設計→ソフトウェア方式設計→ソフトウェア詳細設計 |
| ③プログラミング | コーディング→単体テスト |
| ④テスト | 結合テスト→システムテスト→運用テスト |
| ⑤導入・受入れ | 受入れテスト、利用者等の教育訓練 |
上記の開発の流れはウォーターフォールモデルと呼ばれる開発モデルです。他にも開発モデルはありますが、それは別の単元で学習します。
要件定義
ストラテジ編で（1回目の）要件定義を学習した際に、「要件定義は2度現れる」と書きましたが、開発プロセスにおける要件定義が2回目の要件定義となります。2回目の要件定義では、担当者からのヒアリングなどを元に、システム・ソフトウェアに要求される機能、性能などをより具体的に明確化するシステム要件定義やソフトウェア要件定義などが行われます。
もし要件定義に不備があれば、開発作業に大幅な手戻りが生じたり、望み通りのシステムができなかったりなどの問題が生じるため、要件定義は非常に重要な作業となります。
システムに要求される機能や性能を明確化します。これにはハードウェアの性能やネットワーク環境などが含まれます。
なお、ここでも1回目の要件定義と同様に機能要件と非機能要件を明確にしていきます。
機能要件
業務要件の実現に必要な情報システムの機能に関する要件で、システムが備えるべき機能について定めたものです。そのシステムが扱うデータの種類や構造、処理内容、操作画面や帳票印刷といったインタフェースなど。必ず備えていなければいけない最低限必要な機能です。
非機能要件
性能や可用性及び運用・保守性などの品質要件や、技術要件、セキュリティ、運用要件などの機能面以外の要件全般。利用者の満足度や利便性などを向上させるものです。
ソフトウェア（コンピューターにインストールされるプログラム）に要求される機能や性能を明確化します。インターフェース（操作画面）やデータの定義（データの種類やデータベースの要件）などが含まれます。
「システム」という言葉は様々な意味合いで使われますが、少なくともITパスポート試験では、ソフトウェアとハードウェアを合わせたもの（もしくはそれらにネットワーク環境などを加えたもの）を「システム」と呼びます。
ITパスポート試験では、「どの作業がどのプロセスで実施されるか」といった問題がよく出題されますが、それらの作業をすべて丸暗記するのはとても大変で非効率です。なので、「このプロセスでは大体こういうことをやるんだ」ということだけをざっくり理解しておいて、選択肢の中から考えて選べるようにするのがいいと思います。あまり細かいことは気にしないというのが勉強のコツです。
なんで２回も要件定義するのさ。１回で十分じゃないの？
要件定義プロセスでの「１回目の要件定義」は、依頼元企業が中心となって行うものでした。したがって、あまり技術的なことは気にせずに「システムでこういうことがしたい」ということを明確にする業務要件定義がメインです。
しかし、開発プロセスでの「２回目の要件定義」はベンダー企業のシステムエンジニアなどが中心となって行うシステム要件定義がメインです。
次の設計の工程に進むため、エンジニア目線でより細かいところまで詰めていくといった作業になります。
ここで細かいところまで詰めておかないと、次の設計のプロセスに入れないんすよ。
品質特性はシステムやソフトウェアの品質を客観的に評価する基準で、要件定義などにおいて考慮すべき指標とされます。
- 機能性：目的を達成するために必要な機能が実装されているか。
- 効率性：使用する資源（時間・労力・資金）の度合いとその効果。費用対効果。
- 使用性：わかりやすさ、使いやすさ。
- 信頼性：故障などがなく、機能が正常に稼働するか。
- 保守性：保守作業（管理・修理）がしやすいか。
- 移植性：別の稼働環境に移した場合の対応のしやすさ。
複数人でレビュー（審査や点検など）を行うチェック手法です。依頼元と開発元で要件定義の内容を確認し、誤解や認識のズレがないかなどをチェックします。
共同レビューは要件定義だけでなく、開発プロセスの様々な場面で実行されます。
システム設計
システム設計は、その名の通り要件定義にもとづいてシステムを設計する工程です。いわば、システムの”設計書”を作成する工程といえます。
システム設計は次のような手順で進められます。
システム方式設計
（外部設計）
ソフトウェア方式設計
（内部設計）
ソフトウェア詳細設計
（プログラム設計）
システム方式設計（外部設計）
入出力画面や帳票などのシステムの見える部分の設計を行います。また、ハードウェアやネットワークの構成を決定したり、システム要件を「ハードウェア」、「ソフトウェア」、「手作業」のうち、どの手段で実現するのかを振り分ける作業なども含まれます。
ソフトウェア方式設計（内部設計）
ソフトウェア要件定義に基づいて、ソフトウェアの全体構造（最上位レベルの構造）や処理手順、データベースの設計などが行われます。
ソフトウェア詳細設計（プログラム設計）
ソフトウェア方式設計に基づき、コーディングが行えるレベルまで詳細に設計していきます。
コーディングとはプログラム文を書くことをいいます。
ソフトウェア方式設計はいわばソフトウェアの全体像の設計です。このままではプログラミング作業を行うことは難しいため、プログラミングを行いやすい機能ごとのプログラムの単位（モジュール）まで分割していきます。
例えば「ログイン」という大きな機能を実装したい場合、「ID、パスワードの入力」「ID、パスワードの認証」「新規登録」「パスワードリマインダ」などの小さな機能がいくつも必要となります。これらを分割したうえで、次のプログラミングの工程に進んでいくわけです。
確認○×問題
会計システムの開発を受託した会社が、顧客と打合せを行って、必要な決算書の種類や、会計データの確定から決算書類の出力までの処理時間の目標値を明確にした。この作業を実施するのに適切な工程はシステム要件定義である。
（出典：令和元年度秋期分 問45一部改変）
答え：〇
システム要件定義では、担当者からのヒアリングなどを元に、システムに要求される機能や性能を明確化します。
次の作業はシステム開発プロセスのシステム設計で実施される。
実務に精通している利用者に参画してもらい、開発するシステムの具体的な利用方法について分析を行う。
（出典：令和2年度秋期分 問44一部改変）
答え：×
設問の作業はシステム要件定義で実施される作業です。
無停止のシステムを実現するために、システムの方式を設計するときの検討事項として、「データの暗号化」が適切である。
（出典：平成25年度秋期分 問47一部改変）
答え：×
「データの暗号化」は無停止のシステムの実現とは関係ありません。無停止のシステムを実現するためには、例えば「ハードウェアを多重化して、障害が発生した場合は予備のハードウェアに切り替えて稼働を継続する」といったことなどを検討します。
システム開発を、システム要件定義、システム方式設計、ソフトウェア要件定義、ソフトウェア方式設計、ソフトウェア詳細設計の順で実施するとき、ソフトウェア詳細設計で初めて決定する事項は「コーディングを行う単位となる個々のプログラムの仕様」である。
（出典：平成25年度秋期分 問40一部改変）
答え：〇
ソフトウェア詳細設計（プログラム設計）では、ソフトウェア方式設計に基づき、コーディングが行えるレベルまで詳細に設計していきます。
ソフトウェア製品の品質特性を、機能性、使用性、信頼性、移植性などに分類した場合、機能性に該当するものはbである。
| a | 障害発生時にデータを障害前の状態に回復できる。 |
| b | 仕様書どおりに操作ができ、適切な実行結果が得られる。 |
| c | 他のOS環境でも稼働できる。 |
| d | 利用者の習熟時間が短い。 |
（出典：平成25年度春期分 問46一部改変）
答え：〇
| a.信頼性 | 障害発生時にデータを障害前の状態に回復できる。 |
| b.機能性 | 仕様書どおりに操作ができ、適切な実行結果が得られる。 |
| c.移植性 | 他のOS環境でも稼働できる。 |
| d.使用性 | 利用者の習熟時間が短い。 |
