要求仕様書の標準化プロセス
「DUNGEON」はソフトウェア開発の各工程において必要とするドキュメント標準を決めて、その具体的なテンプレートを用意したものです。概念的なアプローチとはまったく逆に、アウトプット側から開発プロセスを標準化するという実践的な考え方を重視しています。 これまで7回にわたって、基本設計から詳細設計、プログラミング、単体テスト、結合テスト、総合テストという流れに沿って、各プロセスで必要とするドキュメントの標準化を説明してきました。最終回の今回は、その前段のプロセスである要求分析フェーズのアウトプットについて説明します。 みなさんはSLCPという言葉を知っていますか。SLCPとはSoftware Life Cycle Processの略で、ソフトウェアの開発ライフサイクル、つまりこれまで解説してきた基本設計から総合テストまでの開発工程を指す言葉です。SLCPの代表的なものは30年前に提唱されたウォ
第39回 Web開発者との付き合い方 〜Web屋の一分（いちぶん）：ITpro
前回は，コミュニケーション・コストについて触れましたが，今回はもう少しWebサイト・デザインに絞って話をしてみたいと思います。 意見集約という「小リーダー」の役目 前回の復習になりますが，何か大きな事柄を決めようようとするとき，あまりに民主的に行うと，意見を集約するのに膨大な時間がかかります。私は，Web開発にとって「時間」が一番大切だと思っているので，結論を出すまでのプロセスを効率化することは至上命令です。 様々な方法があるかもしれませんが，基本的には，機動性の良いグループ単位で意見を集約し，代表者会議の場で即決できることが鍵になるように思えます。小グループの小リーダーたちの機動力と，権限を持っているという体制，これに勝るものはないでしょう。 そして，意見集約の効率化という側面だけでなく，クライアントの担当者が時間までに難しい結論を決めてきてくれたり，決をとる場で「責任は俺が取るから」と
意図が伝わる設計書作成の心得【第5回】
仕様書の品質を均一化するためにテンプレートを利用する現場は多いと思うが，正しく運用できているだろうか。ちょっとした心がけの違いで，過剰品質の原因となったり，型にはまりすぎた平板な仕様書を生みだしたりする。「テンプレートの利用に伴う弊害」をテーマに取り上げ，よく起こる2タイプの事例を通して，予防するための心得とは何かを考えてみたい。 仕様書を作成する際，記述する情報の質と量が重要であることは言うまでもないが，その記述レベルは人によってばらつきやすい。特にシステムの規模が大きければ，仕様書の作成にかかわる人の数が増え，生み出される仕様書の質と量のばらつきも大きくなってくる。 このような問題を避けるため，書式や記述レベルを均一化する目的で仕様書の「テンプレート（ひな型）集」や「ガイドライン」を用意したり，プロジェクトの実情に合わせた「記述サンプル」を作って配布したりする開発現場は多いだろう。仕様
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
