【基本情報】システム開発

システムを開発する流れ

「企画」⇨「要件定義」⇨「開発」⇨「運用」⇨「保守」

これをソフトウェアライフサイクルという。

検討すべき項目
スケジュール、体制、リスク分析、費用対効果、適用範囲

システム開発の調達の流れ

情報提供依頼（RFI）、、、最新の導入事例などを提供する
提案依頼書（RFP）の作成と提出、、、システムの内容や予算などの諸条件を提案依頼書にまとめて、システムベンダに提出する。
提案書の受け取り、、、システムベンダは具体的な内容を提案書としてまとめ、発注側に渡す。
見積書の受け取り、、、提案内容でOKが出たら、開発や運用・保守にかかる費用を見積書にまとめて発注側に渡す。
システムベンダの選定、、、提案内容や見積もり内容を確認して、発注するシステムベンダを決定する。

開発の大まかな流れとついになる組み合わせ

• 基本計画（要件定義）
  この工程では、作成するシステムにどんな機能が求められているかを明らかにする。
  要件を取りまとめた結果については、要件定義書という形で文書にして残す。

• システム設計
  要件定義の内容を具体的なシステムの使用に落とし込む。
  外部設計、内部設計、プログラム設計

• プログラミング

• テスト
  単体テスト、結合テスト、システムテスト、運用テスト

• 導入・運用

システムの開発手法

ウォーターフォールモデル
各工程を順番に進めていくもの。管理がしやすく、大規模開発などで広く使われている。手戻りすると大変。

プロトタイピングモデル
開発初期の段階で試作品（プロトタイプ）を作り、それを利用者に確認してもらうことで、開発側との意識ずれを防ぐ手法。
利用者が早い段階でシステムに触れて確認することができる。（手戻りすることはない）
プロトタイプと言っても作る手間は必要なので、あまり大規模なシステムの開発には向かない。

スパイラルモデル
システムを複数のサブシステムに分割して、それぞれのサブシステムごとに開発を進めていく手法。個々のサブシステムについては、ウォーターフォールモデルで開発が進められる。

レビュー、、、工程の完了ごとに成果物をチェックすること
上流CASEツール、、、システムの分析や設計を支援する。ER図やDFDなど。
下流CASEツール、、、プログラムの自動生成ツールやテスト支援ツールなど。
保守CASEツール、、、リバースエンジニアリングなどのリエンジニアリング機能はこれにあたる。

開発に関する情報は、リポジトリと呼ばれるデータベースで一元管理される。

システムのさまざまな開発手法

RAD（Rapid Application Development）
エンドユーザと開発者による少人数構成のチームを組み、開発支援ツールを活用するなどして、とにかく短期間で開発を行うことを重要視した開発手法。
開発の期限を設ける事があり、これをタイムボックスという。

アジャイルとXP
スパイラルモデルの派生型で、より短い反復単位（週単位が多い）を用いて迅速に開発をおこなう手法の総称がアジャイル。
一つの反復で一つの機能を開発し、反復を終えた時点で機能追加されたソフトウェアをリリースする。

アジャイル型の代表的な開発手法がXP。少人数の開発に適用しやすいとされ、XPは変更を許容する柔軟性を実現している。

XPでは５つの価値と１９のプラクティスが定義されている。

name	explanation
テスト駆動開発	実装の前にテストを定め、そのテストをパスするように実装を行う。テストは自動テストであることが望ましい。
ペアプログラミング	2人1組でプログラミングを行う。1人がコードを書き、もう1人がそのコードの検証役となり、随時互いの役割を入れ替えながら作業を進める。
リファクタリング	完成したプログラムでも、内部のコードを随時改善する。冗長な構造を改めるにとどめ、外部から見た動作は変更しない。
ソースコードの共同所有	コードの作成者に断りなく、チーム内の誰もが修正を行う事ができる。その代わりに、チーム全員が全てのコードに対して責任を負う。
継続的インテグレーション	単体テストを終えたプログラムは、すぐに結合して結合テストを行う。
YAGNI	「You Aren't Going to Need It.」の略。今必要とされる機能だけのシンプルな実装にとどめる。

リバースエンジニアリング、、、既存ソフトウェアの動作を解析することで、プログラムの使用やソースコードを導き出すことをリバースエンジニアリングという。
これによって得られた仕様をもとに新しいソフトウェアを開発する手法をフォワードエンジニアリングという。

マッシュアップ、、、公開されている複数のサービスを組み合わせることで新しいサービスを作り出す手法。

業務のモデル化

DFD

データの流れを図として表したもの。

E-R図

実体（エンティティ）と実体間の関連（リレーションシップ）という概念を使って、データの構造を図に表したもの。

ユーザインターフェース

CUI
画面に表示されるのは文字だけで、そのコンピュータに対して入力するのも文字だけ。文字を打ち込むことで命令を伝えて処理させている。このような文字ベースの方式をCUI（Character User Interface）という。

GUI
グラフィカルな操作方法。
GUIで使われる部品には以下のようなものがある。

ウィンドウ、、、アプリケーションの基本領域で、このうえに部品を配して操作画面を作る。
メニューバー、、、アプリケーションを操作するための項目が並んだメニュー。細目を収めたプルダウンメニューが羅列されている。
プルダウンメニュー、、、クリックすると、下に垂れ下がって表示されるメニュー。
テキストボックス、、、文字入力用の矩形領域。
チェックボックス、、、選択肢を複数選択したり、特定の項目をオン/オフさせるといった用途に用いる。
ラジオボタン、、、複数ある選択肢の中から一つだけを選ばせたい時に用いる。

コード設計と入力のチェック

入力ミスやバーコードの読み取りミスを検出するために、チェックディジットの使用も有効。

入力ミスを判定するチェック方法

チェック方法	説明
ニューメリックチェック	数値として扱う必要のあるデータに、文字など数値として扱えないものが含まれていないかをチェックする。
シーケンスチェック	対象とするデータが一定の順序で並んでいるかをチェックする。
リミットチェック	データが適正な範囲内にあるかをチェックする。
フォーマットチェック	データの形式が正しいかをチェックする。
照合チェック	登録済みでないコードの入力を避けるため、入力されたコードが表中に登録されているかをチェックする。
論理チェック	販売数と在庫数と仕入数の関係など、対となる項目の値に矛盾がないかをチェックする。
重複チェック	一意であるべきコードなどが、重複していないかをチェックする。

モジュールの分割

各プログラムをモジュールという単位に分解・階層化させることを、プログラムの構造化設計という。

STS分割法、、、プログラムを入力処理、変換処理、出力処理という三つのモジュール構造に分割する方法。
トランザクション分割法、、、プログラムを一連の処理（トランザクション）単位に分割する方法。
共通機能分割法、、、プログラム中の共通機能をモジュールとして分割する方法。

モジュールの独立性を測る尺度として用いられるのがモジュール強度とモジュール結合度。

テスト

単体テスト、、、各モジュールごとにテストを行って、誤りがないかを検証する。
結合テスト、、、複数のモジュールをつなぎ合わせて検証を行う。
システムテスト（総合テスト）、、、システム全体のテストを行う。

ブラックボックステスト、、、モジュールの内部構造は意識せず、入力に対して適切な出力が使用通りに得られるかを検証する。
同値分割と限界値（境界値）分割がある。

ホワイトボックステスト、、、モジュールの内部構造が正しく作られているのかを検証する。
命令網羅、判定条件網羅（分岐網羅）、条件網羅、複数条件網羅がある。

総合テストでモジュール間のインタフェースを確認する方法には、トップダウンテストや、ボトムアップテストなどがある。
非対象の下位のモジュールをスタブ、非対象の上位のモジュールをドライバと呼ぶ。

リグレッションテスト、、、プログラムを修正したときに、その修正内容がこれまで正常に動作していた範囲に悪影響を与えてないか（新たにバグを誘発することになっていないか）を確認するためのテスト。

横軸をテスト項目消化件数、縦軸を累積バグ件数として表したものをバグ管理図という。
その時の曲線を信頼度成長曲線といい、バグは途中から加速度的に発見され、最終的にバグ件数は頭打ちになって収束する特徴がある。