BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース コードの品質のためにアジャイルとウォーターフォールを組み合わせる

コードの品質のためにアジャイルとウォーターフォールを組み合わせる

ブックマーク

原文(投稿日:2014/10/17)へのリンク

2014年のCAST Research on Application Software Health (CRASH)のレポートは、アジャイルとウォーターフォールを混ぜた手法で開発した企業向けソフトウエアはどちらか一方の手法だけで開発されたものよりも強靭で安全であると報告している。

このレポートでは、CASTのAppmarqというベンチマーキングリポジトリのデータを解析し、ビジネスアプリケーションの構造的品質の世界的な動向を調査した。開発手法やCMMI成熟レベル、アウトソーシングなどがソフトウエアの品質にどのように影響するかを調査している。

レポートの要旨はCASTのウェブサイトからダウンロードできる(登録が必要)。

InfoQはCASTのバイスプレジデントであり主席サイエンティストも務めるBill Curtis氏に今回の調査について、また構造的品質要因について、アジャイルとウォーターフォールを混ぜることについて話を聞いた。

InfoQ: CASTを知らない読者のために、CASTの紹介をお願いします。

Bill: CAST (www.castsoftware.com)はApplication Intelligence Platform (AIP)と呼ばれる技術を開発し、複数のレイヤ、複数の言語を使ったビジネスシステムの構造的品質を分析しています。構造的品質は非機能的なシステム内部の属性によって構成されます。強靭さ、性能効率性、セキュリティ、変更可能性などの属性です。CASTのAIPは優れた設計、優れたコーディングの実践に対する1200の違反を検知します。28のプログラミング言語に対応しています。Java、.NET、C、C++、COBOL、PHP、ABAPなどです。分析結果から、開発者向けには問題点の場所と深刻度を報告し、経営層にはアプリケーションポートフィリオのリスクとコストを明示します。

InfoQ: なぜ構造的品質が重要なのでしょうか。

Bill: 構造的品質が表すのは、正しい処理をしているかどうかということだけではありません。設計やコードが障害や不正アクセス、データ汚染を防ぐようにできているか、スケールはできるか、複雑すぎないかなどの点も検証します。ビジネス上の重要なアプリケーションがこれらの問題に直面すると影響は大きく、最悪の場合はソフトウエアの品質が経営問題になります。

Diomedis Spinellis氏がその著書Code Qualityで書いているように、構造的な問題は従来のテストでは検知が難しいです。大部分のテストケースは機能的な正しさを検証するために作られています。しかし、最も被害が大きい構造的欠陥のほとんどは、異なる設計レイヤの間のコンポーネント間のやり取りで発生します。やり取りの前提が正しくないのです。これらの設計上の複雑な欠陥はユニットレベルの静的な解析では検知できません。研究によればこれらの問題はシステム内の構造的な問題の10以上を占めることは稀なものの、大量のファイルが関連しているため大量の再作業が必要になります。

InfoQ: 企業にとってどのような構造的品質要素が最も大きな問題を食い止めるのでしょうか。

Bill: いくつかの要素が考えられますが、セキュリティと信頼性が最も注目を集めつつあります。というのは、毎日脆弱性や大規模障害が報道されるからです。恥ずかしいことに、私たちはSQL注入のようなほとんどのセキュリティの欠陥について何年も前から知っています。現在の最新の検知能力で、なぜこのような欠陥を排除できないのでしょう。多くのアプリケーションにとって、ピークタイムに障害を避け、障害からすぐに復旧するためには、信頼性がとても重要です。

InfoQ: CASTがこのような研究をしているのはなぜですか。

Bill: 私たちの多くの顧客がアプリケーションの分析結果をAppmarqリポジトリに提供してくれ、自身の構造的品質の指標のベンチマークにしています。匿名化されたデータは構造的品質とその要因を調査するに豊富な情報を提供してくれます。データの科学的な価値に加えて、私たちは顧客に改善を推進するための内部データの活用法も提供したいのです。私たちはIT部門に、製品の構造的品質を分析することが重要であるということを理解してもらおうとしています。継続的改善には製品とい同様にプロセスや手法も関わってきます。

InfoQ: 調査はどのように実施されましたか。

