mhlyc -presentation

僕が書きたいことをひたすらに書き綴る、自己満足のブログです。

SQuBOKアドベントカレンダー -ソフトウェア品質保証の考え方と実際-

遅れましたがSQuBOKアドベントカレンダーの17日目です。

www.adventar.org

 

 

「SQuBOK V2」と「ソフトウェア品質保証の考え方と実際」

「ソフトウェア品質保証の考え方と実際」という神の書があります。

品質保証に関わるエンジニアであれば必読の書といえるでしょう。(私も最近読みましたが。)  
SQuBOKでは以下のトピックスにて参照されています。
  • 2.4 KA: 検査のマネジメント(p.112〜)
  • 2.11.2 S-KA: バージョン管理(p.145〜)
  • 2.17 KA: レビューのマネジメント(p.164〜)
  • 2.20 KA: リリース可否判定(p.180〜)
この記事では、「ソフトウェア品質保証の考え方と実際」両方を読みつつ、SQuBOKで参照されている内容について自分の理解を書いていこうと思います。
 

2.4 KA: 検査のマネジメント(p.112〜)[保田 1995, p.37]

ここでは、ソフトウェアの検査とは何か、検査部門の役割、主な活動はどのようなものかについて述べられています。SQuBOKに載っているのは概要レベルの内容ですが、保田氏の著書にはさらに詳細な内容が記載されています。

検査を行うにあたり設計製造部門から独立した組織とすることにも触れられています。これは後述する製品の合否判定をより公正にするためです。

また、検査組織を成功させるためのポイントも書かれています。非常に良い内容なのでぜひ読んでみていただきたいです。抜粋すると、「品質第一主義」の企業理念、経営幹部の品質意識、検査組織の出荷停止権限、検査組織の品質責任、開発責任者の意識が重要であると述べられています。

このあたりは、特に日立の品質保証という文化に基づいて書かれている部分も多いように思います。全部とはいかないかもしれませんが、必要そうな要素は取り入れていくとよいのではと思います。

 

2.11.2 S-KA: バージョン管理(p.145〜)[保田 1995, p.283]

これも、保田氏の著書を参照するとより詳しい知識を得られます。

ソフトウェアの変更には、外部要因によるものと内部要因による変更の二種類があり、それぞれの変更が与える信頼性や納期への影響は異なると述べられています。

また、構成・変更管理の基本的な概念についても用語ベースからまとめられているので「構成管理って何?」と思っている方は読んでみると理解が進むと思います。

 

2.17 KA: レビューのマネジメント(p.164〜)[保田 1995, p.72]

SQuBOKではレビューの計画、実施、記録、実施結果の評価で考慮すべき点について挙げられています。保田氏の著書ではより詳細な、レビューの目的やレビューを成功させるポイント、レビュー対象に応じたチェック観点についても述べられています。(当書籍の中では、レビューではなくデザインレビュー、またはDRと表記されています。)

レビューの目的

まずレビューの目的です。成果物の不良摘出、品質向上はもちろん、目的はそれだけではありません。レビューの結果を設計技術や開発プロセスの改善に役立てたり、副次的な効果としてメンバの仕様理解、育成などもあります。

 

レビュー成功のポイント

レビュー成功のポイントには以下のものがあります。(成功というか、むしろ「レビューをしても役に立たない」という羽目にならないようにするための留意点だそうです)

  •  工程表に、レビュー工程を明示すること
  • タイムリーに明確な仕様書が作成されること
  • 適切なメンバーの参加
  • レビュー用チェックリストの整備と活用
  • 過去の不良事例の整備・編集と検索
  • レビューの事前準備が必要

確かに言われてみると当たり前のことばかりです。しかし、特に納期が迫っていたり余裕がなかったりするプロジェクトでは、残念ながらないがしろにされていることもあります。効果が出ないレビューをしても意味がありませんから、必要な投資と思ってしっかり準備、計画した上でレビューを行うべきでしょう。

 

レビュー対象に応じたチェック観点

内部ドキュメント検査、外部ドキュメント検査に分けて記述されています。ここで内部ドキュメントは機能仕様書などを指し、対して外部ドキュメントはマニュアルなどを指します。

 

内部ドキュメント検査で、特に外部仕様書(機能仕様書)をチェックする場合、以下の観点があります。

  1. 合目的性あるいは完全性(要求仕様を反映した外部仕様になっているか)
  2. 無矛盾性
  3. 信頼性
  4. 使用性
  5. 効率性
  6. その他の品質特性(標準適合性、セキュリティ、接続性、互換性など)

 

内部仕様書(設計仕様書)の場合は以下のようになります。

  1. 追跡可能性あるいは完全性(外部仕様書または上位の内部仕様書で定義された内容が実現されているか)
  2. 無矛盾性
  3. 一貫性
  4. 信頼性関連特性(誤った操作を行ったり、ソフトウェア内部で異常が発生したりしてもデータやプログラムが破壊されないこと)
  5. 保守性関連特性(変更性、拡張性、解析性、モジュール性などの高さ)
  6. 効率性関連特性
  7. 移植性関連特性

 

外部ドキュメント、特にマニュアルのチェックを行う場合は以下のようになります。

  1. 理解性(ソフトウェアの概念や機能が理解しやすいこと)
  2. 習得性(ソフトウェアができるだけ早く使えるようになること)
  3. 運用性(必要な時に必要な項目を検索して、ソフトウェアを操作できること)

当然ですがレビュー対象によって書かれるべきこと、確認すべきことは異なります。しっかり事前に頭に入れた上でレビューに臨みたいですね。

 

2.20 KA: リリース可否判定(p.180〜)[保田 1995, p.107]

保田氏の著書にも、SQuBOKとほぼ同じ内容が書かれています。ただし内容がやや詳細まで書かれているので、合わせて参照するとよいでしょう。
リリース可否の判定は、出荷後の回収が困難であればあるほど後戻りができず、しっかりとプロセスを踏んだ慎重な判断が必要になります。また、不合格項目があった場合でも以下の項目を満たした場合に限り出荷を許可できる場合があることにも触れています。(特別採用)
  • 当該顧客に対し当面は実用上の支障がないこと
  • 不合格項目の解決時期が明確かつ妥当であること

ソフトウェア品質保証の考え方と実際,1995 p.108より引用

この特別採用をするかどうかの判断も、極めて慎重に行うべきであることは言うまでもありません。
 

 おわりに

いかがでしたでしょうか。本から抜粋した紹介しただけではありますが、参考になる箇所がありましたら幸いです。 
1章の「ソフトウェア品質保証の考え方」だけでも読む価値は大いにあるでしょう。ソフトウェア品質とは何を指すか、品質保証とは何か考察されており、自分の考えを深化させる助けになると思います。
また、ソフトウェア品質技術者の試験を受ける方にもオススメです。なぜなら、試験対策の副読本として当書籍が指定されており、試験対策としても重要な内容が書かれているからです。
 
他にも、QAの仕事に必要な、実践的な知識が数多く掲載されています。随時読み返しながら、日々の業務に役立てていきたいです。
 
<