派生開発 - ipa.go.jp · 「xddp」「usdm」「pfd」などの派生開発に有効な方法の研究と普及勉強会研究会／フォーラムカンファレンス地方部会

［ET2015IPA／SEC入門ゼミ講演資料］(C) copyright 派生開発推進協議会

派生開発XDDP-なぜ特化したプロセスが必要なのか？

ET2015　IPA/SEC 「SEC先端技術入門ゼミ」2015.11.18

1

1

派⽣生開発推進協議会(AFFORDD) 代表　清⽔水吉男

http://affordd.jp/

(C) copyright 派生開発推進協議会［ET2015IPA／SEC入門ゼミ講演資料］

自己紹介：清水吉男• 株式会社システムクリエイツ代表取締役 • 派生開発推進協議会代表

2

プロフィール• 1968年からソフトウェアの世界に入り、企業の業務システムやオンラインシステムの開発を手掛ける。

• 1977年に組み込みシステムの世界に転じ、POSシステムやインクジェットプリンターなどの多くの製品の開発に携わる。

• CMMとの出会いを機に、自ら考案した要求の仕様化技法(USDM)や派生開発向けの開発プロセス(XDDP)やプロセスの設計ツールとしてのPFDを提案。

• 1995年からプロセス改善のコンサルティングを開始。• 2010年に派生開発推進協議会を設立し、これらの普及活動へ。

XDDP

●「SEの仕事を楽しくしよう」（SRC）●「わがSE人生に一片の悔いなし」（技術評論社：新書）

USDM

(C) copyright 派生開発推進協議会［ET2015IPA／SEC入門ゼミ講演資料］ 3

派生開発推進協議会：AFFORDD■ 2010年２月に「派生開発推進協議会」（http://affordd.jp）を設立し、「XDDP」「USDM」「PFD」などの派生開発に有効な方法の研究と普及

勉強会

研究会／フォーラム

カンファレンス

地方部会

地方支援

❖ 年１回開催、一般公募❖ 現場での成果／研究会の成果を発表❖ 大阪での開催を模索

❖ XDDP，USDM, PFDを多くの人に知ってもらうために、首都圏以外に地方でもセミナーや勉強会を繰り返し開催する

❖ 現在11テーマの研究会が活動❖ XDDPやUSDMに対して、入門から効果的な活用方法について研究活動

❖ 研究会の成果をカンファレンス等で発表❖ 次の指導者の育成

❖ 各地方単位で会員がまとまって情報交換や技術交流をすすめる

❖ 地方を強くするという考えのもとに、地方行政の活動を支援する

次回＝2016年5月27日 (金)


第１部：混乱する派生開発• 多くの現場では、「派生開発」に振り回されている• いつまで派生開発で回すのかの方針もない• 不適切な技術でソースコードを劣化させている• 現場のSEは「新規開発」の勉強もできていない

4

多くのソフトウェアエンジニアは、ソフトウェア開発の楽しさを味わうことなく退場？


現状の開発でバグが多発していませんか？• その開発は

5

• 「保守マニュアル」から外れた変更が多くなっていませんか？

• 機能追加はどのように対応していますか？

•本当の新規開発ってほとんどないですよね。•ということは「新機能の追加」ですか？新規開発？

保守？

それとも派生開発？

•該当箇所を見つけ次第に変更していませんか？•変更に伴うデグレが起きていませんか？


派生開発の特徴• 機能追加と変更が繰り返される• 製品やシステムは競争している• 保守マニュアルが機能しないケースが多くなった• 開発期間は短い？• 新規開発よりずっと難しい（別の難しさ）• リリースの遅延は事業遂行に致命的

6

派生開発に必要な知識や技術を体系立って習得していない

それなのに・・・まともな設計技術を身につけていない人に任せている？

そして・・・


ソースコードしかないケース（いきなりの変更）

変更箇所を探して、見つけ次第にソースコードを変更していませんか？

7

要求仕様書／機能仕様書

ソースコードしかない！

その行為からどんな（性質の）バグがでるか考えたことはありますか？

最後の段階でコードレビューをしていませんか？

変更案件を１件取り出す

従来方法

変更箇所を探す

ソースコードを変更する

変更方法を考える

終了？

そのレビューでどれだけのバグが発見できましたか？


