組み込みソフトの品質保証に必要な複数の活動と重点ポイント
- 1. 組み込みソフトの品質を保証し品質を向上するには複数の観点での活動が必要です
- 2. リリース判定とソフト開発監査とテストがソフト品質保証の基本の３点セット
- 3. リリース判定
- 4. ソフト開発監査
- 5. テスト品質
- 6. バグ管理とプロセス品質と他社制ソフト品質が第二の３点セット
- 7. プロセス品質
- 8. バグ管理 （この分類はまだ概要説明ページだけです）
- 9. 他社制ソフト品質 （この分類はまだ概要説明ページだけです）
- 10. 他にも品質を良くするのに必要な事はいろいろあります
- 11. その他のお話し （この分類は不定期に記事が増えます）
- 12. バグの巣 （この分類はすこしずつ記事を書き足しています）
- 13. プロダクト品質 （この分類はまだ概要紹介ページだけです）
- 14. 開発技術 （この分類はまだ概要紹介ページだけです）
- 15. 開発組織 （この分類はまだ概要紹介ページだけです）
- 16. 開発委託 （この分類はまだ概要紹介ページだけです）
- 17. 私の横顔 （この分類はたぶん不定期に記事が増えます）
- 18. 亀の甲より年の劫という諺もありますが、なんせグータラなもんで。。。
組み込みソフトの品質を保証し品質を向上するには複数の観点での活動が必要です
ソフトの品質を保証し品質を向上するために、グータラ親父はリリース判定とテスト品質とソフト開発監査をまず最初に取り掛かるべき最重要の３点、バグ管理とプロセス管理と他社製ソフトの品質管理を次ぎに重要な３点、として取り組んできました。
ソフトの品質の保証や向上には何か１つの事だけを行えば良いという銀の弾丸は在りません。色々な地道な活動を積み上げて初めてソフトの品質を保証する事ができます。色々な活動が必要なのですが、限られた人員と時間しか無い現実の中では効果が出易い活動から優先的に手を付けていく事が必要になります。このブログでは、40年近くを組み込みソフトの開発と品質保証に取り組んできたグータラ親父の経験を元に、品質の保証と向上に必要な活動について紹介していきます。
先ず一番最初に必須なのは、「リリース判定」を正しく行うためのリリースの基準とリリース判定の仕組みの構築です。品質の悪いソフトのリリースをリリース判定で止める事ができないと、ソフトの品質保証は実現できません。その次に重要なのが、ソフトの品質を測り改善するための「テスト品質」の確保です。質の良いテストを十分な量で行ってソフトの潜在バグを徹底的に洗い出して修正する事で初めて品質の良いソフトが出来上がります。三番目に重要なのが、他社に開発委託したソフトの品質を確保するための「ソフト開発監査」です。ソフトの規模が大きくなり全てを自社開発する事が難しくなった現在の開発現場では、開発委託先のソフト開発能力の把握や改善は自社ソフトの品質保証に不可欠です。
これらの最重要の３点ができてきたら、その次に大切なのは「バグ管理」と「プロセス品質」と「他社製ソフトの品質管理」の３点です。テストで見つけたバグを確実に修正して製品に反映するためのバグ管理の仕組みと、設計レビューやテストレビューなどの必須の開発作業や開発管理を規定するプロセス品質と、有償・無償で採用し自社ソフトの中に取り込んで使っている「他社製ソフトの品質管理」の３つの活動もまた、自社ソフトの品質に大きな影響を与えます。
このブログでは分類ごとに概要説明のページがありますので、まずはそのページをご覧ください。概要説明ページよりも詳しい具体的な内容は、概要説明ページからリンクされている個々の記事にありますので、興味を持たれた方はそちらもご覧ください。組み込みソフトの品質の保証や改善に日々苦労しておられる皆さんに、少しでもお役に立てれば幸いです。
リリース判定とソフト開発監査とテストがソフト品質保証の基本の３点セット
組込ソフトの品質を保証するには色々な作業がありますが、それらの中で重要なトップ３は「リリース判定」と「ソフト開発監査」と「テスト」です。 まずはこの３点セットについて紹介しましょう。 個々の内容はそれぞれの説明の表題から辿るか、ページの上部にあるメニューから辿ると概要を説明したページに飛びますので、実際の内容についてはそちらをご覧ください。
リリース判定
「リリース判定」は、製品の出荷判定と同じでソフトの品質保証の最後の砦です。品質保証で一番大事な事は、品質が悪いソフトをリリースしない事です。ところが、リリースするソフトの品質が良いのか悪いのかを判断するのはなかなか難しいものです。ソフトの品質はどんな指標を使って、どんな基準で善し悪しを判定すれば良いのでしょうか？ リリース判定の分類では、グータラ親父がリリース判定を行う時に使っていた４つの基準と４つの仕組みについて紹介します。
４つの基準とは、プロセス品質、プロダクト品質、テスト品質、残存バグです。４つの仕組みとはリリースの種類、リリース判定責任者、リリースの判定方法、リリース判定ワークシート です。 基準や仕組みという言葉の意味とはと微妙にズレてる項目もありますが、まあそこはグータラ親父のよもやま話と思って、聞き流していただけると有難いです。
ソフト開発監査
「ソフト開発監査」は、ソフト開発組織の持つソフト開発能力の良し悪しを開発プロセスと開発技術力の２つの面から判定するために、ISO9001 と CMMI の考え方を融合させてエイヤっ勝手に作り上げた方法です。開発組織には社内の開発組織とソフト開発業務を委託している業務委託先の両方がありますが、グータラ親父は主に業務委託先のソフト開発能力の良し悪しの判定や開発能力を改善するための指導の手段として、ソフト開発監査を実施してきました。
大規模化が進む現在のソフト開発では、全てを自分達で開発する事は不可能です。全部や一部のソフトを、国内や海外のソフトハウスに開発を業務委託する事が頻繁に起こります。 ところで委託先の会社はソフトの開発管理や技術管理はちゃんとできていて、ソフトの開発能力を十分に持っているのでしょうか？
組み込みソフトの開発能力の良し悪しが簡単のに測れると良いのですが、ほとんどの作業が設計者の頭の中で進むソフト開発では、組織の持つ開発能力の良し悪しを測る事はなかなか難しいものです。グータラ親父は、開発プロセス・要求仕様・テスト・設計と実装の４つの観点から委託先のソフトエア開発能力の良し悪しを判定する「ソフト開発監査」という方法を独自に作って使ってきましたので、その内容を紹介します。
テスト品質
「テスト」は、ソフトウエアに限らず品質を保証するための唯一の方法です。保証するとは、製品がその機能や性能を持っている事を確かにする、という事なのでテストして結果がOKならばその時点で保証した事になります。組み込みソフトの場合には、機能や性能のように仕様書に書いてある項目以外にも、安定性や堅牢性のように仕様書に具体的に書いていない非機能要件も製品にとって重要になります。グータラ親父は、仕様書に明確に書かれていない事が多い非機能要件をどれだけテストして保証しているのかに注意して、テストの質と量を確認してきました。この非機能要件は、国が異なると品質のベースになっている常識が違う事もあるので、特に海外に開発業務を委託する時には注意が必要です。このブログでは、グータラ親父がテストの良し悪しを判断する時に注意してきた内容を紹介します。
バグ管理とプロセス品質と他社制ソフト品質が第二の３点セット
ソフトの品質を改善できる「銀の弾丸」はありません。出来る事を地道にコツコツと積み上げるしかないのが現実です。組み込みソフトの品質保証も、リリース審査と開発監査とテストだけでは足りません、これらの次に大切な事は、「バグ管理」と「プロセス品質」と「他社制ソフト品質」の３点セットです。 これの分類はまだ概要説明ページしかできていないですが、具体的な記事はこれから少しずつ書いていく予定です。
プロセス品質
「プロセス品質」が良いと予定通りのコスト・品質・納期でソフトを開発できるようになります。ソフトそのものの品質を指す「プロダクト品質」とはまた別の品質なのですが、プロセス品質はビジネスとしてソフト開発をする場合には大切な品質です。ところでプロセスってなにでしょうか？プロセスのどんな点に注意すればプロセス品質が良くなるのでしょうか？ プロセスとは日本語に訳する手順が一番近い言葉ですが、なかなか掴みどころがないと感じて居る人も多いと思います。
ISO9001 や CMMI はプロセス改善に重点を置いて組織の品質保証の能力を評価し改善する手法でう。必要な開発プロセスが具体的に決まっていて、その開発プロセスが適切に実施されていて、開発プロセスが実施されている状況を適切に管理しているか、という視点で組織を評価して足らない箇所を補う事で組織を改善していきます。ソフト開発のプロセスでは、特に計画の立案、キックオフとクロージング、リスクと懸案の管理、レビューなどのプロセスが重要です。この分類では、ソフトウエアのプロセス品質を考える場合の、ソフト開発プロセスの様々な切り口について、グータラ親父流の考え方を紹介します。
バグ管理 （この分類はまだ概要説明ページだけです）
「バグ管理」と「不具合管理」は組み込みソフトの品質を良くするために重要な管理です、よく似た内容ですが明確に分けて管理する必要があります。バグ管理はソフトに潜在するバグを見つけ出しこれを修正していく作業の管理の事です、一方で不具合管理は市場で発生した不具合について回避策や根本対策を提供する作業の管理の事です。不具合にはバグに起因する問題の他に、仕様上の問題や性能不足や運用上の問題も含まれます。また、例えソフトにバグが存在していても市場での運用でそのバグが顕在化しないので不具合にならない場合もあります。ですので、バグと不具合とは分けて管理する必要があります。
バグ管理の目的はデバッグ作業を効率的に進める事です。既に出来上がっているソフトの品質を良くするための唯一の方法はデバッグです。ソフトウエアの品質はソースコードに含まれるバグを取り除く事でのみ良くする事ができます。設計レビューはこれからソースコードに作り込まれるかも知れないバグを減らしてくれますが、既にソースコードに入り込んでしまっている潜在バグは、デバッグ作業で取り除かない限り無くなりません。このデバッグ作業を進めるために、テストで見つかったバグが取り除かれるまでを管理する事がバグ管理です。
不具合管理の目的は製品が市場で使われている中で発生した不具合を効率的に対応する事です。組み込みソフトが搭載されている製品はエンドユーザに様々なサービスを提供しますが、そこで不具合があるとサービスの提供に影響が出てしまいます。この場合には、できるだけ早く不具合の回避策を提供して当面のサービスの提供を続けながら、根本的な対策を用意する事が大切です。市場で起きた不具合について、回避策の提供から根本対策の提供までを管理する事が不具合管理です。 この分類ではバグ管理と不具合管理について、グータラ親父が注意してきた事を紹介します。
他社制ソフト品質 （この分類はまだ概要説明ページだけです）
ソフトの開発では開発委託と並んで他社製のソフトを使う場面が多くなってきました。 他社製ソフトにも、対価を支払って購入した購入ソフト、オープンソースソフト（OSS）、チップベンダ等がチップと共に提供してくれる無償のフリーソフトなど、様々な物があります。様々な他社製ソフトウエアがあるのですが、最終的に自社の製品に組み込んだ時点で、その品質は自社で保障する必要が出てきます。 品質の悪い他社製ソフトウエアを組み込んでしまってはリリースするソフトの品質が低下してしまいます。
では、他社製ソフトの品質を確保するには何に注意すれば良いのでしょうか？ 社内で設計・制作する内作ソフトと違って他社制ソフトはその内部が見えにくいので品質の良し悪しを判断するのもなかなか難しいです。難しいですがなんとかしないといけないので、他社製のソフトを利用するにあたってどのような点に注意する必要があるのか、グータラ親父が注意していた点を中心に紹介していきます。
他にも品質を良くするのに必要な事はいろいろあります
その他のお話し （この分類は不定期に記事が増えます）
このブログはソフトウエアの品質に関する記事を大まかな分類に従ってが書いてあるのですが、記事を書いている途中にふっと分類に入らない横道の事についても書き足したくなる事があります。ソフトウエアに関係する事もあれば、全く関係の無い事もあるのですが、思いつくままに書いた記事をここに集めてみました。 気分転換にでも、ご覧ください。
バグの巣 （この分類はすこしずつ記事を書き足しています）
バグ・・・嫌な言葉ですね、できれば関わりたくないのですが、残念ながらソフトウエア開発の世界に居る限りは、このバグと縁を切る事は不可能です。このバグというやつは、思いもよらない場所に潜んでいて、開発遅れを起こしたり市場で不具合を引き起こしたりします。そして、このバグが好んで潜んでいるバグの巣とでもいうような場所があります。何年間もソフトウエアの開発と品質の現場に居ると、そのようなバグの巣の在りそうな場所も、いくらか判る様になってきます。 この分類では、グータラ親父が特に気を付けていたバグの巣について、紹介します。
プロダクト品質 （この分類はまだ概要紹介ページだけです）
ソフトウエアの品質とはイコールプロダクト品質です。ところでソフトウエアのプロダクトとは何でしょうか？ 簡単に言えばソフトウエアの開発プロセスが生み出す成果物なので、CPU上で実行されるプログラムの実行コードや、その元になるソースコードや、さらにその元になる設計ドキュメントが、ソフトウエアのプロダクトです。では、これらのソフトウエアプロダクトの品質は、どんな観点で何を見ればその善し悪しが見えてくるのでしょうか？ この分類では、ソフトウエアのプロダクト品質とその善し悪しの判定方法について、グータラ親父流の考え方を紹介します。
開発技術 （この分類はまだ概要紹介ページだけです）
ソフトウエアを開発するためにはどんな知識と技術が必要なのでしょうか？ ソフトウエアが使われる業務やサービスに関する知識、ソフトウエアが稼働するハードウエアに関する知識、など色々と知っておく必要がある知識があります。そして、それらの知識を元にしてソフトウエアを開発していくには、ソフトウエアの開発に固有の技術がいくつかあります。それは、ソフトウエアの要求設計技術、ソフトウエアの設計技術、ソフトウエアの実装技術、ソフトウエアのテスト技術、ソフトウエア開発管理技術 等です。これらの技術については、いろいろな考えがあり何をすれば良いか迷う事も多いです。この分類では、これら技術についてのグータラ親父流の考え方を紹介します。
開発組織 （この分類はまだ概要紹介ページだけです）
ソフトウエアは一人で開発する事もできますが、ソフトウエアが大規模化してきた現在では、多くの人が協力して色々な役割を分担して開発を進める事が多いです。多くの人が協力するので必然的に組織ができて、その組織がお互いに関連しながら、一つのソフトウエアの開発が進みます。そして、必要な組織が存在してちゃんと機能を果たしているかどうかという点が、出来上がったソフトウエアの品質に影響してきます。ソフトウエアを開発する組織としてこれが正解というのはありませんが、この分類では、ソフトウエアを開発する組織としてどんな組織が必要でどんな注意点があるのか、グータラ親父の経験を元に少し解説してみます。
開発委託 （この分類はまだ概要紹介ページだけです）
大規模化した現在のソフトウエアでは全てを自社で開発する事は難しく、一部のソフトウエアの開発を社外のソフトウエアハウス等に委託する事が良く起こります。 開発委託をする場合には、自社で開発するのではな無いので、実際にソフトウエアが出来上がってくるまでは、どんな品質のソフトウエアになっているのか知る事ができず、結構ハラハラします。少しでも心配事を減らすには、委託する業務範囲や仕様を明確にして、委託先の開発状況を監視し、工程や品質を管理して、出来上がった成果物の検収にあたって充分な確認をする事が大切になってきます。 この分類では、開発委託を行う時の様々な注意点についてグータラ親父の経験を元に紹介していきます。
私の横顔 （この分類はたぶん不定期に記事が増えます）
このブログを書いているグー―タラ親父は、どこで生まれて、ソフトウエアの世界でどんな仕事をしてきたのか少し自己紹介をしておきます。ついでに、今興味のある事とかも、少しずつ書き足してみようと思いますが何時になるかは判りません。 あまり期待せずにお待ちください。