Webソフトウェアプロジェクトのリスク管理プロファイル？

Question

私は「Software as a Service」ウェブサイトプロジェクトの作業を開始しようとしています。これは私が取り組むこの種の最初のプロジェクトなので、可能性のあるリスクを予測しようとしていますが、私は考慮しないことがさらに多くあります。

この種のプロジェクトに適したリスクプロファイルの定型告知者は誰にも分かりますか？

おかげで、

エイドリアン

Answer 1

「リスク」に割り当てられた緩和計画を、影響を受けるリスク、エントリー日、ステータス（オープンを、含まれている必要がありますまたは悪いデザイン。確率論はほとんどまたはまったく関係していません。

まず、ソフトウェア開発プロジェクトの「リスク」プロファイルから始めます。ユーザーのバイイン、スポンサーシップ、要件、テスト、コミットメントなどの標準的な情報。その変更はありません。

WebベースのSaaSには、新たな管理やユーザーの "リスク"が追加されません。ユーザーは依然として嘘をつき、マネージャーは依然として非現実的なスケジュールを持ち、顧客は非現実的な価格を要求します。

技術を学ぶためには時間が必要です。これは「リスク」ではなく、コストです。

1. あなたが前にフレームワークを使用していた場合を除き、あなたは離れてスローされます枠組みの中で、小さな何かを構築します。 「自己テスト」または「概念実証」または「デモンストレーション」。あなたは最終的な生産コードに進化しようとしません。これは危険領域ではありません。小さなものを作り上げてそれを放棄しないと、その技術に苦労し、時間と予算に達することができなくなります。

2. 堅固なセキュリティモデルを用意していない限り、セキュリティ上の問題に多くの時間を費やす予定です。多くの脅威シナリオ、セキュリティホールとなる多くの技術的なギャップ、おそらくユースケースに対処していないいくつかの迷惑ソフトウェアがあります。

   誰もがセキュリティが簡単だとふりをするのは好きです。 「それは単なるパスワードだ」

   実際の脅威を列挙して解決策を見つけるのに多くのプロジェクト時間を与えてください。ほとんどの場合、これは簡単です - SSLとダイジェスト認証と適切なコーディング慣行を使用して、OWASPの脆弱性をすべて防ぎます。しかし、あなたの状況には独特の奇妙なものがあるかもしれません。

   すべての層（データベース、Webサーバー、アプリケーション、操作手順など）でセキュリティをアーキテクチャでサポートする必要がない場合は、セキュリティホールを持つソフトウェアを作成します。

3. パフォーマンス目標を法的に拘束されている場合を除き、パフォーマンステストを実施し、問題を見つけて問題を解決する時間を確保してください。パフォーマンステストは、ソフトウェアの作成後および使用許諾テスト前の2週間の作業ではありません。パフォーマンステストは、構成可能な多数のアイテムとの継続的な闘争です。

   すべてのさまざまなコンポーネントの設定は難しいです。長い時間がかかり、優れた負荷シミュレータが必要です。すべてのアイテム（リバースプロキシサーバー、Webサーバー、アプリケーション、データベース）の設定を練習する時間を自分で許さない場合は、適切に拡張されていないソフトウェアを配信することになります。

4. また、メッセージスキーマを設計（および再設計）する時間を確保します。 RESTful Webサービスを使用する場合は、リソースを適切に定義するために複数の試みが必要になります。 SOAP/XMLを使用する場合は、メッセージとWSDLの取得に多くの時間を必要とします。ここでは残念な決断を下すことになるので、メッセージを変更して後悔して修正する時間を取っておいてください。

5. ユニットテストと使用可能なユニットテストスイートの作成に多くの時間を取ってください。Webサービスは、適切なスタンドアロン単体テストと、単一の包括的なスイートの一部である単純なWebサービス統合テストを備えているため、テストするのが煩わしいことがあります。

   既知のフィクスチャでデータベースをシードし、サーバーを起動し、クライアント要求を実行し、サーバーをシャットダウンしてデータベースを破棄することができるテストスイートを構築したいと思うでしょう。複雑に聞こえますが、最初の重大なリファクタリングを開始する頃には、本当にそれが必要になります。

これらは「危険」ではありません。これらはあなたが時間をおく必要がある難しいものです。具体的には、リワークのために時間を残す必要があります。初めてのプロジェクトでは、最適ではない決定を下すことになります。あなたはそれらを解くために時間、許可、技術サポートが必要です。

Answer 2

私が受け取ってきたこれに似た何かを持っているようだ今月のweb designer magazine。あなたは実際にサービスを実行している、あるいは単に一般的にプロジェクトを構築していることを意味しますか？

1. 「ウェブデザインの大惨事を避けるためにInterdirectの9段階のプロセス」

   事前に定義されたプロジェクトの配信方法に従ってください：私はこれが面白い発見しました。

2. 新しいクライアント/プロジェクトのquestionairre/checklistから開始してください。
3. 要件を分析するための「ディスカバリーミーティング」を開催します。
4. チームメンバーの責任を定義します。
5. 機能仕様書「青写真」を作成します。
6. クライアントに署名して仕様に同意させてください。
7. 継続的な通常のクライアント通信を確実にします。
8. できるだけ早くクライアントの承認を得るための作業が完了しました。
9. 最初からクライアントの信頼を構築し、優先させます。などそれはサービスの種類を知らなくても、どのように「利用可能」公共の消費のため

Answer 3

、 - 私はあなたが標準のグループにそれを打破することができると思う：

セキュリティ

• 登録ユーザに限定
• フル監査履歴
• 侵入検知と報告
• 安全な接続

品質

• パフォーマンス - リターン結果が要求性能

メンテナンス

にアップグレードパスを定義し

• をフォーマットすることで合意し-で提供
• リターン結果を満たします（コミュニケートなアターション、下位互換性など）

テンプレートは、どちらか悪いの管理）基本的にすべての（ある）閉じて、対処し、その

Answer 4

six steps to managing project riskをご覧ください。いくつかのやりとりやさまざまな種類のリスク、すべてのリスクが悪いわけではないことを記載しています。