ＩＴパスポート試験対策　開発技術

ＩＴパスポートの【マネジメント系】の【開発技術】についてまとめていきます。

システム開発のプロセスの基本的な流れである『要件定義』、『システム開発』、『プログラミング』、『テスト』、『ソフトウェア保守』などについてしっかりと学習していきましょう！

『システムの要件定義』や『システム設計』の項目はＩＴパスポート試験でもよく出題される内容となっていますので、語句の意味などをしっかりと把握するようにしましょう。

ソフトウェアの開発モデルでは特に『ウォータフォールモデル』、『アジャイル開発』による２つの用語についての出題傾向が高くなっています。
それぞれの開発手法の特徴やメリット・デメリットについてきちんよ理解するようにしましょう。

第１章　システム開発技術

システム開発
必要なハードウェアを調達し、必要な機能をもったソフトウェアを新たに作ること

ソフトウェアライフサイクルプロセス（SLCP）
『企画』、『要件定義』、『開発』、『運用』、『保守』の５つのサイクルから構成されているソフトウェアサイクル

システム開発のプロセス
システム要件定義
システムで実現したいことを決める工程
↓
システム設計
システム要件定義で決めた内容にあわせ、ハードウェアとソフトウェアの仕様や動作を決める工程
↓
プログラミング
実際にソースコードを書く工程
↓
テスト
システムが仕様どうりに動くか確認する工程
↓
ソフトウェア受け入れ
完成したソフトウェアをお客さんに納品する工程

第２章　システム要件定義

システム要件定義
システムに必要な条件（システム要件）を決める工程
システムに必要な条件をきちんと書類に残し、お互いに共有することで、責任の所在を明確にでき、後々のトラブルを未然に防止する役割がある。

システム要件
業務要件のうちシステムで実現する要件であり、具体的にはシステムに必要な機能や性能で、開発プロセスの最初にシステム要件定義を行い、そのシステムに必要な条件を明確に決める必要がある。

機能要件
ユーザへのヒアリングで明らかになった、システムに必要な機能

非機能要件
ユーザのヒアリングでは、明確にならない部分ではあるが、システムに必要な性能

品質特性
システムの品質を評価する基準
『機能性』、『信頼性』、『使用性』、『効率性』、『保守性』、『移植性』の６つがある

システム要件定義書のレビュー
システム要件定義のプロセスで作成する文章を『システム要件定義書』といい、システム要件定義書が完成したら、開発側と発注者側の両者で一緒に書類の内容を確認して、誤りや相違点がないかをチェックする。
この作業を『共同レビュー』という。

第３章　システム設計

システム設計
システム要件定義にて決めたことをもとにして、システムの設計図を書き起こすこと

（1）システム方式設計
システム要件定義プロセスにて洗い出したシステム要件を『ハードウェア』、『ソフトウェア』、『手作業』のいずれかに振り分けるプロセス
『ハードウェア』、『ソフトウェア』に振り分けられたシステム要件のみシステムにて実現する。
システム方式設計により、システムに『何が』、『いくつ』必要なのか明確になる。

（2）ソフトウェア要件定義
ソフトウェアの要件（機能や性能）を決める工程
システム方式設計で『ソフトウェア』に割り振られたシステム要件を具体化する工程となる。
　・インターフェースの要件（画面、帳票、ファイルなど）
　・データの要件（データの種類、データベースの要件など）

（3）ソフトウェア方式設計
ソフトウェア要件定義にて決めたソフトウェア要件をプログラム単位まで分割する工程
ソフトウェア要件をどのように実現するかを決定する工程となる。

（4）ソフトウェア詳細設計
ソフトウェア方式設計でプログラム単位まで分割された要件をさらにコーディングできる単位まで分割する工程
動作ロジックを検討し、その結果をフローチャート（流れ図）にして表現する。
この工程にて分割されたプログラムをソフトウェアユニット（ソフトウェア単体）と定義される。

外部設計と内部設計とは

外部設計
ユーザから見える箇所の設計で、コンピュータの制約は考慮せず、ユーザの立場からみた業務機能を中心に設計する
　・システム要件定義
　・システム設計の『システム方式設計』

内部設計
ユーザから見えない箇所の設計
　・シスエム設計の『ソフトウェア要件定義』
　・システム設計の『ソフトウェア方式設計』

第４章　プログラミング

プログラミングとは

プログラミング
プログラミング言語の文法に従って、処理手順を書く工程

コーディング
プログラミングの工程で流れ図に従ってソースコードを記述すること

コンパイラ
人間が書いたプログラムを機械語に変換することを『コンパイル』といい、この処理を行う機能のこと

第５章　テストとソフトウェア受入れ

テスト
システムが仕様どおりに動くかどうかを確認する工程
不具合の有無をチェックし、要件定義プロセスで明確にした『業務に必要な条件（業務要件）』をきちんと実現しているかもあわせて確認する。

単体テスト
プログラムに誤りがないことを検証する。通常は『ホワイトボックステスト』といわれるテスト手法でおこなう。

結合テスト
単体テストを完了したプログラム同士を組み合わせて、データの受け渡しや連携が上手くいっているかを検証する、
通常は『ブラックボックステスト』といわれるテスト手法にて行う。

