TOP > IT講座 > 基本ソフトウェアの知識 > 第1回 システム開発管理

■ 第1回 システム開発管理

ソフトウェアの試験の手法
試験の方式
ソフトウェアの試験を実施するには、試験の目的とそれに合った方式を決定し、テスト項目を作成します。
以下では、その際の手法・着眼点に関して記述します。
ブラックボックステスト
プログラムの内部処理は全く意識せず(=ブラックボックス)、外部仕様書に基づいて行う試験です。
仕様に基づいて入力を決め、想定した出力(動き)をしていることを確認します。
     ◆テストケースの設定方式

同値分析

取り得る値の有効値、無効値の代表値でテストケースを作成します。
■Ex.範囲が1〜9の場合: 有効:5 無効:−1、13

限界値分析 有効範囲、無効値の境界部分の値でテストケースを作成します。
■Ex.範囲が1〜9の場合:
  ・0(無効値)、
  ・1(有効範囲の最小)、
  ・9(有効範囲の最大)、
 ・10(無効値)   
原因→結果の検証 プログラムの動作を決定する要因となる項目(INPUT)を抜き出し、それによる結果(OUTPUT)を検証します。
■INPUT:
  ・入力ファイルの内容
  ・各種設定値(ini)の内容
  ・オペレーションの内容
  ・OS、他関連APの状態 など
■OUTPUT:
  ・プログラムの動作
  ・ログファイルの内容
  ・メッセージボックス等
  ・OS、他関連APの状態 など

ホワイトボックステスト
プログラムの内部処理に基づき、内部仕様(ソース)に基づいて行う試験です。
ソースに書いてある命令をすべて1回は実行させることを、また、処理の流れの整合性などを確認します。
    ◆テストケースの設定方式

命令網羅

プログラム中のすべての命令を実行します。(C0カバレージ)

判定条件網羅

プログラム中で真偽の判定がある箇所において、その両方のルートを少なくとも1回は実行します。(C1カバレージ)

条件網羅

2つ以上の条件で真偽を判定する場合、すべてのパターンを網羅します。
■Ex. If (1=真) and (2=真)の場合
  1)1:真 2:真 →真
  2)1:真 2:偽 →偽
  3)1:偽 2:真 →偽
  4)1:偽 2:偽 →偽
この4パターンをすべて実行します。

複数条件網羅

条件網羅に加え、それに伴うすべての分岐を網羅します。

モジュール集積(結合)テストの種類
ソフトウェアの試験は、一般的に個々のモジュール(最小単位)で試験をした後に、
順次モジュールを結合して、あるまとまった単位での試験を行います。
以下には、結合を行う際の方式について記述します。

ボトムアップテスト

下位モジュールから順次結合して、試験を行う方法です。

トップダウンテスト

上位モジュールから順次結合して、試験を行う方法です。
入出力・メインのロジックから優先的に試験を行います。

ビックバンテスト

プログラムの各モジュールを別々にテストした後、全体を一度に結合してテストする方法です。


ソフトウェアの品質管理
開発しているソフトウェアの品質を図る、あるいは品質を向上させるための手法について、以下に記述します。
信頼性成長曲線
試験時のエラー累積数を、試験の時間数で表される曲線です。
理想的な形としては、S字型となります。
試験の進行状況の指標、またはソフトウェア品質の評価基準となります。
信頼性成長曲線の動向

・初期のエラー累積数:小
 ■モジュールの集積度小、スタブの利用など想定外エラーが生じにくい。

・中期のエラー累積数:増加
 ■集積度が上がり、スタブの利用もなくなり、エラー検出率が増加する。

・終了期のエラー累積数:減少
 ■エラー箇所の修正が行われ、エラー含有率が減る。

信頼性成長曲線からわかること
●初期段階でのエラーが多く、次第に収束していく場合
→テストの方法・手順が適正でない
●モデル曲線よりも、エラー累積数が下回る場合
→テストケースが甘い。確認方法、内容が甘い。
→モジュールの品質が極めてよい
→モデル曲線(エラー数の見積もり)がそもそも間違っている。
レビュー
各工程の途中、あるいは最終段階で、成果物の内容について、不足がないことをチェックする工程です。
また、成果物の内容の精度を高めるための指摘を行う場ともなります。
以下に、レビューの種類を記述します。

インスペクション

・作成者が中心となって実施します。
・モデレータ(調停者)が進行役となります。
・ソースコードを1行ずつチェックしながら評価を行います。
・抽出した問題点は、モデレータが管理し、Pj全体の担当や各工程にフィードバックされる形をとります。

ウォークスルー

・作成者が中心となって実施します。
・作成者が主体となって進行します。
・レビューで指摘された内容について、実際の修正・確認は担当者(作成者)が行います。
・多くの観点から行う目的もあるので、エンドユーザなども参加する場合もあります。(要求、設計段階など)


ソフトウェア開発の工数算出法

ソフトウェア開発の工数を算出する手法について、以下に記述します。

ファンクションポイントモデル
ソフトウェアに含まれる機能(入出力データの数・インターフェイスの数など)によってコストを見積もります。
機能の要素

外部入力

EI(キーボードなどからの入力)

外部出力

EO(帳票などの出力)

外部照会

EQ(データベース検索、検索結果の表示)

内部論理ファイル

ILF:該当アプリケーションが維持管理するファイル
(データベースとの連携、ログファイル出力)

外部インターフェイスファイル

EIF:外部アプリケーションで維持管理し、該当アプリケーションでは、参照のみ行います。
(他APとのIF用ファイル作成)

FP法カウントの手順(ソフトウェアの機能→ソフトウェアの規模)

1)

境界設定

測定対象のソフトウェアの範囲を明確にします。

2)

機能洗い出し

ソフトウェア内の機能(上記)を抽出します。設計書ベースで行います。

3)

複雑さ評価

抽出した機能の個数*機能毎の複雑さ係数(項目数・ファイル数などで異なる)を算出します。

4)

システム特性評価

通信の有無やトランザクションの多少などの14項目について5段階の評価を行い、合計します。

■ これで算出したFP値に、決まった定数を掛けることで、人月工数やステップ数を算出するといった形で利用されます。
COCOMO(Construction Cost Model)
統計的モデル(過去の実績)に基づいて、開発期間・開発工数を予測してコストを見積もります。
開発するソフトに規模(実際にはソースコードの行数)を推定済みとして、難易度や技術者のスキルを加味し、開発工数(人月)や期間を算出します。


Next    IT講座トップへ 



基本ソフトウェアの知識