スライド 0 - cyx.co.jp · 「体系的ソフトウェアテスト入門」 rick craig 他著...

2007/09/07

Copyright © 2007, Cyx Inc., All Rights Reserved.

株式会社サイクス宗雅彦

http://www.cyx.co.jp/

Excellent Quality People

禁無断転用

XDev2007

いまどきの開発にソフトウェア構成管理が必要な本当の理由

D-7: ソフトウェア構成管理×パターン

講演用テキスト

このテキストおよびソフトウェア構成管理リソースを下記URLから配布しています。

http://www.cyx.co.jp/scm/

2007/09/07 - 1 -Copyright © 2007, Cyx Inc. All Rights Reserved.


禁無断転用

自己紹介

宗　雅彦

(そう　まさひこ) Email:[email protected] 株式会社サイクス

(http://www.cyx.co.jp)代表取締役・プリンシパルコンサルタント

●外資系コンピュータメーカーの米国ソフトウェア研究所で、国際化ＵＮＩＸ開発、

　

マルチプロセッサＵＮＩＸカーネルの開発プロジェクトに従事。

●インターネットブーム熱かりしシリコンバレーで、ＩＴベンチャーの技術発掘、投資、

事業提携業務に携わる。

●2000年にITコンサルティング会社の株式会社サイクスを創業。

●2005年に米国Software Quality Engineering社と

エス・キュー・イー・ジャパンを設立。

ビジネス系システム、組み込みソフトウェア開発の、プロジェクトマネジメント改善、

品質管理システム構築、要求開発/テストプロセス改善等のご支援に取り組む。

宗教の宗の方です

コンサルティング・

技術支援

セミナー・

トレーニング



禁無断転用

技術情報発信

「体系的ソフトウェアテスト入門」

Rick Craig他　著

宗　雅彦　監訳

　成田　光彰

訳

　日経BP社　刊

「はじめて学ぶソフトウェア

　のテスト技法」

Lee Copeland　著

宗　雅彦　訳

日経BP社　刊

「アジャイルソフトウェア

　マネジメント」

宗　雅彦、前田　卓雄　訳

日刊工業新聞社　刊

「パターンによる

ソフトウェア構成管理」

宗　雅彦訳

翔泳社　刊

[System Testing with an

Attitude(和訳)] 宗雅彦監訳

翔泳社

刊

2007年秋予定

「要求開発と要求管理」

Karl Wiegers著

宗　雅彦

監修

　マイクロソフトプレス　刊

「要求開発ワークショップ

の進め方」

Ellen Gottesdiener著

三島邦彦、前田卓雄、

宗雅彦監訳

日経BP社刊



禁無断転用

アジェンダ

●いまどきのソフトウェア開発はどうなっているのか

●ソフトウェア開発プロセスの危険な落とし穴

●ソフトウェア構成管理とは

●パターンによるソフトウェア構成管理

●ソフトウェア構成管理ツール



禁無断転用

いまどきのソフトウェア開発はどうなっているのか



禁無断転用

いまどきの開発といえば・・・

出典：

Ventro社“Offshore 2005 Research: Preliminary Findings and Conclusions”

●欧米5,231社のオフショア開発サービス顧客企業の現状調査から

オフショア開発サービス顧客企業の第一の期待がコスト低減にあることに対して

0%

5%

10%

15%

20%

25%

30%

増加低減なし 0-20%低減 21-40%低減 41-60%低減 61%以上低減

46%

9%

45%顧客側プロセス改善

従業員コスト

ベンダー実行

コスト低

減

の理

由

は？

50%以上は

顧客側努力

による

コスト低減

オフショア開発利用によるコスト低減実績

53%はコスト増加

あるいはコスト低減

効果なし

オフショア開発利用によるコスト低減理由



禁無断転用

オフショア開発利用の失敗要因

28%

10%

21%9%

15%

14%3%

顧客側の準備と運用の不備

顧客側のモラルと支援不足

顧客・ベンダーの計画不備

ミスコミュニケーション・文化

ベンダーの能力不足

そもそも誤っていた

その他

オフショア開発利用における失敗原因

●38%は顧客側のなんらかの不備によるもの

●15%はベンダー側の能力不足によるもの

●30%は顧客・ベンダーの双方に関わる問題によるもの

※オフショア開発という選択がそもそも誤っていたとの評価が15%

顧客側の準備と

運用の不備とは？

顧客・ベンダーの

計画不備とは？



禁無断転用

欧米と日本の現状を比較してみる

それでは日本のオフショア開発の現状はどうか！？



禁無断転用

ソフトウェア開発プロセスの危険な落とし穴



禁無断転用

落とし穴①：コミュニケーションの機能不全問題

ヒトは“考え”を

自然言語、絵、

図、ジェスチャ

などを使って

伝えようとする

それを受取った

ヒトは、“考え”を

再構築しようと

する。

再構築の失敗=ミスコミュニケーション

伝えようとしている

“考え”が複雑

文化、商習慣、

ドメイン知識の

ギャップ

伝達手段の

ギャップ

オフショア開発はコミュニケーションの機能不全が起こる条件がすべて揃っている

顧客要求開発・高位レベル設計実装テスト要求は複雑で大規模

言葉の違い

文化・商習慣の違い

ドメイン知識不足

モデリング手法の違い

再構築の失敗要因



禁無断転用

開発プロセスはコミュニケーションプロセス(講演資料追加ページ)

要求定義高位レベル

設計詳細設計

コーディング単体テスト

統合テスト

システムテスト

要求ソフトウェアプロダクト

受け入れテスト

要求

仕様書

高位レベル

設計書

詳細

設計書

ソース

コード

RTF RTF RTF RTF

受入

テスト

仕様書

システム

テスト

仕様書

統合

テスト

仕様書

単体

テスト

仕様書

RTF：

Running Tested Feature (テストされた実行可能なソフトウェア)

要求仕様書の１項目が変更されたら・・・

テストをしてバグが検出され、その根本原因が

上流の仕様書にあるとしたならば・・・

変更とその変更がもたらす影響にかんする情報を

どのようにしたら的確にコミュニケーション可能か？



禁無断転用

落とし穴②：共有データ問題

共有コンポーネント

修正だ！動かない!! 原因は!?

プライベートな

ワークスペースを

持つことで解決

共有コンポーネント共有コンポーネント

BUT

複数バージョンのコンポーネントを

どうメンテナンスするのか?



禁無断転用

落とし穴③：複数コンポーネントのメンテナンス問題

共有コンポーネント共有コンポーネント

問題をなんら解決しない!!

共有リソースライブラリ


共有リソース

ライブラリを利用

することで解決

だれもが自由に修正できれば変更を通知する仕組みがなければBUT



禁無断転用

落とし穴④：同時アップデートの問題


バージョンA

共有リソースライブラリ


だれもが自由に修正できれば

変更を通知する仕組みがなければ


バージョンB

同じ問題を解決すれば・・・

同じモジュールの異なる問題を

解決すれば・・・

管理されておらずコントロールされていない共有リソースライブラリは

問題をなんら解決しない

BUT



禁無断転用

【再】いまどきのソフトウェア開発

これらの問題はプロジェクト規模が増加するほど致命的になる

顧客開発組織-A 開発組織-B

運用保守プロセス

要求

仕様書高位レベル

設計書

詳細

設計書ソース

コード

テスト

仕様書テスト

仕様書テスト

仕様書

●影響する成果物をコントロールするために、必要となるタスクに関して、関係者全員と

どのようにコミュニケーションをとりますか?

●プロジェクトリーダとして、なにが起きているかを、すべてのチームメンバがお互いに

コミュニケーションをとっていると確信を持つことができますか?

●作業が重複しておらず、メンバーの作業がお互いに成果物を壊していないことを

どうやって確信することができますか?

要求の追加・変更バグ対応の修正

成果物になんらかの変更の必要が生じたときにあなたは・・・・・？

オフショア開発プロジェクトに限って起きる問題ではない



禁無断転用

ソフトウェア構成管理とは



禁無断転用

構成管理のルーツ

●構成管理は製造業

– 米国軍需産業

– で生まれた。

●製品の規模が増大するにつれて、製品の複雑さが増大し、ひとりのヒトが

　　ひとつの設計/製品情報をコントロールすることが困難になった。

●とりわけ設計変更情報のコントロールとコミュニケーションに重大な問題を

生じるようになった。

●1962年のUS Air Force　AFSCM 371-1 が最初の構成管理標準である。

その後、MIL/DoD標準として各種標準が発行されている。

●ソフトウェアの規模の増大と、それに伴う複雑性の増加から、ソフトウェア

構成管理の重要性が認識され、DoDおよびIEEE, ANSI, ISOを含む

国際組織から、ソフトウェア構成管理(SCM)標準が発行されるに至った。



禁無断転用

ソフトウェア構成管理とは

ある時点におけるシステムの構成を識別し、この構成の変更をシステマティックに

コントロールすることで、システムの全ライフサイクルを通して、構成の統合性

(完全性)とトレーサビリティをメンテナンスするための、規範(discipline)である。Bersoff, Henderson, Siegel”Software Configuration Management”

ソフトウェア構成管理は以下のことを要求する：

●ソフトウェアシステムの構成アイテム(コンポーネント)を識別し、その機能的/ 　

物理的特性を文書化すること。

●いったんこれがなされれば、構成アイテムのどのような変更も、適切なチャネルを

とおしてのみ行うことができる。

●変更管理の全プロセスは文書化され、変更内容は関係者全員に通知される。

●システムが要求仕様に適合していることをチェック/検証するメカニズムが

なければならない。

効果的なソフトウェア構成管理(システム)とは、単に、誰がコードやドキュメントに

変更を行ったかを記録するツールを持つことではない。それらを超えて、関係者

全てがソフトウェアの変更に関与することを保証するために、よく考えられた命名

規約、ポリシー、手続きを持つことである。　　　　　　　　　Davis ”Prinsciples of Software Development”



禁無断転用

パターンによるソフトウェア構成管理



禁無断転用

参考文献

「パターンによるソフトウェア構成管理」

スティーブ・P・バーチャック等

著

　宗　雅彦訳

翔泳社　刊

“著者はしがき”より

・・・構成管理に携わる人々はツールと制御に関心

があるという固定概念があります。彼らは保守的で

あり、遅いながらも予測可能な進捗を好みます。

・・・これらは極端な固定概念であり、私の経験では

優れたソフトウェア技術者と優れたリリース/品質保

証/構成管理担当者は共通の目的を持っています。

・・・彼らは優れた品質のシステムを、余分な労力を

最小限に抑えた上で出荷することに注力していま

す。

・・・この本では（パターンを用いて)ソフトウェア構

