システム開発技術
システムは、要件定義・設計・実装・テスト・導入・保守の順に作られます。どの工程で決めたことを、どのテストで確かめるかを対応させておくと、漏れと手戻りが減ります。
要点
システム要件定義・ソフトウェア要件定義
- システム要件定義のタスク
- システムの境界を決め、要件を定義し、評価して、発注側（取得者）と受注側（供給者）が共同でレビューする。
- システム要件の定義
- 利用の状況と運用シナリオから、システム化の目標と対象範囲（対象業務・部署）を決める。
- 何をするかが機能要件、速さや信頼性などが非機能要件。性能はレスポンスタイムやスループットで示す。
- セキュリティ要件・移行要件・運用要件・UXデザイン、使える品質かを確かめる適格性確認要件も決める。
- システム要件の評価とレビュー
- 要件と上流の要求を、どちら向きにもたどれる状態（双方向の追跡可能性、トレーサビリティ）にして確かめる。
- ソフトウェア要件定義のタスク
- システムを構成するソフトウェア構成品目ごとに、境界・要件の定義・評価・共同レビューを行う。
- ソフトウェア要件の定義
- 業務モデルと論理データモデルを作り、機能・画面・帳票・インタフェースを決める。表現にはDFD・E-R図・UMLを使う。
- ソフトウェア要件の評価とレビュー
- システム要件に合っているか、実現できるかを確かめる。要件と設計・テストの対応表がトレーサビリティマトリクス。
- 業務分析・要件定義の手法
- 利用者へのヒアリングは計画を立て、議事録に残す。目標ごとに利用者（アクター）とのやり取りを書くのがユースケース。
- 画面の見本がモックアップ、動く試作がプロトタイプ。早く見せて仕様の漏れと手戻りを防ぐ。
- DFDはプロセス・データフロー・データストアで流れを描く。E-R図は実体と関連を描く。
- UMLにはクラス図・ユースケース図・シーケンス図・ステートマシン図などがある。
- 「〜として、〜したい。なぜなら〜」の形で要求を書くのがユーザストーリー。条件と動作の組を表にするのが決定表。
設計
- システム設計のタスク
- システム設計、利用者用文書の暫定版の作成、設計の評価と共同レビューを行う。
- システム設計
- 要件をハードウェア・ソフトウェア・サービス・手作業に振り分け、作業負荷やコストを見て分担を決める。
- 信頼性と性能からハードウェア構成（冗長化、IaaS・PaaS・SaaSの利用）を、自社開発かパッケージかでソフトウェア構成を決める。
- 処理方式（集中処理・分散処理、マイクロサービスアーキテクチャ、サーバレス）と、データベースの種類（RDB・NoSQL）を選ぶ。
- システム統合テストの設計
- システム全体が機能を満たすかを確かめる範囲・計画・手順を、システム統合テスト仕様書にまとめる。
- アーキテクチャの評価
- 決めた構成が要件に合い実現できるかを共同レビューで確かめる。中心の業務の規則を外側の技術から切り離すのがクリーンアーキテクチャ。
- ソフトウェア設計のタスク
- ソフトウェア設計、利用者用文書の暫定版、設計の評価と共同レビューを行う。
- ソフトウェア設計
- ソフトウェアをソフトウェアユニット（プログラム）まで分け、各ユニットの機能とユニット間の関係を決める。
- インタフェース設計では画面・帳票の項目や配置、入力値が範囲内かを調べるリミットチェックなどを決める。
- ユニットのテストは中の作りを見るホワイトボックステスト、統合テストは仕様だけを見るブラックボックステストで設計する。
- ソフトウェア要素の評価
- 要件に合っているか、ユニット間で食い違いがないか（内部一貫性）を確かめ、設計書をレビューする。
- ソフトウェア品質
- JIS X 25010の製品品質は8特性：機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性。
- 利用時の品質は5特性：有効性・効率性・満足性・リスク回避性・利用状況網羅性。
- ソフトウェア設計手法
- 処理の流れから設計するのがプロセス中心設計、データの構造から設計するのがデータ中心設計（正規化して一事実一箇所）。
- 構造化設計は機能を段階的詳細化で階層に分け、順次・選択・繰返しで組む。図法はNS図・HIPO・ジャクソン法・ワーニエ法。
- オブジェクト指向設計はデータと操作をまとめるカプセル化、継承、多相性。共通部分をくくるのが汎化、部品の集まりが集約。
- 業務の専門家と開発者が同じ言葉（ユビキタス言語）でモデルを作るのがドメイン駆動設計。
- ソフトウェア要素の設計
- 処理のタイミングや周期、使う資源、入出力装置の違いを基準に要素を分ける。
- プログラムは分かりやすさ・保守性・再利用性などを基準に分割する。
- モジュールの設計
- データの流れで入力・変換・出力に分けるのがSTS分割、処理の種類ごとに分けるのがTR分割。
- モジュール内のまとまり（モジュール強度）は強く、モジュール間のつながり（結合度）は弱いほど独立性が高い。
- 最も望ましいのは機能的強度とデータ結合。モジュール仕様は流れ図や決定表で書く。
- 部品化と再利用
- 再利用を前提に部品を作り、組み合わせて開発する（コンポーネントウェア）。パッケージは合わない所だけ補う。
- アーキテクチャパターン
- よくある構造の型。MVCモデルはデータ（Model）・表示（View）・制御（Controller）に分ける。
- デザインパターン
- オブジェクト指向設計でよく使う設計の型。生成・構造・振る舞いに関するパターンの3種類。
- レビュー
- 進行役（モデレーター）が主導し、役割を決めて公式に誤りを洗い出すのがインスペクション。
- 作成者が説明しながら参加者と一緒にたどるのがウォークスルー。同僚どうしで見るのがピアレビュー、設計書を見るのがデザインレビュー。
実装・構築
- ソフトウェア構築のタスク
- ユニットの作成、テスト手順とデータの作成、ユニットのテスト、文書の更新、コードとテスト結果の評価を行う。
- ソフトウェアユニットの作成
- 詳細設計書に沿い、コーディング標準とプログラム言語の仕様に従って書く（構造化プログラミング）。
- コードとテスト結果の評価基準
- 設計まで追跡できるか、外部・内部の一貫性、テスト網羅性、統合と保守ができるかで評価する。
- コーディング標準
- インデント・命名規則・ネストの深さ・使用禁止命令を決める。守らないと読みにくく、誤りの元になる。
- コーディング支援手法
- コード補完・シンタックスハイライト・オートインデント、標準違反を見つけるコードオーディター。
- コードレビュー
- 標準や設計に合っているかを確かめる。分岐の多さを表すサイクロマティック複雑度は「判定の数＋1」。
- デバッグ
- 動かさずに調べる静的解析、動かして調べる動的テスト。デバッガのブレークポイント、成り立つはずの条件を書くアサーション。
- ユニットテストの目的
- テスト仕様どおりに動くかを確かめ、欠陥（作りの誤り）と、それが表に出た障害を見つける。
- ユニットテストの手順
- 計画（日程・体制・ツール）→準備（環境・テストデータ）→実施→評価の順に進める。
- ユニットテストの実施と評価
- 呼ぶ側の代わりがドライバ、呼ばれる側の代わりがスタブ。見つかった欠陥の累計はバグ曲線で見る。
- テストの手法
- 仕様から作るブラックボックス法：同値分割・限界値分析（境界値分析）・原因結果グラフ・実験計画法。
- 中の作りから作るホワイトボックス法：命令網羅・判定条件網羅・条件網羅・複数条件網羅。
- わざと誤りを埋め込み、見つかった割合から残りの誤りの数を推定するのがエラー埋込法。
統合・テスト
- ソフトウェア統合・検証テストのタスク
- 統合計画を作ってユニットをつなぎ、統合テストを行う。続く検証テストで要件どおりかを確かめ、納入の準備をする。
- ソフトウェア統合
- つなぐ順序を計画する。直したら前の確認をやり直す（回帰戦略）。
- ソフトウェア統合テスト
- 上位から下位へつなぐトップダウンテストはスタブ、下位から上位へつなぐボトムアップテストはドライバを使う。
- ソフトウェア検証テスト
- ソフトウェア要件どおりかを、機能・性能・負荷・セキュリティの各テストで確かめる。直した後にほかの部分へ不具合が出ていないかを見るのが回帰テスト。
- ソフトウェアのテスト結果の評価
- 結果を記録・分析してプログラムを直し、必要なら設計書と利用者用文書を更新する。
- システム統合・検証テストのタスク
- ソフトウェア・ハードウェア・手作業を統合して試し、システム要件どおりかを確かめ、運用と保守に引き継ぐ準備をする。
- システム統合
- 統合する順序を計画し、構成品目を順につないでいく。
- システム統合テスト
- システム設計で決めたテスト仕様に従い、全部をつないだシステムが要件を満たすかを確かめる。
- システム検証テスト
- システム要件どおりかを確かめる。仕様書に頼らず、試しながら次の手を決めるのが探索的テスト。
- システムのテスト結果の評価
- 結果を分析し、性能が足りなければチューニングする。必要に応じて文書を更新する。
導入・受入れ支援
- 導入・受入れ支援・妥当性確認のタスク
- 導入計画を作って導入し、取得者の受入れレビューとテストを支援し、教育訓練を行う。妥当性確認テストは実施して結果を管理する。
- 導入
- 移行の方法、データの保全、業務への影響、日程と体制を導入計画にまとめ、計画に沿って実行環境を整える。
- 受入れ支援
- 取得者が受入れテストを行い、契約どおりなら検収する。供給者は教育訓練（e-Learningなど）と利用者マニュアルを用意する。
- 妥当性確認テスト
- 実際の利用者の目的に合うかを確かめる。使用性テストや試行利用で行い、見つかった問題は解決まで追跡する。
保守・廃棄
- 保守のタスク
- 問題の修正や機能追加を、既存部分に影響を出さずに行う。外から見た動きを変えずに中を整理するのがリファクタリング。
- 既存のプログラムを解析して仕様を取り出すのがリバースエンジニアリング。
- 廃棄のタスク
- 運用に支障がない状態にしてから、支援を終え、システムを停止・解体・撤去する。
- 保守のタイプと形態
- 見つかった誤りを直す是正保守、表に出る前に直す予防保守、環境の変化に合わせる適応保守、性能や保守性を高める完全化保守。
- 現地で作業するオンサイト保守と、通信回線で行う遠隔保守。
- 保守の手順
- 準備→問題の把握と修正の分析→修正→レビューと受入れ→再発防止策の順。新旧を並べて動かす並行運用で移行する。
- 廃棄
- 廃棄計画を立てて利用者に知らせ、必要なデータは保持して後から参照できるようにしておく。
さわって確かめる
ブラックボックス法でテストデータを作り、ホワイトボックス法で網羅率を測り、V字モデルで設計とテストを対応させます。
1. 同値分割と境界値分析でテストデータを作る
仕様「点数が下限〜上限なら受け付け、合格ライン以上なら合格」で、0・60・100 のときの境界値を確かめよう。
2. テストケースを選んで網羅率を出す
T2 と T3 だけを選び、条件網羅は100%なのに判定条件網羅が100%にならないことを確かめよう。
テストするプログラム
- 判定1：A > 0 かつ B > 0 か
- 真 → 処理P
- 偽 → 何もしない
- 判定2：C ＝ 1 か
- 真 → 処理Q
- 偽 → 処理R
3. V字モデルで、テストと設計を対応させる
それぞれのテストが何を基準に確かめるかを選び、「答え合わせ」を押そう。
- ソフトウェアユニットのテスト（単体テスト）
- ソフトウェア統合テスト（結合テスト）
- ソフトウェア検証テスト
- システム統合テスト
- システム検証テスト
- 受入れテスト（妥当性確認テスト）
3問チェック
最初に選んだ答えで採点します。全問正解で、この単元に「済み」の印が付きます。
-
入力欄は 1〜50 の整数だけを受け付ける。境界値分析で選ぶテストデータの組として、最も適切なものはどれか。
- 1、50
- 0、1、50、51
- −10、25、100
- 1、2、49、50
答えと解説
正解はイ。境界のすぐ内側（1と50）と、すぐ外側（0と51）を試す。アは外側を試していないので、「0 も受け付けてしまう」誤りを見逃す。ウは各同値クラスの代表値で、同値分割の選び方。エは内側だけ。
-
「A > 0 かつ B > 0 なら処理Pを行う」という判定を、(A, B)＝(1, −1) と (−1, 1) の2つのテストケースで試した。正しい説明はどれか。
- 判定条件網羅は100%になる
- 条件網羅は100%だが、判定条件網羅は50%
- 条件網羅も判定条件網羅も50%
- 処理Pが実行されるので、命令網羅は100%になる
答えと解説
正解はイ。A>0 と B>0 はそれぞれ真と偽を1回ずつ取るので条件網羅は100%。しかし判定はどちらも偽で、真の側を通らないので判定条件網羅は2つ中1つの50%。処理Pは一度も実行されないので、エも誤り。
-
モデレーターと呼ぶ進行役が主導し、参加者の役割を決めて成果物の誤りを公式に洗い出すレビューはどれか。
- ウォークスルー
- インスペクション
- ペアプログラミング
- 回帰テスト
答えと解説
正解はイ。ウォークスルーは作成者が説明しながら参加者とたどる形で、進行役を立てる決まりはない。ペアプログラミングは2人で1つのコードを書く開発の進め方。回帰テストは修正後にほかの部分へ不具合が出ていないかを確かめるテストで、レビューではない。