- 0
- 0
- 1
質問
-
開発手法別の開発プロセスをIT全般統制で考慮してますか？
質問
開発プロセスについてですが、
大型案件（高額案件や、長期開発案件）は、ウォーターフォール型が多く、
中小規模案件は、プロトタイプやスパイラル型が多いと思います。
ベンダーの裁量だけでなく、納期までにどれだけの期間と予算がとれるかでも、開発プロセスに違いがでると思います。（大手ベンダーだと、自社内の統制で、開発フェーズが決定されていることが多いです）
基本設計〜結合テストフェーズ（特に詳細〜単体テストフェーズ）をユーザ側で指定してしまうのは、ベンダーもやりずらいと思いますし、ユーザ側も検収作業が増えて大変になると思います。開発フェーズの決めは、開発ベンダーの意向を踏まえた上で決定するのが一番だと思います。ただ、要件提案、要件定義、基本設計の上位フェーズや、テスト、検収の導入前フェーズは、ユーザ側の意見がなくては決定できないものです。だから、開発ベンダーに一任する部分と、ユーザとして介入する部分を明確にするのがいいと思います。
＞そもそももっと単純に、
＞1.企画計画終了(方針決裁)、2.基本設計終了(実施決裁)、3.カットオーバ＞ー判定
＞の３箇所に経営者層を巻き込んだゲートがあるくらいで十分なんじゃない＞か、と個人的には思うんですが
私も、基本は上記で十分かと思います。
開発ベンダーと意思疎通ができているか確認することが、一番大事なので
開発期間が長期にわたったり、費用がかかる場合は、
適宜にゲートを増やすのがいいのかなと思います。
お役に立ちましたか？他にもたくさんの ノウハウが共有されています。
質問
開発手法別の開発プロセスをIT全般統制で考慮してますか？
・・・というのも、自分はIT全般統制の開発プロセスで、あたりまえのように
典型的なウォーターフォール型のプロセスを前提に統制手続きを定義しました。
それで、整備としての監査は問題なかったのです。
しかし実際は、開発ベンダーの流儀で、プロトタイピング型の開発が
かなり混じったような、以下のような感じのプロセスに（結果的に）なってしまいました。
1.企画・計画
2.要件定義 ※必要最低限のドキュメンテーション（DB定義など）
3.開発
4.レビュー及びテスト ※適宜参加者を選出
(3〜4を繰り返し、徐々にプロトから完成品へ)
5.カットオーバー判定
ご覧の通り要件定義、基本設計、詳細設計のフェーズがありません。
それらは、開発〜レビュー及びテストの中で確定していきます。
統制の整備と運用開始時期がオーバーラップしてしまったこともあり、
このように策定した統制手続きと乖離してしまったわけなんですが、
多分、開発ベンダーにウォーターフォール型をごり押ししていたら、
開発も相当遅延していたんだろうと推測できます。
（実際、ユーザビリティも含めた問題点が早期に発見でき、
合理的だったという意見が多数を占めています）
そこで、最初の質問に戻るんですが、
そもそもいろんな開発ベンダーがいて、いろんな開発手法があるなかで、
それらにフレキシブルに対応できるような開発プロセスを策定するって
無理があるような気がしています。
なので、、、
あくまで「ウォーターフォール型を基本」とするが、
開発ベンダーの得意とするプロセスがあり、それが合理的だと判断できれば
それを適宜取り入れる。
・・のような注記で済ませようかと思うのですが、どう思いますか？
自分はちょっと自信がありませんｗ
そもそももっと単純に、
1.企画計画終了(方針決裁)、2.基本設計終了(実施決裁)、3.カットオーバー判定
の３箇所に経営者層を巻き込んだゲートがあるくらいで十分なんじゃないか、と個人的には思うんですが。
みなさんは、多様化する開発プロセスとその統制についてどんな感じでお考えですか？