私は、複雑さがユーザーの操作にあるソフトウェアの計画に慣れています。私が学んだアジャイル ソフトウェア エンジニアリングの原則は、この種のシナリオでうまく機能します。ユーザー ストーリーは、計画のほとんどがユーザー インタラクションに関するものであれば、非常に簡単に書き出すことができます。
私は現在、ユーザーが行う唯一の介入が実行ボタンを押して、エラーが発生した場合にエラーを読み取るシステムに取り組んでいます。
このシステムの他のすべての作業は、データ処理であり、非常に重いデータ処理です。この処理ワークフローでは、約 5 つの異なるデータ変換を計画しています。
これらのプロセスは本質的に疎結合であるため、個別のプロセスとして簡単に計画し、ワークフローに組み込むことができます。それでも、データ駆動型プロセスの計画の問題は依然として残っていますが、規模は小さくなります。
このようなデータ主導のプロセスを計画するにはどうすればよいですか? このタイプのソフトウェアの既知の設計プロセスはありますか?
同じ！
計画と反復型開発のアジャイル原則は、あらゆるタイプのプロジェクトに使用できます。これは依然としてユーザー主導である可能性がありますが、「ユーザー」の概念を拡張する必要がある場合があります。構築しているソフトウェアを最終的に使用するのは誰ですか？あなた自身？技術チーム？他のプロセス？「実際の」ユーザー？彼らが誰であれ、あなたは彼らをデザインに含め、彼らにあなたとスペックについて話し合うようにさせる必要があります。
ユーザーが望むものに優先順位を付けることから始めます。彼らが見たい機能の「コア」セットは何ですか、および/または新しいプロセスのアーキテクチャを定義する最も重要な機能は何ですか？それらの最初の数回の反復を計画します。（開発環境をセットアップしたイテレーション0の後）。これらの終わりに、あなたのシステムはそれがするべきすべてをするわけではありません、しかしそれは始まりになります。また、エンドツーエンドのストーリーに焦点を当てます。目的の出力ではない場合でも、早い段階で出力を生成してから、リファクタリングして改善することをお勧めします。
慣れ親しんだユーザーストーリーを書き続け、各ストーリーの冒頭に「XXXとして、私は...するために...」という文を追加します。そのため、各ストーリーは、そのストーリーの元のリクエスターと緊密にリンクされています。（XXXは、自分自身、別のシステム、または実際のユーザーである可能性があります）。
受け入れテストの包括的なセットに非常に早い段階で焦点を合わせます。（おそらく、 JBehaveやFITnesseのような自動化されたフレームワークを使用します（Javaを使用しているが、私が推測するすべての言語に代替手段があります）。データ駆動型プロジェクトの場合、これらは最も重要です。システムのドキュメントとして機能し、将来性があります。受け入れテストは次のように構築する必要があります。「空の」（または「与えられた」システム）から開始し、データとしてXX、YY、ZZを追加すると、結果はAA、BB、CCになります。受け入れテストは、ユーザーによって常に確認および承認されている限り、遠慮なくハッキングしてスラッシュしてください（それらについて何も仮定せず、すべてを検証してください）。
次に、反復を繰り返し、目的の仕様セットに到達するまで複雑さの層を追加します。
私は、データの管理と処理（さまざまなソースからのマージ、「ゴールデンソース」の維持、バイテンポラルデータベース、他の外部システムへのフィードなどを含むリポジトリ）に基づくいくつかの中規模から大規模のプロジェクトに携わってきました。チームの機敏性が高いほど、プロジェクトは成功しました。はるかに。
何らかの形式の受け入れテスト (BDD は最近多くの注目を集めています) を使用すると役立ちます。結果のPDFには、存在することを確認したいさまざまな「機能」が確かにありますよね？BDD受け入れテストを使用して、これらの機能を検証する（フィードバックを提供する）責任を最終ユーザーに移すことをお勧めします。