公式文書があるケース（新規開発崩し）• 要求仕様書から順に該当箇所を変更していませんか？

8

変更依頼変更依頼に

そって要求仕様書を更新する

要求仕様書

仕様が変更された箇所に該当する部分を更新する

設計書で変更された箇所に該当するソースコードを更新

する

各段階の設計書

変更

変更

変更

変更箇所

変更箇所

• 新規開発…– 関係者は内容を全て把握しており、途中の変更に対して影響する箇所も判断できる

ソースコード

• 派生開発…– 全体を知っている人はいませんよ！

– それって「要件管理」のつもり？– 状況は全く違いますよ！


変更箇所の調査の仕方もおかしくないですか？• 目的の変更箇所を求めてソースコードの中を探し回って「探検隊」になってしまう

9

– 参考： SQiP研究会第６分科会の報告• 『変更の影響範囲を特定するための「標準調査プロセス」の提案』

• 必要以上の工数を使って、後には歩き回った経路が残るだけ

• 処理構造や関数の役割は把握できたか？• 変更箇所は漏れたでしょう• 影響箇所も探せなかったでしょう

http://www.juse-sqip.jp/workshop/seika/2014/attachs/SQiP6-A.pdf


• 新規開発と派生開発とではバグの性質が異なる

10

種類求められていることバグのパターン

新規開発 •要求仕様に書かれていることを実現すること

•要求仕様で求められていることができていない

派生開発

機能追加

変更

•表示や処理内容、データの変更、追加、削除

•別システムで実現している機能の移植

•追加機能を受け入れる変更

•依頼された変更の解釈を間違えて変更した•依頼されたところだけでは足りなかった•関連箇所の変更箇所を漏らした•予想外のところで影響が出た

新規開発と派生開発（変更）では求められていることが違う？

新規開発と派生開発のバグの違い


バグの特徴は把握していますか？

11

変更漏れ

• 依頼された箇所は変更したが、別の画面で同じデータが使われていたことに気づかなかった

• 関数の仮引数で変化したデータ名を追わなかった• 依頼された変更だけでは目的を達成できなかった

変更間違い• 依頼の意味を勘違いしたことで変更方法を間違えた• 既存処理の理解を勘違いしたことで変更すべき箇所を間違えた

変更の影響

• 表示される項目が増えたことで「選択ボタン」が画面から消えてしまった

• データの種類によって処理が増えてしまい、返信までの時間がかかりすぎでタイムアウトになった

• 上記のバグは新規開発では出てきません• それとも「仕様漏れ」と分類しているのでしょうか？

• 原因プロセスはどこですか？


そのバグに対処できますか？

変更漏れ変更間違い影響の気づき漏れ

いずれのプロセスでも、これらのバグを防ぐことができなかった！

変更依頼変更依頼にそって要求仕様書を更新する

要求仕様書

仕様が変更された箇所に該当する部分を更新する

設計書で変更された箇所に該当するソースコードを更新

する

各段階の設計書

変更

変更

変更

変更箇所

変更箇所

ソースコード

新規開発崩し

変更案件を１件取り出す

従来方法

変更箇所を探す

ソースコードを変更する

変更方法を考える

終了？

いきなりの変更派生開発特有のバグ


要求とプロセスが違っていることに気づいていない？

① 変更箇所についての –「before / after」の情報と –「before」と「after」の「差」の情報を表現しているか？

13

バグが混入した仕組みも分かっているのに、そこで実行しているプロセスにそれに対応するプロセスや仕組みが含まれなければ、そのバグの発生を防止することはできない

②それについて検討し、レビューする手段と機会はありますか？

これがなければ変更の影響を防止できない

a

before

b

after

「差」


そのプロセスで「部分理解」を克服できるのか？

• 派生開発では「部分理解」の状態での作業が強いられる

14

「部分理解」の状態＝思い込みや勘違いが混入する状態

見つけ次第に（ソースコードを）変更する方法で「部分理解」をどうやって克服しますか？

•ソースコードの劣化•調査技術の不足　など

–このままの状態で変更すればバグになる可能性がある–担当者が「部分理解」の状況を克服できないなら、　組織（プロセス）で克服するしかない


そもそもソースコードを読む技量はあるのか？

適切な調査技術が「部分理解」を緩和し、変更箇所や影響箇所の把握に貢献する

