リリース判定は4つのリリース判定基準と4つのリリース判定の仕組みで実施する

2018年7月24日

ソフトはリリース判定で品質の悪いソフトの出荷を止めて品質を保証する

 ソフトの品質保証 をするために大切な事は、ソフトのリリース判定を正しく実施して品質の悪いソフトを出荷しない事です。そして、リリース判定を正しく実施するには、リリース判定基準リリース判定の仕組みの両方が具体的に決まっている必要があります。いろいろな方法がありますが、グータラ親父はリリース判定の4つの基準リリース判定の4つの仕組みを使ってきました。

リリース判定を正しく実施する事で品質の悪いソフトのリリースを止める事ができれば、市場では品質の良いソフトだけ使われるのでソフトの品質を保証できます。この「リリース判定」に分類した記事では、グータラ親父がリリース判定に使ってきたリリース判定の4つの基準と4つの仕組みについて紹介しています。

製品の市場状況や時代や技術の背景によって、ソフトに求められるの品質も変わるので、リリース判定には全ての場合に当てはまる判定基準や判定方法は在りませんし、グータラ親父のやってきた方法が最適な方法かどうかも判りません。それでも、この記事が実際にソフトのリリース判定をする人の参考になれば幸いです。

ソフト品質の判定基準は品質の悪いソフトを見つけるという視点で

良い品質のソフトをリリースするとは言いかえると、悪い品質のソフトをリリースしないという事です。単なる言葉遊びにも聞こえますが、良い品質のソフトウエアをリリースする手段は、何が揃えば品質が良いと言えるのかなど、考えないといけない事が一杯あるのでなかなか難しいのです。でも悪い品質のソフトウエアをリリースしない手段は、考え方としては少し簡単です。リリースする前にいろいろと調べて品質の悪い点が見つかったらそのソフトをリリースしないというルールを守れば良いだけです、方法論としては判り易いですね。

ただし、工場で同じ物を作る量産品の場合と違って、一品生産品のソフトウエアはリリース時に品質を確認するのが難しいという面があります。別の記事でも書いていますが、量産品の場合はこれが正しいという本来あるべき姿が決まっています。ゴールデンサンプルと呼ぶ事もありますね。 その、ゴールデンサンプルと同じなら品質は良いと判断できるので、出荷前に色々と検査や測定をして、ゴールデンサンプルとの違いが無ければ良品なので出荷し、違いが大きければ不良品と判断して出荷しない、という方法が採れます。

ところが、一品生産品のソフトウエアにはゴールデンサンプルという物がありません。要求仕様はありますが、要求仕様はゴールデンサンプルに相当する出来上がったソフトウエアでは無いので、ゴールデンサンプルとの違いを測定して不良品と判断する方法は、ソフトウエアの品質の判定には簡単には使えません。

品質の判定はテスト品質と残存バグとプロセス品質とプロダクト品質の4つで

ではソフトウエアの品質が良いか悪いかはどうやって判断しましょうか? なかなか厄介な問題ですが、ソフトの品質を調べるための指標を決め、それぞれの指標について判定のための基準を決めて、さの基準を満たしていなければ品質の悪いソフトと判断してリリースを止める、と考えるとやるべき事が少し具体的に見えてきます。

もちろん、ソフトが使われる場面や誰が使うのかとか、もしソフトに問題があったらどんな影響がでるのか、とかソフトにとって。必要とされる品質のレベルは千差万別です。でも、ソフトの品質が必要なレベルに達しているかどうかを判断する方法は、ある程度似通ってくると思います。

グータラ親父は、テスト品質の状況を確認し、残存バグが市場に与える影響を考えて、ソフトのプロダクト品質の状況を確認し、そのソフトの開発に使ったプロセス品質の状況を確認して、ソフトウエアの品質が良いかどうかの判定をしてきました。この4つが、グータラ親父の使ってきた4つの判断基準です。

判定はリリースの種類と判定責任者と判定方法を決めワークシートを使って

