システム開発技術(1)
①システム開発のプロセス(1)
(要件定義~テスト)
p86~
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
1
システム開発
(例)図書館管理システム
を作る
 多くの画面を定めて
多くのプログラム
を作る必要がある


この「作る」 = 「システム開発」

どうやって作っていくかを勉強する
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
2
①システム開発のプロセス
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
3
システム開発のプロセス(p86)
要件定義
運用テスト
外部設計
設計
内部設計
プログラミング
『システム開発技術』
システムテスト
結合テスト
単体テスト
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
テスト
4
(業務)
要件定義書
発注依頼
発注依頼承認
品種登録申請
(
工
依
務
頼
課
元
他
)
(1)要件定義(p76)
発注依頼
購買依頼一
覧
発
購注
買部
課署
・
総
務
課
)
メール、FAX、DB
受領
(
 「業務要件」を明確にする
価格決定連絡
書
購入したい品目、 数量、 所属課長に承認
を得る。
納期を申請する。
見積書
(合意後)
交渉結果について、購買
物流部長(総務課長)の決
購入依頼(予定品名、数量、時期)を 裁を得る。
もとに取引先と交渉する。
取
引
先
情報システムを使って実現される
見積書
(前残数量、当月入庫
「業務内容」を明確にする
経営戦略~利用者ニーズを調査・分析する
≒「業務分析」
 手法:ヒアリングなど(後期)
 優先度・予算なども考慮
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
承認
見積依頼
5
(2)設計工程の概要(p87・・・大分類)

外部設計
 利用者から見える部分の設計


例)画面設計書
内部設計
 開発に必要な部分の設計

例)プログラム設計書
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
6
開発プロセス(工程)の詳細(p87)

共通フレーム(SLCP、p99)
 Software
Life Cycle Process
慣用的な
工程名
共通フレームでの
工程名
要件定義
要件定義
システム要件定義
システム方式設計
ソフトウェア要件定義
ソフトウェア方式設計
ソフトウェア詳細設計
外部設計
内部設計
『システム開発技術』
共通フレー
ムでの
階層
業務
システム
ソフトウェア
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
7
A.外部設計工程の詳細
①システム要件定義(p86)
→ システム設計への要件として再定義
ⅰ)システム機能(機能要件)の明確化
営業 受注、出荷指図・準備・確認、請求、生産依頼、委託加工発注、
システム ロットNo別在庫管理などの営業・物流管理業務を行う
ⅱ)非機能要件の明確化
生産 中間体生産計画、生産指図、生産実績、製品入庫・予定、原材料
 業務要件
②システム方式設計(p87)
システム
購買
システム
会計
システム
仕掛在庫管理、工程外注管理などの生産管理業務を行う
購買品(原燃料荷資材、設備・工事など)の発注依頼、発注、入庫
などの購買管理業務を行う
会計伝票、入金支払、債権債務管理、固定資産管理、損益計算な
どの会計業務を行う
→ どういう方式で実装するか
ⅰ)ハードウェア方式 (汎用機 vs C/S)
ⅱ)ソフトウェア方式 (ERP vs 開発、 手作業の範囲)
 システム要件
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
8
外部設計工程の詳細(続き)
③ソフトウェア要件定義(p87)
 システム要件
→ 内部設計への要件として再定義
ⅰ)データの定義

画面設計
ⅱ)外部インタフェースの定義

コード設計
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
9
画面設計

画面設計、帳票設計(p215)
どんなデータが必要になるか=データ定義
 GUI(第6回)とも関連
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
10
コード設計

コード採用の狙い
 入力ミスの防止

チェックディジット(第6回)
 処理の正確化

主キーの一意化
例
 空港:NRT、KIX
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
11
B.内部設計工程の詳細(p87)
④ソフトウェア方式設計
→ どういう方式で開発するか
ⅰ)DBMS・プログラム言語の選定
ⅱ)プログラムや
データベースの「全体構造」
 ソフトウェア要件
⑤ソフトウェア詳細設計
 どういうプログラムを作るか(プログラム設計書)
ⅰ)DFD・ER図(次頁) → プログラム分割(最小単位まで)
ⅱ)データベース詳細
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
12
DFD・ER図(ソフトウェア詳細設計、後期第5回で)
(参考)
得意先
注文
受注
確定注文
納品
未出荷受注
←DFD
出荷依頼
請求書
出荷指図
請求
出荷
出荷指図実行
売上
出荷準備
出荷待ち受注
出荷
請求計算
在庫減
売掛金
商品在庫
得意先
倉庫
請求
受注
出荷
指図
売掛金
商品
ER図→
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
13
(3)プログラミング(p88)

プログラミング(PG)
 アルゴリズムの基本構造(第4回)
