FC2ブログ

[Other]209/8/28 第6回UMTPモデリング技術セミナー、参加レポート

 UMTP Japan - UMTPモデリング技術セミナー 第6回開催(2009-08-28)のご案内

に、参加してきました。

 会場はオフィス内でしたので、周辺写真等は撮影しておりません(もっとも、有名なビル街のまっただ中ですので、場所の特定は簡単ですね)。

 当日は快晴で、とても暑い一日でした。開始時間が13:30ということで、すこし前までお昼の時間帯でしたから、エキナカから地下道を通ってビルに到着するまで、かなりの人混みだったことを覚えています。

 このセミナーは、主にUMTP L2合格者を対象としたものだそうで、中心としているテーマは要件定義でした。その中で、UMLを拡張したsysMLという表記法をご紹介いただきました。

  1. 要求モデリング
    • 要求定義工程は、前後の工程から独立した工程として行うことはできない
    • 単独で要求定義工程を行おうとすると、テスト工程や運用フェーズに移行後に出てくる要求を見落とす可能性がある
    • ソフトウェアの分類(SPE分類)
      • 一つの定まった手法で要求定義を完璧に行うことができる、というのは神話
    • 境界条件
      • 人工物には、境界条件による限界が必ずある
      • その点で、自然物とは区別される・・・常に明文化されない、暗黙の条件、仮定の下でのみ成立する
    • 「正しい要求」と「望ましい要求」
      • 「望ましい要求」が、つねに[正しい要求]とは限らない・・・顧客のいいなりになることが必ずしも正しいとは言えない
    • 要求の実現可能性は、その根拠が常に明確でなければならない
      • 要求の実現可能性を明確にすることがプロジェクトのリスクを低減する
    • 要求工学と呼ぶべき領域は、いまだ体系化されているとは言えない
  2. 非機能要件
    • 例えば、オペレータの振る舞いのように、ソフトの作り込み以外の要素についても要件の一つと考えなければならない
      • MUFG証券で発生したセキュリティ事故:管理者の悪意ある行動を未然にチェックできなかった
      • ユーザビリティの問題も、たぶんそう
    • 外部環境
      • 目的、ステークホルダ、ユーザー特性(オペレーションに従事するのがアルバイトか呪暮れのオペレータか、など)、ビジョン、ミッションといった、システムの外的要因を定義しておくことが必要となる
    • セキュリティ
      • 外部との相互作用(システムの「使われ方」)を明確に定義することが、セキュリティを確保するために必要
    • 三つのE
      • 明示的主張
      • 証跡
      • 知識
    • 信頼性の観点 ※下記それぞれについて、KPIを定義しておくことが必要
      • 開発作業中の信頼性
      • 運用中の信頼性
      • トラブル時の信頼性
    • 問題フレームの紹介
    • 要求仕様の完了基準の紹介
      • Leveson,N.G.
    • 要求レビューの手法
      • チェックリスト
      • シナリオ
      • その他...
    • レビュー指摘
      • レビュー中は、要求誤りと指摘誤りの二つのミスに注意する
      • 指摘誤り(正しい動作を誤りと誤判定すること)を避けるには、れびゅあー自身が要求を正確に把握しておく必要がある
      • アクターとイベントは常に明確にしておかなければならない
  3. ゴール指向
    • ゴール指向とは
      • BSCやTOCも、ゴール指向分析の一種である
      • 目的(何を以て望ましいとするか)については、基準、達成度、優先度などの属性が存在する
    • NFR分析の紹介
      • ゴール/サブゴール/ソリューションの階層構造である
      • システムを、各構成要素(たとえば、クライアント、サーバ、ネットワーク)に分解し、それぞれについて構成部品とソリューションを紐付けしていくことで、モレなく対策を講じることができるようにする
    • i*フレームワークの紹介
    • GQMの紹介
    • BSCの紹介
    • UMLビジネスモデルの紹介
    • リザルトチェーンの紹介
    • SysMLの紹介
      • 従来のUMLを拡張したモデル
      • Requirement Dialogなどを追加し、ソフトウェア要求に限らずシステム要求全体を記述できるようにした
      • 要求菅野総監を示すステレオタイプが定義されており、要求をゴールツリー形式で階層的に表現する
    • GSN(Goal Structure Notations)の紹介
      • ゴール、戦略(サブゴール)、コンテクスト(外部入力)を系統樹として記述する
      • 各ゴールや戦略は、最終的にソリューションに関連づけられなければならない。ソリューションが未定義であるゴール/サブゴールについては、ソリューションが未定義であることを明示的に記録する
スポンサーサイト



FC2ブックマーク | この記事をokyuuへインポート | このエントリーを含むはてなブックマーク | ニフティクリップへ追加 | この記事をクリップ! | イザ!ブックマーク | POOKMARK Airlinesに登録する | del.icio.us |
動作未検証 | | 動作未検証 | 動作未検証 | 動作未検証 | 動作未検証 | 動作未検証 | 動作未検証 | 動作未検証 | 動作未検証 | 動作未検証 | 動作未検証

comment

管理者にだけメッセージを送る

カレンダー
10 | 2019/11 | 12
- - - - - 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
最近の記事
月別アーカイブ
カテゴリー
ブログ内検索
RSSフィード
リンク
いろいろリンクボタン
埋め込みe-Words