システム開発技術

Download Report

Transcript システム開発技術 

システム開発技術（１）
①システム開発のプロセス（１）
（要件定義～テスト）
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
（業務）
要件定義書
発注依頼
発注依頼承認
品種登録申請
(
工
依
務
頼
課
元
他
)
（１）要件定義（p76）
発注依頼
購買依頼一
覧
発
購注
買部
課署
・
総
務
課
）
メール、FAX、ＤＢ
受領
(
 「業務要件」を明確にする
価格決定連絡
書
購入したい品目、 数量、 所属課長に承認
を得る。
納期を申請する。
見積書
(合意後）
交渉結果について、購買
物流部長(総務課長)の決
購入依頼(予定品名、数量、時期)を 裁を得る。
もとに取引先と交渉する。
取
引
先
情報システムを使って実現される
見積書
（前残数量、当月入庫
「業務内容」を明確にする
経営戦略～利用者ニーズを調査・分析する
≒「業務分析」
 手法：ヒアリングなど（後期）
 優先度・予算なども考慮
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
承認
見積依頼
5
（２）設計工程の概要（p87・・・大分類）

外部設計
 利用者から見える部分の設計


例）画面設計書
内部設計
 開発に必要な部分の設計

例）プログラム設計書
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
6
開発プロセス（工程）の詳細（p87）

共通フレーム（ＳＬＣＰ、p99）
 Software
Life Cycle Process
慣用的な
工程名
共通フレームでの
工程名
要件定義
要件定義
システム要件定義
システム方式設計
ソフトウェア要件定義
ソフトウェア方式設計
ソフトウェア詳細設計
外部設計
内部設計
『システム開発技術』
共通フレー
ムでの
階層
業務
システム
ソフトウェア
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
7
Ａ．外部設計工程の詳細
①システム要件定義（p86）
→ システム設計への要件として再定義
ⅰ）システム機能（機能要件）の明確化
営業 受注、出荷指図・準備・確認、請求、生産依頼、委託加工発注、
システム ロットNo別在庫管理などの営業・物流管理業務を行う
ⅱ）非機能要件の明確化
生産 中間体生産計画、生産指図、生産実績、製品入庫・予定、原材料
 業務要件
②システム方式設計（p87）
システム
購買
システム
会計
システム
仕掛在庫管理、工程外注管理などの生産管理業務を行う
購買品（原燃料荷資材、設備・工事など）の発注依頼、発注、入庫
などの購買管理業務を行う
会計伝票、入金支払、債権債務管理、固定資産管理、損益計算な
どの会計業務を行う
→ どういう方式で実装するか
ⅰ）ハードウェア方式 （汎用機 ｖｓ Ｃ／Ｓ）
ⅱ）ソフトウェア方式 （ＥＲＰ ｖｓ 開発、 手作業の範囲）
 システム要件
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
8
外部設計工程の詳細（続き）
③ソフトウェア要件定義（p87）
 システム要件
→ 内部設計への要件として再定義
ⅰ）データの定義

画面設計
ⅱ）外部インタフェースの定義

コード設計
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
9
画面設計

画面設計、帳票設計（p215）
どんなデータが必要になるか＝データ定義
 ＧＵＩ（第６回）とも関連
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
10
コード設計

コード採用の狙い
 入力ミスの防止

チェックディジット（第６回）
 処理の正確化

主キーの一意化
例
 空港：NRT、KIX
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
11
Ｂ．内部設計工程の詳細（p87）
④ソフトウェア方式設計
→ どういう方式で開発するか
ⅰ）ＤＢＭＳ・プログラム言語の選定
ⅱ）プログラムや
データベースの「全体構造」
 ソフトウェア要件
⑤ソフトウェア詳細設計
 どういうプログラムを作るか（プログラム設計書）
ⅰ）ＤＦＤ・ＥＲ図（次頁） → プログラム分割（最小単位まで）
ⅱ）データベース詳細
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
12
ＤＦＤ・ＥＲ図（ソフトウェア詳細設計、後期第５回で）
（参考）
得意先
注文
受注
確定注文
納品
未出荷受注
←DFD
出荷依頼
請求書
出荷指図
請求
出荷
出荷指図実行
売上
出荷準備
出荷待ち受注
出荷
請求計算
在庫減
売掛金
商品在庫
得意先
倉庫
請求
受注
出荷
指図
売掛金
商品
ER図→
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
13
（３）プログラミング（p88）

プログラミング（ＰＧ）
 アルゴリズムの基本構造（第４回）
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
（４）テスト（p88～）

「正しく作られているか」を確認する
①単体テスト（p88）

別名：モジュールテスト
 デバッグ（DeBug）
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
15
②結合テスト（p89）
複数のプログラムが連携できているか
トップダウン（ＴｏｐＤｏｗｎ）テスト
ボトムアップ（ＢｏｔｔｏｍＵｐ）テスト
『システム開発技術』
・・・スタブ
・・・ドライバ
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
16
③システムテスト（p90）
外部設計書どおり（全体として）できているか
機能テスト
 侵入（ペネトレーション）テスト（p294）も
性能テスト
負荷テスト
対
システム要件定義（外部設計）
回帰テスト
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
17
④運用テスト
 （業務）
要件定義書どおりできているか
 業務ができるか
 実際の利用者が参加
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
18
（５）テストの技法

ホワイトボックステスト（p88）
I=1
I=I+1
I=<N
 内部構造のすべての経路をテスト

どう網羅させるか（省略）
 単体テストで

ブラックボックステスト（p89）
 機能が仕様書どおりか
 結合テスト以降で
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
19
ブラックボックステストの技法

同値分割
範囲
値

有効同値クラス 無効同値クラス
Ａ＜０
０≦Ａ≦１００
Ａ＞１００
文字
０を含む正整数
小数点
負数
同値クラスごとに
各１回テストする
限界値分析（境界値分析）
 例：１０個以上１００個未満
 正常限界：１０、９９
 異常限界：９、１００
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
20
（６）システム開発への利用部門の参画
利用者（業
務遂行）の
立場から
（p86）
要件定義
運用テスト
システムテスト
外部設計
内部設計
結合テスト
プログラミング
単体テスト
対応関係・・・ミソ
（p86）
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
21
Ｅｎｄ
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
22
Link先
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
23
非機能要件（p86）

（戻る）
性能要件
 どのくらいの処理能力を持たせるのか
月間処理件数（データベース容量）
 １分あたりの処理件数（スループット、第５回）


運用要件
 いつでも使えるのか（可用性、第２回）
 故障しないか（信頼性）

障害対策、セキュリティなど
『システム開発技術』
（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
システム開発技術（２）
①システム開発のプロセス（２）
（テスト管理、・・・）
②ソフトウェアの規模見積り
『システム開発技術』
（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
（７）テストの管理
テストカバー率（p88）
ＳＴ－１ 進捗状況
残り＝７６件
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
信頼度成長曲線
（ゴンペルツ曲線）.
テスト実施率＝９９％
正常完了率＝９４％
ＳＴ－１ ソフトウェア品質管理
300
250
200
150
100
50
0
未対応率＝１８％
障害件数累積
障害対応件数累積
障害残件
『システム開発技術』
2006/2/14
2006/2/7
2006/1/31
2006/1/24
2006/1/17
2006/1/10
残り＝５１件
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
30
（補足）開発システムが高品質とは
標準的
信頼度成長の
不思議
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
31
（８）工程ごとにレビュー（p112）

レビュー（Review）の目的
 ミスを含んだまま次の工程に進まないように
 設計・製作時に、品質の向上を図る
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
32
レビューの方法（p113）
①インスペクション
 公式なレビュー
 モデレータがレビューを進める
 時間・コストがかかる
②ウォークスルー（ＷａｌｋＴｈｒｕ）
 実務的なレビュー
 開発者がレビューを進める
 内容が伴わないおそれも
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
33
（９）ソフトウェアの受入れ（p91）
ソフトウェア開発を委託
 パッケージを導入


受入れテスト（検収テスト）
委託元
調達先（SI企業、p70）
開発
『システム開発技術』
納入
受入れ
テ
ス
ト
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
34
システム開発のプロセス（再掲）
運用
要件定義
運用テスト
外部設計
設計
内部設計
プログラミング
『システム開発技術』
システムテスト
結合テスト
単体テスト
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
テスト
35
（１０）システムの保守（運用に入ると）

情報システムが本稼働（Production Run）
 運用（Operation）


運用：後期第１２回
日々情報システムを運転する
保守（Maintenance、p91）
①障害（テスト漏れ）
②改善
仕様変更
 業務変化、環境変化

 情報システム（プログラム）を修正＝保守
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
36
システムの保守

事故った！
一般的な保守の分類
 ＢＭ（Ｂｒｅａｋｄｏｗｎ Ｍａｉｎｔｅｎａｎｃｅ、事後修理）

障害を取り除く
 ＰＭ（Ｐｒｅｖｅｎｔｉｖｅ Ｍａｉｎｔｅｎａｎｃｅ、予防保守）
障害が起こらないようにする（MTBFを長く）
 定期保守
２月１日に


形態別の分類
 Remote

Ｍａｉｎｔｅｎａｎｃｅ（遠隔地保守）
MTTRが短くなる（第２回）
『システム開発技術』
（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
 行数（本数）から開発作業規模（人月）を計算する








良さそう
ＦＰ法（p92）





 プログラムの点数を見積る

画面数、ファイル数などから








 点数から開発作業規模（人月）を計算する




難易度を考慮
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
40
規模見積りの例（１）

プログラムステップ法
 ３０００本のプログラムを修正
 ３０％修正が必要
 １日１人：
０．２５本修正できる
 本数＝３０００
ｘ ０．３ ＝ ９００
 規模（人日）＝９００ ÷ ０．２５ ＝ ３,６００
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
41
規模見積りの例（２）

ＦＰ法
外部入力（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
 点数：３５０（←上２表の積和）
 生産性係数：０．０７３
（人月／FP）
 規模（人月）＝３５０ ｘ ０．０７３ ＝ ２５．５５
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
42
5
8
0
5
4
見積り－練習１
当初開発見積：１５０人月のプロジェクトで
 現時点：６０人月を投入、３０％完了（遅れている）
 今後：同じ生産性の場合、完了までに「今後
何人月」必要になるか。

『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
43
練習１の回答
１５０人月：１００％ を目指していたが
 現６０人月：３０％完了（実績）

 現６０人月：当初４０％（＝６０／１５０）完了予定
同じ生産性の場合、トータルでは
１５０ｘ（４０／３０）＝２００（人月）
 既に６０人月投入しているから
今後：２００－６０＝１４０人月必要になる。

『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
44
Ｅｎｄ
『システム開発技術』
（C）Copyright, Toshiomi KOBAYASHI,2009-2015
45