 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 開発プロセスの本質 | ||||||||||
|
本連載の「第1回：目的指向開発」で述べた通り、ソフトウェア開発においては、ステークホルダの観点から発生する要件を包括的にカバーすることが重要である。一旦ステークホルダごとの目的や要件が明確化されたら、それを満たすための成果物と開発作業を特定する。それが開発プロセスだ。 つまり開発プロセスとは、多くの観点から見て必要とされる成果物と開発作業を整理して、それらをつなぎ合わせたものだと考えられる。図2は典型的な開発作業において発生する観点と、そこから見た成果物をモデルとして可視化した後、複数のモデル間で連携をとる様子をあらわしている。この一連の作業が開発プロセスの本質である。  図2：開発プロセスの俯瞰図 一方で開発プロセスには手法として、UP（Unified Process）やアジャイル（Agile）などいくつかの分類がある。 例えばUPは、プロセスとしての形式知（注1）に着目し、誰がいつ何をどのように実施するかというプロセスのメタモデルを規定している。アジャイルは逆に暗黙知（注2）に着目し、メタモデルではなく少数の原則に従うことで開発現場に起きる事象に迅速に対応することを目的とする。
注1：
形式知とは、図や文章などで表現されている知識で、学習などにより習得できる知識のこと。
注2： 暗黙知とは、個人が修得した経験／知識の中でも、他の人が知ることが難しい知識のこと。 開発方法論としてどちらがよいという問題ではなく、本質的な部分に目を向けてそれを取り入れることが重要だ。本質とはソフトウェア以外の産業にも普遍的に存在するものであり、開発プロセスが存在する理由といってもよい。筆者の考える開発プロセスにおける本質とは、表1にあげる内容である。
表1：開発プロセスの本質 |
||||||||||
| 開発プロセスにおける運用・保守の観点 | ||||||||||
|
今日のソフトウェア産業に共通した問題点が1つ存在する。それは運用・保守の観点が不足しているという点だ。 分散システム（注3）の設計が困難な理由としては、既存資産を含めて散在する複数のサブシステムやアプリケーションの構築、運用管理をシステム全体を通じて可視化し連携させなければならないことがあげられる。
注3：
分散システムとは、機能実現のために連携して動作するソフトウェアやハードウェアのリソースのまとまりのこと。具体例としては、WebサービスのシステムとWebアプリケーションなど。
また設計時点でアプリケーションの配布や運用管理の観点が考慮されないと、後になって物理構成との不整合が判明し、期待した性能がでなかったり、余計な追加投資が発生したりといった問題点を抱えることになる。 現時点ではこういった問題を解決する手段として、ドキュメントを通じた関係者間のコミュニケーションにより解決する努力がなされている。しかしこのようなドキュメントは、フェーズが進むにつれて実際のコードや物理システム構成との間にギャップが発生し、システム規模が大きくなるにつれ管理能力の限界に達する。その結果、保守に大きな課題を残すことになりがちだ。 つまりこれら課題を解決するには、開発の初期段階から運用・保守の観点を取り込まなければならない。次項で述べるモデル駆動型の開発においては、運用・保守の観点をいかに取り込むかという点が重要なポイントとなる。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
