伝票書きなどそれまで人の手で行っていた業務をコンピュータ化することで、効率を上げることがシステム開発の目的である。しかし、エンジニアの経験やノウハウに依存していることによってシステム障害が起こっているという課題も挙げられている。ここでは、システム開発全体の流れを把握するために必要となる基礎知識をまとめる。
情報処理推進機構のシラバスにおいては「22.システム化計画」「23.要件定義」「24.調達計画・実施」「25.システム開発技術」「26.開発プロセス・手法」に対応している。
１ システムを開発する流れ
「企画」→「要件定義」→「開発」→「運用」→「保守」という5段階のプロセスで、システムの一生は表される（ソフトウェアライフサイクル）。システム化計画として企画段階で検討すべき項目は、スケジュール、体制、リスク分析、費用対効果、適用範囲といった5項目である。
システム開発の調達を行う
調達とは、開発を担当するシステムベンダに対して発注をかけることである。契約締結に至るまでの流れと、そこで取り交わす文書は次のようになる。
- 情報提供依頼：情報提供依頼書（Request For Information：RFI）を渡して、最新の導入事例などの提供を依頼する
- 提案依頼書の作成と提出：システム内容や予算などの諸条件を提案依頼書（Request For Proposal：RFP）にまとめて、システムベンダに提出する
- 提案書の受け取り：システムベンダは具体的な内容を提案書としてまとめ、発注側に渡す
- 見積書の受け取り：提案内容でOKが出たら、開発や運用・保守にかかる費用を見積書にまとめて発注側に渡す
- システムベンダの選定：提案内容や見積内容を確認して、発注するシステムベンダを決定する
開発の大まかな流れと対になる組み合わせ
- 基本計画（要件定義）：利用者にヒアリングするなどして求められる機能や性能を洗い出す
- システム設計：要件定義の結果に基づいてシステムの詳細な使用を固める。複数の段階に分けて、大枠から詳細へと細分化しながらつめていくのが一般的（外部設計→内部設計→プログラム設計）
- プログラミング：プログラミング言語を使って、設計どおりに動くプログラムを作成する
- テスト：作成したプログラムにミスがないか、仕様通り作られているか検証する。検証は設計の逆で、詳細から大枠へとさかのぼる形で行うのが一般的（単体テスト→結合テスト→システムテスト→運用テスト）
- 導入・運用：問題がなければ発注元にシステムを納入して運用を開始する
基本計画（要件定義）
この工程では、作成するシステムにどんな機能が求められているかを明らかにする。要件を取りまとめた結果については、要件定義書という形で文書にして残す。
システム設計
この工程では、要件定義の内容を具体的なシステムの仕様に落とし込む。
- 外部設計：利用者側から見た設計。ユーザインタフェースなど、利用者が実際に手を触れる部分の設計を行う
- 内部設計：開発者から見た設計。外部設計を実現するための実装方法や物理データ設計などを行う
- プログラム設計：プログラムをどう作るかという視点の設計。プログラムの構造化設計や、モジュール同士のインタフェース仕様などを行う
プログラミング
プログラミングとは、プログラムを作成することである．プログラムの作成は、プログラミング言語を使って命令を１つひとつ記述していく。最初に全部機械語に翻訳してから実行するコンパイラ方式と、逐次翻訳しながら実行するインタプリタ方式がある（詳細は次章）。
テスト
この工程では、作成したプログラムにミスがないかを検証する。テストは以下のような複数の段階に分かれている。
- 単体テスト：モジュールレベルの動作確認を行う
- 結合テスト：モジュールを結合させた状態での動作確認や入出力検査などを行う
- システムテスト：システム全体を稼働させての動作確認や負荷試験などを行う
- 運用テスト：実際の運用と同じ条件下で動作確認を行う
２ システムの開発手法
ウォータフォールモデル、プロトタイピングモデル、スパイラルモデルの3つが、代表的な開発手法である。
ウォータフォールモデル
ウォータフォールモデルとは、要件定義からシステム設計、プログラミング、テストと各工程を順番に進めていくものである。開発手法としては最も古くからあるもの。管理がしやすいため大規模開発などでよく使われているが、利用者がシステムを確認できるのが最終段階に入ってからになるため修正が困難である。
プロトタイピングモデル
プロトタイピングモデルとは、開発初期の段階で試作品（プロトタイプ）を作り、それを利用者に確認してもらうことで、開発側との意識ずれを防ぐ手法である。利用者が早い段階でシステムに触れることができるため修正が容易だが、プロトタイプを作る手間が必要である。
スパイラルモデル
スパイラルモデルとは、システムを複数のサブシステムに分割して、それぞれのサブシステムごとに開発を進めていく手法である。個々のサブシステムについては、ウォータフォールモデルで開発が進められる。サブシステムが完成するごとに利用者の確認が得られるためプロトタイピングモデルの利点も合わせ持つが、サブシステムに分割するスキルが必要となる。
３ 業務のモデル化
システムに対する要求を明確にするためには、対象となる業務をモデル化して分析することが大事である。そのために役立つのが、業務プロセスのモデリング（モデル化）だ。代表的なものには、DFDとE-R図の2つがある。
DFD
DFD（Data Flow Diagram）とは、データの流れを図として表したものである。次のような記号を使って図示する。
- ○：プロセス。データを加工したり変換したりする処理を表す
- □：データの源泉と吸収。データの発生元や最終的な行き先を表す
- →：データフロー。データの流れを表す
- ＝：データストア。ファイルやデータベースなど、データを保存する場所を表す
E-R図
E-R（Entity-Relationship）図とは、実体と実体間の関連という概念を使って、データの構造を図に表したものである。実体は「□」、関連は「→」で表す。関連を表す矢印は、「そちらから見て複数か否か」によって矢じり部分の有無が決まる。
４ ユーザインタフェース
ユーザインタフェースは、システムと人間の接点にあたる部分。システムの「使いやすさ」に直結する。
CUIとGUI
CUI（Character User Interface）とは、文字を打ち込むことで命令を伝えて処理させる方式のこと。コマンド（命令）を知らないとコンピュータを操作できなかった。
GUI（Graphical User Interface）とは、画面にアイコンやボタンを表示して、それをマウスなどで操作して命令を伝える方式のこと。一般的に使用されているWindowsやMac OSはこちらの方式。
GUIで使われる部品
GUIでは次のような部品を組み合わせて操作画面を作る。
- ウィンドウ：アプリケーションの基本領域で、この上に部品を配して操作画面を作る
- メニューバー：アプリケーションを操作するための項目が並んだメニュー。細目をおさめたプルダウンメニューが羅列されている
- プルダウンメニュー：クリックすると下に垂れ下がって表示されるメニュー
- テキストボックス：文字入力用の短形領域
- ラジオボタン：複数ある選択肢の中から、1つだけを選ばせたいときに用いる
- チェックボックス：選択肢を複数選択したり、特定の項目をオン／オフさせるときに用いる
画面設計時の留意点
画面設計時の留意点は、以下のものがある。
- 入力は自然な流れとなるように、左から右、上から下へと移動させる
- 「重要項目は赤」などのように、画面上で用いる色使いにルールを持たせる
- 入力ミスに対してはエラーメッセージを表示して、原因と対処法とをわかりやすく簡潔に提示する
- 不慣れな利用者のためにヘルプなどの操作ガイダンスを用意する
- 画面ごとのレイアウトや入力パターンを共通化させる
- 選択肢の数が多いときは、選択肢をグループ分けしたり階層化したりして選びやすくする
帳票設計時の留意点
システムの処理結果は多くの場合帳票として出力することになるため、以下のような留意点が挙げられる。
- 各帳票の基本レイアウトを共通化させる
- 関連する項目は隣接した場所に配置する
- 記載する情報は最小限にとどめて簡潔にまとめる
５ コード設計と入力のチェック
コード設計では、どのようなコード割り当てを行うと効率的にデータを管理できるか検討する。
コード設計のポイント
コード設計で定めたルールは、運用開始後にはなかなか変更することができない。そのため、システムが扱うであろうデータ量の将来予測などを行って、適切な桁数や割り当て規則などを定める必要がある。入力ミスやバーコードの読み取りミスを検出するためには、チェックディジットの仕様も有効。
チェックディジット
チェックディジットとは、誤入力を判定するためにコードへ付加された数字のこと。
入力ミスを判定するチェック方法
システム誤動作や内部エラーを引き起こさないためのチェック方法は、以下のものがある。
- ニューメリックチェック：数値として扱う必要のあるデータに、文字など数値として扱えないものが含まれていないかをチェックする
- シーケンスチェック：対象データが一定の順序で並んでいるかのチェック
- リミットチェック：データが適正な範囲内にあるかのチェック
- フォーマットチェック：データの形式が正しいかのチェック
- 照合チェック：登録済みでないコードの入力を避けるため、入力されたコードが表中に登録されているかを照合する
- 論理チェック：販売数と在庫数と仕入数の関係など、対となる項目の値に矛盾がないかのチェック
- 重複チェック：一意であるべきコードなどが、重複して複数個登録されていないかのチェック
６ テスト
作成したプログラムはテスト工程で各種検証を行い、欠陥（バグ）の洗い出しと改修を行うことで完成に至る。
テストの流れ
テストの流れは、単体テスト→結合テスト→システムテスト（総合テスト）と進む。小さい範囲から大きい範囲へと移行していくことがポイント。
- 単体テスト：各モジュールごとにテストを行う
- 結合テスト：複数のモジュールをつなぎ合わせて検証を行い、モジュール間のインタフェースが正常に機能しているかなどを確認する
- システムテスト：システム全体のテストを行う（性能・負荷・機能など）
ブラックボックステストとホワイトボックステスト
単体テストで、モジュールを検証する手法として用いられるのがブラックボックステストとホワイトボックステストである。
- ブラックボックステスト：入力に対して適切な出力が仕様通りに得られるかを検証するもの
- ホワイトボックステスト：モジュールの内部構造が正しく作られているかを検証するもの
テストデータの決めごと
テストデータを作成する基準として用いられるのが、同値分割と限界値分析である。
- 同値分割：データ範囲を種類ごとのグループに分け、それぞれから代表的な値を抜き出してテストデータに用いるもの
- 限界値分析：各グループの境目部分を重点的にチェックし、境界前後の値をテストデータに用いるもの
トップダウンテストとボトムアップテスト
結合テストでモジュール間のインタフェースを確認する方法には、トップダウンテストやボトムアップテストなどがある。
- トップダウンテスト：上位モジュール（呼び出す側）から先にするテスト
- ボトムアップテスト：買いモジュール（呼び出される側）から先にするテスト
- その他：折衷テストやビックバンテスト（すべてのモジュールを一気につなげてテストする）
リグレッションテスト
リグレッションテスト（退行テスト）とは、プログラムを修正したときに、その修正内容がこれまで正常に動作していた範囲に悪影響を与えていないかを確認するためのテストである。
バグ管理図と信頼度成長曲線
バグ管理図とは、横軸でテスト項目の消化件数（や時間）、縦軸で発見したバグの累積件数を表したもの。一般に、テストされて品質が高まっていれば、信頼度成長曲線という計上の線になる。特徴は、バグは途中から加速度的に発見される点と最終的にバグ件数は頭打ちになって収束する。
最後に
システム開発の基礎知識として、開発の流れ、開発方法、業務のモデル化、ユーザインタフェース、コード設計、テストについてまとめた。
古くからビジネスで用いられている複式簿記（Double-Entry Bookkeeping System）も、企業の財務諸表を作成するための効率的なシステムである。また、沖縄県うるま市の「介護老人保健施設いしかわ願寿ぬ森（むい）」では、FileMakerを使って施設内のシステム化に自前で取り組み、必要な情報を多職種で共有している。システム開発を有効に行うことで、様々な場面で役立つものを作ることができる。さらに、ATR（国際電気通信基礎技術研究所）では、脳波を利用して車いすや家電を動かすシステム開発が行われているなど、医療介護への応用も進んでいる。
本稿が、システム開発について興味を持つきっかけになれば嬉しい
次回はプロジェクトマネジメントについてまとめる。
|
|
キタミ式イラストIT塾 「ITパスポート」 平成24年度 CBT対応 |
