システムの構造や実装方針を決定し，アプリケーションの機能，データ，画面などを定義する「基本設計」。ITエンジニアの「コア中のコア」と言えるスキルだが，「最近弱体化している」と指摘する声が増えている。今こそすべてのITエンジニアが，ユーザーの高品質，短納期の要求に応えるために，「基本設計」のスキルを改めて見直すべきだ。 「ベテランのエンジニアは基本設計の一般的な手順は理解しているが，高度化・専門化した実装技術を駆使したアーキテクチャの設計でとまどう。一方，若手エンジニアは実装技術には詳しいものの，肝心の基本設計の基礎的な方法論を理解していないことが多い」――。 こうした悩みは，多くの開発現場に共通する。これは，基本設計そのものが難しくなっているからにほかならない（図1）。 メインフレーム時代は，ウォーターフォール型の開発プロセスと自社の製品の知識さえあれば基本設計をこなせた。しかし，システム
Part5では，基本設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは，欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。 そこでPart5では，基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，（1）設計作業を実施する，（2）成果物をレビューして欠陥を洗い出す，（3）
Part3では，オブジェクト指向に基づく基本設計の方法論を，UP（Unified Process）をベースに解説する。下流工程で試行錯誤を繰り返さないためには，「実行可能なアーキテクチャ」を構築することと，アーキテクチャの利用方法を解説した「アーキテクチャ説明書」が極めて重要になる。 Part2では，主にウォーターフォール型開発プロセスとDOA（データ中心型アプローチ）に基づいた基本設計の手順を示した。だが，最近はWebシステム開発を中心に，反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。 そこでPart3では，オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP（Unified Process）を例にとって，オブジェクト指向設計における基本設計の勘どころを解説しよう。 動くアーキテクチャを作る UPでは「方向付け」，「推敲」，「作成」，「移行」という4つ
高品質で変化に強いシステムは，アーキテクチャの良し悪しに依存する。だがアーキテクチャの設計は，外部システムとの連携や性能・信頼性の確保など考慮すべき点が多く，困難を極める。そこで利用したいのが，先人たちが生み出した方式設計のひな型である「パターン」だ。 ここ数年で，「パターン」という言葉がよく使われるようになった。読者も耳にしたことがあるだろう。 そもそも「パターン（Pattern）」とは，ある問題の解決策をテンプレート（ひな型）として記述したものである。問題を解決する手順や方法が記されているため，パターンを利用することで，迅速かつ確実に問題を解決できる。採用したパターン名をお互いに伝え合えば，メンバー間のコミュニケーション・ギャップも少なくなる。ただし，何でもパターンになるわけではない。再利用の価値があるものだけがパターンとなる。 パターンそのものの起源は古く，1970年代に米カリフォル
ITアーキテクトとして，システムの全体構成や使用する製品の選定，アプリケーション・アーキテクチャ設計までを手掛ける「方式設計」を担当することは，重圧を感じつつも非常にやりがいを得られるものである。ところが，苦労して美しいアーキテクチャにしたはずなのに，開発がスタートすると次第にアプリケーション開発者によって「見覚えのない方式」があちこちに導入され始めたり，全く意図しない実装になったり，リリース間際にはツギハギだらけの構造に仕上がっていて悲しい思いをしたりすることがある。 悲しい思いをするだけならともかく，意図から離れた実装をするようになると，保守性が悪くなったり，性能に悪影響を及ぼしたりする。ITアーキテクトは，アプリケーション開発者が方式設計通りに開発してくれると思ってはいけない。方式設計通りに開発してくれるように導かなければいけないのである。 筆者が実際に経験したものから例を挙げると，
○○さんへ 続きを読む 前回、方式設計のミッションと思われる（ちょっと自身ない）を列挙してみました。こうすると、方式設計とはプロジェクトそのものをデザインする工程だと思ったです。 ソフトウェア・デザインと同様、この設計が後の工程に与える影響は少なくないです。無駄なタスクやリスクの見過ごしがいったいどんな結末を生むのか、いくつかのパターンは皆さん見た事、体感した事があると思います。 続きを読む
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
