More Related Content Similar to 変更に基づくソフトウェアのライフサイクルとプロセス Similar to 変更に基づくソフトウェアのライフサイクルとプロセス (20) 2. 講義概要
〜～ みなさんと⼀一緒に考えたいこと 〜～
• 前編「ソフトウェアの⼀一⽣生」
– ソフトウェアには⼈人間と同じように⼈人⽣生 (？) が
あると考えられています．
– ソフトウェアはどのように⽣生まれて，成⻑⾧長して，
⽼老老いていくのでしょうか．
• 後編「ソフトウェアの変更更」
– ⼈人間の成⻑⾧長が細胞分裂裂の繰り返しによって起こる
ように，ソフトウェアでもミクロな変更更が成⻑⾧長と
進化を起こします．
– ミクロな変更更はどのように⾏行行われるのでしょう．
3. 参考書籍
• Software Engineering: The Current
Practice (2011)
– ゼロからのソフトウェア開発
ではなく「変更更」を重点的に
教えるユニークな教科書
– 著者: V. Rajlich
• ⽶米国ウェイン州⽴立立⼤大学教授
• ソフトウェア理理解に関する
国際会議 ICPC における
終⾝身ステアリング委員
http://www.amazon.co.jp/dp/1439841225
5. ソフトウェア・ライフサイクル
• ソフトウェアの⼀一⽣生をいくつかの段階に
分ける考え⽅方
– 例例: ウォーターフォール・モデル (1970年年代)
• 上流流の要求や設計に注⼒力力
要求分析 し，仕様の漏漏れや誤解を
減らす
設計
• 実装段階での時間と労⼒力力
の無駄を最⼩小限に抑えて
実装 スケジュールの遅延を回
避し，品質を⾼高める
(ユーザへの引き渡し)
保守・運⽤用
7. 変更更を踏まえたライフサイクル
• 段階的 (staged) モデル [Rajlich 2011]
初期開発
ソフトウェアの進化
初期バージョン • 新しい機能の追加 ソフトウェア開発者の
進化中 • 不不具合の修正 仕事の⼤大部分は「変更更」
進化の終了了 サービスパッチ
• 最⼩小限度度の変更更
稼働中 (深刻なバグ，セキュリティ
問題などへの対応)
サービス期間の終了了
段階的廃⽌止
停⽌止
運⽤用停⽌止
8. 例例: マイクロソフト製品
• サポートライフサイクルを導⼊入 (2002年年10⽉月)
オンライン
メインストリーム 延⻑⾧長サポート
サポートの種類 セルフヘルプ
サポートフェーズ フェーズ
サポート
仕様変更更、新機能のリクエスト ✔ ✖
✔
セキュリティ更更新プログラム ✔ ✔ マイクロソフトの
オンライン上にあ
★ るリソースを利利⽤用
その他の修正プログラム (バグ修正) ✔ (延⻑⾧長修正プログラ し、マイクロソフ
ムサポート契約) トに直接コンタク
トを取る必要がな
無償サポート (ライセンスやライセン く、すばやく問題
スプログラム、その他の無償ライセン ✔ ✖ を解決することが
スプログラムに付属) できます。
有償サポート (インシデントサポート、
時間制サポート) ✔ ✔
ビジネス、開発
全製品
サポート対象の製品カテゴリ ⽤用ソフウェア 全製品
(最短 5 年年間)
(最短5年年間)
http://support.microsoft.com/gp/lifecycle/ja より表を引⽤用 (⼀一部を修正)
9. 世代交代を含むライフサイクル
• 複数のバージョンを並⾏行行して開発する
初期開発
初期バージョン
ソフトウェア
進化中 の進化
(ver 1.x) サービス
パッチ
稼働中
新しいバージョン
への進化
段階的廃⽌止
ソフトウェア
進化中 の進化
(ver 2.x)
運⽤用停⽌止
サービス
パッチ
新しいバージョン
稼働中
への進化
段階的廃⽌止
進化中 運⽤用停⽌止
(ver 3.x)
10. 例例: Microsoft Windows
• Vista 以降降は 3 年年ごとに新バージョンをリリース
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
バージョン
Windows XP
Professional メインストリーム 延⻑⾧長サポート
サポート
Windows
Vista メインストリーム 延⻑⾧長サポート
Business サポート
Windows 7 メインストリーム 延⻑⾧長サポート
Professional サポート
Windows 8
メインストリーム 延⻑⾧長サポート
Pro
サポート
http://support.microsoft.com/gp/lifeselectwin のサポート情報をもとに年年表を作成
11. 例例: Ubuntu の⻑⾧長期サポート版
(LTS; Long Term Support)
• 2008年年4⽉月から 2 年年ごとにリリース
https://wiki.ubuntu.com/LTS より図を引⽤用
12. 例例: 全銀システム
• 銀⾏行行間の為替取引 (振り込み等) を処理理する
ためのネットワーク
http://www.zengin-net.jp/zengin_net/pdf/pamphlet_j.pdf から第2図を引⽤用
13. 例例: 全銀システム
• 現在は第6次システム (2011年年〜～)
1970 1980 1990 2000 2010
第1次
(1973.4〜～) 第2次
<5年年> (1979.2〜～) 第3次
<8年年余> (1987.11〜～) 第4次
<8年年> (1995.11〜～) 第5次
<8年年> (2003.11〜～) 第6次
<8年年> (2011.11〜～)
2000万件/⽇日
システムの処理理能⼒力力
(テレ為替) 1500万件/⽇日
1350万件/⽇日
500万件/⽇日
100万件/⽇日 140万件/⽇日
http://www.zengin-net.jp/zengin_net/pdf/pamphlet_j.pdf 第2表から図を作成
14. 前半のまとめ
• ソフトウェアには⼀一⽣生 (ライフサイクル)
があります．
– 若若いときには成⻑⾧長もするし，病気 (バグ) への
抵抗⼒力力もありますが，やがて成熟期に⼊入ると
健康維持に気をつけながら社会に貢献します．
– 寿命はソフトウェアの種類や環境により様々
ですが，多くの⼈人に使われるソフトウェアは
5〜～10年年程度度は⽣生存します．
– 寿命が尽きる前に，次の世代 (バージョン) に
役割を引き継ぎます．
16. なぜ変更更が必要なのか？
• 変更更は⽬目的によって 4 種類に分類される
変更更の種類* 変更更の意図・⽬目的
完全化 ソフトウェアに新しい機能を追加し，より価
Perfective Change 値を⾼高めるための変更更．
適応 ソフトウェアを新しい運⽤用環境へ適応させる
Adaptive Change ための変更更．
是正 ソフトウェアのバグや不不具合を修正するため
Corrective Change の変更更．
予防的 ソフトウェアとその価値を予防的に守るため
Protective Change の変更更．ユーザにはこの種の変更更による効果
は直接⾒見見えない．
* 変更更の種類の⽇日本語訳は JIS X 0161:2008 で定義されたソフトウェア保守の区分と⼀一致させた．
17. 変更更要求の管理理
• 新しい機能を考えついたり，バグを⾒見見つけた
としても，いきなり変更更を始め (られ) ない
– ⼀一般には，ソフトウェアの利利⽤用者と開発者は同じ
⼈人ではない
– 変更更には時間やお⾦金金がかかるので，重要な変更更を
優先して対応するべき
• 対策: 忘れないように書きとめておこう
– 要求管理理ツール
– バグ管理理システム (Bug Tracking System; BTS)
18. 例例: EC-CUBE
• 電⼦子商取引 (EC) サイトを構築するための
パッケージ・ソフトウェア
– 国内で開発され，オープンソースで公開中
顧客向け画⾯面
管理理画⾯面
http://demo211.ec-cube.net/
19. 例例: EC-CUBE の開発コミュニティ
(掲⽰示板・電⼦子会議室)
• 質問・バグ報告・機能要望を誰でも投稿できる
http://xoops.ec-cube.net/modules/newbb/index.php
20. 変更更要求の 1 つ分に対する
開発プロセス
変更更の開始 • 実装する変更更要求を決める
(Initiation)
• 修正の中⼼心となる重要なソースコードの箇所や
実装箇所の特定 更更新すべきモジュールを特定する
(Concept Location)
• 特定した箇所への変更更の実装⽅方針を検討しなが
変更更影響の分析 ら，修正すべきソースコードの範囲を⾒見見積る
(Impact Analysis)
• ソースコードの修正を容易易にするために，事前
変更更前の
リファクタリング にリファクタリングを⾏行行う
(Prefactoring)
• ソースコードを修正し，新しい機能を実装した
(Verification)
変更更の実現 りバグを除去したりする
検証
(Actualization)
• 変更更を実装した後に，ソースコードをきれいに
変更更後の
リファクタリング 整える
(Postfactoring)
• 変更更されたソースコードを版管理理システムにコ
変更更の完了了 ミットしたり，⽂文書の更更新やリリース作業など
(Conclusion)
を⾏行行う
21. 変更更の開始
(Initiation)
• 優先度度や開発スケジュールに従い，対応
する変更更要求を選択する
次回リリースで対応
題名: 受注商品情報が空で注⽂文が完了了できる (2013/1/xx)
投稿者: jiro / 投稿⽇日時: 2012-10-24 15:53
バグ 要望
説明: EC CUBE ver2.11.5ですが、受注商品情報
（dtb_order_detail）が空で注⽂文が完了了できる
（場合がある）現象が発⽣生しています。 積み残し課題
ふむふむ… (バックログ)
似たような現象を確認された⽅方はいらっしゃいま
バグ 要望
すでしょうか？
開発者 ユーザ
22. 実装箇所の特定
(Concept Location)
• 変更更要求に含まれる “概念念” に対応する
ソースコードの箇所を特定する
概念念 実装個所 (ファイル名)
• pages/shopping/LC_Page_Shopping.php
• pages/shopping/LC_Page_Shopping_Complete.php お買い物の完了了
商品カタログ • pages/shopping/LC_Page_Shopping_Confirm.php お買い物の確認
ショッピング • pages/shopping/LC_Page_Shopping_Deliv.php
会員登録 • pages/shopping/LC_Page_Shopping_LoadPaymentModule.php
• pages/shopping/LC_Page_Shopping_Multiple.php
• pages/shopping/LC_Page_Shopping_Payment.php
• html/install/temp/install.log
• html/shopping/complete.php
• html/shopping/confirm.php
• html/shopping/deliv.php
......
開発者
23. 変更更影響の分析
(Impact Analysis)
• 特定した箇所の付近を調査し，変更更が必要な
範囲を⾒見見積る SC_CartSession.php 内の
checkProducts 関数
LC_Page_Shopping_Confirm.php
…
function action() {
$objCartSess = new SC_CartSession_Ex();
…
// 前のページで正しく登録⼿手続きが⾏行行われた記録があるか判定
if (!$objSiteSess->isPrePage()) {
SC_Utils_Ex::sfDispSiteError(PAGE_ERROR, $objSiteSess);
}
…
// カート内商品のチェック
$this->tpl_message = $objCartSess->checkProducts($this->cartKey); SC_Utils.php 内の
if (!SC_Utils_Ex::isBlank($this->tpl_message)) { IsBlank 関数
SC_Response_Ex::sendRedirect(CART_URLPATH);
exit;
}
24. 変更更の繰り返しプロセス
(アジャイル反復復プロセス)
プロダクト・バックログ
イテレーション・
バックログ プロダクト
ユーザ マネージャ
ビルド
並⾏行行開発による
ソフトウェア変更更
… デイリー
ミーティング
プログラマ
イテレーションミーティング
／リリース プロセス
マネージャ
25. 反復復型のライフサイクル (再掲)
• 段階的 (staged) モデル [Rajlich 2011]
初期開発
ソフトウェアの進化
初期バージョン • 新しい機能の追加 ソフトウェア開発者の
進化中 • 不不具合の修正 仕事の⼤大部分は「変更更」
進化の終了了 サービスパッチ
• 最⼩小限度度の変更更
稼働中 (深刻なバグ，セキュリティ
問題などへの対応)
サービス期間の終了了
段階的廃⽌止
停⽌止
運⽤用停⽌止
27. 後半のまとめ
• ソフトウェアの進化は⼩小さな変更更の繰り返し
で実現されています．
– ⻑⾧長⽣生きの秘訣: 随所でコミュニケーションを⾏行行い
関係者の価値観やアイデアを素早く取り込む
– デザイン思考: 作りながら考え，考えながら作る
• 変更更は単純作業ではありません．プロのソフ
トウェア開発者なら…
– クールに: ⼩小さな変更更を確実こなす
– 創造的に: 新しいアイデアややり⽅方を試したり，
同僚僚と議論論したりする
28. おわりに
• ソフトウェアがこれからも社会のしくみ
を⽀支え続けていくために，みなさんの⼒力力
が必要です！
– ⼤大きな進化を⼀一度度きりの開発，⼀一⼈人の開発者
だけで実現することは困難でも…
– 適切切な知識識・スキルを備えた開発者がチーム
ワークを発揮して，⼩小さな変更更を着実に積み
重ねていけば達成できるはず．
• プロのソフトウェア開発者としてお会い
できる⽇日を楽しみにしています．
29. 参考⽂文献
• V. Rajlich, “Software Engineering: The
Current Practice”, Chapman & Hall/CRC,
2011
• ⼤大森隆⾏行行, 丸⼭山勝久, 林林晋平, 沢⽥田篤史, “ソフ
トウェア進化研究の分類と動向”, コンピュー
タソフトウェア, 29(3), 3-28, 2012
• T. Mens, Y.-G. Guehénéuc, J. Fernández-
Ramil, & ,M. D’Hondt, “Guest Editors’
Introduction: Software Evolution”, IEEE
Software, 27(4), 22–25, 2010
