2011年04月29日

私が考えているシステム開発の工程

システム開発をしていると、常に運用のことが後回しになっており、
作ってみたけれど、結局使いにくい、運用がまわしにくいと言われてしまうことが多いと感じます。
言い訳ではありますが、私はあまり運用設計まで実施することがないので、
常に最初から案件に関わっていればと思うこともあります。

会社では常に現行システムがあるのであれば、運用がどうなっているのか、性能や環境はどうなのかを
先に調査するよう求めています。
ですが、システムを作る人間は、どうやったらできるのか、どうやって作るのか、システムとはどうあるべきか、
方法論、方式論、開発論、手法ばかりが先行してしまいます。
私たちは作る側ですので、美しく、安く、それなりに品質の高いものをはやく作りたい、
それができれば評価される世界にいます。
たしかにその世界にいるので、上記の論述は必要です。
でもその前に、ちゃんと作ったあとのことを先に考えていたいと思うのです。

私だったらこんなシステム、結局面倒になって使わなくなるだろうなということを感じるものでも、
システム開発側のルールやリスク、場合によってはスキルや作ってしまったから等の理由で
顧客にリリースしてしまいます。
それでも私の会社でも納品さえしてしまえば、Win-Winの関係を築くことができたと言ってしまっています。
これは何を先にやるべきか、あまり明確になっていなからではないかと考えています。

よくあるV字モデルは、
要件定義、基本設計、詳細設計、製造、単体テスト、結合テスト、システムテスト、ユーザー受入テストと
だいたいこのような形で記述されています。
より詳細に見ても、要件定義や基本設計で運用の詳細を見てきた案件が一度もありませんでした。
他の方はもしかしたらやっているのかもしれません。
これは自分の今後のために、反省のためにやるべきことを明確にしていきたいと思います。


まだまだ考え中ではありますが、私が考えているシステム開発の工程は以下の通りです。
一部は詳細に表現しています。
これから、さらに細かく内容を確定していきたいと思います。

第1フェーズ
顧客の現状分析と要求確定
目的定義・実現内容(業務機能・確定可能な非機能)の確定
第2フェーズのスケジューリング

第2フェーズ
現行の運用・環境分析(調査)
実現可能性の分析
実現内容(未確定部分の非機能)の確定
新規 運用内容・運用環境(想定)・保守内容の設計
第3フェーズ以降のスケジューリング

第3フェーズ
業務機能 機能分割
業務機能 機能処理フロー設計
業務機能 詳細設計
開発環境 テスト環境 構築(手順策定)
システム・運用テスト設計
性能テスト設計

第4フェーズ
業務機能 共通処理の抽出
業務機能 機能処理フローをイベントドリブンに変換
フレームワーク設計・実装
新規 移行設計
結合テスト設計

第5フェーズ
フレームワーク テスト
実装
単機能テスト(単体テスト)

第6フェーズ
結合・トランザクション・性能テスト

第7フェーズ
システム・運用確認

第8フェーズ
導入
ユーザ確認


posted by Kiruahさん at 22:17| Comment(0) | TrackBack(0) | ノウハウ