ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。

第29回S-Openホットセッションに参加してきました

 11月17日(月)、S-Open(Software Professional Engineers' Network:ソフトウェア技術者ネットワーク)のホットセッションに出席しました。
 テーマは、「非機能要件の動向および捉え方と設計への適用」。3人の識者がそれぞれ、エンタープライズ系・組み込み系・学術からの視点でお話されました。プレゼンターの詳細についてはS-OpenのWebサイトをごらんいただくとして(11月26日現在、情報がアップされていませんが・・・)、備忘録をまとめておきます。誤認などあったらごめんなさい。

【講演1】非機能要件のトレンド

  • ドキュメントへの記述量と、発生する問題の量の2つを軸にした座標系では、「記述は少なく問題が多い」に位置するのが、非機能要件。
  • 要求分析は、ゴール志向の活用が有効。
  • 顧客は、シーケンス図もビジネスプロセス図も見てくれない!マトリクスを用いてのアクタ間関係分析が効果的。
  • 非機能要件を設計に落とし込む際、その誤りの摘出は、伝統的な(そして単純な)V字型モデルでは、最後の最後になってしまう。これでは遅すぎる。W字型(動的V字型)モデルといったアプローチが必要。
  • 非機能要件は、テスト評価できなければならない。(定量的な評価ってことと理解しました)

【講演2】情報システムにおける非機能要件とアーキテクチャ

  • 「要件」と「要求」は、意識して区別している。「要件」はシステムに実装すべき、かつ発注側と受注側で合意の取れているものを指す。
  • 非機能要件を網羅的に記述するためのチェックリストが有効。それを整理し、XMLのようなマークアップ言語で記述するフレームワークが研究されている。

【講演3】組み込みソフトウェア開発と非機能特性

  • 非機能要件は、拡張UMLで記述することが可能。そのためのステレオタイプが、十分ではないにせよ、整備されている。
  • 非機能要件は、プラットフォームとの対応付けが必要。よって、アーキテクチャを開発チーム全体で共有する必要がある。
  • 一方、セキュリティなど一部の非機能要件は、機能要件で代替することが可能。システムが許容できない機能の記述である「ミスユースケース」の利用も有効。
  • 非機能要件の評価技法は確立されていない。アーキテクチャの評価手法として、シナリオを活用したレビュー方法である「ATAM」がある。

----------
 わたしにとっては、知らない単語続出でした。その中でも「ゴール志向」「ATAM」の2つは、どうも基本用語だったようで・・・、勉強が必要です。会場にはゴール志向の本を読んでいた方もいるというのに、聞いたことすらないって。。。
 非機能要件や、システムインフラの品質評価の手法は、わたしの会社でも確固たるものがなく、研究中。今回のセッションで得たキーワードを元に、勉強を進めていこうと思います。
 なお、この講演で一番笑ったのが(笑うことが目的ではないが・・・)、ものすごく早口でびっくりさせられた、講演3のプレゼンター・岸教授の発言。「早い早い、早すぎるよ・・・もう少しゆっくり・・・」と思ってた講演の中盤、

 「ここまでのんびり話しすぎたので、ちょっと駆け足で行きます」