2

AcmeCMSを作成しているとしましょう。このCMSWebアプリケーションを使用すると、サブカテゴリ（深さ無制限）を使用して無制限の数のカテゴリを作成でき、各カテゴリには0以上のコンテンツページを関連付けることができます。

したがって、このプロジェクトは、大まかに次のようになります。

フロントエンド 1.インデックスページ2.コンテンツページのリストを含むカテゴリページ3.コンテンツページ

管理コントロールパネル 1.カテゴリ（追加/更新/削除）2。ページ（追加/更新/削除/）

スキーマ設計1.テーブル2.ストアドプロシージャ3.データアクセス層

質問：バグトラッカーとWikiを使用していますが、このプロジェクトをどのように分類すればよいですか？

各セクション（フロントエンド/管理パネル）を個々のページに分割し、各ページ（またはテーマ）の簡単なユーザーストーリーを作成することを考えています。

ユーザーストーリーが完成したら、バグトラッカーに、開発する必要のある機能を表すケースのリストと、それぞれの見積もりを作成します。

このプロジェクトを適切に分解していますか？このプロジェクトを失敗させる計画の大きなギャップ（理論的にはとにかく！）

詳細な回答、おそらく私が何をすべきかについての一般的な考え、それを説明する詳細な例とその理由などを提供してください。

4

3 に答える 3

2

「各セクション (フロント エンド/管理パネル) を個別のページに分割し、各ページ (またはテーマ) の簡単なユーザー ストーリーを作成することを考えています。」

ページにはストーリーがありません。ユーザーにはストーリーがあります。ページは、ユーザー ストーリーを実装するために作成するものです。

テーマは、これほど小さなものがあるとすれば、「コンテンツの管理」です。おそらく、2 つのテーマがあります: 執筆/編集に関するストーリーのコレクションと、ブラウジング/読書に関するストーリーです。

一部のユーザー (「編集者」?) は、コンテンツを作成、整理、更新、および削除して、何かできるようにしたいと考えています[質問には書かれていません]。5x8 のカードやマーカーよりも優れた、安価な、高速な Web ページを使用するように強制します。

一部のユーザー (「読者」?) は、コンテンツを調べて移動できるようにしたいと考えています。-- 何かでより幸せになり、より生産的になります。マグネットでホワイトボードに 5x8 枚のカードをくっつけるよりはましなので、Web ページを使用するように強制します。

コンテンツの作成と管理のテーマに関するストーリーがあります。

「次に、バグトラッカーで、開発しなければならない機能を表すケースのリストと、それぞれの見積もりを作成します」

右。そして機能は、最初にデータ モデルから始めて、次に便利な形式で提示する必要があります。おそらくページ上。実際、ユースケースを大まかに満たすモデルができたら、プレゼンテーションを微調整して、モデルをより使いやすくすることができます。

「ビジネスレイヤーとプレゼンテーションは、私が詳細にする必要があるものです」

モデル == ビジネス層。それらは同じものです。

ページ == プレゼンテーション。ノート。これが最後です。ユース ケースと、それらのユース ケースをサポートするモデルを用意したら、人々がモデルを操作できるように、それらを提示できます。

于 2008-11-20T02:48:46.360 に答える
1

私が見る限り、あなたのデザインには明らかなギャップがいくつかあります。機能の一部が暗示され (カテゴリとページのリンク)、いくつかは完全に除外されています (管理者のログイン、ユーザー管理、プレビューなど)。これらは小さなアプリケーションの約半分を構成するため、最初のアウトラインに含めることをお勧めします。おそらく、CMS を設計するために、より体系的なアプローチを取りたいと思うかもしれません。そして、少なくとも 3 つの一般的なルートがあります。

  1. 最初にドメイン モデルを設計し、次にビジネス レイヤーを設計し、次に UI とデータ モデルを設計します。

  2. データ モデルから始めて、その上にビジネス レイヤーと UI を構築します。

  3. 最初に UI をモデリングしてから、他のすべてをモデリングします。

どのパスを選択するか (またはその組み合わせを選択するか) に関係なく、いくつかの一般的なガイドラインがあります。

  1. 自動化する作業の全体像から始めます。これを「作業範囲」と呼びます。ここでの「全体像」は文字通りの意味であり、プロセスを説明する単なる物語である可能性がありますが、アクション、アーティファクト、他のアプリケーション、ユーザーなどを含む豊富な図を使用して視覚化するのが最善です.画像が意図した製品以上のものを包含する必要がある等式の一部であり、自動化したい作業のセグメントよりも大きくなければなりません。

  2. 次に、製品に処理してもらいたい特定の作業の概要を説明します。これは通常、「製品範囲」と呼ばれます。

  3. アプリケーションのユーザー ロール (またはプロファイル) のリスト、入力と出力のリスト、外部インターフェイスのリストを作成します。

  4. ここで、いくつかのユーザー ストーリーを書き始めたいと思うかもしれません。すべてのユーザーの視点を示す必要があるため、ユーザー プロファイルごとに少なくとも 1 つ必要です。

  5. この時点で、ドメイン モデル、UI モデル、またはデータ モデルのいずれかを使用して問題のより正確なモデリングを開始するのに十分な情報を自由に使用できます。

すべてのステップは非常に反復的です。アプリケーションについてもう少し理解し、その幅広いコンテキストを理解し、要件を満たすために実装する必要がある機能のリストを手に入れたら、非常に大まかな見積もりを出し、優先順位付けプロセスを実行する立場になります。

言うまでもなく、これは単なる単純化されたフレームワークであり、多くのソフトウェア開発者は、スキル、ニーズ、好みなどに応じて、アプリの設計に異なるアプローチをとります。しかし、問題をより体系的に評価するための良い出発点になる可能性があります。解決したい。

于 2008-12-08T12:01:22.633 に答える
0

「無制限」の部分は壊れています...GMailにも上限があります...

編集：私の答えは反対票を投じられましたが、私はそれが正しいと思います。プログラマー以外の人と話すとすぐに、「無制限」の部分は非常に危険になり、後ろで刺される可能性があります。また、無制限のネストのためのスケーラブルなデータスキーマを持つことはできません...しかし、それは明らかなはずです。

于 2008-11-20T02:20:35.387 に答える