システム開発―要件定義からUATまでITの基礎スキル

システム開発をテーマに、要件定義からUATまでITの基礎スキルをまとめています。

▲記事トップへ

目次

このページの目次です。

1. システム開発とは
2. 要求定義・設計
3. プログラミング
4. レビュー、テスト
5. UAT（受け入れテスト）
6. 開発管理

知識の幅を広げるための参考
更新履歴

1. システム開発とは

システム開発とは、新たな仕組みを作ったり業務の効率化を目的に、ハードウェアやソフトウェアを組み合わせるなどして、システムをつくることです。

システム開発の工程

システム開発の流れは、要件定義、設計、プログラミング、レビュー、テスト、UATという工程が基本となります。

システム開発関連の職種

システム開発の担当職種には、上流と呼ばれる概要設計・要件定義・基本設計を担当する職種、それ以降の詳細設計・プログラミング・テスト・導入支援などを担当する職種などがカテゴライズされ、 前者はシステムエンジニア、後者はプログラマ、また全てを取り仕切るプロジェクトマネージャーなどと呼ばれることが多いと思います。

2. 要求定義・設計

要件定義から設計に関連する基礎知識をピックアップしていきます。

E-R(Entity-Relationship)図

E-R(Entity-Relationship)図は、業務上の管理対象、たとえば、顧客、商品、部品、サービス、 人などを実体(Entity)として、モデル化するために用いられます。

E-R図を用いると、蓄積される情報の関連性が視覚的に示され、最適な情報の蓄積構造を検討することが出来ます。

またE-R図は、個々のDBMS(データベース管理システム)などの物理的な特性を離れて、 本来のデータ間の関連を簡潔な図表で示せることから、データベース設計の基礎になります。

このように、E-R図は、エンティティ(実体)、リレーションシップ(関係)という2つの概念を 用いてデータをモデル化する図です。 データベース設計を行うときなどに広く用いられています。

UML

UMLとは、オブジェクト指向によるシステム開発で利用され、 分析から設計、実装、テストまでを統一した記述法です。 これは、システム開発を行うメンバーが同じ認識を持つために、情報を図式化するもので、 統一された記号と意味が定義されています。

数種類の図があり、役割に応じて使い分けます。 大きく分けると、構造図、振舞い図、実装図の3種類があります。

クラス図

クラス図は、構造図に含まれクラスとクラスの関係を示す図です。

集約

集約(共有集約)は、コンポジション(合成集約)のようなオブジェクトのライフサイクルの一致は 意味しておらず、一般的な関連とほぼ同じ意味合いを持ちます。

集約は、白抜きのひし形を実践で記述します。 たとえば、次の図の場合、クラスAとクラスBが集約に該当します。

モジュール設計

モジュール設計について見ていきます。

モジュールの分割基準

モジュールの変更による影響を少なくするためには、 モジュール間の関連性を出来るだけ少なくし独立性を高くすることが重要です。

モジュールは、１つの機能だけを持たせることによってモジュールの強度が強くなります。 複数の機能を持たせると、それぞれの機能に関連性が出てきて、モジュールの強度が弱くなってしまいます。

一方、モジュール間のインタフェースを単純にすることで、モジュールの結合度を弱くすることが出来ます。 モジュール間のインターフェースが単純でないと、他のモジュールを意識する必要がでてきます。 なお、モジュールの結合度の基準は以下の様になっています。

モジュールの結合度の基準

結合度基準	説明	結合度
内容結合	あるモジュールが他のモジュールの内容を直接参照	強 ↓ 中 ↓ 弱
共通結合	いくつかのモジュールが共通領域を参照
外部結合	いくつかのモジュールが共通データを参照
制御結合	パラメータを渡してモジュールを実行
スタンプ結合	データ構造を変数化して受け渡す
データ結合	データのみを引数として受け渡す

3. プログラミング

プログラミングについて触れていきます。

言語

プログラム構造や構文解析についてまとめていきます。

プログラム構造

プログラム構造について見ていきます。

基本制御構造

プログラムの基本制御構造には次のようなものがあります。

• 連接
• 選択
• 反復（前判定、後判定）

フローチャート

プログラム構造はフローチャートで表せます。以下は、フローチャートの例です。

1. while型の繰り返し構造
   

構文解析

構文解析についてまとめていきます。

構文解析とは

構文解析とは、プログラムの基本要素からプログラムの構造を定めて、 それらが文法に沿っているかどうかを調べ、オブジェクト・プログラムを作り出すために必要な情報を得ることをいいます。

コンパイラで構文解析した結果の表現方法

コンパイラで構文解析した結果の表現方法の一つに４つ組み形式があります。

(演算子,被演算子1,被演算子2,結果)

この形式は、被演算子1と被演算子2に演算子を作用させたものが結果であることを表します。

たとえば、次の一連の4つ組は、以下のようになります。

（*,B,C,T₁） （/,T₁,D,T₂） （+,A,T₂,T₃）
T₁、T₂、T₃、T₄は一時変数を表すとします。
(1)（*,B,C,T₁）⇒T₁＝B*C
(2)（/,T₁,D,T₂）⇒T₂＝T₁/D
(3)（+,A,T₂,T₃）⇒T₃＝A+T₂

