昨日の
情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。
の第二段。今日は、ＴＤＤ
ＴＤＤができる根拠は、シナリオにある。
外部設計終了段階、つまりＧＵＩが決まった時点で、
「この画面に、こういう値を入れたら、こうなるよね」
というのは、ユーザーで合意を取る。
また、外部インターフェース、とくにＷｅｂＡＰＩにおいて、
確認の意味をこめて、
こういうのを入れたら、
こういう結果が帰ってくるはず。
というサンプルを出す
（例：
ＹＡＨＯＯ ＡＰＩ 一番シンプルな地図の表示）
実装側は、このサンプルが動くように実装する。
つまり、サンプルを出した時点で、入出力の例が決まるので、
この例が実現できるように、プログラムを組んでいく。
まさにＴＤＤができるというわけだ。
実務的には、こんなかんじで、サンプルの実現というような形で
プログラムしていくんじゃないかなあ・・ちがう？？
（私はそうだけど・・）
だが、この話を受け入れるには、
「外部設計が完了するまで、シナリオないしはユースケース記述を行っている」
ということになってしまい、いや、実際そうなんだけど、
アカデミックな世界では、そう見ていない気がする・・・
つまり、機能要件、非機能要件は要求仕様で確定し、
外部設計の段階では要求を出すのではなく、
ユーザーインターフェースの決まりに従って、
機能要件・非機能要件に添った形で設計していく
というふうに見ているような感じがする。
前回出した「
機能要件の合意形成ガイド」では、機能要件は外部設計において、
最終合意されるという立場だけど（だから外部設計のガイドになっている）
大学では、機能要件は、要求仕様で確定し、
ＭＤＡによって、実装可能
にすらなると考えているようだ。
当然、この結果、大学の側からすると、シナリオ作成は、要求仕様の分野の
技術となる。でも、この要求分析のレベルのシナリオでは、ＴＤＤには使えない。
画面にどう入力するかまでわからないと、具体的なテストの値としては使えないのだ。
シナリオ自体には、画面の値を記述するまでの記述力がある
（自然言語で書くからね）
なので、実務的には、シナリオに近いものを書いて、ＴＤＤの元とし、
要求→外部設計→ＴＤＤの話は繋がる。
でも、大学の教える内容では、
要求 ｜ 外部設計 ｜ ＴＤＤ
と、この間の話が繋がらなくなる。むしろ、外部設計はＭＤＡが完成すれば
いらないんじゃないかと思っている節もある。
このへんが、ちょっと、大きな差なんですよね！
アクセス
トータル
ランキング
