紹介文 :
ソフトウェア開発の定量的な品質管理では、プログラムコード行数あたりのバグ摘出数・テスト数といった指標を使うことが多い。昨今は業務パッケージソフトウェアの利用などでプログラムコードを直接書かないプロジェクトが増え、プログラムコード行数を用いた指標を利用することが難しくなってきている。また上限・下限値といった水準値を定めて指標値を評価するが、
統計的に意味のある類似したプロジェクトの情報の入手が前提となっている。昨今は技術の多様化が進んでいるため類似したプロジェクトを見つけるのが厳しくなっており、この点からもプログラムコード行数を用いた指標を利用することが難しい。そこで本論文ではテストプロセスを対象とした、プログラムコード行数を用いない品質分析技術を提案する。
また現代のビジネスにとってソフトウェアの重要性は増しており、 その開発を高速に行うことが市場に求められている 。迅速に提供できたとしても ソフトウェアの品質が悪ければ提供価値が下がるため品質管理の重要性は変わらない 。品質を保ちつつ品質管理にかかる作業は高速であることも求められている。プロジェクトでは次のフェーズに進んで良いか判断するために、各フェーズの終了時に品質を 確認するクオリティゲートを設定することがよくあるそのための品質報告 情報のとりまとめや、次のフェーズに進んで良いか判定している期間がソフトウェア開発を停滞させてしまうことがある 。この点に品質管理を高速にするための改善余地があると考え、解決するための手法を提案する。
定量的な品質管理は開発中に日々行うことが理想ではあるが、実現できているプロジェクトは多くはない。そこで日々の品質管理のために何を確認しているのかヒアリングを行った。 その結果、テスト観点に対してテストを網羅的に実施できているかと、すり抜けバグの 発生状況の確認を行っていることが多かった。この 2 つを定量的に確認できるような品質分析技術として整理し、無理なく品質管理を日々行うことで開発速度を落とさない品質管理 手法を策定した。
本論文では2 章で解決したい課題を明確にし、3章で改善策の提案を行い、4章で提案手法の適用結果を紹介し、 5 章で今後の展開を述べる

紹介文 :
ソフトウェア開発を成功に導くために、技術者の能力の均質化や底上げ、開発プロジェクト内での共通認識の醸成を目的として、開発標準などのドキュメントを作成している企業は非常に多い。しかし、ソフトウェア開発プロジェクトは複雑であるため、開発標準に記すべきノウハウは多岐にわたる。そのため開発標準が重厚長大なドキュメント群となってしまうことが多い。多くの技術者は多忙な開発の中で重厚長大な開発標準を読むこととなり、大変な苦労を感じている。結果として開発標準は技術者から「役に立たない」・「読みたくない」といった評価を受けることがある。また、ソフトウェア開発に関する技術やテクニックは、常に進化しており、開発標準も進化に追従していかなければない。しかし、重厚長大なドキュメントを修正するには、執筆やレビューの工数が負担となり、迅速な改善が難しい。その結果、開発標準に記されているノウハウが、時代遅れとなってしまうことも珍しくなく、技術者からの評価がより悪化してしまう。開発標準が、ユーザである技術者から見て魅力のないドキュメントとなってしまうと、目的であった技術者の能力向上や、共通認識の醸成がうまく進まず、ソフトウェア開発プロジェクトが失敗に終わってしまうことがある。そこで我々は、オープンソースソフトウェアの開発技術・文化を、組織などの閉じたコミュニティで実践するインナーソース開発のノウハウを、開発標準の作成に適用し、このような問題を解決した。本発表では、これらの経験に基づくノウハウや、考え方を紹介する。