I=1
public class Sample1 {
public static void main(int x) {
if (x < 3) System.out.println(true); else
System.out.println(false);
}
}
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
I=I+1
I=<N
14
(4)テスト(p88~)

「正しく作られているか」を確認する
①単体テスト(p88)

別名:モジュールテスト
 デバッグ(DeBug)
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
15
②結合テスト(p89)
複数のプログラムが連携できているか
トップダウン(TopDown)テスト
ボトムアップ(BottomUp)テスト
『システム開発技術』
・・・スタブ
・・・ドライバ
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
16
③システムテスト(p90)
外部設計書どおり(全体として)できているか
機能テスト
 侵入(ペネトレーション)テスト(p294)も
性能テスト
負荷テスト
対
システム要件定義(外部設計)
回帰テスト
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
17
④運用テスト
 (業務)
要件定義書どおりできているか
 業務ができるか
 実際の利用者が参加
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
18
(5)テストの技法

ホワイトボックステスト(p88)
I=1
I=I+1
I=<N
 内部構造のすべての経路をテスト

どう網羅させるか(省略)
 単体テストで

ブラックボックステスト(p89)
 機能が仕様書どおりか
 結合テスト以降で
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
19
ブラックボックステストの技法

同値分割
範囲
値

有効同値クラス 無効同値クラス
A<0
0≦A≦100
A>100
文字
0を含む正整数
小数点
負数
同値クラスごとに
各1回テストする
限界値分析(境界値分析)
 例:10個以上100個未満
 正常限界:10、99
 異常限界:9、100
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
20
(6)システム開発への利用部門の参画
利用者(業
務遂行)の
立場から
(p86)
要件定義
運用テスト
システムテスト
外部設計
内部設計
結合テスト
プログラミング
単体テスト
対応関係・・・ミソ
(p86)
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
21
End
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
22
Link先
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
23
非機能要件(p86)

(戻る)
性能要件
 どのくらいの処理能力を持たせるのか
月間処理件数(データベース容量)
 1分あたりの処理件数(スループット、第5回)


運用要件
 いつでも使えるのか(可用性、第2回)
 故障しないか(信頼性)

障害対策、セキュリティなど
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
24
回帰(退行)テスト(p90)


他の部分でバグ発生

→ 退行









退行しないように
修正したら
他の部分もテスト
















『システム開発技術』
(戻る)
Sub NameCheck (Uname As String, Ucode As Integer, Ssw As Integer)
Static nmul(1 To 5) As Integer
Const p_mod% = 16384
Dim i , j, n, w As Integer
nmul(1) = 1: nmul(2) = 2: nmul(3) = 3: nmul(4) = 5: nmul(5) = 7
If LenB(Uname) < 10 Then End
w=0
For i = 1 To 5
For j = 1 To 2
k = (i - 1) * 2 + j
n = CInt(Asc(MidB(Uname, k, 1)))
w = w + (n * nmul(i) Mod p_mod)
Next j
Next I
If Ssw <> 1 Then
If Ucode <> w Then
MsgBox "名前が変えられています。"
End
End If
Else
Ssw = 0
If Ucode <> w Then
Ssw = 1
End If
End If
End Sub
バグ発生
プログラム修正
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
25
システム開発技術(2)
①システム開発のプロセス(2)
(テスト管理、・・・)
②ソフトウェアの規模見積り
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
26
①システム開発のプ
ロセス(続き)
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
27
システム開発のプロセス(再掲)
要件定義
運用テスト
外部設計
設計
内部設計
プログラミング
『システム開発技術』
システムテスト
結合テスト
単体テスト
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
テスト
28
(前回の整理)テスト工程

テスト(開発)のプロセス
 単体/結合/システム(機能、性能、負荷)/運用

テスト(方式)の種類
 トップダウン/ボトムアップ

テスト(技法)の種類
 ホワイトボックス
 ブラックボックス

同値分割/限界値分析
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
29
(7)テストの管理
テストカバー率(p88)
ST-1 進捗状況
残り=76件
2006/2/14
2006/2/7
2006/1/31
2006/1/24
テスト総ケース数
テスト実施数累積
正常完了数累積
2006/1/17
2006/1/10
ケース数
1600
1400
1200
1000
800
600
400
200
0
信頼度成長曲線
(ゴンペルツ曲線).
テスト実施率=99%
正常完了率=94%
ST-1 ソフトウェア品質管理
300
250
200
150
100
50
0
未対応率=18%
障害件数累積
障害対応件数累積
障害残件
『システム開発技術』
2006/2/14
2006/2/7
2006/1/31
2006/1/24
2006/1/17
2006/1/10
残り=51件
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
30
(補足)開発システムが高品質とは
標準的
信頼度成長の
不思議
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
31
(8)工程ごとにレビュー(p112)

