[ThinkIT] 第3回：基本設計書 (1/3)第1回で「業務フロー」、第2回で「機能一覧表とI/O関連図」について説明しました。今回は残りのアウトプットを取り上げて、基本設計フェーズのドキュメント標準を完了させることにします。「DUNGEON」の標準で定義されている基本設計工程のアウトプットは、表1の通りです。
Part1 今こそ「基本設計」のスキルを見直す
システムの構造や実装方針を決定し，アプリケーションの機能，データ，画面などを定義する「基本設計」。ITエンジニアの「コア中のコア」と言えるスキルだが，「最近弱体化している」と指摘する声が増えている。今こそすべてのITエンジニアが，ユーザーの高品質，短納期の要求に応えるために，「基本設計」のスキルを改めて見直すべきだ。 「ベテランのエンジニアは基本設計の一般的な手順は理解しているが，高度化・専門化した実装技術を駆使したアーキテクチャの設計でとまどう。一方，若手エンジニアは実装技術には詳しいものの，肝心の基本設計の基礎的な方法論を理解していないことが多い」――。 こうした悩みは，多くの開発現場に共通する。これは，基本設計そのものが難しくなっているからにほかならない（図1）。 メインフレーム時代は，ウォーターフォール型の開発プロセスと自社の製品の知識さえあれば基本設計をこなせた。しかし，システム
Part5 基本設計におけるレビューの勘どころ
Part5では，基本設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは，欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。 そこでPart5では，基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，（1）設計作業を実施する，（2）成果物をレビューして欠陥を洗い出す，（3）
Part3 オブジェクト指向の基本設計を理解する
Part3では，オブジェクト指向に基づく基本設計の方法論を，UP（Unified Process）をベースに解説する。下流工程で試行錯誤を繰り返さないためには，「実行可能なアーキテクチャ」を構築することと，アーキテクチャの利用方法を解説した「アーキテクチャ説明書」が極めて重要になる。 Part2では，主にウォーターフォール型開発プロセスとDOA（データ中心型アプローチ）に基づいた基本設計の手順を示した。だが，最近はWebシステム開発を中心に，反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。 そこでPart3では，オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP（Unified Process）を例にとって，オブジェクト指向設計における基本設計の勘どころを解説しよう。 動くアーキテクチャを作る UPでは「方向付け」，「推敲」，「作成」，「移行」という4つ
Part2 設計手順の基本を身に付ける
Part2では，多くのシステム開発で実績を持つ日本IBMの「IBM-DOA」に基づく外部設計フェーズの手順を説明する。ここで紹介するDOAに基づく複合／構造化設計手法は，どんなプロジェクトにも応用できる基本的なアプローチだ。基本をしっかりと身に付けてほしい。 DOA（Data Oriented Approach：データ中心型アプローチ）は対象システムの「データの流れ」の把握に重点を置きながら，要件定義や設計を進めていくアプローチである。 DOAには様々なタイプがあるが，日本IBM独自の「IBM-DOA」では，主に業務全体をデータの流れに着目して図で表現するDFD（Data Flow Diagram）を使って業務を分析・設計していく。Part2では，この「IBM-DOA」に基づく外部設計フェーズの進め方を説明しよう。「今さらDOAか」と思わないでほしい。最も基本的で一般的なアプローチなので，
Part4 方式設計で利用できる「パターン」を知る
高品質で変化に強いシステムは，アーキテクチャの良し悪しに依存する。だがアーキテクチャの設計は，外部システムとの連携や性能・信頼性の確保など考慮すべき点が多く，困難を極める。そこで利用したいのが，先人たちが生み出した方式設計のひな型である「パターン」だ。 ここ数年で，「パターン」という言葉がよく使われるようになった。読者も耳にしたことがあるだろう。 そもそも「パターン（Pattern）」とは，ある問題の解決策をテンプレート（ひな型）として記述したものである。問題を解決する手順や方法が記されているため，パターンを利用することで，迅速かつ確実に問題を解決できる。採用したパターン名をお互いに伝え合えば，メンバー間のコミュニケーション・ギャップも少なくなる。ただし，何でもパターンになるわけではない。再利用の価値があるものだけがパターンとなる。 パターンそのものの起源は古く，1970年代に米カリフォル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
