Abstract#
情報システムの必要性が明らかになったとします。しかし、この情報システム、いざ導入しようとすると選択肢がたくさんあったりして、具体的にどういう手順で導入していくのが良いか迷うところです。そこでここでは、情報システムの導入方法について、記録したいと思います。Topic#
立場#
| ここでは、読み手の立場を職場の情報システム導入担当と仮定します。エンドユーザでもなく、自分で作るわけではなく、要求を分析して、要求仕様を固めて、発注するといった作業をする人の立場から書いています。 |
手順#
- 目的
| これが一番重要です。何のためにこのシステムを導入するのか確認し、明文化し、合意を得ましょう。 |
- 画面イメージ
| エンドユーザにシステムのイメージを説明するとき、これが一番伝わる気がします。 |
- ステークホルダー分析
| だれがこの情報システムにより影響をうけるか。さらに具体的にこのシステムを誰が使うかを調べます。 |
- ユースケース分析
| システムを使う場面です。システムをどう使うかの観点から、分析します。UMLのユースケース図＋ユースケースシナリオを使って表します。 |
- エンティティ分析
| このシステムで扱う情報を分析しましょう。 |
- 要求仕様
| ユースケースを実現するために、どんな機能や性能が必要かを要求仕様として記述します。ユースケースとトレースが取れることが重要です。 |
有名な開発手法の話#
- ウォーターフォール
| 段々でやっていくやつです。そのうち引用を使いつつ正確に記述します。 |
- プロトタイピング
| とりあえず、試しに作ってみて使ってみて改善していくやり方です。そのうち引用を使いつつ正確に記述します。 |
| Abridge Technology[1]のDr. Richard Bechtoldさんは、プロトタイピングのようなIterativeなアプローチは素晴らしいと語ります。ユーザによる早めのチェック（Validation）ができるとか、技術的もしくは社会的なリスクが早めにわかるとか、悲劇的なプロジェクトの失敗の確率がさがるとか、状況の変化に柔軟に対応できるとか。リスクとしては、コンフィギュレーションコントロールが利かなくなるとか、レビューやテストがおざなりになるとか、欠陥が丸見えだとか、スケジュールとコストがぐだぐだになるとか、過度の利用者の介入など。リスクはありますよね。 |
| しかし、確かに情報システムのようなソフトウェアを作る場合に有効なのはわかります。しかし、発注側としては、システムを作るのにいくらかかるかわかりにくという点で非常に難しい。やろうとすると、システムに対して、対価を支払うのではなく、人の拘束費にお金を支払う形にならざるを得ません。難しいところです。 |
| 最近MS ACCESSを使って、大学の課題をやる機会があったのですが、プロトタイプとしてのデータベースを簡単に作るツールとして、このMS ACCESS、なかなか使えるツールだと思います。 |
Reference#
- [#1]Adridge Technology. web site. http://www.rbechtold.com/
