requirements - なぜこれほど多くのサイトが、作成しようとしているシステムについて説明するのではなく、プログラミングについて議論するのでしょうか?

Question

より優れたソフトウェアを構築する方法を人々に教えるサイトはたくさんありますが、(プログラマーとして) 私たちが作成することになっているドメインの詳細な説明を実際に提供しているサイトがほとんどないのはなぜですか? さまざまなタイプのシステム間で共通の要件のパターンが出現し始める前に、非常に多くの在庫、会計、および ERP システムを構築することしかできません。論理的に言えば、プログラマーがアーキテクチャーで再利用可能なコンポーネントを作成するために多くの時間を費やしている場合、それは、プログラマーが作成することになっているシステムを説明する再利用可能な「青写真」が必要であることを意味しますか? つまり、ソフトウェア開発の焦点は「方法」に集中しすぎているようです。

私の質問は次のとおりです。さまざまな種類のシステム仕様をすべて 1 つのサイトにまとめてカタログ化する作業は行われましたか? プロジェクトの開始時に適切な要件が不足していることがソフトウェア開発の悩みの種の 1 つである場合、既に記述されている同じタイプの以前のシステムからの要件仕様を「再利用」できる方が理にかなっているのではないでしょうか?

score 6 · Accepted Answer

ありますが、通常はソリューションを販売したいベンダーによって運営されています。:-/;

score 5 · Accepted Answer

一般的なデータベース設計のソリューションを提供しようとするサイトDatabaseAnswersがあります。これは、あなたが説明しているような完全なソリューションと同じではありませんが、正しい方向への一歩です。

あなたは「[o]neはこれまでに非常に多くの[...]システムを構築することしかできない」とコメントしています。共通点が明らかになります。しかし、共通性を見つけるのに十分なそのようなシステムを構築した人々は、共通システムのバージョンを作成することによってそれから利益を得ようとし、そしてそれを販売します。同じことをするかもしれない他の人々に助けを与えることは彼らの利益にはなりません（そう思われます）。

score 4 · Accepted Answer

「Dummy's guide to Inventory IT」、顧客、住所、連絡先の詳細などの認定データモデルがどこにあるのか、完全に同意します。同じコードを非常に多くの異なる場所に、微妙に異なるフィールドで再実装していることに気付きました。とロジックですが、基本的に同じものです。数年前、事前に調理されたデータモデルのサイトを見つけました。これは正しい方向への小さな一歩ですが、ユニバーサルデータモデル全体ではありません(接続なし)。ただし、彼らが自社の製品にあまり関心を持っていないことに気付くでしょう。

また、販売可能な製品として独自の「ユニバーサル」データモデルを開発している組織で働いたこともあります。1 つは金融サービスのドメインにあり、1500 以上の DB2 テーブルに到達し、あきらめました。組織はユニークであることに誇りを持っていますが、私たち (技術者) は、ほとんどが内部でかなり似たようなことをしていることを認識しています。 UniversalCustomer (TM) 1.7 を使用。また、これらの企業は、SAP や Peopleware などを利用する機が熟しています。

最後に、ここには起業家にとって簡単に手に入る成果がたくさんあります。共通のドメインを説明する適切な短冊のセット。つまり、人の名前、住所、電話番号など、さまざまな文化での肩書きや電話番号のレイアウトなど、すべての小さな問題を処理するという非常に単純なものを意味します。

score 3 · Accepted Answer

私の経験では、UI に含まれるユースケースがバラバラになります。実際、私はさまざまな組織や業界 (通信、食品、ヘルスケア、電子機器の製造と流通、消費財、アパレル、航空宇宙、その他多数) に適用されている在庫システムを設計および構築しました。ダースのデータモデルが出現し、それらのすべてに対してほとんど変化 (拡張ではなく変化) で機能する優れたデータモデルが出現しました。

しかし、同じ業界内であっても、さまざまな理由 (製品の性質、数量の変動、平均注文数、経理要件、従業員のモチベーションなど) により、実際の人々の仕事のやり方は大きく異なります。正当な理由があります。

上記の例はすべて、より深い抽象化レベル、特にデータモデルに関するものであるように見えることに注意してください。ユーザーに近づけば近づくほど、私たちの関心は彼らの関心に次ぐものになる必要があります。

最悪の例: 従業員のスケジュール管理システムや勤務時間報告システムで、画面ごとに 1 週間を表示し、複数画面のデータ入力フォームを表示するパターンに気付いた人はいますか?

score 2 · Accepted Answer

LenSilverstonによるデータモデルリソースブックをご覧ください。

