サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

ソフトウェア開発 旧館より

仕様を縦断する視点、横断する視点

投稿日:2008年4月15日 更新日:


外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。

レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。

そこではある要求仕様が、その該当画面(とそこで定義されている機能)で過不足なく満たされているかを焦点にレビューします。
上記の焦点の結果、「システム全体を通じて」複数の機能の観点からが漏れがちになることが時々あります。

例えば…

「A画面では要求仕様書の要望の**という点を考慮して設計している」ということがレビューされ、OKが出たとします。
が、一方、B画面では同じ要望を「別の観点」で考慮した設計になっていることがあります。

この結果、単機能レベルでの単体テストは順調にクリアされても、いざ結合テスト時にインターフェース不備によるバグが多く発生することになります。
#要求仕様管理がキッチリ出来ていればこういう漏れは防げるように思いますが…それはそう簡単では無く…。

原因の1つにA画面で検討した仕様/内容/問題点に対する同じ視点(=同じ要求仕様からの視点)でB画面を検討しないこと、もしくは検討した結果、2つの結論が異なってしまうことがあります。

その仕様が、どの要求仕様に対するものか分かる…フェーズを縦断したラインでのトレースはできることが多いです。
そこそこな規模の開発プロセスでは各フェーズにおけるインプットとアウトプットが明確に定義されていることが大半です(現場でそれが実践されているかはまた別として…)。

ですが、同フェーズ内において、機能間で要求仕様に対して整合性の取れた設計になっているか…つまり横のラインでのトレース、管理ノウハウってそれ程知られていないような気がします。

上流工程→下流工程への情報の伝達や管理ノウハウは色々情報があります。それこそ本やWebで山程見つかります。
が、横の連携はかなり泥臭い方法で今もしているような気がします。

プロジェクトがうまく行かなくなる要因の1つに、この横の連携の破綻があるのでは?と考えています。
実際、下流工程になれば一気に人が増えることが多く、横の連携で要求仕様や設計に対し共通した認識が持てているかがポイントだと思います。

明確な答えが出ているわけ色々なプロジェクトで遭遇している実装フェーズなどにおける仕様ズレによる手戻り防止のきっかけになればと思っています。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visual Hunt

-ソフトウェア開発, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

最高のプレゼンテーション―心をつかむ見せ方、話し方[読書感想]

最高のプレゼンテーション―心をつかむ見せ方、話し方 プレゼン = 「パワポ(PowerPoint)を作らな!!」+「本番でのしゃべり!」となるのがだいたいの感じだと思いますが、この本はプレゼン = ( …

SCRUM BOOT CAMP THE BOOKを読みました

「SCRUM BOOT CAMP THE BOOKはいい本です!マネージャーも開発者もみんな読んでみてください!」で終わらせようと思ったら・・・ @yohhatu それでもいいけどw もうちょっとww …

「今年の漢字は?来年の漢字は?」アクティビティ

先日、所属組織の忘年会でちょっとしたイベント?ゲーム?をしたので紹介します。 メンバーによりますが、2時間ダラダラ話したり、若手が(半ば押し付けられる形で)芸をしてお茶を濁すような宴会は、あまり好きで …

インプットとアウトプットのバランス

仕事ではインプットに対してどのようなアウトプット(成果物)を出すかが大事です。 一握りの創造性豊かな人以外にとって、そのアウトプットの元ネタとなるインプットが存在していることが大半です。 インプットは …

タスクマネジメントツール「Trello」

今のところ、個人で一番使っているタスクマネジメントツール「Trello」です。 Trelloとは? 「Fog Creek Software」が提供しているWebベースのタスクマネジメントツールです。 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。