(1)、(2)より
T₂＝B*C/D…(4)

(4)、(3)より
T₃＝A+B*C/D

プログラミング方法

プログラミング方法は、大きく分けると以下があります。

• 構造化手法

  プログラムを順次、選択、繰り返しの3つを基本としてコーディングする手法です。 新規に小さいプログラム作る時など簡単に作れて便利な手法ですが、 プログラムが大きくなってくるとプログラムの拡張や保守が難しくなります。

• オブジェクト指向

  オブジェクトという概念に注目し、これをモジュール化に役立てる手法です。 構造化手法のプログラムよりもコード量は多くなりますが、 独立性の高いプログラムの実現がしやすく、 構造化手法の手続き型のプログラムよりも拡張性の高い柔軟なプログラムが構築できます。

4. レビュー、テスト、UAT

レビュー、テスト、UATに関連する基礎知識をまとめていきます。

レビュー手法

設計レビューとは、設計工程において、設計内容を文書化して他の人に チェックしてもらうということを体系化したものです。

ウォークスルーは、設計上の誤りを早期に発見することを目的として、 開発担当者同士で実施するレビューのことをいい、作成された仕様書などを開発担当者を 含む複数の関係者で検討し、エラーを発見します。

ベンダテスト

ベンダテスト（開発者によるテスト）について見ていきます。 UAT（発注者による受け入れテスト）については後で記載しています。

単体テスト

単体テストは、モジュール単位に行うテストであり、モジュール内の論理的なエラー検出が主な目的です。 単体テストのテスト手法にはブラックボックステストとホワイトボックステストがあります。

また、デバッグを支援するソフトウェアをエバッガと呼びます。 デバッガには、たとえば、動的でバックツールの一つであるトレーサがあります。

トレーサは、プログラムの命令の順序、実行結果などの履歴情報を出力します。

テスト設計・管理手法

テスト設計・管理手法について見ていきます。

成長曲線

ソフトウェアのエラー発見数と期間は、成長曲線に似ており、 これを見てシステムの品質を評価することも出来ます。

たとえば、あるシステムをサブシステムa、bに分けて開発しているとします。 現在はそれぞれのサブシステムのテストが終了した段階で、現在までのテストに関するデータは表のとおりになり、 このシステムの基準テスト項目は、10項目／kステップであるとします。

サブシステム名	開発規模	テスト項目数	未解決バグ数
a	30kステップ	300	0
b	20kステップ	200	0

また、現在までのバグ検出状況は次のグラフで示されるものとします。

サブシステムa、bの難易度を同等とすると、2つのサブシステムとも、表より未解決バグ数は０件となっております。

しかし、グラフを見るとサブシステムaの方はバグ検出数が減少しており、サブシステムbの方はバグ検出数が減少していません。 サブシステムbのバグの検出数は、今後も同じ数出てくるのではないかと予想されます。

したがって、十分にテストされているとはいえませんが、サブシステムaの方が、 サブシステムbよりもバグの検出数が収束しており、品質は高いと判断できます。

5. UAT（受け入れテスト）

UATは、User Acceptance Testの略で、発注者による受け入れのためのテストです。 受け入れテストあるいは、承認試験、検収試験、受入試験などと呼ばれることもあります。

UATのテストシナリオで考慮すべき点

UATですべてを確認するのはいろいろな理由で難しく、テストシナリオを絞り込んでテストする必要があります。 では、どのような点を考慮するとよいものでしょうか。

重要機能

この機能がないと成り立たないなど、重要機能は当然テストが必要ですね。

実際データ

開発側はテストデータを使用してテストすることが多く、実データとズレが起きやすいかと思います。

実環境

最終的にリリースされる環境でテストすることは重要です。

セキュリティ

ユーザー側が要件として出にくく、セキュリティ面は軽視されがちですが、被害や事故が起きると大きな損害につながりますので、UATでも意識してチェックしたいです。

UATは第三者機関が行うことも

UATは受け入れ側の情報システム担当や情報システム部門の担当者が行うことが一般的ですが、専門知識が不足しているなどの理由から外部の事業者にテストの一部あるいは全部を委託するケースもあります。

6. 開発管理

開発管理関連について見ていきます。

PART図

図に示すように、作業の順序と作業時間を、矢印(アロー)を基本とした図をPART図といいます。

クリティカルパス(CPM：Critical Path Method)は、作業開始点と終了点間で、 作業日程に余裕がない経路のことです。 すなわち、その経路の作業が完了しないとすべての開発作業が完了しないという経路です。

したがって、クリティカルパスの日数＝すべての開発が完了する日数となる経路、 言い換えると一番時間のかかる経路ということになります。 図では、A→C→E→G→L→Nの経路がクリティカルパスになります。

知識の幅を広げるための参考

• ITスキル体系

  ITスキルを体系的に把握するコンテンツとしてzealseedsのITスキル体系をまとめています。

更新履歴

更新履歴になります。

• 2020/6/14 UATのテストシナリオで考慮すべき点について追記しました。
• 2020/4/11 システム開発について追記しました。
• 2020/3/4 UATについて追記しました。

戻る