成管理の実例をいくつか説明します。

・・・比較的小規模なチームでソフトウェア開発に携

わり、ソフトウェア構成管理を効果的に実施できて

いないと考える方にとって、ことさら興味深いもの

になるでしょう。



禁無断転用

パターン超入門

●パターンとは：

　

あるコンテキストにおける問題に対する解。

しかし単なる“解”を超えた良い“解”。

　“パターンとは私たちの環境でいく度となく繰り返し起きる問題を記述し、

それからその問題の中心となる解を、同じことを二度とせずに繰り返し

利用できるような方法で記述するようなものである。

　　“パターンには必然であるという側面があります。パターンは問題を解決

　　　します。しかしそれは”状況に応じて必要な“パターンなのです。”

“適切に表現されていれば、前提となるコンテキストの中で与えられた

問題を解決するすべての可能な解を含む不変の領域を、パターンは

　　与えるのです。”

Christopher Alexander

●あるパターンは他のパターンを補完する。

　個々のパターンは仮にあたりまえにみえても、それらのパターンの

組み合わせをどのように適用するかといった詳細は必ずしも

　　　あたりまえではない。

“それぞれのパターンは、コンテキスト間の関係、コンテキストにおいて

発生する力の体系、およびコンテキストの中で、それらの力が調和する

