<< XP, ICONIX, ウォーターフォール系 : 要件定義 詳細化 | main | 自分でやるなら  教えるなら >>

実践 ICONIXプロセス : 要件定義

ICONIXプロセスでは、要件定義の主な活動は次の3つ。

● ドメインモデリング (用語集:概念クラス図)
● ユースケースモデリング
-- ユースケースパッケージ図とユースケース図 (機能体系、メニュー体系)
-- それぞれのユースケースの記述
● 要求レビュー (関係者で集まって認識あわせ)

要件定義のための情報収集は、

・画面の紙芝居
・要求の箇条書き
・業務マニュアル

などをあげている。

また、要件定義の初期の作業で、既存システムの調査もあげている。

・既存画面の調査 (ユースケースモデリングの参考情報)
・既存テーブルの調査 (ドメインモデリングの参考情報)

何度も書いている通り、要件定義は、ウォーターフォール系のやり方と本質は同じ。ウォータフォール系のやり方では、もっと細かく手順や書式を決めているけど、やっていることを(乱暴に?)要約すると ICONIXプロセスになる。

ウォーターフォール型の開発プロセスの手順や書式を勉強するのは良いことだと思います。いろいろ参考になる点がある。フルセットで完全に実施する価値はないと思いますが、自分たち流にカストマイズして軽量プロセスでやることは意味があると思います。 Unified Process (UP) は、最初から、カストマイズすることを前提にしているみたいですね。 自己流でトライアンドエラーするより、何か参考になるものをうまく流用したほうが楽ができます。

XP は、クラス図を描けとか、ユースケースを記述せい、とは言っていないけど、必要に応じてやっている。 Kent Beck は、XP では、プロジェクトの最初から最後まで、毎日、要求分析と設計をする。 一日のうち4時間は、分析や設計だといっている。 コード書くのは30分以下らしい。 のこりの3時間ちょっとは、テストと(チームメンバーへの?)サポート。 

XP では、顧客がチームメンバーだから、毎日が要件定義の日々らしい。
XP の要件定義の最初のインプットは、短文のユーザーストリー。 一件一枚のカードに書く。典型的には50枚から100枚くらいらしい。

これって、顧客からの要求の箇条書きだし、もうちょっと形式的にソフトウェア要求仕様書とかと同じものですよね。

参考: http://ootips.org/xp.html

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM