|
|
|
Page1
Page2
|
変更シナリオと変更への対応
プロジェクトを成功に導くアーキテクチャは、変更が生じる可能性の高い部分をあらかじめ明確にしていることが多い。プロジェクトを失敗させる最大の要因となるのは、プロジェクトがかなり進んでから予想もしなかった変更が加えられることである。たとえば、設計が完了し、コーディングが始まってから発生するような変更がこれに当たる。こうした変更に的確に対処できないプロジェクトは、たとえその変更が発生するまで適切に管理が行われていたとしても、困難に陥ることになる。したがってアーキテクチャには、プログラムに発生し得る変更の一覧と、それぞれの変更への対処法の概要を記載しておく必要がある。また、要求が確定していないと､後になって変更が生ずる可能性が高くなるので、アーキテクチャには未確定度の高い要求を列記しておくべきである。
問題を引き起こす要因としては、補助的なテクノロジが変更されるというケースもしばしば見られる。たとえば、使用していたクラスライブラリの供給元の会社が開発者の知らぬ間に倒産していたというような場合である。外部のテクノロジ（コンパイラベンダー、ハードウェアプラットフォームなど）を利用する場合は、特定の供給元だけに依存しないようにする必要がある。やむを得ない場合は、万が一その唯一の外部テクノロジに依存できなくなっても開発者が回避策を採れるように、アーキテクチャに防護壁を作っておかなければならない。
どのような変更が起こり得るかを予測するときには、8割方の予測を行った時点で作業をやめるべきである。可能性のある変更をすべて予測することはおそらく不可能だし、8割以上正確に予測しようとする作業は、負担に見合う効果が得られない。
再利用分析と内製/購入の意思決定
アーキテクチャに含める重要な項目として、コンポーネントの入手方法の指定がある。市販品を購入するのか、組織内のソースから再利用するのか、ゼロから内製するのかを、それぞれのコンポーネントについて決めておく。
コンポーネントを再利用するかどうかは、ソフトウェアの設計全体に影響を及ぼすので、アーキテクチャ設計時に決めておかなければならない。たとえば、市販されているアプリケーションの枠組みを利用して新しいアプリケーションを作成するとアーキテクチャチームが決定した場合、ソフトウェア全体をその枠組みに基づいて設計する必要が出てくる。アーキテクチャ設計時にコンポーネントの再利用の是非を考慮するのは、再利用するかどうかによってコストとスケジュールが多大な影響を受けるからでもある。まったく新規にソフトウェアを作成する代わりに、コンポーネントを購入するか、または組織内のソースを再利用すれば、スケジュール短縮とコスト低減に最大限の効果を発揮する。
アーキテクチャチームが積極的に再利用を考慮すべき対象は、ソースコードにとどまらない。データ、詳細設計、テストケース、計画、マニュアル、およびアーキテクチャの構成要素なども、場合によっては再利用可能なので、検討対象とすべきである。
標準的な機能に対するアプローチ
設計に関する決定の中には、個別のコーディングに広範な影響を与えるものがある。したがってアーキテクチャでは、システム全体の構成を検討することに加えて、こうした設計に関する決定のうち最も広範に影響するものにも対処しておく必要がある。次に示すのは、アーキテクチャで設計時に決定すべき典型的な機能の一部である。
◆ 外部ソフトウェアとのインターフェイス
作成するソフトウェアは他のソフトウェアとデータのやり取りをする可能性があるか。関数呼び出しには何を使用するか。プログラムインターフェイスを通じて渡されるデータはどのような構造をしているか。それはどのような形式か。
◆ ユーザーインターフェイス
ユーザーインターフェイスはシステムの他の部分からどの程度独立しているか。インターフェイスの変更が他のソフトウェアコンポーネントに影響することはないか。
◆ データベースの構成
データベースの構成と内容はどうなっているか。
◆ データストレージ
データベース以外のデータをどのように保存するか。どのようなファイル形式を使用するか。主なデータ構造はどのようになっているか。
◆ 主要なアルゴリズム
ソフトウェアの主要なアルゴリズムはどのようなものか。すでに定義されているのか、あるいは新しいアルゴリズムを定義することもソフトウェアプロジェクトの作業に含まれるのか。
◆ メモリ管理
個々のプログラム要素に対するメモリの割り当てはどのような方針で行うか。
◆ 文字列の保存方法
エラーメッセージのようなテキスト文字列の保存と呼び出しはどのように行うか。
◆ 並行処理とスレッド
ソフトウェアはマルチスレッドをサポートするか。マルチスレッドをサポートする場合、並行処理や再入など、関連する問題をどのように処理するか。
◆ セキュリティ
ソフトウェアはセキュリティの確保された環境で稼働する必要があるか。その必要がある場合、ソフトウェアの設計にはどのような影響があるか。
◆ ローカライズ
ソフトウェアがもともとターゲットとしている言語以外の言語を使用している国で、そのソフトウェアを使用する可能性はあるか。テキスト文字列、文字セット、文字を書く方向（左から右ではなく右から左に書く）が異なる場合はどのように処理するか。
◆ ネットワーク
ネットワーク上でのマルチユーザーによる操作をどのようにサポートするか。
◆ 移植性
複数の環境における動作をどのようにサポートするか（たとえば、UNIXとWindowsの両方で動作可能にする場合）。
◆ プログラム言語
ソフトウェアのコードの作成に任意のプログラム言語を使用することが可能なアーキテクチャか。それとも、特定の言語しか使用できないか。
◆ エラー処理
エラー処理に関する一貫した方針をアーキテクチャで指定しているか。
要求のトレーサビリティ
アーキテクチャチームは「要求のトレーサビリティ表」を作成する必要がある。本書の「第9章 品質保証」でテストケースに関連して紹介したのと同様のものである。
要求のトレーサビリティ表を作成するのは、往々にして退屈な作業であり、ときにはイライラする作業でもある。というのは、アーキテクチャが完成したと思ってトレーサビリティ表でチェックしてみると、どのサブシステムでもサポートされていない要求が、必ずいくつかは見つかるからである。しかし、そのときはいら立っても、サポートされていない要求が見つかるのは喜ぶべきことである。アーキテクチャ設計時にエラーを発見して修正する時間は、同じエラーを構築作業やシステムテストの最中に発見して修正する時間に比べて、50〜200分の1で済むからである。
|
要求開発のフェーズでは、実現できるかどうかわからない危険性をはらんだ機能が存在し得る。プロジェクトチームはその時点でそのような機能の一覧を作成しておいたはずである。アーキテクチャ設計が完了するまでには、その一覧の項目のほとんどについて解決しておかなければならない。実装方法の概要を明確にするか、または、実装が不可能であると判断したらその項目を一覧から削除し、それ以降の検討対象から外しておく。
ステージ別納品計画書との整合
アーキテクチャ設計において、本書の手法を採用するプロジェクトにとってはきわめて重要な特徴がもう1つある。それは、アーキテクチャがステージ別納品計画書と整合していなければならないという点である。ステージ別納品計画では、機能を複数のステージに分けて開発し納品する。それをアーキテクチャがどのようにサポートするかをソフトウェアアーキテクチャ文書に記述しなければならない。特に肝心なのは、一度にまとめて実装しなければならず、複数のステージに分割できないようなサブシステムに他のサブシステムが依存するようなアーキテクチャを作成しないことである。システムを構成する個々の部分の依存関係を明確にして、ステージ別納品計画書と整合する順番でそれぞれの部分を開発するように、詳細に計画を作成しなければならない。
アーキテクチャ設計時には特に、ステージ別納品に対する反感が強くなるものである。ステージ別納品を行うためには、アーキテクチャに関して「最適とは言えない」決断が必要になることがあるからだ。たとえば、仮の足場となる一時的なコードを作成しなければならない場合がある。これは、他の手法を採用すれば不要なものだ。あるいは、サブシステム間の依存度を最小限にするために作成するコードが増えてしまうこともある。しかし、このとき念頭に置いておくべき重要な問いは、「何に対して最適とは言えないのか」ということである。重要な機能がプロジェクトの終了時まで納品されないようなアーキテクチャは、最適であるとは言えないだろう。同様に、プロジェクトを中止に追い込むほどのリスクを内包する実装方法に依存するようなアーキテクチャも、最適であるとは言えない。アーキテクチャは、完成システムが目指す固定的な最終目標だけを念頭に置いていては設計できない。開発の各段階ごとの動的な中間目標も考慮して設計しなければならない。
アーキテクチャの完成を判断する目安
どの時点でアーキテクチャが完成したと言えるかを見極めるのは、非常に難しい。ある意味では、そのアーキテクチャに「賭ける」覚悟ができるまで、完成したとは宣言できない。つまり、アーキテクチャチームがアーキテクチャをこれ以上変更しないと決め、プロジェクトを先へ進めてよいと判断するまで、完成したと宣言できないのである。現実にはもちろん変更は行われるのだが、アーキテクチャチームはそれくらいの確信を持っているということである。
しかしある意味では、アーキテクチャは決して完璧ではあり得ない。どこかの時点で開発チームは、プロジェクトの次の段階へ進まなければならない。チームは、プロジェクトがコーディングの段階に入るまで設計に関するすべての問題を完全に把握することはできない。したがって、アーキテクチャが完璧であることを期待すべきではない。
|
完璧を目指して努力すると、結局何も達成できなくなることが多い。大切なのはミニマリズムとシンプルさ、そしてすべての要求をサポートすることである。たった1つの最良の解決策を見つけることにこだわる必要はない。
アクティビティと成果物を十分に定義して綿密に監視することを忘れてはならない。さもないと、アーキテクチャチームの作業はとかく暴走しやすく、アーキテクチャ設計フェーズ自体が成果を出せずに終わるおそれがあるからだ。
ソフトウェアアーキテクチャ文書
アーキテクチャの作業が完了したら、「ソフトウェアアーキテクチャ文書」を作成する必要がある。この文書は変更管理委員会に渡され、回覧してレビューを受け、必要なら改訂を加えた上でベースラインとする。こうした手続きを経たソフトウェアアーキテクチャ文書は、それ以降の設計と開発作業の標準になる。これ以降の作業成果物のテクニカルレビューでは、アーキテクチャに沿っているかどうかをレビューしなくてはならない。プロジェクト全体を通じてアーキテクチャに従ってソフトウェアを実装していかなければ、アーキテクチャを作成する意味がない。
作業が進行すると、アーキテクチャの変更が当然必要になる。変更が必要になった場合、アーキテクチャは通常の変更管理プロセスに従って更新しなければならない。このプロセスに従うことによって、アーキテクチャが思いつきで変更されるのを防ぐことができる。また、アーキテクチャの変更を検討する際に、アーキテクチャに欠陥があった場合の影響が、下流の詳細設計や構築に欠陥があった場合に比べていかに膨大であるかが浮き彫りになるだろう。
|
||||||||||||||||||||||||
 |
| INDEX | ||
| 新訳 ソフトウェアプロジェクトサバイバルガイド | ||
| 1. 第10章 アーキテクチャ設計（1） | ||
 |
2. 第10章 アーキテクチャ設計（2） | |
 |
||
 |
「BOOK Preview」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