判断基準があったとしても、判断をするためのプロセスがきっちりと決まっていないと実際の運用がうまく進みません。例えばリリース判定をするソフトが、そのソフトにとって初めてのリリースの場合には関係者を集めて会議を行い色々な立場の人の意見を聞いて総合的に判断する必要がありますし、機能追加やバグ修正をも目的としたリリースなら、一人で判断する事もあります。またリリース判定をするソフトの種類が正式版なのか評価版なのかβ版なのかによっても、判断の基準を変えてきました。色々な状況でのソフトのリリース判定に対応するために、リリースの種類を決め、リリースの判定責任者を決め、リリースの判定方法を決め、それらの決め事にそって実際のリリース判定を行うためのリリース判定ワークシートを使って判定をする必要があります。この4つが、グータラ親父の使てきた4つの判定の仕組みです。

グータラ親父流リリース判定の紹介

リリース判定に分類されている以下の記事では、ソフトのリリース判定をするために必要な情報や判定の基準について、できるだけ整理して記事に書き綴ってみましたので、ご覧下さい。 

記事のタイトルの先頭にソフトウエアのリリース判定に関する小分類を付けてあります。小分類に続くサブタイトルが具体的な記事の概要です。 読む順番は特に決まりはありませんので、気になる記事から順にご覧ください。

全体をざっと理解したい人は、小分類が概要となっている2本の記事をご覧ください。 概要の記事に書いてある事をもう少し詳しく知りたい方は、個々の記事をご覧頂くか、概要の記事の文末からリンクされている個々の記事を順番に読み進めて頂くと良いと思います。

  •   概要・リリース判定はテスト品質/残存バグ/プロダクト品質/プロセス品質の4つの基準で判断する
  •   概要・リリース判定はリリースの種類/判定責任者/判定方法/ワークシートの4つの仕組みで実施する
  •   リリース判定基準・テストの量はテスト密度で測る
  •   リリース判定基準・テストの量はテスト実施率も確認する
  •   リリース判定基準・テストの種類まずは異常系と準正常系
  •   リリース判定基準・テストの種類2つ目は安定性と堅牢性
  •   リリース判定基準・テストの種類3つ目はRAS機能
  •   リリース判定基準・テストの種類4つ目はバージョンアップ機能
  •   リリース判定基準・テストの種類5つ目は過去不具合の確認
  •   リリース判定基準・テストの実施状況は進捗確認から
  •   リリース判定基準・テストの実施状況はバグの検出状況も見る
  •   リリース判定基準・バグは顕在バグと潜在バグに分けて考える
  •   リリース判定基準・潜在バグは何件残っているかを推定する
  •   リリース判定基準・残存バグ0は必須条件じゃない
  •   リリース判定基準・信頼度成長曲線はまあまあ使える
  •   リリース判定基準・残存バグはサービス提供への影響で判断する
  •   リリース判定基準・残存バグから電話申告の件数を推定する
  •   リリース判定基準・残存バグから電話申告の件数を推定する(その2)
  •   リリース判定基準・残存バグから電話申告の件数を推定する(その3)
  •   リリース判定基準・プロダクト品質はまずは設計品質を確認する
  •   リリース判定基準・プロダクト品質はコード品質も確認する
  •   リリース判定基準・プロセス品質は開発実務と開発管理に分けて考える
  •   リリース判定基準・開発管理プロセスはまず開発計画を見る
  •   リリース判定基準・開発管理プロセスは設計と実装とテスト計画を見る
  •   リリース判定基準・懸案やリスクの管理とベースライン管理も見る
  •   リリース判定基準・保守の体制と契約は明確になっているか
  •   リリース判定基準・ゲートプロセスの実施状況
  •   リリース判定の仕組み・ソフトのリリースには社外向けと社内向けがある
  •   リリース判定の仕組み・リリース判定の対象は社外向けのソフト
  •   リリース判定の仕組み・リリース判定は品保部長か開発部長か社長が行う
  •   リリース判定の仕組み・リリース判定は公式レビューで行うのが最良
  •   リリース判定の仕組み・リリース判定は2部署会議や個別判断でも可能
  •   リリース判定の仕組み・リリース判定の結果はチェックリストで記録を残す
  •   リリース判定その他・特別採用によるソフトのリリースもあり得る
  •   リリース判定その他・特別採用はテストの状況と潜在バグと残存バグで判定する
  •   リリース判定その他・テストとバグの悩ましい関係
  •   リリース判定その他・ソフトの品質はプロダクト品質が大切
  •   リリース判定は4つのリリース判定基準と4つのリリース判定の仕組みで実施する
  • Posted by グータラ親父