はじめに
II市場分析ソリューション
1.市販されているシステムの機能の標準化
2.既存のシステムの欠点
3.情報システムの生産のためのサポートシステムを作成する際の課題
IIIシステムの基本構造の設計
1.タイプごとに解決すべき問題の区分
2.それらの要件とタスク
最初に、作成された製品の要件に関連する作業の編成方法の問題に焦点を当てましょう。 その実行者と著者は、情報を収集および分析する機能に何らかの形で結びついている可能性が高いです。 人々は並外れており、少し保守的であり、私たちは彼らに適応します。
可能なデータモデルを図3に示します。
図3.-オンデマンドタスク組織モデル
要件自体は本質的に非常に多様であり、作成者はしばしば不機嫌です。 この課題に対処するため、「要件」プロパティのほとんどを別のクラス「要件コンテンツ」に配置します。 このように頻繁に変更される詳細を条件付き定数から実際に分離することで、他の静止した詳細に影響を与えることなく、要件のコンテキストの形成の全体的な進化を保存および表示できます。 どの「要件コンテンツ」のセットが現在関連しているか（セット全体の1つ）を理解するために、図3に示すように、「要件」テーブルへの後方リンクを使用できます。 バックリンクの使用の反対者は、リクエストでコンテンツの現在のバージョン（単なる文字列）を示す弱い接続を編成するか、たとえば、実際のコンテンツの作成の日付/時刻を保存します。 一般的に、好きなように。
次のポイントである要件は、ほとんどの場合プロジェクトのフレームワークで発生します。 しかし、計画またはその大部分が一方のプロジェクトと他方のプロジェクトの両方に適しており、要件を複製することは単に不適切であることが判明する場合があります。 したがって、私たちは、多数の多数の「プロジェクトの要件」を通じて、要件をプロジェクトと関連付けます。 もちろん、異なるプロジェクトの要件のステータスは異なる場合があります。 たとえば、あるプロジェクトでは既に長い間実装されていますが、別のプロジェクトではまだ議論されているだけです。 したがって、ステータスを「要件」自体ではなく、「プロジェクトの要件」リンクに閉じます。
システムのユーザーの幻想の翼を切らないように、要件自体を互いに論理的にリンクしながら、それらを複数のリンクでリンクします。 したがって、1つだけでなく、双方向性のさまざまな側面を特徴付ける多数の関係を使用して、2つの要件を調整する機会を提供します。 しかし、要件の階層的な従属性にもかかわらず、私たちは取り残します。 この見方はまだよく知られています。 結局のところ、詳細を掘り下げて要約するツリー構造でのナビゲーションは、グラフのウェブをさまようよりも簡単に知覚できます。
もちろん、「要件」には、コメントを通じて議論の機会を提供する必要があります。 議論と調整の重要なスケジュールを持っている人のために、ワークフローからプロットを見て、より複雑なビジネスプロセスを基礎として取ることができます。
また、添付ファイルを要件に添付することも可能である必要があり、タイプごとに分割するとよいでしょう。 一般に、要件への投資をアーティファクトのアカウンティングの形で整理し、バージョン管理、プレゼンテーションの入力、記録のための「キャプチャ」などでサポートすることは興味深いことです。
要件アーカイブで、成果物を操作するのに適したユースケースを見つけました。 イチジクに持っていきます。 4、修正されたため変更なし。
図4.-アーティファクト管理を使用するためのオプション
複雑さを克服し、要件の管理の利便性を確保するには、タイプごとの区分を検討する価値があります。 例：
- アーキテクチャ;
- 機能性
- ビジネスプロセス;
- デザインと使いやすさ。
- 安全性と信頼性;
- 宛先インジケータ。
- ドキュメンテーション
そして、それらをパーツに分割するので、各セグメントに独自の特定の属性を追加することは理にかなっています。
これは、「要件」の本質をシミュレートできる最小セットです。 おそらくさらなる検討の過程で、それを拡大します。
3.それらの仕様とタスク
要件を処理したら、次のステップである仕様の処理に進みます。 システム内の仕様自体は、要件に基づいて設計プロセス中に表示されます。 まさにこの要件に関連するタスクの遂行の結果として、それらが発生することに気付くのは不必要ではありません。 たとえば、タスクは次のように聞こえます。「要件の仕様を作成する」。 同時に、このタスクの「パフォーマンスレポート」とそのソリューション、つまり実行の結果として世界に公開された「仕様」とをリンクする価値さえあります。
このような仕様は、要件とは異なり、プログラマーがプロジェクトで使用する特定のツール、プラットフォーム、およびプラクティスを考慮に入れる必要があるため、チームリーダー、ソリューションアーキテクト、またはソフトウェアエンジニアリングマネージャーがその形成に直接関与します。 したがって、このコンテキストでは、それらの設定を考慮する必要があります。
実際、この仕様はユーザー要件を開発者レベルに変換し、それらを正規化し、詳細化し、プログラマーが操作する概念（フォーム、テーブル、ボタン、手順など）に導きます。
可能なデータモデルを図5に示します。
図5.-仕様に従ったタスク編成のモデル
プロジェクトごとに繰り返すことができる要件とは対照的に、仕様は各実装ごとに非常に一意です。 結局のところ、これは特定の条件、特定のITプロジェクトにおける要件の具体化です。 したがって、このプロジェクトが実施されるフレームワーク内で、「プロジェクト」属性が仕様に追加されました。 また、「Requirement」リンクとリンクします。
要件で編成されたのと同じ方法で、仕様間の接続を調整します。
要件と同様に、仕様には、コメントを介して議論する機能、および添付ファイルを添付する機会が備わっています。
便宜上、仕様もタイプに分けられます。 例：
- 機能性
- デザインと使いやすさ。
- 安全性と信頼性;
- 宛先インジケータ。
そして、要件のタスクと比較して、それに応じてタスクのタイプが拡張されます。
- 評価;
- 実装;
- テスト;
- バグ修正。
- ドキュメンテーション
一般的なソフトウェア生産チェーンにおける仕様の場所を決定することについてもう一度説明しましょう。 一方では、仕様との関係を確立しました。これが仕様の出現の理由でした。 一方、結果として、この仕様が実装されている製品アセンブリに結び付けます。 また、1つの同じ仕様の実装が異なるアセンブリに現れる可能性があるため、それらを直接リンクするのではなく、「多対多」ソリューション-「アセンブリの仕様」を通じてリンクします。
これで、新しいアセンブリでテストする必要がある仕様だけでなく、たとえば、仕様のソリューションがどのアセンブリに登場したか、要件が実装されている製品のバージョンなども追跡できます。
良いことには、アプリケーションの領域に応じて、少なくとも属性のセットが異なると、仕様自体が互いに異なるはずです。 たとえば、フォーム、レポート、手順、アクセスマトリックスなどを記述するためのテンプレート 構成は大きく異なります。 使用済みのプラットフォーム、ライブラリ、サービス、およびその他のツールも、この傾向に大きな影響を与える可能性があります。
4.それらのアセンブリとタスク
ターゲット製品の機能をコードで実装する場合、何らかの形で無形資産を形成する必要があり、その作業は何らかの方法で使用できます。 たとえば、-で始まるとテストします。
したがって、たとえば反復のために選択された特定の仕様セットを実装した後、チームは製品を組み立てる必要があります。製品は独自のバージョンを受け取り、生産の次の段階に転送できます。
エンティティ「アセンブリ」をモデルに導入します。 可能なデータモデルを図6に示します。
図6.-アセンブリ組織モデル
各アセンブリは特定のプロジェクトに対して実行され、モデルにはそれにリンクがあります。 アセンブリの仕様の構成については、前のセクションで既に説明しました。
Assemblyオブジェクトに設定されたタスクには、次のタイプがあります。
- アセンブリリリース;
- アセンブリ統合テスト。
- スタンドへのアセンブリの取り付け。
タスクのレポートによると、特定の各アセンブリが展開されたサイト、時期、およびユーザーを判断できます。
必要に応じて、新しい開発サークルを立ち上げたり、間違いを修正したり、不正確さを解消したりするために、仕様に従って新しいタスクを作成できます。 この場合、最新バージョンが実装されたアセンブリを簡単に判断できます。
5.現在の設計段階の分析
設計の結果、ほとんどの場合、疑問と矛盾が生じました。
鶏と卵のジレンマ。 新しい「要件」は、「既存のタスク」に基づいて作成できます。 たとえば、詳細を指定する必要がある場合は、この要件から直接「現在の要件を詳細に設定」というタスクを作成します。 実行の結果、次のチェーンが形成されます。まず、このタスク自体が要件に基づいて作成されました。 第二に、タスクのために、独自の追求で、新しい要件が作成されます。 さらに、同様にオンデマンドのタスクにより、「仕様」が生まれます。
そして、ここで合理的な疑問が生じます。最初の要件はどこにあるべきか、タスクなしでどのように作成されたのでしょうか？ まあ、たとえそれが「可能だった」と判明したとしても、要件「ナンバーワン」を作成する作業に注目する方法は？ ここから出ることは確かに可能です。 たとえば、理由を（システムで）せずに、要件を作成し、その要件にタスクを掛けて、その作成、処理などの時間を相殺します。
わずかに目立たない問題は、アセンブリを作成するためのソリューションです。 結局、最初の「アセンブリタスク」の作成前であっても、システムに登録されます。 そして、少なくとも仕様の新しい実装をアセンブリ（またはその設計）に添付するために必要です。 ただし、この場合、たとえば、サービスの作業を整理することができます。これは、コマンドに応じて、システムに新しいアセンブリを登録したり、バージョン番号を割り当てたりします。 作業自体は従業員向けではなく、アセンブリはすでにシステムにあるかのように。 そして、時間を帳消しにすることは何もないようです。 また出た。
その他。 多層プロジェクトでは、多くの場合、製品を相互作用するモジュール、サービス、およびその他の統合に分割する必要があります。 この場合、製品自体は、小さな製品の多くのアセンブリで構成する必要があります。 そして、すべてを同時に大量に生産する必要はありません。 一部の製品は依然として関連しており、一部の製品は新たに再構築する必要がある場合があります。 したがって、サブシステムの相互互換性（または移植性）およびアセンブリの推奨アセンブリを確立する必要があります。 しかし、ソフトウェアの生産プロセスで設計作業を検討するときにこの問題に戻ってみましょう。 「パート3」を参照