システムテスト
システム要件が仕様どうりに動作するかを検証する。

運用テスト
本番環境と同じ条件下でシステムを運用し、業務要件どうりにシステムが動作することを検証する。
共通フレームでは、運用テストはユーザが主体となっておこなうので、運用プロセスとして規定されている。

ホワイトボックステスト
入力したデータが意図どうりに処理されているかを、プログラムの内部構造を分析して確認するテスト手法
プログラムに記述されている全ての処理を実行し、動作を確認する。
ホワイトボックステストは開発者（プログラマ）が実施する。

ブラックボックステスト
入力と出力だけに着目し、ある入力に対して仕様書どうりに出力が得られているかどうかを確認するテスト手法
システムがどうのような処理を行っているのかを問題とせず、結果が正しければOKとします。
ブラックボックステストは開発者だけではなく、発注者（ユーザ）を一緒に行う。

テスト関連の重要語句

バグ
プログラム上の誤りや不具合のこと

デバッグ
プログラム上の誤りや不具合を修正する作業

コードレビュー
ソースコードをレビューすること

回帰テスト（リグレッションテスト）
システムに修正や機能追加をしたために、別のところで新しいバグが出ていないかを確認するテスト

ソフトウェアの受け入れ
開発者が作成したソフトウェアを発注者に納品する工程

ソフトウェア導入
発注者側の本番環境にソフトウェアをインストールする工程
現行システムを新システムに切替えることを『移行』とゆう

ソフトウェア受け入れ支援
発注者が『ソフトウェア受け入れテスト』を行い、開発者がそのテストの手助けをします。
開発者が発注者にシステムを引き渡す際に行われるテストで、システムが契約どうりに完成しているかどうかを確認する。

第６章　運用プロセスと保守プロセス

システム開発の最終工程について

運用プロセスとは
完成したシステムを本番環境で動かす工程
利用者マニュアルなどを使って、システム導入後も継続して利用者への教育を実施します。

保守プロセスとは
稼働中に見つかったバグを修正したり、ソフトウェアに新機能を追加したりする工程
システム開発の最後の工程となり、稼働中の本番環境に対して何らかの作業を行う工程となる。
『ソフトウェア保守』といわれる用語としてITパスポート試験では出題される。

システムの値段について
システム開発はビジネスとして行われるため、仕事としての対価を支払ってもらう必要がありますが、システムの値段については『ファンクションポイント法』が用いられることが多くある。

ファンクションポイントとは
システムが提供する機能に点数をつけて開発費を見積もる方法で、ISOでも規格化されている見積もり方法

第７章　ソフトウェアの開発モデル

ソフトウェアの開発モデルについて

ウォーターフォールモデル
ソフトウェアの開発プロセスを上流工程から下流工程に向かって一直線に順番に進める手法
各工程が明確に分けられている上に、前工程の完了後に次の工程を始めるため、計画が立てやすい点が最大のメリットとなる。
デメリットとしては、修正作業がとても大変となる点で、システムの手直しが生じた場合に不具合のあった工程まで戻ってやり直す必要がある。

アジャイル開発
短期的にソフトウェアの開発とリリースを繰り返し、ビジネス環境の変化やユーザのニーズに柔軟に対応できる開発モデル
従来以上に高品質の製品を、より速く開発することが求められている状況で、迅速かつ適切に顧客ニーズに対応できるメリットがある。

アジャイル開発では、事前に綿密な計画を立てずに、品質は高くなくとも、素早く市場に製品をリリースします。
仕様変更に柔軟に行いながら、小刻みに製品をリリースすることで、現在の製品に求められるスピードを品質に対応できる開発モデルである。

DevOps
開発担当者（Development)と運用担当者（Operations)が連携してシステム開発する手法
開発者の目的である『より良いシステムと作ること』、運用者の目的は『システムを安定して運用すること』を目指すため開発者や運用者の目的の違いによる衝突を、ツールや組織文化を用いて解決し、ユーザにより品質のよい価値（製品）を届けるように取り組めます。

XP（eXtreme Programming)
アジャイル開発の手法の一つで、１９のプラクティス（実践）が定義された開発手法
いくつかのプラクティスをご紹介します。

①テスト開発駆動
通常はプログラムを書いたあとに行う単体テストを、順序を逆にして先におこない、このテストを通るようにプログラムを書く開発手法
開発者はテストに合格するためのプログラムを書けばよいため、プログラムの目的が明確になり、段階的に進めるために、不具合の少ない状態での開発が可能となる。

②ペアプログラミング
二人のプログラマが１つのパソコンを使ってソフトウェアを開発する手法
一人がプログラムを書いているときに、もう一人がそれをチェックしながら作業を行う、二人が同じプログラムの内容を理解しながら作業を進めるので、一人が仕事を休んでも、もう一人が作業を続けることか可能となる。
初心者と熟練者が二人で組むことで、技術を習得するためのOJTとしての効果を発揮できる。

③リファクタリング
プログラムの機能使用は変えずに、内部構造を変えること。
簡潔に表現すると『外部から見た”プログラムの動作”は変えずに、プログラム内部のソースコードを改善する』こと