15

理解するには「形」を変える必要がある

要求仕様書

設計書

ソースコード

設計書（部分）

要求仕様書を理解して設計書を作成する

コンピューターに実行させるために

実装する

ソースコードを理解して設計書の一部を作成するソースコードを読んで理解するに

は自分で要求仕様から設計（して実装）する以上の技量が必要

「設計する」行為が失われている中で、この技術も失っていないか？


第２部：XDDPの登場• バグがプロセスのミスマッチで発生する以上、派生開発のバグは既存のプロセスで改善できない

16

XDDPの出番！

– 機能追加と変更を異なるプロセスで対応する– それぞれ２種類の要求仕様書で対応する– 変更プロセスには「変更３点セット」の成果物を必須とする– 変更要求仕様書も変更設計書も全て「before」⇒「after」で表現する


「XDDP」の誕生に本質を見る

■ アメリカの顧客からの要求 (1978年)■ アメリカで開発された製品■ 初めてのドメイン■ 初めて見る言語、ソースコード

■ １週間で、新しいプロセスを設計してシミュレーション■ 機能追加と変更のプロセスに分けて品質と生産性を確保■ 変更箇所を「before / after」で記述し、先方にレビューを依頼

４０数項目の機能追加と変更を３ヶ月で！

「保守」のプロセスでは対応できないと判断

３ヶ月の納期を達成！


機能追加と変更とを異なるプロセスで対応させる

18

• 「XDDP」では機能追加と変更を異なるプロセスで対応する

追加機能要求仕様作成

統合テスト

追加機能分の設計

追加機能分の実装

追加機能分テスト

「部分理解」の制約を緩和する

参照

公式文書の更新

コードの変更

変更分のテスト

変更要求仕様書TMの作成

変更設計書の作成

変更３点セット① 変更要求仕様書② TM（Traceability Matrix)

③ 変更設計書

変更要求仕様書はすべての「変更」を扱う

差分データを使って「構成管理」で更新する


成果物カバー範囲記述内容レビュー機会

変更要求仕様書 What（Why）

何を変更するか？どのような振る舞いを変更するかなぜ、変更するのか？

○○

ＴＭ Where 変更する仕様がどこにあるか？ ○変更設計書 How 具体的な変更方法を記述する ○ ○

■ 効果的なレビューの機会を確保して、「部分理解」を緩和する■ ソースコードの変更作業と、公式文書のマージの両方に活用できる■ 今回の派生開発の変更記録として保存する

観点が違う

「変更３点セット」の成果物の意味■ 「XDDP」の変更プロセスでは３つの成果物を作成する（必須）

作られるタイミングも違う


「変更３点セット」が「部分理解」を緩和する• 「変更箇所」を「before / after」で表現することで「部分理解」の状態を緩和する

20

□ □ □ LIB20-03 インターネット貸出し操作時に、ステータスを「貸出し中」にセットしているのを「予約中」に変更する

□ □ □ LIB30-02 検索画面で表示される書籍情報の「版番号」の表示を削除する

• 「before / after」を表現することで担当者の理解が見える• さらに、ここから「影響箇所」に気づく機会を得る

before 担当者が該当箇所として現状（の仕様）を理解した状態

after 変更の依頼から、担当者が「before」の状態をこのように変更すれば良いと判断した状態

変更仕様


ソースコードの変更を可能な限り遅らせる

ソースコードをいきなり変更しないことで可能になる21

変更行数の見積り

ソースコードの変更に必要な工数を担保

変更仕様への展開で見積精度UP

ソースコードの変更をできるだけ遅らせる

余分なソースコードの変更作業を減らすことでコードの劣化を防ぐ

変更要求の記述

より適切な変更箇所を選択する機会を確保する


なぜ、派生開発に特化したプロセスが必要かおわかりいただけたでしょうか

22

短い時間でしたが・・・

それではディスカッションへ

Documents

派生開発 - ipa.go.jp · 「xddp」「usdm」「pfd」などの派生開発に有効な方法の研究と普及 勉強会 研究会／フォーラム カンファレンス 地方部会

派生開発 - ipa.go.jp · 「xddp」「usdm」「pfd」などの派生開発に有効な方法の研究と普及勉強会研究会／フォーラムカンファレンス地方部会