ような構成として定式化される”

　Christopher Alexander

参考文献におけるパターンの構造

●タイトル

●写真

●コンテキスト

●問題

●問題説明

●解

●詳細な解の説明

●検討課題



禁無断転用

ソフトウェア構成管理パターン言語

Mainline (4)

Third Parly Codeline(10)

Task Level Commit(11)

Unit Test (14)

Regression Test (15)

Codeline policy (12)

Private Workspace (6)

Active Development Line (5)

Integration Build (9)

Private System Build(8)

Repository (7)

Private Versions (16)

Release Line (17)

Task Branch (19)

Release-Prep Code Line(18)

Smoke Test (13)

コードライン

関連パターン

ワークスペース

関連パターン

開発者が仕事を

遂行するうえで

必要な成果物を

置いておく場所

ソフトウェアや他の

成果物の集まりが

時間に沿って変化

していく過程を

あらわしたもの



禁無断転用

ソフトウェア構成管理の一般的な作業(講演資料追加ページ)

●

Private Workspace(6)を作成

●

Private Workspace(6)をRepository(7)

　　もしくはコードラインから取得

●

変更作業およびTask Branch(19)を設定

●

ワークスペースをコードラインの最新の状態で更新

●

ワークスペースからコードラインに対して、変更の

Task Level Commit(11)を実行

