ソフトのプロダクト品質を良くするには
プロダクト品質を良くするには何が必要でしょうか
ソフトウエアの品質と言った場合には普通はプロダクト品質を指します。ソフトウエア品質、つまりはプロダクト品質を良くするにはプロダクト品質そのものを良くするというアプローチと、プロセス品質をよくするというアプローチがあります。この分類ではプロダクト品質の元になっているソースコード品質、実行コード品質、設計品質、テスト品質 について品質を良くするためには何をすれば良いのかを紹介していきます。
プロダクト品質とプロセス品質
ソフトウエアの品質を保証したり評価したりする場面で、グータラ親父はプロダクト品質とプロセス品質のどちらの品質に該当するかを常に意識していました。ソフトウエアの品質には様々な側面があるので、何か大まかな概念を元に整理して考えていかないと、判りにくかったからです。
プロダクト品質とプロセス品質という考え方は、あまり広く使われているわけでもありませんが、ソフトウエアの品質を整理する上でなかなか使い勝手のよい概念です。簡単に言えば、プロダクト品質とはソフトウエアその物の品質で、プロセス品質とはそのソフトウエアを開発するプロセスの品質です。
ですので、普通にソフトウエアの品質という場合には、プロダクト品質を指します。一方でプロダクト品質の良し悪しを判断したり、プロダクト品質が良いソフトウエアを開発しようとした場合には、プロセス品質の良し悪しも関わってきます。そもそもプロダクト品質ってどんな物なのか、グータラ親父なりに理解している事を紹介してみますので、参考にご覧ください。プロセス品質については、こちらの記事を参照して下さい。
プロダクト品質ってなにでしょう？
プロダクト品質は、ソフトウエアその物の品質と言いましたが、もう少し具体的に言うと、ソフトウエア開発の成果物の品質と言えます。ソフトウエア開発の成果物というと色々とあるのですが、大まかには以下のような物でしょう。
- 設計書（要求仕様書とか基本設計書とかシステム設計書 等）
- ソースコード（計算機言語で書かれたソースコード）
- 実行コード（コンパイルやビルドで生成された実行イメージ）
- テスト結果（実行コードをテストした結果の記録）
もう少し狭い意味でのプロダクト品質だと、３つ目の実行コードの品質と考える事もできるのですが、プロダクトをソフトウエア開発の成果物と考えると、設計書やソースコードという中間成果物やテスト結果のような成果物も、ソフトウエア開発の活動で作成される成果物です。そしてこれらの成果物もまた、成果物としての品質を持っているので、それらも含めてプロダクト品質と呼んでも良いと思います。というか、グータラ親父はそのようにプロダクト品質を捉えていました。 とはいえ、これだけでは今一つではプロダクト品質がどんな物なのか判りにくいと思います、それぞれのプロダクト品質の測り方の例を使って、もう少し具体的にプロダクト品質を見てみましょう。
実行コードの品質
まずは、一番判り易い実行コードの品質です。実行コードの品質なので、大前提としてその実行コードを実行した時の何かを測れば品質が判ります。 で、何かを測るとなると一番測り易いのはやはりテストをしたその結果ですね。テストをした結果たくさんのバグが見つかるようなら、その実行コードの品質は良く無いと言っても良いでしょう。
もちろん、テストの中には機能を確認するテストや性能を確認するテストや異常状態からの回復性を確認するテストなど、色々のなテストがあります。それらの色々な種類のテストを実施した結果として、見つかったバグの数が少ないほどその実行コードの品質は良いと言えます。世間一般でソフトウエアの品質として求められるのは、この実行コードの品質で、品質の良し悪しはバグが多いか少ないかで語られる事が多いです。
もちろん、使い勝手とか判り易さとかもソフトウエアの品質として重要ですが、これらもそのような項目を評価するテストを行えば良し悪しは判ります。そのような面も含めて、実行コードの品質はテストの結果見つかるバグで判断ができると考えても良いと思います。
ソースコードの品質
実行コードの品質はテストで見つかるバグで測りました。 では、実行コードの元になるソースコードの品質は何で測りましょうか？ グータラ親父はソースコードの品質は主にコードレビューの指摘の件数や内容を見て推定していました。コードレビューなら、ソースコードの実行品質と保守品質の両方の面で、コードの問題点が抽出されるからです。
実行品質と保守品質というのは、ソースコードの品質を ①コードを実行した時の品質に影響を与える実行品質と、②今後発生するソースコードの保守や再利用時の品質に影響を与える保守品質 の２種類分けたものです。これまたグータラ親父が勝手に名付けている品質ですが、ソースコードの品質を考える時に割と便利な考え方です。
前者の実行品質は実行コードの品質を測るテストでも測れるのですが、後者の保守品質はテストでは測れません。しかし、ソースコードが読んで判り易いかとか、ソースコードの移植性が良いかなどの品質特性は、ソフトウエアライフサイクルを通してソフトウエアの価値を考えた場合には、実行品質と同等かそれ以上の重要な品質です。これを保守品質と呼んでいました。
そして一般的にソースコードレビューでは、意識するかしないかに関係なく実行品質と共に保守品質についてもチェックしている事が殆どです。経験を積んだソフトウエア技術者は、保守品質の重要性をよく理解しているので、レビューの指摘の半分程度は保守品質についての指摘になる事が多いです。 そのような点も考慮にいれて、ソースコードレビューでの指摘の件数と内容を元に、グータラ親父はソースコードの品質を推定していました。
設計書の品質
ソースコードの品質をソースコードレビューの指摘の件数や内容で判断するならば、設計書の品質は設計書のレビューでの指摘の件数や内容で判断するのが良いですね。ソフトウエアの設計書は、プロジェクトや組織によって名称や定義や記述範囲が様々なのですが、どのような場合でも設計担当者が作成した設計書に対して、デザインレビューを行って内容の確認や間違いを修正していって、完成版の設計書を作っていきます。
デザインレビューでは、設計書に書かれた設計内容に漏れ・抜けが無いか、必要な機能や性能は組み込まれているか、必要な信頼性・堅牢性・異常回復性・保守性などの非機能要件も設計されているか、等の観点で多角的に設計内容が確認されていきます。そのデザインレビューで指摘の件数や内容は、設計の品質を測るのにちょうど良い情報を提供してくれます。
もちろん、設計書の品質には日本語として表記に揺れは無いかとか、関連する資料へのリンクは明記されているかとか、設計書の表示上の品質もありますが、これらも含めて問題があればデザインレビューで指摘されているでしょうから、デザインレビューの指摘の件数や内容を見ていれば、設計書のプロダクト品質を推定できると思います。
テストの品質
プロダクト品質の最後がテストの品質ですが、テストの品質は２つに分けて考える必要があります。一つ目は、テスト設計の品質で、２つ目がテスト結果の品質です。まず最初のテスト設計の品質ですが、簡単に言うとテストの量とテストの質が必要十分と言えだけのテスト項目が設計されているか、という観点での品質です。単に機能が動作している事を確認する正常系のテスト項目だけなのか、異常回復機能を確認する異常系のテスト項目もあるのか、仕様上の最大構成でも動作する事を確認する大規模テストの項目があるのか、等テストの目的に沿ったテストの項目とテストの件数が設計されているかどうか、というのがテスト設計の良し悪しを判断する基準になります。
一方で、テスト設計に従って実際にテストを実施していくと、様々な事が起こります。テストの工程計画通りにテストが進むこともあれば大幅に工程遅れが出る事もあります。テストをするとバグが大量に見つかってテストが滞る事もあれば、殆どバグが見つからないで肩透かしを食らう事もあります。これらの、テストの実施結果がどんな状況になっているのか、言い換えればテストで順調にバグを見つけて、実行コードの品質を良くするデバッグ処理が適切に実行されるトリガーとしてテストが効果を出しているか、という事がテスト結果の品質になります。
プロダクト品質の概要は判りましたでしょうか？
グータラ親父の考えるプロダクト品質について概要を紹介してきました。世間一般でいう所のプロダクト品質とは違いがあるかも知れませんが、まあこんな考え方もあるな～程度で読んでいただければと思っています。
もう少し時間が取れましたら、グータラ親父の考えるプロダクト品質について、具体的な内容を別の記事で書き足していこうと思っています。記事が書けたら、この下に具体的な記事のリストが見えるようになりますので、興味のあるかたは参照ください。