テスト分析とテスト設計の違いについて

Tsuyoshi Yumoto @yumotsuyo

うん、もう横に置いていいからこういうことを知った方が良いね。RT @mkoszk: テストにおける分析と設計は横に置いておくことにする。 分析と設計に悩んでいるのであれば、遠回りかもしれないけど、構造化分析と構造化設計をさらっと見ておくと、理解が進むかも...

Tsuyoshi Yumoto @yumotsuyo

工夫する事と理解する事がごっちゃになってて、やっている事との意味と手順もごっちゃになってる。RT @mhlyc: 課題解決のために工夫するのが設計としてしまうと、なんでも設計に含まれてしまうのではと思いました。分析と何が違うのだろうかとモヤモヤが深まりました。

Tsuyoshi Yumoto @yumotsuyo

ツイッターで説明すんの面倒だからウチにこい！

Tsuyoshi Yumoto @yumotsuyo

ホント、やりましょうか。RT @akiyama924: @yumotsuyo そうね。対話したほうが良いと思います。 たとえばJaSST17東京の初日の午前中にテスト分析とテスト設計の違いに関心のあるひとが集まって会議をするとか。

Yasuharu NISHI @YasuharuNishi

ゆもつよさんの場合一貫してない例と高いコミュ力で済んじゃうから、対話しない方がゆもつよメソッドの進化のためにはいいと思うの。 RT @yumotsuyo: ツイッターで説明すんの面倒だからウチにこい！

鈴木三紀夫 @mkoszk

要件定義の後工程が基本設計や外部設計だとして、基本設計や外部設計で要求分析をするか、という問いと仮定します。 組織の標準プロセスを設計するとき、設計で要求分析というアクティビティは入れません。 でも現場では、例えば要件定義を別会社が実施している場合、テーラリングして入れますね。 twitter.com/mhlyc/status/8…

リリカル @mhlyc

開発工程における分析は、例えばV字モデルでいうと要件定義のあとに要件分析みたいなのがあるのかなと思います。要件を仕様に落とし込むのが設計ですから、その前にどんな要件があってどんな構造をしていて、どう設計すればうまく整理できるか考えるのは開発工程における分析かなと思いました。

2016-12-19 09:13:24

鈴木三紀夫 @mkoszk

要件定義の後工程が基本設計や外部設計だとして、基本設計や外部設計で要求分析をするか、という問いと仮定します。 組織の標準プロセスを設計するとき、設計で要求分析というアクティビティは入れません。 でも現場では、例えば要件定義を別会社が実施している場合、テーラリングして入れますね。 twitter.com/mhlyc/status/8…

リリカル @mhlyc

@mkoszk 要件定義を同じチームの別の人が実施している場合も、要求分析は必要になりませんか？

鈴木三紀夫 @mkoszk

@mhlyc プロジェクトのプロセス設計をプロジェクトマネージャーが行うとします。プロジェクト特性に合わせて、PMが判断すればよいのではないでしょうか。 当該PJに集められた人達が初顔合わせのようだったら入れるでしょうし、○○組と呼ばれるようなPM一座だったら入れないでしょうし。

鈴木三紀夫 @mkoszk

@mhlyc 疑問、というか、もやもやしているところは、そこなの？

リリカル @mhlyc

@mkoszk モヤモヤしているのは、テストにおいてなぜ分析が必要なのか、なぜ設計が必要なのか、なぜ分析と設計を分けなければならないのかです。 そのために分析と設計は開発工程ではどこに対応するだろうかと考えました。僕は要求分析の後に設計を行うだろうと思いました。

鈴木三紀夫 @mkoszk

@mhlyc 要件定義は工程名称、要件分析はアクティビティ名称であっている？ 一般的な開発プロセスでは、要件定義工程内に要件分析が入っているけど、基本設計内にすべきという意見？ それとも、設計前に要件を確認し理解するところから始めるよねと言っているの？

リリカル @mhlyc

@mkoszk 要件定義工程内に要件分析が入っている→自分が要件定義をよく理解していなくて、入っていないのかと勘違いしていました…　入っているなら問題ありません。主張したいのは「設計前に要件を確認し理解するところから始めるよね」ということです。

鈴木三紀夫 @mkoszk

@mhlyc ちなみに、要求分析または要件分析は、「要求」または「要件」の分析で設計とは関係ないよ。だから要求分析や要件分析と言ってしまうと誤解される可能性があるので、「要件を理解するためのアクティビティ」があるぐらいにした方がとおりがいいと思うよ。

鈴木三紀夫 @mkoszk

@mhlyc と、REBOKの要求分析章の担当は言ってみる

リリカル @mhlyc

@mkoszk なるほど。「分析＝分解して整理し、対象を理解すること」というように定義するなら、「要件を理解するためのアクティビティ」は要件分析といえるのではないかと思い先の発言をしました。

Tsuyoshi Yumoto @yumotsuyo

うーん、「要件を仕様に落とし込むのが設計ですから」これって誰に教わったんですか？RT @mhlyc: 開発工程における分析は、例えばV字モデルでいうと要件定義のあとに要件分析みたいなのがあるのかなと思います。要件を仕様に落とし込むのが設計ですから...

リリカル @mhlyc

@yumotsuyo 書籍に書いてあった覚えはないですが、昔会社の先輩に「一番広いのが要求。そのスコープを絞ったのが要件。要件をどう実現するか考えるのが設計」と教わりました。

Tsuyoshi Yumoto @yumotsuyo

@mhlyc その先輩の言ったことは合ってる。けど、その先輩も要件を仕様にすることが設計だとはいってないよね。

リリカル @mhlyc

@yumotsuyo 要件を仕様化すること＝設計　ではないのですか？　要件を実現できるような形にするのが仕様化であり、設計であると思っていました。

あきやま🍠 @akiyama924

ここがボタンの掛け違いだったのか。 仕様は具体化のことです。 要求が具体化できたら要求仕様ですし、設計が具体化できたら設計仕様ですし、性能を具体化したら性能仕様です。 twitter.com/mhlyc/status/8…

リリカル @mhlyc

じゃあ設計書と仕様書って全然違う意味じゃないですか！今まで大体同じ意味なのかなって勘違いしていましたよ！と新しいモヤモヤポイントが… twitter.com/akiyama924/sta…

リリカル @mhlyc

というか設計仕様書とはなんだろう。画面設計をするとしたら、画面設計書と画面仕様書と画面設計仕様書は違うものなのかな？今までは大体同じようなものだろと思っていた。

リリカル @mhlyc

分析はなんとなくわかって来たけど、むしろ設計がなんなのか不明。

あきやま🍠 @akiyama924

@mhlyc 全然違う意味ですよ。 機能仕様書は機能を具体化してみんながこれ(What)を作ればいいんだって確信するためのものですし、機能設計書は機能を実現するための方法(How)を描いた図面（ソフトウェアではUMLのような図ではなく文章の場合も多いけど）のことです。