SQuBOK読破会活動紹介とSQuBOKにおける派生開発

Editor's Notes

1. SQuBOK読破会に所属しております、藤沢ともうします。 コミュニティショートセッションとして、SQuBOK読破会というコミュニティの紹介と SQuBOKにおける派生開発に関する記述について発表いたします。
2. 私は、日々関東のSIerのQAとして設計書のレビューやシステムテスト工程のテスト業務などにあたっています。 まだ入社３年目で勉強を本格的に始めて間もなく、ひとまずソフトウェア品質にかかわる全般的な知識を得たいという目的で 池田さんとりまとめのSQuBOK読破会に参加することとしました。 今回はその池田さんとのご縁で発表の機会をいただきました。また、自分自身派生開発について勉強したかったという思いもあります。 現在の業務での派生開発との関わりとしては、製品バージョンアップにともなうテストなどで テストケースの流用と追加などの派生開発特有の問題を感じています。
3. このセッションでははじめに紹介した通り、この２つについて発表します。
4. まずSQuBOK読破会についてです。 これは文字通り、SQuBOK第2版を最後まで読破する会です。 SQuBOKというのはソフトウェア品質に関する知識がまとめられた、いわば宝箱のような本なのですが、 いかんせんページ数も300ページ以上あり一人で読み切るのは大変です。
5. そこで、一人ではなくみんなで読んでいこうじゃないかということで発足したのがこの勉強会です。 読書ではなく読破としているのもポイントです。
6. こちらが定例会のメニューです。 まずはじめに、各々が今月読んだ書籍の紹介をします。 自分では読まないような本について感想を聞くのは知識の幅を広げるのにとても良いです。 本編の読破は、輪読形式で進めていきます。また、輪読にあたり SQuBOKに参考文献として追加すべきものはあるか、また追加すべき内容はあるかといった観点で議論します。 ここでの議論のアウトプットは、毎回担当を決めて記録しています。 終わったら懇親会です。 ここではSQuBOKの内容に限らず、様々な情報交換の場となっています。
7. 本編の議論のアウトプットは、SQuBOK策定部会にフィードバックもしています。
8. 実際の雰囲気です。楽しく真面目に勉強しています。
9. これまでの活動の状況と、今後やりたいことについてです。 2015年1月から月１回のペースで進めていて、年内には読破完了の予定です！ また、東洋大学野中誠先生をゲストとしてお迎えして合宿を行ったりもしています。 今後やりたいこととして、これらのことをやってみようかと話しているところです。
10. まとめです。 SQuBOK読破会の趣旨は、一人で読み切るのが難しいSQuBOKをみんなで読破しようというものです。 基本メニューはこの３つで、今後やりたいこともいま色々と検討しているところです。 今後も精力的に取り組んでいきます。
11. ここからはSQuBOKにおける派生開発に関する記述についてまとめたものを発表します。
12. まずはSQuBOKの読み方について簡単に説明します。 まずは普通に各項目を読んでいく読み方です。この読み方だと、各項目について概要レベルの知識を得ることができます。 次に、参考文献をたどっていく読み方です。これは実際はSQuBOK自体を読んでいるわけではないのですが、これもSQuBOKの使い方のひとつです。 SQuBOKはあらゆる品質関連の技術へのポインタ集であるためです。 各項目の終わりに書いてある関連知識領域から、関連トピックスをたどっていく読み方もあります。
13. SQuBOKの樹形図を示します。
14. 赤くしている箇所は、藤沢の考える派生開発に関連するトピックスです。
15. まず、XDDPとUSDMに関する記述があります。この発表では、XDDPを主に扱います。というのも、USDMについてはすでに清水さんが解説されているからです。
16. その他にも、いくつか関連トピックスがあります。モデル化、
17. プロダクトライン開発、
18. 変更管理、
19. 最後に、保守の技法についてです。 これらの関連トピックスについても解説をします。
20. 最後に、保守の技法についてです。 これらの関連トピックスについても解説をします。
21. まずはXDDPについて、概要レベルの内容を紹介します。 SQuBOKにおける位置づけとしては、プロセスモデルというトピックの中のひとつとしてとらえられています。 XDDPの実施目的は、「ミスや漏れによる手戻りを防止して短納期を達成し、プロジェクトの混乱を未然に防ぐ」ことになります。
22. XDDPを本当に簡単に説明するならば、「変更要求を変更と機能追加に分類し、それぞれ異なる手順で開発する」とする開発アプローチであるといえます。 機能追加については通常の開発方法で開発しますが、 変更の場合は大きく手順が異なります。 まず仕様の抽出を行い、次に変更要求仕様書、トレーサビリティマトリクスを作成し、 マトリクスの各交点に対して変更設計書を記述します。 その後、一斉にソースコードの修正を行います。
23. SQuBOKには概要レベルでしか記載がないため、参考文献としてあげられているXDDP本を読んで、内容を補足します。 XDDP本には、XDDPの各成果物についてより詳細な説明があります。
24. まず変更要求仕様書についてです。 これは変更内容について特定し、変更箇所に関する情報を整理するための文書です。 これを作成する目的は、無駄な変更を防ぐこと、ソースコードを読んで思い出す時間を減らすこと、レビューや確認を容易にすることです。
25. 次に、変更設計書についてです。 これは、関数など具体的な変更内容を文章で記述したものです。 どの関数の、どの部分を、どのように変更するか具体的に記述します。 ここで注意するのは、変更点のみを記述するという点です。
26. トレーサビリティマトリクスは、変更要求仕様書と変更設計書を関連付ける文書です。 これを作成することにより、「ここに変更が入るのなら、ここも似た機能だし変更が必要なのでは？」といった 連想を働かせます。
27. 以上がXDDPに関する解説です。USDMについては今回は割愛します。 ただ、他にも派生開発に関連すると思うトピックスがありますので紹介します。
28. モデル化というトピックスが派生開発に関連すると思います。 モデル化によって、開発対象の構造や振る舞いにかかわる複雑さを軽減し、保守や管理を容易にすることができます。 派生開発におけるUSDMはモデルのひとつといえるため、他にどのようなモデルがあるのか知っておくことは重要だと考えます。
29. 次に、プロダクトライン開発です。 これは多品種製品向けのソフトウェア開発技法です。 複数製品における共通のコア資産を構築し、そのコア資産から各製品を導出します。 派生開発との関連としては、要求可変性分析と関係するため、要求仕様の記述法であるUSDMとも関係してくると思います。
30. 変更管理は構成管理下の構成要素を変更するためのアクティビティです。 変更要求を深く吟味して、確実にシステムに反映します。 変更管理はすなわち変更要求の管理ですから、派生開発ともかかわりがあります。
31. 最後に、保守の技法についてです。 これは既存のソフトウェアを正しく解析し、効果的かつ効率的に変更・拡張、再利用できるようにする技法のことです。 派生開発の前提として、既存のソフトウェアが存在します。したがって、これはまさに派生開発において必要になる技法といえます。
32. SQuBOKにおける派生開発に関する記述についてまとめました。 SQuBOKでは、XDDPやUSDMをはじめ、それに関連して保守や変更管理に関するトピックスも扱われています。 XDDPでは、機能追加と変更で異なるプロセスをとります。これは、部分理解という派生開発における課題をクリアするためにプロセスを最適化した結果であるといえます。 また、XDDPやUSDM以外の関連トピックスについても合わせて学習することで理解が深まるでしょう。
33. おわりに、私からメッセージです。 SQuBOKは、品質改善のスタート、いわば起爆剤になると思っています。 はじめに、SQuBOKを読み
34. 興味のある分野について、理解を深めていきます。
35. そのあと、得られた知識をもとに実践します。
36. すると、きっとさらに勉強したい分野が見つかります。
37. そしたらまた、SQuBOKを読むのです。これはサイクルになって循環して、SQuBOKを起点にしてソフトウェア品質を 改善することができるようになるはずです。 あまりSQuBOKなどBOKといわれるものにみなさんは馴染みがないかもしれません。しかし、私は読破会を通して認識が変わりました。 SQuBOKにはあらゆる知恵がつまっています。もちろん、ただ読むだけでは飽きてしまうかもしれませんが、 興味のある分野だけでも読んでみて、それをきっかけに何かを知ることができたら、何か行動をひとつでも変えることができたら、それは大きな価値となると思います。 みなさんもSQuBOKから、品質改善の一歩を踏み出してみてはいかがでしょうか。 以上で発表を終わります。ありがとうございました。
38. 説明する時間なし。飛ばす
39. 説明する時間なし。飛ばす
40. 時間なければ飛ばす
41. 説明する時間なし。飛ばす