●

新しいコードラインを作成する

　　(Mainline(4)用、Active Development Line（5)用、Release Line(17)用、

Release-Prep Code Line(18)用、Third Party Codeline(10)用)

●

Named Stable Base(20)のひとつにラベルを付けるか

　　バージョンを付けるかして区別する



禁無断転用

パターンとそれが解決する問題(部分)(講演資料追加ページ)

パターン名称番号解決する問題

Ma inline 4 ブランチ作成とそのマージにかかる作業を減らすためにどのようにコードラインを管理すべきか

Act iv e De v e lo pm e nt L ine 5 急速に発展するコードラインをどうやって使える状態に安定させるか

P riv a t e Wo rkspa ce 6 常に変更されているコードラインをどのように最新の状態に保ち、矛盾が生じないように変更を加えるか

Re po sit o ry 7 適切なコンポーネントの適切なバージョンを取得して新しいワークスペースをつくるにはどうしたらよいか

Third P a rt y Co de Line 10 自分自身のコードのバージョンとサードパーティのコードのバージョンを調整するためにはどうしたらよいか

Ta sk Le v e l Co m m it 11 バージョン管理システムへの登録の間隔とその間の変更量のバランスをどうとればよいか

Re le a se Line 17 作業中のコードに影響を与えることなく、リリース用のバージョンを保守するにはどうしたらよいか

Re le a se -P re p Co de Line 18 差し迫ったリリース用のコードラインを安定させ、同時に作業中のコードラインで新しい作業を進めるにはどのようにすればよいか

Ta sk Bra nch 19 コードラインの一貫性や統合性を損ねることなく、コードラインに対する複数の長期にわたる、互いに重複するような変更をチームが実施できるようにするにはどうしたらよいか

Na m ed St a ble Ba se 20 どのくらいの頻度で統合すべきか



禁無断転用

パターンによるSCM導入の道筋

(講演資料追加ページ)

●

解決しようとしている問題の全体像を明らかにする

●

パターンのコンテキストと問題説明のセクションを見回して、差し迫っている

問題の解決に使えそうなパターンと同様に、すでに使っているパターンを特定する

●

すでに適用しているパターンがわかったら、そのうちのひとつから始める。

Mainline開発を確立したいのであれば、Mainline(4)からはじめる。

●

コンテキストと検討課題のセクションを見回しながら、パターン言語が示す

パターンを適用する

●

以上の仮定を、パターン言語全体について完了するまで、繰り返し進めていく



禁無断転用

ソフトウェア構成管理ツール



禁無断転用

ソフトウェア構成管理ツールにまつわる誤解

●ソフトウェア構成管理ツールがすべてを解決する効果的なソフトウェア構成管理(システム)とは、単に、誰がコードやドキュメントに変更を行ったかを

　　記録するツールを持つことではない。それらを超えて、関係者全てがソフトウェアの変更に関与する

ことを保証するために、よく考えられた命名規約、ポリシー、手続きを持つことである。

　　　　　　　　　Davis ”Prinsciples of Software Development”

　　

混沌を自動化すれば混沌が加速する

●ひとつのソフトウェア構成管理ツールがすべてに適合する

商用、オープンソースのソフトウェア構成管理ツールが流通しており、これらはいずれも

その機能、価格、技術サポート、カスタマイズ容易性、スケーラビリティにおいて異なる。

　　ソフトウェア構成管理に対する組織の要求はそれぞれ異なる。この要求の分析を行う

　　ことなしに、ソフトウェア構成管理ツールの購入（導入）に走ることは極めて危険である。

　　ソフトウェア構成管理およびソフトウェア構成管理ツールの導入に成功するためには、

組織の文化、採用しているソフトウェア構成管理のプラクティス(パターン)、手続きと、

　　

ソフトウェア構成管理ツールが適合していることの確認が先決である。



禁無断転用

SCMパターンとツールサポート(例)(講演資料追加ページ)

SCMコンセプト名 CVSコンセプト名コメント

リポジトリリポジトリ CVSROOTともいう開発用ワークスペース作業ディレクトリ

作業コピーcvs checkout -Rcvs update -R(cf. cvs export)

コードラインブランチ作成 cvs tag -b変更作業 N/Aワークスペース更新更新 cvs updateタスクレベルコミットコミット cvs commitタスクブランチブランチ cvs tag -bラベルタグ rtagサードパーティコードライン

ベンダブランチ cvs import -b

ご参考：その他ツール情報は、書籍“パターンによるソフトウェア構成管理:付録B”および

http://www.cyx.co.jp/scmをご参照ください。



禁無断転用

リソースURL

ソフトウェア構成管理パターン、ソフトウェア構成管理ツールなど、ソフトウェア構成管理に関するリソースを下記URLで提供しています。

http://www.cyx.co.jp/scm/



禁無断転用

ご清聴に感謝します！

　

コンサルティング・トレーニングのご案内はホームページまたは下記連絡先まで。

株式会社サイクス

〒104-0032 東京都中央区八丁堀2-11-8 平澤ビル2F PHONE: 03-3537-7121 FAX: 03-3537-7156 URL: www.cyx.co.jp Email: [email protected]




禁無断転用

著作権の取り扱いについて

著作権の取り扱い

本書の著作権は特に記述がないかぎり、株式会社サイクス

(Copyright ©2007, Cyx Inc. All Rights Reserved)が保有しています。

本書の無断修正・転用は、株式会社サイクスの書面による許諾がある場合を除き、著作権法で禁じられています。


●本書の配布は自由です。

●内容の無断修正および無断転用は著作権法で禁じられています。

株式会社サイクス

〒104-0032 東京都中央区八丁堀2-11-8 平澤ビル2F PHONE: 03-3537-7121 FAX: 03-3537-7156 URL: www.cyx.co.jp Email: [email protected]

スライド 0 - cyx.co.jp · 「体系的ソフトウェアテスト入門」 rick craig 他 著...

Documents

スライド 0 - cyx.co.jp · 「体系的ソフトウェアテスト入門」 rick craig 他著...