「パート1」
はじめに
II市場分析ソリューション
1.市販されているシステムの機能の標準化
2.既存のシステムの欠点
3.情報システムの生産のためのサポートシステムを作成する際の課題
IIIシステムの基本構造の設計
1.タイプごとに解決すべき問題の区分
「パート2」
2.それらの要件とタスク
3.それらの仕様とタスク
4.それらのアセンブリとタスク
5.設計段階の分析
IVシステムインフラストラクチャ要素の設計
無数の種類の魔法の中で、創造はより大きな自由を提供します。 誰もが独自の方法で作成します。 最善を尽くして、独自のフォームを見つけてください。
（おとぎ話）
前のパートで始めた馴染みのあるパターンの破壊と、他の新しいパターンの構築を続けます。
1.一般的なプロジェクトインフラストラクチャ
プロジェクト管理の観点からプロセスの構成について簡単に説明しましょう。 多かれ少なかれユニークな製品の生産について話しているという事実を考慮して、本質-「プロジェクト」は前のセクションですでに言及されました。
ほとんどのソフトウェア開発方法論は健全な反復アプローチを促進するため、プロジェクトをより小さな部分に分割する別の要素である反復を追加します。 この場合、情報システムの生産プロセス全体にスプレーされることはありませんが、コードの要件の実装に直接関連するアクティビティのみの反復で作業を編成します。 これにより、システムのスケーラビリティがわずかに低下しますが、最初の段階で、既存の製品の汎用性により技術的な適合性が低下することに注意しました。 したがって、システムを自分用に調整します。
標準トラッカーでは、反復は、ラベル、エピック、またはその他の追加機能を使用したタスクで最も頻繁に示されます。 追加のエンティティ「イテレーション」を導入します。
可能なデータモデルを図7に示します。
図7.-プロジェクト組織モデル
新しい「Scope to iteration」要素を使用して、「Specifications」を反復に入力する機会を提供します。 これにより、複数の反復で1つの仕様を実装する必要性という問題が解決されます。 プロジェクトの大部分は完全に不完全であり、このチャンスはかなり場違いであることが判明する可能性があります。
「反復範囲」要素に「実装済み」属性を追加し、成功（または失敗）を示すチェックリストを整理します。 これで、コードに仕様を実装し、慎重にチェックした後、反復のためにスコープリストで仕様を「ジャンプ」できます。 また、必要に応じて、たとえば、完了したタスクのステータスに応じて、このプロセスを完全に自動化できます。 ITマネージャーは、ミニマリズムのスタイルでこのような視覚的な調整を非常に好みます-彼、タスクのリスト、およびその実装に関する目盛りだけで、余計なものはありません。
それでは、Scopeの後ろから見ていきましょう。 そこで、計画された内容の確認を受け取ることが期待される後方で、「SRSタスク」の「反復にスコープ」を結び付けます。 したがって、反復の一部としてコミットされた仕様に従って実行されたすべてのアクティビティを追跡できます。 記事を注意深く読んだ人は、「SRSタスク」は「仕様」に直接関連し、さらに「反復の範囲」を通じて、過剰なつながりがあることに気付いているはずです。 これらの状況では、誰がそのような困難を解決するためにすでに慣れています。 たとえば、仕様への接続を削除できますが、これによりデータの処理が複雑になります。 特に、SRSタスクは反復なしでは設定できません。 しかし、あなたは何を知らない。 または、冗長な通信を残しますが、リンク内のデータの一貫性を確保します。 これにも十分な資金があります。
そして、まともな社会で慣習的であるように、各反復は、実施される義務（反復の仕様）に従って、実装された機能を備えた最終アセンブリで終了する必要があります。 これを行うには、「反復」で「アセンブリ」にリンクを設定します。
このシナリオでモデルをテストします。
- 反復のために、特定の数の仕様が含まれており、スコープに含まれています。
- スコープごとに、SRSタスクが各行に対して作成され、コードで仕様が実装されます。
- 新しいアセンブリがシステムに登録されます。
- すべての開発タスクが完了すると、アセンブリタスクが設定されます。
- スコープごとに、SRSテストタスクが行ごとに作成されます。
- アセンブリをスタンドに設置した後、テストタスクが実行されます。
- スコープごとに、成功したテストに合格しなかった各行に対して、エラーを修正するためのSRSタスクが設定されます。
- エラーが検出されるまで手順4から繰り返します。
- 反復で極端なアセンブリが組み立てられ、反復の結果が要約されます。
データモデルの場合、このシナリオは簡単です。
では、何がありますか？ 実装された機能のコンテキストとして、反復によってスコープを取得できます。 タイプ別、アーティスト別などのタスクリストを表示します。 パフォーマンス計画として。 何とどのようにレポートを参照してください。 最後に、製品の現在のバージョンを入手します。
要件の変更（管理）に関する作業は、反復の外部で実行できます。 基本的にフレームワークにそれらを含める場合、別のエンティティ「反復の要件の範囲」を追加して、共通の祖先から継承できます。図を参照してください。 8.同様に、緊急の必要がある場合、アセンブリ作業も反復に含めることができます。
図8.-反復のスコープ組織モデル
2.統合ソリューション
アセンブリの最初のトピックを考慮して、統合ソリューションの問題に触れました。これは、単一のソフトウェアパッケージに開発されている製品に異なるサブシステムの複数のアセンブリを含めることを意味します。 この面ではジレンマが発生します。一方で、いくつかの関連するアセンブリが1つのプロジェクトに同時に関与し、他方では、同じアセンブリが異なるプロジェクトに入り、異なる最終製品を入力する可能性があります。 「Product」という別の要素を含める必要性を強制的にハングさせます。
実際、ターゲット製品は、プロジェクトで情報システムを作成するプロセス全体の結果でなければなりません。
このようなターンでは、図9に示すように、「プロジェクト」との既存の「アセンブリ」接続を削除し、追加の「製品のアセンブリ」要素を介してインストールする必要があります。
図9.-対象製品の会計のモデル
ターゲット製品の新しいバージョンを少しずつ収集するため、これらの粒子自体（それに含まれるサブシステム）の再アセンブリは必ずしも必要ではありません。「製品のアセンブリ」では、選択したアセンブリが関連する製品のバージョンを示します。 解決策はまあまあです。もちろん、このメカニズムはペイントによって実装できます。
このソリューションのオプションとして、各サブシステムのアセンブリを個別の製品として表し、他のより基本的な製品からターゲット製品を形成できます。
3.コミュニケーションサポート
この出版物では、プロジェクトの参加者に連絡するというトピックについて、すでに何度も触れました。 たとえば、彼らは議論の間に要件と仕様についてコメントすることを検討しました。 標準の製品では、通知、割り当てられたタスクに関する参加者への通知、コメントでの言及など、多くの場合、まだ便利な機能があります。
しかし、ここでは、提案されている製品にはあまり見られない別の興味深いトピックがあります-検討中のシステムの枠組み内で会議や集会を開催します。 会議を計画する際に、システムで運用している一連の要素（要件、仕様、アセンブリ、反復、タスクなど）に基づいて議論中の問題を判断すると便利です。 繰り返しますが、議論の参加者は常に利害関係者（プロジェクトの利害関係者）の形で手元にあります。 問題に対する事前のドラフトソリューションを準備して、招待された人に前日の議題に慣れさせることもできます。
可能なデータモデルを図10に示します。
図10.-会議の組織モデル
たとえば、この写真を想像してください。プロジェクトに参加している複数のチームが、電話または吸音メッセンジャーを使用してリモートで通信し、「燃える」プロジェクトについて話し合います。 すべてがすでに輝いていて、限界まで加熱されています。 まだ怖くない？ その後、悪化します。 アナリスト、テスター、開発者、およびプロジェクトマネージャーがディスカッションに参加します。 最初に、1つのトピックをひねらないと、誰が責任を負いますか？ 提示？
さて、最初の質問が議論されたと仮定すると、彼らは悲鳴を上げ、お互いに目を開きました。 第二に移る時間です-どうすればいいですか？ これは、事前に準備された質問のリスト、さらに良いことに、すべてのディスカッション参加者が自分の画面で見ることができるように準備された決定草案のリストが便利な場所です。 ここで、誰でも質問から、たとえばその実装の需要やタスクに直接進むことができると想像してください。 コメント、レポートを参照してください。 数字と事実に誰かの鼻を突く。 そして、質問と同様に簡単かつ自然にページに戻ります。 便利ですか？
しかし、それだけではありません。 問題について話し合った後、すぐにその決定を策定し、今後のアクションの計画を修正し、将来的に実行者のタスクに変換することができます。 それだけです。すべての参加者はすぐにそれをすぐに見て、静かに同意するか、大声でresります。 そして最も重要なことは、これらすべてがシステムで修正されており、aでそれを削減できないことです。 また、手書きの落書きを使用して写真を添付する必要がなくなりました。 このような電撃戦は、状況を改善するという点で非常に生産的で効果的です。
このシステムでは、プロジェクトの会議のリストに従って、古い戦いを簡単にブラッシュアップし、製品を作成する過程で生じたすべての障害を排除した迅速かつ効果的な対策を自慢できます。