Comments
Description
Transcript
ソフトウェア 学
ソフトウェア⼯学
(
(part
1))
情報メディアシステム分野
情報メデ
アシステム分野
手塚太郎
この資料は以下の場所にあります。
http://xi.kc.tsukuba.ac.jp/lec/SE1.pdf
ソフトウェア(Software)
z データ処理システムを機能させるための，プログラム，⼿順，
規制，関連⽂書などを含む知的な創作
規制
関連⽂書などを含む知的な創作
プログラム
要求定義書，外部設計書，内部設計書，データベース定義
要求定義書 外部設計書 内部設計書 デ タベ ス定義
書，コーディング規約，取扱説明書，運⽤マニュアル
プログラム，プログラムを作成する過程で得られるシステ
プログラム プログラムを作成する過程で得られるシステ
ム設計書，フローチャートをはじめとする設計書，および，
プログラム説明書などの関連資料
z cf. ハードウェア(hardware)
コンピュータ装置
コンピュ
タ装置
応⽤ソフトウェア
システム
ソフトウェア
ミドルウェア
基本ソフトウェア
ワードプロセッサ，メーラーなど
GUI，データベース管理ソフトウェアなど
OS, コンパイラなど
1
ソフトウェアとハードウェアの違い
z ソフトウェア
経年劣化なし
導⼊後に修正可能
製品の量産コスト，配布・流通コストは低い
製品の量産コスト 配布・流通コストは低い
機能拡張，性能改善，環境適合に関する要求
機能拡張，性能改善，環境適合
関 る要求
ソフトウェア進化が前提
z ハードウェア
経年変化あり (磨耗，部品の寿命）
導⼊後の修正はほぼ不可能
製品の量産および配布コストあり
機能や性能を維持することに対する要求
2
ソフトウェア開発(Software Development)
z 顧客の要求をソフトウェア製品に変換する作業
良いソフトウェアを効率的に構築
品質(良さ)とコスト(時間/お⾦)のバランスが重要
要求
ソフトウェア開発
プログラム
顧客
ソフトウェア
開発者
コンピュ タ装置
コンピュータ装置
(ハードウェア)
3
ソフトウェア開発技術の歴史
1960
機能の時代:
既存業務の情報システム化
1970
スケジュールの時代:
スケジ
ルの時代
開発計画やライフサイクルの登場
1980
コストの時代:
開発における⽣産性が重要視
1990
2000
現在
品質の時代:
社会の依存度が増⼤
使い勝⼿の良さに対する要求
複雑さへの挑戦
IBM OS/360 (1964): 500万⾏(推測)
⾦融システム(1980半ば): 500万⾏
DVDレコーダ(2000): 20万⾏
⾦融システム: 6400万⾏
DVDレコーダ(2000): 100万⾏
⾃動⾞: 500〜1000万⾏
携帯電話: 500万⾏
⾃動⾞(2000): 100万⾏
携帯電話(2001): 100万⾏
WindowsXP(2002):
4000〜7000万⾏(推測)
4
ソフトウェア⼯学(Software Engineering)
z コンピュータソフトウェアを対象として，その構築，運⽤，
保守における⽣産性と品質の向上を実現するための技術体系
や学問体系
⽅法論(methodology)
(
gy)
技法(technique) / 道具(tool)
プロジェクト管理(project management)
z ソフトウェア危機(software crisis)を打開するためのソフト
ウェア開発の技術体系および学問体系
z ソフトウェア⼯学の⽬的
学
的
良いソフトウェアを開発すること
– ソフトウェアの品質特性
ソフトウ アの品質特性 (国際規格 ISO 9126)
z ソフトウェア⼯学の実践
ソフトウェアを開発するための理論，原理，技術に基づく
ソフトウ アを開発するための理論 原理 技術に基づく
⽅法論や，表記法，ツールを活⽤して，ソフトウェアを構
築，運⽤，保守する活動
⼤規模・⾼信頼ソフトウェアの開発 ≠ プログラミング
5
ソフトウェア危機
z 技術者不⾜，納期遅れ，品質低下，開発費増⼤
NATO会議(1968年)で指摘
⽣産物の側⾯
ハードウェアの⼤型化に伴うソフトウェアの規模の拡⼤
コンピュータの普及に伴う開発ソフトウェアの数の増⼤
⼈の側⾯
ステークホルダー(stakeholder)の多様化
– ソフトウェア開発とのその成果物に対する利害関係者
時間の側⾯
開発時間および利⽤時間の増⼤
動作環境や社会的要求が変動
役割の側⾯
コンピュータで扱う分野の拡⼤
社会的に重要なコンピュータシステムに対する信頼性の向上
ソフトウェアの⼤衆化に伴う使い勝⼿の向上
z
z
z
z
6
ソフトウェアの開発⼯程
ソフトウェア開発⼯程とは
z ソフトウェアの開発をどのように進めるかを規定したもの
開発における作業: 開発プロセス(process)
各作業において，プロダクト(product)を⽣成
– ⽂書，図表，プログラム，マニュアルなど
⽂書 図表 プログラム マニュアルなど
z ソフトウェアプロセスモデル(process model)，ライフサイ
クル(life cycle)ともいう
クル(
y )とも う
要求分析
(requirements analysis)
基本設計
(basic design)
運⽤・保守
(maintenance)
詳細設計
(detail design)
テスト
(testing)
実装
(implementation)
8
ソフトウェア開発プロセス
要求仕様書
要求記述
求 述
顧客
顧
基本
設計
要求
仕様化
要求
獲得
要求分析
3
3
3 3
3 3
3 3 3
設計
3
3
3
運⽤・保守
納⼊
テスト
報告書
基本設計
仕様書
テスト
a = 0;
…
while ( ) {
if ( )
…
else
…
}
…
ソース
プログラム
詳細
設計
実装
詳細設計
仕様書
9
ソフトウェア開発プロセス(要求分析)
z 要求獲得
利⽤者(ユーザ)
利⽤者(ユ
ザ) が要求するシステムを整理し，⾃然⾔語
が要求するシステムを整理し ⾃然⾔語
で⽂書化
– 要求記述を作成
z 要求定義
どのようなシステムを作成するのかを決定
システム要求書を分析し，開発するシステムを形式的に⽂
，
書化
– 要求仕様書(requirements specification)
分析者(analyst)が実施
10
ソフトウェア開発プロセス(設計)
z 基本設計
システム設計(system design)
design)，外部設計(external
外部設計(external
design)ともいう
外部から⾒たシステム全体をどのように作成するのかを決定
ソフトウェアアーキテクチャやユーザインタフェースを決定
– 基本設計仕様書
設計者(designer)が実施
z 詳細設計
プログラム設計(program design)，内部設計(internal
design)ともいう
個々のモジュールのアルゴリズムやデータ構造を決定
– 詳細設計仕様書
詳細 計仕様書
プログラマ(programmer)が実施
11
ソフトウェア開発プロセス(実装，テスト)
z 実装
コーディング(coding)ともいう
コ
ディング(coding)ともいう
プログラム設計仕様をプログラムに変換
具体的なプログラミング⾔語(program language)による
記述
– ソ
ソースプログラム(source
スプ グラム(
p
program)
g
)
プログラマが実施
z テスト
仕様書どおりにプログラムが動作するかどうかを検査
– テスト報告書(test report)
試験者(tester)が実施
– ソフトウェア作成と独⽴の組織を⽤意
デバック(debug)
– エラー(error)の修正は設計者やプログラマが実施)
12
ソフトウェア開発プロセス(運⽤・保守)
z 運⽤・保守
納⼊後のソフトウェアを維持・管理
納⼊後のソフトウェアを維持
管理
運⽤段階で検出された故障(残存エラー)の修正
変更要求への対応
– 新機能の追加
– 既存機能の変更
– 新しい環境への適合
保守者(customer engineer)が実施
13
ウォーターフォールモデル
z トップダウンな開発プロセス: 滝(waterfall)
引継ぎに関するレビュー
要求分析
各段階での正しさに
関するレビュー
基本設計
詳細設計
実装
困難
⼿戻りを想定
していない
テスト
保守
利点: ⼯数⾒積もりや進捗管理が容易
⽋点: 仕様変更に弱い，誤り発⾒の遅れ，修正コストの増⼤
14
V字モデル
z ウォーターフォールモデルはV字モデルとして捉え直せる。
要求分析
統
統合テスト
基本設計
結合テスト
詳細設計
単体テスト
実装
15
ソフトウェア開発モデルの推移
z 1960年代: 流れ図(flowchart)を利⽤
ウォーターフォールモデル
要求分析
開発⽅法論なし
基本設計
z 1970年代: 構造的なソフトウェア開発
詳細設計
ウォータフォールモデル
実装
z 1980年代: ソフトウェアライフサイクル有害説
テスト
新しいソフトウェア開発モデルの必要性
z 進化型(成⻑型，発展型)プロセスモデルの登場
1) 開発の初期段階から実⾏可能なプログラムを部分的に作成
2) プログラムを実際に動作させて機能を確認
3)) プ
プログラムの改善
グラムの改善
4) (2)と(3)を繰り返し
使い捨て型プロトタイピング(throwaway
(
yp
prototyping)
yp g)
スパイラルモデル(spiral model)
進化型プロトタイピング(evolutionary prototyping)
アジャイルプロセスモデル(agile process model)
保守
16
新しいソフトウェア開発モデル
1) ソフトウェアプロトタイピング(software prototyping)
9
システム設計時に試作品(プロトタイプ; prototype)を構築
2) 操作的アプローチ(operational
操作的アプロ チ(operational approach)
9
実行可能な仕様(executable specification)の作成
ソース
プログラム
要求分析
プロトタイプ作成
要求仕様
基本設計
詳細設計
プロトタイプ評価
実装
テスト
保守
17
新しいソフトウェア開発モデル(cont’d.)
3) オブジェクト指向ソフトウェア開発(object-oriented software development)
9 オブジェクトを単位としてソフトウェアを構築
オブジェクト: 実世界の「もの」や「役割」などを抽象化したもの
9
スパイラルモデル(spiral model)
インクリメンタル(incremental) + イテラティブ(iterative)
4) アジャイルソフトウェア開発(Agile software development)
例) XP(extreme programming)
アジャイルアライアンス宣言(manifesto)
プロセスやツールよりも，個人や人同士の交流を重視
プ
9 包括的なドキュメントよりも，動作するソフトウェアを重視
9 契約上の交渉よりも，顧客との協調を重視
契約上の交渉よりも 顧客との協調を重視
9 計画に従うことよりも，変化に対応することを重視
9
注) 左側の項目を軽視するという意味ではない
目標の
決定
計画
リスク分析
プロトタイプ
開発
テスト
Boehm (1988)
18
使い捨てプロトタイピング
z システム設計時にプロトタイプ(試供品: prototype)を構築
問題点の早期発⾒と要求のあいまいさの解消
– プロトタイプに基づき要求仕様書を作成
⼤幅な⼿戻りを減少
プロトタイプ作成
要求分析
要求仕様書
基本設計
プロトタイプ評価
詳細設計
実装
テスト
保守
19
スパイラルモデル
z プロトタイプを作成し，利⽤者からのフィードバックに対応
しながら，徐々にシステムを作成
しながら
徐々にシステムを作成
リスク(開発の失敗)を分析することで，リスクを軽減
リスク分析
プロトタイピング
⽬標の決定
要求分析
設計
実装
次のフェーズ
ズ
の計画
テスト
ウォーターフォール
モデルへの適⽤例
プロダクトの開発
プ
ダ
評価
20
進化型プロトタイピング
z プロトタイプを徐々に修正し，そのまま完成品として利⽤
機能が明確な部分から構築
反復型開発モデル
– イテラティブ(iterative)
– インクリメンタル(incremental)
インクリメンタル
実装
テスト
実装・テスト
イテラティブ
設計
要求分析
21
アジャイルプロセスモデル
z 変化に迅速に対応
軽量(lightweight)プロセス
軽量(li ht i ht)プロセス
XP(extreme programming), Scrumなど
z 開発対象を多数の⼩さな機能に分割して，各機能を短期間で開発
開発対象を多数 ⼩さな機能 分割
各機能を短期間 開発
1つの反復(iteration)で1機能を実現
実⾏可能なソフトウェアを随時提供
究極の反復型開発(進化型プロトタイピング)
–
変更コスト
従来
変更コスト
アジャイル
時間
時間
分析 設計 実装 テスト
分析 設計 実装 テスト
22
XP（エクストリームプログラミング）
z アジャイル開発の代表例のひとつ
z 開発時における具体的なプラクティス（⾏動指針）の集まり
当初のXPにおける12のプラクティス（前半）
計画ゲーム
The planning game
次回リリースの範囲を早急に決める
小規模リリース
Small releases
リリースサイクルを短めに
比喩
Metaphor
システムの動きを表すメタファー（比喩）を導入
シンプルデザイン
Simple design
余分な複雑さを減らす
テスティング
Testing
プログラマが継続的にテストを書く
リファクタリング
Refactoring
g
コードの見直しを積極的に行う
23
XP（エクストリームプログラミング）
当初のXPにおける12のプラクティス（後半）
ペアプログラミング
Pair p
programming
g
g
2人のプログラマが組になってコードを書く
共同所有権
Collective ownership
すべてのプログラマがすべてのコードにアクセス可能
継続的インテグレーション
Continuous integration
常にテストを実行し、動作する状態におく
週40時間
40 hour week
働き過ぎは良い結果を生まない。
顧客
オンサイト顧客
On site customer
ユ ザをチ ムに加える
ユーザをチームに加える
コーディング標準
C di standards
Coding
t d d
全プログラマがコーディング標準に従う
全プ
グラ が
ディング標準に従う
z 現在では19のプラクティスまで増えている。
24
ソフトウェアライフサイクルプロセス
SLCP（ソフトウェアライフサイクルプロセス）
z ソフトウェア開発とその周辺の業務⼿順におけ
る作業項⽬を定義し 標準化したも
る作業項⽬を定義し、標準化したもの。
z 他社に開発依頼する場合、作業⼿順に関する⽤
語や定義が異なると、トラブルが⽣じうるため、
語や定義が異なると
トラブルが⽣じうるため
統⼀が必要。
z 「ソフトウェア開発モデル」と異なり、開発の
「ソフトウェア開発モデル」と異なり 開発の
周辺業務も含まれている。
z プロジェクト管理において、管理の対象となる。
26
SLCPの要素
プ
プロセス群
プ
プロセス
主ライフサイクルプ
主ライフサイクルプロ
セス
取得、供給、契約の変更管理、企画、
要件定義、開発、運用、保守
支援ライフサイクルプ
プ
ロセス
文書化、構成管理、品質保証、検証、
文書化
構成管理 品質保証 検証
妥当性確認、共同レビュー、監査、問
題解決、ユ ザビリティ（使用性向上）
題解決、ユーザビリティ（使用性向上）
管理、環境整備、改善、人的資源、資
組織に関するライフサ
産管理 再利用プログラム ドメイン技
産管理、再利用プログラム、ドメイン技
イクルプロセス
術
システム監査プロセス
27
開発プロセス
1. プロセス開始の準備
2. システム要件定義
シ
ム要件定義
3. システム⽅式設計
4. ソフトウェア要件定義
5. ソフトウェア⽅針設計
6. ソフトウェア詳細設計
7 ソフトウェアコード作成およびテスト
7.
ソフトウェアコ ド作成およびテスト
8. ソフトウェア結合
9. ソフトウェア的確性確認テスト
10. システム結合
11. システム適合性確認テスト
12 ソフトウェア導⼊
12.
13. ソフトウェア受け⼊れ⽀援
28
運⽤プロセス
1. プロセス開始の準備
2. 運⽤テスト
3 業務およびシステムの移⾏
3.
4. システム運⽤
5. 利⽤者教育
6 業務運⽤と利⽤者⽀援
6.
7. システム運⽤の評価
8. 業務運⽤の評価
9 投資効果および業務効果の評価
9.
29
保守プロセス
1. プロセス開始の準備
2. 問題把握および修正分析
3 修正の実施
3.
4. 保守レビューおよび受け⼊れ
5. 移⾏
6 ソフトウェア廃棄
6.
30