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

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

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

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

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


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

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

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

例えば…

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

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

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

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

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

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

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

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

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

Photo via Visual Hunt

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

執筆者:


comment

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

関連記事

もっと会議の時間を有効に使いませんか?

今回は、ある会議に出ていて「もう少し効率良く時間を使えるなぁ」と思ったことを書きます。 出席者は地理的に離れている複数チームです。 チームごとのタスクは異なりますが、活動領域には重複する部分もあり協力 …

変更履歴を論理的に見ておかしいと思わないのは…

仕事での行動基準…うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容…を考えることがありました。 SEが作成するドキュメント(堅く言うと「成果物」)にはたいがい「変更履歴」を記入する欄があり …

勝手に親近感

Twitterや社内SNSなどで、「実際に会った」ことも「直接話した」こともない…けれど、その考え方やアクション、マインドにすごく共感したりする方々がいます。 その中には「こんな方を目標にしたい!」と …

会議での「KY読めよ」な空気がキライ

議論が活発な会議で、費用対効果が出ているような会議ならそんなことはないのですが…。 生産的で無い、一方通行的報告的会議で質問すると… 「時間無いねんから」 「そんなんどうでもええやん」 …的な空気にな …

「従業員」満足度調査

本人が望む、望まないは別として「顧客満足度調査」等のようなアンケートに答えたことが1回はあると思います。 その兄弟で「従業員満足度調査」なるものがあります。 「自分の会社にどれほど満足しているか1~5 …

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