http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1232336996&sr=8-1

エンドユーザーの要件やオブジェクト指向デザインとは対照的に、データモデルの観点から再利用可能な設計にアプローチします。ただし、非常に便利であることがわかりました。データモデルを十分に理解すると、最終的にクラスとしてモデル化される要件とエンティティに大きくジャンプできます。

score 1 · Accepted Answer

売れないでしょう。システムのRFQを配布する人から必然的に得られる最初の主張は、「私たちは他の企業とは異なります。私たちの要件は独特です」です。（そして、決して実際にはありません。）

score 1 · Accepted Answer

要件を再利用する場合は、コードも再利用することをお勧めします。しかし、より低いレベルでは、あなたが探しているのは「プログラミングパターン」に沿った「要件パターン」だと思います。

これがこのトピックに関するMicrosoftの本ですが、すべてのドメインパターンと同様に、それらは有機的に成長し、ドメインユーザーと専門家のニーズに適合する必要があるという考えです。アイデアの真の情報源が必要な場合は、パターンに関する独創的な本をチェックしてください。これは、プログラミングではなくアーキテクチャからのものですが、驚きです:)

score 1 · Accepted Answer

80 年代から 90 年代初頭にかけて、「ソフトウェアの再利用」という大きな動きがありました。ソフトウェアコンポーネントのカタログを構築および調整する人々のかなりの業界がありました。それはソフトウェアの未来として多くの人に見られました。Will Tracz の "Confessions of a Used Software Salesman" が良い概観です。Google 用語「Brad Cox Software IC」、「Martin Griss」。私が覚えているように、勝利が宣言され、誰もが他の問題に移りました。

Brad Cox の「Planning the Software Industrial Revolution」がオンラインになっているようです:
http://www.virtualschool.edu/cox/pub/PSIR/

score 0 · Accepted Answer

さまざまな機関間での共有を可能にするためにデータモデルを標準化しようとする政府によるさまざまな取り組みがありますが、これらは必要な場所以外ではほとんどまたはまったく採用されていません。たとえばカナダでは、CPSINがあります。

score 0 · Accepted Answer

さまざまな言語のコードパターンの中央リポジトリがあると便利です。そうすれば、すばらしいコードを披露し、お互いから学びやすくすることができます。また、xyzサービス/製品を提供する良い例を用意することで、全体的なコード品質を向上させることができます。

つまり、他の誰もやったことがないようなユニークなコーディングプロジェクトはいくつありますか？

私の大まかな推測では、私たちの仕事の98％は、多くの異なる企業、同様の業界、同様の機能的ニーズの他の人々によって行われたものです。

つまり、これはstackoverflowが遅れをとるようなものです。問題を共有して話し合うだけでなく、お互いのコードから学ぶこともできます。

score 0 · Accepted Answer

Martin Fowler のPatterns of Enterprise Application Architectureをチェックしてみてください。仕様ではありませんが、あなたが求めるものについて書かれているようです。

免責事項: 私自身は読んだことがなく、その存在しか知りません。

score -1 · Accepted Answer

誰がそのようなものを作成しますか？誰がそれを使うでしょうか？

私が知る限り、あなたはアプリケーション設計のライブラリについて話しているのです。そのような詳細な設計を共有したいと考えている人々は、オープン仕様またはオープンソースの形ですでに共有しています。前者は、そのような仕様を実装する製品、または仕様を実装するシステムと相互運用する製品の作成にすでに関与している人々や組織を引き付ける傾向があります。後者は...ソースをハッキングできるのに、わざわざ設計を再実装する必要があるでしょうか?

Mark Harrison が指摘しているように、一般的なビジネスシステムの設計を進んで宣伝する企業はたくさんあります。「私たちのシステムを購入して、組織に必要な機能を追加してください」と彼らは言うでしょう。「なぜ、すでに行ったことを再実装するために時間を無駄にするのですか?」彼らがあなたに売り込もうとしているものをあなたが再実装することを本当に望んでいないので、彼らが詳細な実装仕様を共有する動機はほとんどありません.

最後に...これらのことは、それほど複雑ではありません。というか、それらは... しかし、複雑さはサイズから生まれ、特定の組織がシステムに課す可能性のある難解な要件の無数の組み合わせから生まれます。実際の作業は、これらの要件を解釈し、基本システムに組み込むことです。退屈かもしれませんが、避けられません。

requirements - なぜこれほど多くのサイトが、作成しようとしているシステムについて説明するのではなく、プログラミングについて議論するのでしょうか?

12 に答える 12

Related

Reference