バザールモデルにおける品質

ソフトウェア開発モデルとしてのバザールモデルというのは従来のソフトウェア開発モデルとまるっきり違うので、簡単に対比して考えてみる。

古典的なウォータフォールモデルでは、工程を要求定義、外部設計、詳細設計、実装、単体テスト、統合テスト、運用保守となる。工程による分割可能で、要求定義を上流工程と実装、テストなどを下流工程と言う。それぞれの工程には明確なアウトプットがあり、要求定義のアウトプットは要求定義書で、それが外部設計のインプットになる。

要求の獲得から実装という一連の流れのなかで、利用者の何らかの問題を解決しなければならないのだけど、要求定義が利用者の要求とかけはなれたものであったら、いくら設計から実装が正しくとも、まったく意味のないものができあがってしまう。要求を的確に把握する事が重要なのだけどそれが一番難しい。

仮に要求定義の時点で利用者の要求を把握していたとしてもウォータフォールモデルでは要求定義をしてから実装が出て運用にいたるまで長い期間がかかるため、その間に要求が変化してしまうこともあり、利用者にジャストミートなソフトウェアを提供することが難しい。

そのためプロトタイプを作って要求の見える化をしたり、素早く実装をくりかえして環境変化による要求変化に追随したりする。

一方バザールモデルはというと、明確な要求定義書とか外部設計書、詳細設計書の類いは通常は存在しない。誰かが問題を発見し、それがバグフィックスであったり、機能的な不備であったり様々なわけであるが、通常は問題を認識した人が実装する。実装者が要求者の場合、実装する人は要求(問題)を正しく認識しているので、要求そのものの齟齬というのは原理的には発生しえない。

機能の需要者が供給者という構図である。

実装については多数の目玉がピアレビューをする。それは機能面と実装面から徹底的にレビューされる。メーリングリストへ、ＸＸという機能を実装したいというRFC (Request for Comments)を投げると様々な観点からのレビューがおこなわれる。実装(パッチ等で提供される場合が多い)についても同様にレビューがおこなわれるだけではなく、様々な環境でテストされるので、機能的な問題、実装上の問題が効率よく発見される。

ソフトウェアのバージョンは安定版と開発版と分離し、通常、新機能については、開発版でProof of Conceptされて、有用性や互換性が検証され、安定版には重要なバグ修正のみを適用することによって安定性互換性を担保している。

リグレッションテストのような自動化した互換性確認というのの適用は今後の課題となっている。

Linuxの品質特性の一つとしてセキュリティについての数字があってWindowsとの比較すると下記になる。

Windowsの脆弱性の緊急度、最高(5%)、高(33%)に対しLinux Kernel 2.6は0%である。狭義の品質不良(機能的不具合)についての定量的データは少ないが、定番のOSSのバグ密度が低い事はよく知られている。

商用ソフトウェアのような予算、スケジュール、リソースの明示的な制約(？)というのはなく自発的な開発者による自発的な開発に依存している。

ただしOSS(オープンソースソフトウェア)だからといって上述したバザールモデルの開発になるとは限らない。むしろ多くのOSSはバザールにならず、ひっそりと誰にも注目も利用もされず忘れさられている。しかしLAMP(Linux/Apache/MySQL/Perl/PHP)等に代表される定番のOSSはバザール開発モデルになっている。

バザールモデルは環境変化、要求変化に対し極めて柔軟にしかも素早く対応する。要求に適合したものがタイムリーにリリースされる。これは通常のウォータフォールモデルによる開発ではなかなか達成できないものである。

このようにバザールモデルで開発したソフトウェアの品質は極めて高いといえる。

なぜソースコードを読むのか？/ユメのチカラ

オープンソースの生産性/ユメのチカラ