システム開発技術
1. システムとソフトウェア
システムは、ハードウェアとソフトウェアから構成されます。
システムの概念図
システム
(PC, 電話機, 回線など)
(プログラム, アプリなど)
システム開発とは、必要なハードウェアを調達し、必要な機能を持ったソフトウェアを新たに作ることです。
手作業で行っている業務をシステムに置き換えることで、業務を大幅に改善できます。
2. 開発プロセスの概要 (SLCP)
ソフトウェアライフサイクルプロセス（SLCP）は、「企画」「要件定義」「開発」「運用」「保守」の5つで構成されます。
開発プロセスは、家づくりに例えられます。
| 開発工程 | 家づくりでの例 | 説明 |
|---|---|---|
| システム要件定義 | 打合せ | システムで実現したいことを決める |
| システム設計 | 設計図作成 | ハード・ソフトの仕様や動作を決める |
| プログラミング | 建築作業 | 実際にソースコードを書く |
| テスト | 検品・品質確認 | 仕様どおりに動くか確認する |
| ソフトウェア受入れ | 引き渡し | 完成品をお客さんに納品する |
要件定義と設計
1. システム要件定義
どのようなシステムを作るのか、必要な条件（機能や性能）を開発会社と明確にするプロセスです。
言った言わないのトラブルを防ぐ重要な工程です。
システムに必要な機能（何ができるか）。
ユーザへのヒアリングで明らかになるもの。
- ・会計処理ができること
- ・決算処理の記録を残すこと
- ・レーンの寿司がお客さんに届くこと
機能以外の性能や品質（速さ、丈夫さなど）。
ユーザからは出てきにくいが必要なもの。
- ・処理が8時間以内に終わること
- ・データは暗号化して保存すること
- ・24時間365日稼働すること
品質特性（ソフトウェアの通信簿）
機能性、信頼性、使用性（使いやすさ）、効率性、保守性、移植性の6つで評価します。
※要件定義書ができたら、開発側と発注側で「共同レビュー」を行い、認識のズレがないか確認します。
2. システム設計の4工程
要件をもとに設計図を書く工程です。以下の4段階で進みます。
-
(1) システム方式設計
要件を「ハードウェア」「ソフトウェア」「手作業」のどれで実現するか振り分ける。 -
(2) ソフトウェア要件定義
ソフトウェアで行う部分について、詳細な機能や性能（画面、帳票、データなど）を決める。 -
(3) ソフトウェア方式設計
要件をプログラムの単位まで分割し、構造を決める。 -
(4) ソフトウェア詳細設計
プログラミング（コーディング）ができるレベルまで詳細化する。フローチャート（流れ図）などを書く。
3. 外部設計と内部設計
ユーザ（発注者）から見えるか見えないかで分類します。
| 分類 | 視点 | 該当する工程 |
|---|---|---|
| 外部設計 | ユーザから見える | ・システム要件定義 ・システム方式設計 |
| 内部設計 | ユーザから見えない | ・ソフトウェア要件定義 ・ソフトウェア方式設計 ・ソフトウェア詳細設計 |
実装・テスト・受入れ
1. プログラミング
プログラム言語の文法に従って処理手順（ソースコード）を書く工程です。
人間が書いたソースコードは、コンパイラによってコンピュータが理解できる機械語（0と1）に翻訳（コンパイル）されて実行されます。
2. テスト手法とV字モデル
開発工程（左側）とテスト工程（右側）は対になっており、V字モデルと呼ばれます。
下から順に検証範囲が広がっていきます。
テストの種類と手法
プログラム単体の検証。
ホワイトボックステスト：内部構造（ロジック）を見て、すべての処理経路が正しく動くか確認する。
プログラムをつなぎ合わせた検証。
ブラックボックステスト：内部構造は気にせず、「入力」に対して正しい「出力」が出るか（仕様通りか）だけを確認する。
- バグ：不具合
- デバッグ：修正作業
- 回帰テスト：修正で他への影響がないか確認
3. ソフトウェア受入れ
開発者から発注者へ引き渡す工程です。
本番環境への導入（インストール/移行）と、発注者自身が行う受入れテスト（検収）を行います。
利用者マニュアルを用いて教育も行います。
運用・保守・見積
1. 運用と保守
運用：本番環境でシステムを動かし続けること。
保守（ソフトウェア保守）：本番稼働中のシステムに対して、バグ修正や新機能追加、改善を行うこと。
2. 見積法（ファンクションポイント法）
システムの「機能（ファンクション）」に「点数（ポイント）」をつけて、その合計で開発規模や費用を見積もる方法です。
ユーザに見える機能を基準にするため、納得感を得やすい手法です。
ソフトウェア開発モデル
1. ウォータフォールモデル
上流工程から下流工程へ、滝（Waterfall）のように一直線に進める手法。
計画が立てやすい反面、後戻り（修正）が大変で、仕様変更に弱いという特徴があります。
2. アジャイル開発
「素早い（Agile）」という意味。短期間に開発とリリースを繰り返し、仕様変更に柔軟に対応する手法です。
スクラムはアジャイル開発の代表的なフレームワークで、チームの連携を重視します。
| 比較 | ウォータフォール | アジャイル |
|---|---|---|
| 計画 | 綿密に立てる | 変更前提 |
| 規模 | 大規模向き | 小規模向き |
| 仕様変更 | 弱い | 強い |
3. DevOpsとXP
DevOps
開発 (Dev) と 運用 (Ops) が連携・協力し、自動化などを取り入れて迅速にシステムを改善していく取り組み。
XP (エクストリームプログラミング)
アジャイル開発の手法の一つ。以下のプラクティスが有名。
- テスト駆動開発：テストを先に書く。
- ペアプログラミング：2人で1台で開発。
- リファクタリング：外からの振る舞いを変えずに内部構造を整理・改善する。
過去問演習（システム開発技術）
実務に精通している利用者に参画してもらい，開発するシステムの具体的な利用方法について分析を行う。
- システム要件定義
- システム設計
- テスト
- プログラミング
ソフトウェア製品の品質特性を，移植性，機能適合性，互換性，使用性，信頼性，性能効率性，セキュリティ，保守性に分類したとき，RPAソフトウェアの使用性に関する記述として，最も適切なものはどれか。
- RPAが稼働するPCのOSが変わっても動作する。
- RPAで指定した時間及び条件に基づき，適切に自動処理が実行される。
- RPAで操作対象となるアプリケーションソフトウェアがバージョンアップされても，簡単な設定変更で対応できる。
- RPAを利用したことがない人でも，簡単な教育だけで利用可能になる。
ブラックボックステストに関する記述として，適切なものはどれか。
- プログラムの全ての分岐についてテストする。
- プログラムの全ての命令についてテストする。
- プログラムの内部構造に基づいてテストする。
- プログラムの入力と出力に着目してテストする。
納入されたソフトウェアの一連のテストの中で，開発を発注した利用者が主体となって実施するテストはどれか。
- 受入れテスト
- 結合テスト
- システムテスト
- 単体テスト
ソフトウェア保守に該当するものはどれか。
- システムテストで測定したレスポンスタイムが要件を満たさないので，ソフトウェアのチューニングを実施した。
- ソフトウェア受入れテストの結果，不具合があったので，発注者が開発者にプログラム修正を依頼した。
- プログラムの単体テストで機能不足を発見したので，プログラムに機能を追加した。
- 本番システムで稼働しているソフトウェアに不具合が報告されたので，プログラムを修正した。
アジャイル開発に関する記述として，最も適切なものはどれか。
- 開発する機能を小さい単位に分割して，優先度の高いものから短期間で開発とリリースを繰り返す。
- 共通フレームを適用して要件定義，設計などの工程名及び作成する文書を定義する。
- システム開発を上流工程から下流工程まで順番に進めて，全ての開発工程が終了してからリリースする。
- プロトタイプを作成して利用者に確認を求め，利用者の評価とフィードバックを行いながら開発を進めていく。
アジャイル開発の方法論であるスクラムに関する記述として，適切なものはどれか。
- ソフトウェア開発組織及びプロジェクトのプロセスを改善するために，その組織の成熟度レベルを段階的に定義したものである。
- ソフトウェア開発とその取引において，取得者と供給者が，作業内容の共通の物差しとするために定義したものである。
- 複雑で変化の激しい問題に対応するためのシステム開発のフレームワークであり，反復的かつ漸進的な手法として定義したものである。
- プロジェクトマネジメントの知識を体系化したものであり，複数の知識エリアから定義されているものである。
システムの開発側と運用側がお互いに連携し合い，運用や本番移行を自動化する仕組みなどを積極的に取り入れ，新機能をリリースしてサービスの改善を行う取組を表す用語として，最も適切なものはどれか。
- DevOps
- RAD
- オブジェクト指向開発
- テスト駆動開発
XP(エクストリームプログラミング)の説明として，最も適切なものはどれか。
- テストプログラムを先に作成し，そのテストに合格するようにコードを記述する開発手法のことである。
- 一つのプログラムを2人のプログラマが，1台のコンピュータに向かって共同で開発する方法のことである。
- プログラムの振る舞いを変えずに，プログラムの内部構造を改善することである。
- 要求の変化に対応した高品質のソフトウェアを短いサイクルでリリースする，アジャイル開発のアプローチの一つである。
リファクタリングの説明として，適切なものはどれか。
- ソフトウェアが提供する機能仕様を変えずに，内部構造を改善すること
- ソフトウェアの動作などを解析して，その仕様を明らかにすること
- ソフトウェアの不具合を修正し，仕様どおりに動くようにすること
- 利用者の要望などを基に，ソフトウェアに新しい機能を加える修正をすること
自社開発して長年使用しているソフトウェアがあるが，ドキュメントが不十分で保守性が良くない。保守のためのドキュメントを作成するために，既存のソフトウェアのプログラムを解析した。この手法を何というか。
- ウォーターフォールモデル
- スパイラルモデル
- プロトタイピング
- リバースエンジニアリング