6. システム/アプリの開発
6.1. システム開発フロー
システムは企画→要件定義→開発→運用→保守というフェーズでシステムの一生は表せられソフトウェアライフサイクルと呼ばれる。
6.1.1. 開発の大まかなフロー
6.1.2. 要件定義
この工程は作成するシステムにどんな機能が求められているか明らかにする。 要件を取りまとめた結果について要件定義書という形で文書に残する。
6.1.3. システム設計
要件定義の内容を具体的なシステムの仕様に落とし込む作業のこと。 システム設計は主に3つの段階に分かれる。
外部設計
「利用者から見た」設計を行う。ユーザインターフェスなどの利用者が直接手を触れる部分の設計を行う。
内部設計
「開発者から見た」設計を行いう。外部設計を実現s塗るための実装方法やデータ設計などを行う。
プログラム設計
プログラムをどう作るかという視点で設計を行う。プログラムの構造化設計やモジュール同士のインターフェス仕様がこれにあたる。
6.1.4. テスト
6.1.4.1. 単体テスト
モジュールレベルの動作確認を行う。
6.1.4.2. 結合テスト
モジュールを結合させた状態で動作確認や入出力の検査を行う。
6.1.4.3. システムテスト
システム全体を稼働させて動作確認や負荷試験などを行う。
6.1.4.4. 運用テスト
実際の運用と同じ条件下で動作確認を行う。
6.2. システム開発手法
6.2.1. ウォータフォールモデル
6.2.2. プロトタイピングモデル
6.2.3. スパイラルモデル
6.3. CASEツール
CASEはコンピュータ支援ソフトウェア工学という意味です。CASEツールはシステム開発を支援するツール。 開発に関する情報はリポジトリというデータベースで管理する。
6.3. システム開発手法2
6.3.1. RAD(Rapid Application Development)
RADは迅速なアプリケーション開発という意味であり、エンドユーザと開発者による少数構成のチームを組み、開発支援ツールを活用するなどして、とにかく短期間で開発することを重要視した開発手法のこと。
RADツールとして有名なのはVIsual Basicのビジュアル開発環境などが該当する。 RADではプロトタイプを作成しそれを評価するサイクルを繰り返すことで完成度を高める。このフェーズが無限に繰り返されないように開発の期限を設けます。これはタイムボックスと呼ばれる。
6.3.2. アジャイル開発とXP(extreme Programming)
アジャイル開発はスパイラルモデルの派生型であり、より短い反復単位を用いて迅速に開発を行う手法である。この開発手法では1つの反復で1つの機能を開発し、反復を終えた時点で機能追加されたソフトウェアをリリースする。
アジャイル開発の一種であるXPは少人数の開発に適用しやすいとされ、既存の開発手法が仕様を固めて行う方式であったのに対し、XPは変更を許容する柔軟性を実現する。 XPでは5つの価値と19のプラクティスが定義されており、そのうち開発プラクティスとして定められているのは以下6つである。
| プラクティス | 説明 |
|---|---|
| テスト駆動開発 | 実装前にテストを定め、テストをパスするように実装を行う。テストは自動テストであることが望まれる |
| ペアプログラミング | 2人1組でプログラミングを行う。1人がコードを書きもう1人がコードの検証役になり、互いの役割を入れ替えながら作業を進める |
| リファクタリング | 完成したプログラムでも内部のコードを随時改造する。冗長コードを改めるに留める。 |
| ソースコードの共有所有 | コードの制作者に断りなく、チーム内の誰もが修正を行うことができる。チーム全員がコードの責任を負う |
| 継続的インテグレーション | 単体テストを終えたプログラムはすぐに結合し結合テストを行う |
| YAGNI | 今必要とされるシンプル機能だけの実装に留める |
6.3.3. リバースエンジニアリング
リバースエンジニアリングは既存のソフトウェアの動作を解析することで、プログラムの仕様やソースコードを導き出す手法。
目的は既にあるソフトウェアを再利用することで、新規開発を手助けすることである。 これによって得られた仕様をもとに新しいソフトウェアを開発する手法はフォワードエンジニアリングと言う。
フォワードエンジニアリングはオブジェクトコードを逆コンパイルしてソースコードを取り出したりする。 これを元となるソフトウェア権利者の許諾なく行うと知的財産権の侵害にあたるため注意が必要である。
6.3.4. マッシュアップ
公開されている複数のサービスを組み合わせることにより新しいサービスを作り出す手法はマッシュアップと呼ばれる。
6.4. 業務のモデル化
モデル化は現状のプロセスを抽象化し視覚的に表すことであり、システムが実現すべき機能の洗い出しのために行われる。 代表的なものにDEFとER図がある。
6.4.1. DED(Data Flow Diagram)
DEFはデータの流れを図として表したもの。
DFDの例
6.4.2. ER図(Entity-Relationship)
ER図は実体と関係という概念を用いてデータ構造を図に表したものである。
6.5. ユーザインターフェス(UI)
6.5.1. CUIとGUI
CUIは文字を打ち込むことでコンピュータに命令を伝えて処理させる方式です。マウスなどは一切用いません。 GUIは画面にアイコンやボタンを表示してそれをマウスなどのデバイスで操作し命令を伝えるグラフィカルな操作方式であり現在の主流である。
6.5.2. GUIで用いられる部品
| 部品 | 説明 |
|---|---|
| メニューバ | アプリケーションの基本領域であり、ここに各コンポーネントが配置されます |
| ウィンドウ | アプリケーションを操作するための項目が並んだメニュー |
| プルダウンメニュ | クリックすると垂れ下がり表示されるメニュー |
| テキストボックス | 文字入力用の短形領域である |
| チェックボックス | 選択肢を複数選択したり特定の項目をON/OFFさせる用途に用いられる |
| ラジオボタン | 複数ある選択肢から1つだけを選ばせるのに用いる |
6.6. コード設計と入力チェック
コード設計のポイント
コード設計で定めたルールは運用開始後に変更することが難しくなります。そのため将来的に扱うデータ量や将来予測を行い、適切な桁数や割り当て規則を定める必要がある。 入力ミスや読み取りミスを検出する方法にチェックディジットを使用する方法がある。
チェックディジット
チェックディジットは誤入力を判定するためにコードへ付加された数字のことである。
入力ミスを判定するチェック方法
| チェック方法 | 説明 |
|---|---|
| ニューメリックチェック | 数値として扱う必要のあるデータに文字など数値として扱えないものが含まれていないかチェックする |
| シーケンスチェック | 対象とするデータが一定の順序で並んでいるかをチェックする |
| リミットチェック | データが適切な範囲内にあるかチェックする |
| フォーマットチェック | データの形式が正しいかチェックする |
| 照合チェック | 入力されたコードが表中に登録されているかチェックする |
| 論理チェック | 販売数と在庫数と仕入れ数関係なく対となる項目の値に矛盾がないかチェックする |
| 重複チェック | 一意であるべきコードなどが重複して複数個登録されていないかチェックする |
6.7. モジュール分割
各プログラムをモジュール単位に分解・階層化させることはプログラムの構造化設計と言います。
シンプルで保守性に優れたプログラムを作るための構造化設計のためのモジュール分割法には「データの流れに注目した技法」と「データの構造に注目した技法」がある。
モジュール分けの利点と留意点
モジュール分けのメリットとして以下のような点があげられます。
- 作業の分担が可能
- 再利用が簡単
- 修正が一部で済む
モジュール分けした後の作業は3つの制御構造を用いてプログラミングする構造化プログラミングへと移る。
モジュール分割技法
「データの流れ」に着目した技法は以下の3種類。
STS分割法
入力処理、変換処理、出力処理という3つのモジュール構造に分割する手法
トランザクション分割法
プログラムを一連の処理(トランザクション)単位に分割する方法
共通機能分割法
プログラム中の共通機能をモジュール分割する方法
モジュール独立性を測る尺度
モジュールの独立性を測る尺度として用いられるのはモジュール強度とモジュール結合度である。
モジュール強度
モジュール結合度
6.8. テスト
6.8.1. テストの流れ
6.8.1.1. 単体テスト
単体テストでは各モジュールごとにテストを個なって誤りがないかを検証する。この手法ではブラックボックステストやホワイトボックステストという手法を用いて検証を行う。
6.8.1.2. 結合テスト
結合テストでは複数のモジュールを繋ぎ合わせて検証を行い、モジュール間のインターフェスが正常に機能しているかを確認する。
6.8.1.3. システムテスト
システムテストはさらに検証の範囲を広げてシステム全体のテストを行う。
- 機能テスト ・・・ 要求された機能がちゃんと動くのか確認する
- 性能テスト ・・・ 処理能力は十分か確認する
- 負荷テスト ・・・ 高い負荷の下でも問題ないかを確認する
テストの流れは以下の通り 。 単体テスト→結合テスト→システムテスト
6.8.2. ブラックボックステストとホワイトボックステスト
6.8.2.1. ブラックボックステスト
モジュールの内部構造は意識せず入力に対して適切な出力が仕様通りに得られるかを確認する。
6.8.2.2. ホワイトボックステスト
モジュール内部構造が正しく作られているかを検証する。入出力は構造をテストするためだけに過ぎない。
6.8.3. テストデータの決めごと
ブラックボックステストを行うさいに入力値をしっかり定義づけることが大切です。その入力テストデータを作成する基準として用いらるのは同値分割と限界値分析である。
同値分割
データ範囲を種類ごとのグループに分け、それぞれから代表的な値を抜き出してテストデータとして用いる。
限界値分析
限界値分析では上記グループの境目部分を重点的にチェックする。境界前後の値をテストデータに用い、境界値分析と言う。
6.8.4. ホワイトボックステストの網羅基準
ホワイトボックステストを行うにあたって、どこまでのテストパターンを網羅するか定めた上でテストケースを設計する。
6.8.5. トップダウンテストとボトムアップテスト
トップダウンテスト
上位モジュールから先にテストを済ませていく方式。 未テストの下位モジュールはスタブと呼ばれ仮のインターフェスとつなげ確認する。
ボトムアップテスト
下位モジュールからテストを行う方式。 ドライバと呼ばれる仮のモジュールをくっつけインターフェスの確認を行う。
その他のテスト
トップダウンテストとボトムアップテストを組み合わせて行う折衷テストやすべてのモジュールを一気につなげるビッグバンテストがある。
6.8.6. リグレッションテスト
リグレッションテスト(退行テスト) はプログラムを修正した時にその修正内容が正常に動作していた部分まで悪影響を与えていないかを確認するテスト。
6.8.7. バグ管理図と信頼度成長曲線
テスト終了、品質向上の十分性を判断する指標としてバグ管理図がある。
6.8.8. システム周りのマネジメント
プロジェクトマネジメント
開発プロジェクトの技法を体系的にまとめたものにPMBOK(Project Management Body of System) がある。PMBOKは米国のプロジェクトマネージメント協会が規格化した知識体系で国際標準化されている。
WBS(Work Breakdown Structure)
WBSはプロジェクトに必要な作業や成果物を階層化した図で表すものであり、PMBOKのスコープ管理に用いらる。
開発コストの見積り
システムの開発の見積もり方法には以下のようなものがある。
| コスト見積もり手法 | 説明 |
|---|---|
| プログラムステップ法 | 従来の手法で、ソースコードの行(ステップ)数により開発コストを算出する手法 |
| ファンクションポイント法 | 標準画面、印刷する帳票、出力ファイルなどユーザから見える機能に着目し、その個数や難易度から開発コストを算出する方法 |
6.9.9. スケジュール管理とアローダイアグラム
システム開発のスケジュール管理にはガントチャートやアローダイアグラムなどが活用されます。
アローダイアグラム
スケジュール短縮のために用いる手法
スケジュール短縮のために用いる代表的手法がクラッシングとファストトラックキングの2つがある。
| スケジュール短縮手法 | 説明 |
|---|---|
| クラッシング | クラッシングは資源を追加投入してコストの増大を最小限に抑えながらスケジュールの所要時間を短縮する技法である。 |
| ファストトラックキング | ファストトラックキングとは通常は順番に実施させるアクティビティやフェーズを並行して逐行するスケジュール短縮法である |
6.6.10. ITサービスマネジメント
ITサービスを提供するにあたっての管理・運用規則に関するベストプラクティスが体系的にまとめられましたITILと呼ばれる。
ITILは大きく分けてサービスサポートとサービスデリバリの2つにより拘束されます。
SLA(Service Level Agreement)
サービスレベルアグリーメント(SLA)はサービスレベル合意書であり、サービスの利用者と提供者の間で「どのようなサービスをどういった品質で提供するか」を取り決めて明文化したものである。
設定した目標を達成するために、計画-実行-確認-改善というPDCAサイクルを構築し、サービス水準の維持・向上に努める活動はサービスレベルマネージメント(SLM) と呼ばれる。
サービスサポート
サービスサポートは1つの機能と5つの業務プロセスにより構成される。
6.6.11. サービスデスクの組織構造
ローカル・サービスデスク
ユーザの拠点内、もしくは物理的に近い場所に設けられたサービスデスクである。
中央サービスデスク
1か所に窓口を集約させたサービスデスクである。
バーチャル・サービスデスク
インターネットなどの通信技術を利用することで、実際には各地に分散しているスタッフを疑似的に1か所で対応しているように見せかけるサービスデスクである。
サービスデリバリ
ITILの中で長期視点でITサービスの計画と改善を図ることはサービスデリバリは5つの業務プロセスにより構成されます。
ファシリティマネジメント
ファシリティマネジメントはサーバなどに設備を適切に管理・改善する取り組みのことで施設管理と呼ばれます。 UPSは無停電電源装置と呼ばれ、外付けバッテリのような使い方のできる装置である。
6.6.12. システム監査
ITガバナンスは組織がITに関するすべての活動、成果及び関係者を適正に統一し、目指すべき姿へと導くための仕組みを組み込むことである。
システム監査人と依頼者・被監査部門の関係
システム監査人には次の要素が求められます。
- 外見上の独立性
- 精神上の独立性
- 職業倫理と誠実性
- 専門能力
システム監査の手順
監査計画の立案
↓
予備調査
↓
本調査
↓
評価・結論
システムの可監査性
可監査性は処理の正当性や内部統制を効果的に監査、レビューできるようにシステムが設計運用されていることである。
またシステムにおける事象発生から最終結果に至るまでの一連の流れを時系列に沿った形で追跡できる仕組みは監査証跡と呼ばれる。
監査報告とフォローアップ
監査意見には保証意見と助言意見の2種類がある。
またシステム監査人が行う改善指導はフォローアップと呼ばれる。