Bill: Appmarqの最低でも10000行以上のコード(LOC)を含むアプリケーションからサンプルを抽出しました。2014年の調査ではサンプル数は1,316。北アメリカ、ヨーロッパ、アジアの12の産業の212の企業のアプリケーションです。LOCの中央値は128,000。しかし、平均は470,000です。143のアプリケーションは100万LOCを超えていたからです。アプリケーションのオーナーの多くはロケーションや開発メソッド、CMMIレベルなどについて叙述的な情報を持っています。いくつかのケースでは、言語と技術を横断して分析を比較するのは難しいです。というのは、起こりえる構造的な違反がに違いがあるからです。40%以上がJava-EEで書かれています。CRASHのレポートには、Java-EEで作られたアプリケーションの分析を支援するのに十分なデータがあります。

InfoQ: "すべて[の構造的品質の特性]にとって、アジャイルとウォーターフォールを混ぜた手法がどちらか一方だけの場合よりも高いスコアを示した"という結論が出ています。詳しく教えてください。

Bill: 強靭さ、性能効率性、セキュリティ、変更可能性などの構造的品質の特性指標で、アジャイルとウォーターフォールを組み合わせた手法が高いスコアを達成しました。強靭さと変更可能性のスコアはどちらか一方だけの手法で開発した場合よりも、中央値が高かったのです。加えて、組み合わせた場合のほうが、分散が小さいです。調査対象のアプリケーションは大規模なものですから、後から設計を見直すのは高価であり、制約があります。そのようなシステムに対する満足のいくアーキテクチャがアジャイルの膨大なスプリントの中から出現すると考えるのはリスクがあります。優れた構造的品質は、ウォーターフォールの初期の設計分析とアジャイルの継続的なテストの組み合わせから生まれているのがわかりました。アジャイルとウォーターフォールでは構造的品質について大きな違いはありません。両者を組み合わせることで違いが生まれるのです。

InfoQ: ソーシングやプロセスの成熟についても発見があったようですね。

Bill: 内製とアウトソーシングとで違いはありませんでした。構造的品質に影響する要因は開発形態とは違うところにあるようです。

また、CMMIレベル1の企業で開発されたソフトウエアの構造的品質は、より成熟した開発環境で開発されたソフトウエアよりも低かったです。開発者がレベル1のデスマーチの罠にかかると、達成できないスケジュールを目指して働きすぎてしまい、構造的欠陥が大量に含まれているコードが生み出されます。そのようなコートを検出したり、リファクタリングしたりする時間もありません。コミットメントとベースラインを制御することで開発者は持続可能なペースで働き、高品質なコードを生み出します。また、アジャイルプロジェクトで、ビジネスサイドからの大きな圧力の下で大量のスプリントを追加されることに不満を持っている開発者もいるようです。スプリントは固まった状態で提供されるのが一番なのです。

CMMIレベル2の目的は、各プロジェクト、各アプリケーション毎にコミットメントとベースラインの制御を確立し、開発者を絶え間ない恐怖とカオスから守ることで、開発者が秩序のあるプロフェッショナルのペースで作業ができるようにすることです。変化を受け入れることはカオスを受け入れることではありません。CMMIレベル2とレベル3の組織のアプリケーションには違いはありませんでした。レベル2から3への移行は企業が押し進めることであり、異なるプロジェクトにも共通の実践を確立し、理解と組織的な学習とスケールを達成する必要があるからです。

InfoQ: アジャイルを実践しようとしている、あるいは既にしている企業に何かアドバイスをお願いします。

Bill: この調査結果は、アジャイルのリーダー、例えば、Alistair Cockburn氏、Scott Ambler氏、Dean Leffingwell氏、Todd Little氏が何年もの間主張してきたことをデータで立証したものです。アジャイルプロジェクトはサイズや複雑さ、アプリケーションが直面している不確実性を考慮して調整しなければなりません。複雑な課題が大きければ、早い段階で設計上の不確実性を除去しておくことで後になって手戻りや技術的な制約に直面することを回避できます。また、アジャイルプロジェクトはシステムレベルでの構造的品質を評価し、サブシステムやアプリケーションのレイヤの間にある問題を検知する必要があります。

機能的な不確実性がある一方で、構造的な不確実性もあります。アジャイルは顧客のニーズの変化に起因する機能的な不確実さに対処するということに注力していあす。構造的な不確実さは‘エレガントな設計’に付託されてしまいます。しかし、大規模なシステムでアーキテクチャをリファクタリングするのはとても大変であり、価値あるソフトウエアのデリバリを遅くします。したがって、開発を実践の集合に見立て、バランスを取りながら、構造的、機能的不確実さのレベルを管理することです。自分のやり方でアジャイルを実践するのがいいでしょう。

この記事に星をつける

おすすめ度
スタイル

BT