レビュー(Review)の目的
 ミスを含んだまま次の工程に進まないように
 設計・製作時に、品質の向上を図る
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
32
レビューの方法(p113)
①インスペクション
 公式なレビュー
 モデレータがレビューを進める
 時間・コストがかかる
②ウォークスルー(WalkThru)
 実務的なレビュー
 開発者がレビューを進める
 内容が伴わないおそれも
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
33
(9)ソフトウェアの受入れ(p91)
ソフトウェア開発を委託
 パッケージを導入


受入れテスト(検収テスト)
委託元
調達先(SI企業、p70)
開発
『システム開発技術』
納入
受入れ
テ
ス
ト
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
34
システム開発のプロセス(再掲)
運用
要件定義
運用テスト
外部設計
設計
内部設計
プログラミング
『システム開発技術』
システムテスト
結合テスト
単体テスト
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
テスト
35
(10)システムの保守(運用に入ると)

情報システムが本稼働(Production Run)
 運用(Operation)


運用:後期第12回
日々情報システムを運転する
保守(Maintenance、p91)
①障害(テスト漏れ)
②改善
仕様変更
 業務変化、環境変化

 情報システム(プログラム)を修正=保守
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
36
システムの保守

事故った!
一般的な保守の分類
 BM(Breakdown Maintenance、事後修理)

障害を取り除く
 PM(Preventive Maintenance、予防保守)
障害が起こらないようにする(MTBFを長く)
 定期保守
2月1日に


形態別の分類
 Remote

Maintenance(遠隔地保守)
MTTRが短くなる(第2回)
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
37
システム保守の留意点
 (目的)安定的・効率的な運用
 (目標)正確な、確実な“保守”

具体的な例
 バックアップをとったものに対して、修正
 回帰テストも(p90)
 設計書も修正
本稼働環境
システム
プロ グラム
戻し
バックアップ
テスト環境
システム
プロ グラム
データ
データ
修正
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
38
②ソフトウェアの
規模見積り
規模=工数:人月(単位)
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
39
開発規模の見積り方法

プログラムステップ(LOC)法
基幹情報システムなど
 プログラムの行数(本数)を見積る

過去の開発経験をベースに



Sub NameCheck (Uname As String, Ucode As Integer, Ssw As
Integer)
Static nmul(1 To 5) As Integer
Const p_mod% = 16384
Dim i , j, n, w As Integer
nmul(1) = 1: nmul(2) = 2: nmul(3) = 3: nmul(4) = 5: nmul(5) = 7
If LenB(Uname) < 10 Then End
w=0
For i = 1 To 5
For j = 1 To 2
k = (i - 1) * 2 + j
n = CInt(Asc(MidB(Uname, k, 1)))
w = w + (n * nmul(i) Mod p_mod)
Next j
Next I
If Ssw <> 1 Then
If Ucode <> w Then
MsgBox "名前が変えられています。"
End
End If
Else
Ssw = 0
If Ucode <> w Then
Ssw = 1
End If
End If
End Sub
 行数(本数)から開発作業規模(人月)を計算する








良さそう
FP法(p92)





 プログラムの点数を見積る

画面数、ファイル数などから








 点数から開発作業規模(人月)を計算する




難易度を考慮
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
40
規模見積りの例(1)

プログラムステップ法
 3000本のプログラムを修正
 30%修正が必要
 1日1人:
0.25本修正できる
 本数=3000
x 0.3 = 900
 規模(人日)=900 ÷ 0.25 = 3,600
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
41
規模見積りの例(2)

FP法
外部入力(p92)
外部出力
外部照会
外部インタフェース
ファイル
内部論理ファイル
FP法の計測表の例(個数を記入)
易
普通
入力画面
出力画面
照会画面
入力ファイル
出力ファイル
FP法の点数表の例
易
入力画面
3
出力画面
5
照会画面
1
入力ファイル
4
出力ファイル
5
普通
4
7
2
5
7
難
易
入力画面
出力画面
照会画面
入力ファイル
出力ファイル
普通
4
2
12
3
5
難
0
5
5
7
2
難
6
10
3
7
10
 点数:350(←上2表の積和)
 生産性係数:0.073
(人月/FP)
 規模(人月)=350 x 0.073 = 25.55
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
42
5
8
0
5
4
見積り-練習1
当初開発見積:150人月のプロジェクトで
 現時点:60人月を投入、30%完了(遅れている)
 今後:同じ生産性の場合、完了までに「今後
何人月」必要になるか。

『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
43
練習1の回答
150人月:100% を目指していたが
 現60人月:30%完了(実績)

 現60人月:当初40%(=60/150)完了予定
同じ生産性の場合、トータルでは
150x(40/30)=200(人月)
 既に60人月投入しているから
今後:200-60=140人月必要になる。

『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
44
End
『システム開発技術』
(C)Copyright, Toshiomi KOBAYASHI,2009-2015
45
ダウンロード

情報化社会での生き甲斐