設計ソリューション：ルールに従ってプレイする

ソフトウェアプロジェクトが大きくなればなるほど、その成功はアナリストの作業の結果、特に設計上の決定を作成して合意するための正しい戦略の選択に依存することは周知の事実です。しかし、これらの創造的な協力者の仕事をどのように整理しますか？そして、彼らの活動の結果を顧客の代表者とプログラマーの両方に等しく明確にする方法は？プロジェクトにとって可能な時間枠とこの作業の重要性をどのように評価しますか？この記事では、政府の顧客向けのソフトウェアプロジェクトの分析作業の管理を最適化するためのレシピを作成しようとしました。どんな批判も歓迎します。



ソース

研究フレームワーク

, .



.

現在、IT労働市場には20種類以上の「アナリスト」欠員が存在するため、カスタムソフトウェアを作成するための州のプロジェクトの分析作業について話し合うことをすぐに予約します。私の経験が示すように、ビジネスプロセスを自動化するメカニズムを理解していないビジネスアナリストは、問題の適切なステートメントを準備することができません。自動化のビジネス目標を理解していないシステムアナリストが適切ではないのと同じように。したがって、私の観点からは、カスタムソフトウェアプロジェクトに取り組むアナリストは、ビジネスアナリスト、システムアナリスト、およびUXデザイナーの能力を組み合わせる必要があります。さらに、原則として、そのようなプロジェクトの主任アナリストは、プロダクトオーナーの機能を実行する必要があります。（顧客が許可した場合）。このような「普遍的な兵士」の活動の組織化については、さらに議論されます。



政府機関の利益のためにソフトウェアを作成する場合、アナリストの主な活動は次のような問題の解決に関連しています。

• 要件管理;
• プログラマー向けのタスクステートメントの作成、実装計画、およびこれらのタスクの実装の制御。
• プロジェクト文書の作成。

カスタムソフトウェアの要件の管理の詳細、それらの最初の明確化の手順、およびそれらの実装を担当するアナリストの主要な役割については、前の記事で詳しく説明しました。



ただし、顧客の要望の具体性は、最終結果が気に入ってもらえることを保証するものではありません。私のプロジェクトの過程で、次のパターンが「明らかに」されました。すべてのタイプのテスト中に記録された顧客のすべての機能コメント（特定されたエラーと混同しないでください！）、設計ソリューションが顧客と積極的に合意されていない要件に関するもの。この点で、NatalyaRukolによって提供された統計は指標です。あるプロジェクトの結果を分析したところ、納品の段階で明らかになった「エラー」の約70％は、開発者側の初期要件の理解不足が原因であることが判明しました。 



ソフトウェア製品の要件が明確になった後、GOST RD 50-34.698に従って設計文書のパッケージを作成し、それを顧客と調整してから、承認されたプロジェクトに従ってソフトウェアを開発する必要があるように思われます。多くの場合、昨日の優秀な学生（原則として、グレードCはそのような文書の存在を知らない）や、ソフトウェア開発の最終結果に個人的に責任を負ったことのない多くの「経験豊富な」トップオフィシャルから聞かれる一連の行動についてです。 



私の経験が示唆しているように、プロジェクト文書の作成は、アナリストの作業の最後の部分にすぎません。例として、研究成果を引用することができます。その結果、GOST 7.32に従ってレポートを生成するか、論文を作成する必要があります。ただし、これらの文書は、得られた科学的結果を形式化したものにすぎません。実りのない実験の実施、「ホワイトノイズ」の統計処理、大量の疑似科学的古紙の中から必要な情報の粒子の検索-科学的作業のこれらすべての不可欠な部分は常に舞台裏に残っています。プロジェクトのドキュメントの場合も同じです。一方では、それはソフトウェア製品の不可欠な部分です..。一方、分析作業の最終結果のみが含まれています。  





出典



私の意見では、この側面は、ソフトウェアプロジェクトの政府契約の要件に従って、「愚かな」顧客が予備テストの段階で設計文書に同意することを計画している多くの理由の1つです。ソフトウェア開発の実際の完了時。



そのため、JIRAのソフトウェアプロジェクトでは、2つの異なるタイプのタスクが形成され、プロジェクトドキュメントの作成アクティビティから分析作業を直接分離することができます。そして、嬉しいことに、そのような結論に達したのは私だけではありませんでした..。では、要件を指定した後、プロジェクトドキュメントを作成する前に、アナリストはソフトウェアプロジェクトに対して正確に何をすべきでしょうか。

設計ソリューションと設計ドキュメント？

紙の上でどれほど美しいか、

言葉に従うのはどれほど簡単か。

あなたを間違いのないものにするのはどれほど簡単か。



B.グレベンシコフ

「設計ソリューション」の概念の定義がGOST34.003-90に記載されているという事実にもかかわらず、私の場合、この概念の意味は、クライアントが提案を単に無視したときに、いくつかの相互に関連しているがあいまいな要件の顧客代表に同意するための苦痛で実りのない試みの過程で「発見」されました。RD 50-34.698-90に厳密に従って形成された目標の設定（TMP）について説明します。顧客の一部についての決定は、試験開始まで行われないであろうことを認識した後、以下の操縦が行われました。私たちの設計ソリューションを顧客に送信されました（彼は正式に合意する義務はなかったこと、すなわち溶液）。 



儀式の属性は設計ソリューションで保持されましたが、ホストされたHMOと比較して、このドキュメントに大幅な調整が加えられました。設計ソリューションは、簡単な説明、ユーザーインターフェイスのレイアウト、印刷用に受信したレポートの形式、アクセスの分散の提案、およびこの設計ソリューションの提供に関する短いシナリオを含む自動化されたビジネスプロセスの図で補足されました。あいまいで矛盾する要件に関して、明確で詳細な説明が行われました。ただし、残りのテキストはあらゆる方法で最小化されました。画面フォームのフィールドが説明されていないのと同じように、簡単なアルゴリズムはまったく説明されていません。その目的と検証ルールは、特定のUIレイアウトから明確でした。  



得られたカクテルは、同時にRD 50-34.698-90の要件に従って作成された文書と形状が似ていましたが、実際には、このGOSTで指定された形式のいずれにも対応していませんでした。同時に、そこに書かれていることは、普通の、準備ができていない顧客の代表者によって理解されました。このドキュメントで指定されている要件は、顧客と請負業者の両方にとって完全に明確でした。要件の境界、計画された作業の必要な範囲、およびこれらの作業をどのように完了する必要があるかが決定されました。



カバーレターには次のようなものが含まれていました。



「記載されている要件を満たすための設計ソリューションのバリエーションを紹介します。提示されたオプションの実装に関する作業の開始についてお知らせします。提案された設計ソリューションに同意できない場合は、お知らせください。」



要件についてさらに議論する場合、そのような手紙への返答がないことは、提案された設計ソリューションとの顧客の正式な合意として解釈されました。顧客が異議を申し立てた場合、この場合、この設計ソリューションの実装に関する作業は中断され、承認されるまで続行できないことが通知されました。この場合、原則として、それ以上の承認ははるかに高速でした。



面白いことに、最初は返信の手紙で、顧客が必要な説明を送信しなかった場合、「作業が中断されました」というフレーズを使用しました。そのような手紙を何度か書いた後、顧客の代表者の1人が、「署名された契約によれば、作業を中断することはできず、要件に関する明確化がないことは開発を終了する理由にはならない」という事実に関連してスキャンダルを作成しました。しかし、彼は「仕事を続けることができなかった」という言葉に異議を唱えなかった。 



後で判明したように、設計ソリューションの形成された構造がGOSTの要件を満たしていないという事実にもかかわらず、提案されたアプローチは、設計文書の形成と承認のための儀式的な体の動きを大いに促進しました。プロジェクトの実施に必要な設計文書の内容は、設計ソリューションの関連セクションを選択的にコピーすることによって形成されました。同時に、予防的に「合意された」設計上の決定に基づいて作成されたドキュメントのセクションに関して、受け入れ中に顧客からのコメントはありませんでした。

 GOSTに準拠していない象の説明

真実は、顧客は彼らが何を望んでいるのかわからないということです。通常、彼らはどの質問に答える必要があるのか​​を知らず、仕様に示されているほど詳細に問題について考えることはほとんどありません。 



フレデリックブルックス

私の意見では、問題ステートメント（設計ソリューション）を適切に説明するための主な基準は、GOSTの正式な要件を満たすことではなく、顧客の要件を満たすための作業を正常に完了するための条件を明確に説明することです。この観点から、要件をチェックするためのテスト項目の説明は、実際にはあらゆる設計ソリューションの不可欠な部分です。





政府の顧客と協力する場合、設計上の決定におけるすべての曖昧さおよび曖昧さは常に政府に有利に解釈されることに注意する必要があります。このような死角を回避するために、ロギング要件の試行錯誤を通じて、設計品質評価チェックリストが作成されました。このチェックリストには、必要に応じて設計決定に反映される主要なセクションがリストされています。したがって、設計ソリューションは次の位置からチェックする必要があります。

1. 顧客の要件のリスト（設計ソリューションの一部として実装されます）。
2. 定義と略語のリスト。
3. 自動化されたプロセスを規制する規範的な文書のリスト。
4. (use case), :
   
   
   
   
   • ( , BPMN – , : , ) ;
   • ;
   • ( ) — ;
   • ( , ).
5. :
   
   
   
   
   • , ;
   • (UI) ( , , ); 
   • () .
6. :
   
   
   
   
   • API;
   • () «» ( );
   • () «» .
   
   
   , « » ( 2011 ., 1). - , ().
7. :
   
   
   
   
   • , () , ;
   • , () .
8. () , , . ( ) . ( ), , () , . «» .

繰り返しますが、これは設計ソリューションの固定構造ではなく、質問の正式なリストです（チェックリスト）、必要に応じて、その回答を何らかの形で設計ソリューションに反映させる必要があります。実践が示すように、上記の要素の1つに関連する開発が予期されていない場合は、設計ソリューションでこれを明示的に指定するとよいでしょう。またはほぼ明示的に（顧客を怖がらせないでください）。主な基準は、明確な解釈です。記載された要件を解決する代わりに、承認の結果として5つの新しい要件が生まれないように、やりすぎないことが重要です。たとえば、「オブジェクトタイプの参照には実際の値のみを含める必要があります」というフレーズと、「タイプの参照は変更の履歴を保存することはできません」というフレーズは同じことを意味しますが、2番目のフレーズは、バージョン管理メカニズムを記述して実装する必要があるという事実につながる可能性があります。これはまさにハンドブックです。設計上の決定を行うとき、その目的は、これらの決定に関連する要件を引き渡すことが保証されているルールを修正することであることを理解することが重要です。

, , , .

プロジェクトの大部分（すべてではないにしても）は、顧客の代表者が最終結果をどのように想像するかに依存します。したがって、すでに初期段階では、ユーザーインターフェイスレイアウトの設計がプロジェクトの成功の鍵となります。顧客が理解しているソフトウェア製品の外部説明の観点から、顧客の要件を明確にして指定します。画面レイアウトの議論に基づく顧客の代表者との対話は、入力および出力データ形式とそれらの変換アルゴリズム（GOSTに従って作成されたIPRの主要セクション）の議論に関する対話よりもはるかに効果的であることが証明されました。



設計割り当てのフレームワーク内で作業することにより、実装境界を理解する透明性に加えて、ユーザーインターフェイスのすべての要素が、いくつかの問題の解決策にもなります。

1. . , , UI, , .
   
   
   
   
   
   : . . ISBN: 978-5-91180-090-1
2. UX- . , , ( ).
3. «» . UI , , – , ( « » ).
4. , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».

出典



自動制御システムのユーザーインターフェイスの設計の原則について少しお話したいと思います。モバイルデバイスの使用が雪崩のように増加しているにもかかわらず、デスクトップコンピュータとラップトップは、政府機関で使用される自動制御システム（およびプログラミングとシステム管理の問題の解決）をめぐって競争に参加していません。現在、インターフェイスのプロトタイピング用にさまざまなツールが登場しています。ただし、モバイルデバイスの利益のためにFigmaまたはAxureを使用する詳細を説明すると、ユーザーインターフェイスの90％を設計できる基本的な方法の10％が失われます。ACS。



私の経験では、ソフトウェア開発の問題を大幅に減らすには、ユーザーインターフェイスを設計するときにいくつかの簡単なルールに従う必要があります。



まず、一般的なナビゲーションスキームを決定する必要があります。このスキームでは、クリスマスツリーのように、新しいインターフェイス要素を簡単に掛けることができます。この点で、私の実践における自動制御システムの場合、最も効果的なスキームが示され、さまざまなIDEで広く使用されています。 



ここでは、IntelliJIDEAまたはPhpStormインターフェイスの例を示しません。ただし、自動制御システムのアナリストの観点から、このようなUIの主要コンポーネントをコンポーネントパーツに分解しようと思います。



このスキームに従って構築されたインターフェイスには、左側に折りたたみ可能な垂直パネルがあり、システム全体のナビゲーションを提供します。階層メニューを含むセクションを含む垂直パネルの存在は、実際には「3クリック」ルールの実装を保証します。





メインナビゲーションバーの各メニューオプションから、オブジェクトのフォームリストにアクセスできます。オブジェクト（カタログ）とこれらのオブジェクトを表示するフォーム（カード）のリストは、ユーザーインターフェイスの大部分を占めています。プロジェクトのフレームワーク内でこれら2種類のフォームを統合し、それに基づいてナビゲーション構造を形成することで、ユーザードキュメントの欠点に関連するユーザーリクエストの数を大幅に減らすことができます。



リストフォームの説明の枠組みの中で、設計は以下を決定する必要があります。

• 表示される属性フィールドのリスト。
• リストビューモードの要件（デフォルトの表示、グループ化、並べ替え）。
• リストアイテムに関連付けられたサブフォームの要件（クイックビューカード（表））。
• フィルタパネルの要件（特定の属性リストに従ったレコードの選択）。
• グループ操作の説明（たとえば、リストアイテムの比較、複数のリストアイテムの属性の変更、複数のリストアイテムのアクセス権の変更など、複数のリストアイテムに対する同時アクション）。
• リスト選択の結果に基づく運用統計レポート（監視）のフォーム（パネル）の説明。
• 印刷用のレポートの要件とその生成のためのアルゴリズムの説明。
• オブジェクトが変更されたときにユーザー（外部システム）に通知するための要件。

リストフォームを設計する場合、次のルールが適切に機能します。

1. — , «» , .   (ribbon). 
2. , , :
   
   
   • — , CRUD: , , , ;
   • ( , );
   • ;
   • ( , , ).
   
   
   
3. ( .. ) . , . .

  :

•   ;
•   , (CRUD, , ..) ;
• /;
• 可能な情報メッセージのリスト。
• オブジェクトの変更の履歴を表示する方法。

ツールキットについて一言。政府の命令によるさまざまなプロジェクトの実施中の試行錯誤の結果、インターフェース設計に対する次の3つのアプローチが最も効果的であることが証明されました。

1. 開発中に既存のインターフェースへの変更が必要な場合は、ホイールを作り直さないでください。ここでPaint.NETは何よりも優れていることを示しました（ちなみに、この記事の写真はその助けを借りて作成されました）。フォームを再描画することは意味がありません。完成したスクリーンショットを変更する方が簡単です。
2. , — « »,   MS Visio . , , , , MS Visio, , , Windows. 
3. , -  , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».

繰り返し、これらすべての議論を高度な開発者に与え、顧客の問題から遠く離れて、私は彼らの色あせた視線を見て、提案されたUIの惨めさと過負荷についての専門家の評価に耳を傾けました。しかし、時間の経過とともに、いくつかのプロジェクトの経験を分析した後、驚くべきパターンに気づきました。プログラマーが開発されたユーザーインターフェイスの後方性と複雑さを熱心に批判する場合、これは顧客がそのようなインターフェイスを大胆に受け入れることの確かな兆候です。

足場とフォームワーク

通常、人々はよく考えます。しかし、問題は、彼らがこれらの問題の解決策ではなく、問題について考えることです。



デビッドアレン

住宅の建設中は多くの補助構造が使用されますが、建設完了後は完全に不要です。これらは足場とフォームワークです。驚くべきことに、非専門家でさえ、これらの構造を購入して維持する必要性に異議を唱えようとはしません。対照的に、IT業界では、「経験豊富な」アナリストがすべての要件を満たすプロジェクトドキュメントをすぐに作成するのに苦労しているのをよく目にします。



しかし、私の意見では、設計ソリューションの予防的な登録と承認がなければ、作成された設計文書は契約の正式な終了にのみ適しており、将来的にはそれが役立つ以上に運用に悪影響を及ぼします。ただし、分析作業における「補助構造」は、上記の設計ソリューションとプロトタイプだけではありません。



出典



一見、すべてがアナリストの経験に依存しているように思われ、これらの補助的な作業の使用を規制することは不可能です。たとえば、1日中顧客を訪問し、翌日3ギガバイトのあらゆる種類のドキュメントを持ってきたアナリストの作業を考慮して規制するにはどうすればよいでしょうか。それとも、アナリストがこれらのドキュメントの調査に1週間を費やしたということですか？これは良いですか悪いですか？そして、プロジェクトの実装に照らして意味のある結果がわからなければ、その質問に答えることはできません。



そのため、私たちのプロジェクトの枠組みの中で、達成された結果の観点から実行された分析作業の分類が実行されました。設計ソリューションに加えて、私が参加しなければならなかったソフトウェアプロジェクトのほとんどは、アナリストが次のタイプの分析資料を開発することを要求しました。

• ドキュメント分析-顧客の規制ドキュメントまたはプロジェクトドキュメントの分析結果に基づくレポート。
• 分析レビュー-発生した問題の解決策の分析結果に関するレポート（原則として、新技術または市場動向の比較分析）。
• 情報調査-顧客の既存のビジネスプロセスの調査結果に関するレポート（現状のモデルの形成-「現状のまま」）。
• — ,   (use case).  legacy-.  
• — , ( ).  
• — , .

予測可能な設計に向けた2番目のステップは、目的の分析結果に対する特定の要件を定義することでした。これらの要件に基づいて、開発中の分析材料のタイプごとにJIRA問題記述テンプレートが定義されました。





分析材料の開発に関するタスクのステートメントには、分析プロセスの説明ではなく、必要な結果の簡単な説明が含まれます。したがって、たとえば、「ドメイン分析を実行する...」や「ドキュメントを調査する」などのフレーズは避けることをお勧めします。

マエストロの計画 

すべてをできるだけ単純に述べる必要がありますが、単純ではありません。



アルバート・アインシュタイン

多くの場合、スケジューリング分析とプログラミング作業に関しては、この場合の結果のタイミングをどのように見積もるかについて多くの論争があります。ただし、この創造的な活動の上記の分析により、ソフトウェアプロジェクトのフレームワーク内でそれがまだ可能であると仮定することができます。これに向けた最初のステップは、システム設計作業を、少なくとも週に1回の頻度でチェックできるパーツに分割することです。GOST R ISO / IEC 15910-2002によると、1つの設計ソリューションを形成するためのアナリストの人件費が5営業日を超えないように努める必要があります（ボリュームの観点から、このような設計ソリューションは約20〜30ページで構成する必要があります）。）。したがって、同じ基準に従って、プログラマーは同じ設計ソリューションをレビューするのに最大3時間かかる必要があります。 



設計ソリューションから技術プロジェクトを作成する必要はないことを理解することが重要です。設計ソリューションは、相互に関連する要件の小さなグループのみをカバーする必要があり、その結果を顧客に提示できます。



メアリーとトム・ポッペンディークが設計上の決定を行う際に警告する罠に陥らないようにすることも重要です。つまり、事前に作成された詳細な仕様が損失を減らすことが保証されているという神話に人質にならないようにします。原則として、設計ソリューションに同意する場合、顧客は覚えているすべてのものをこのドキュメントに詰め込もうとします。したがって、それに同意するときは、予備テストの合格を確実にするために必要な最小値を確保することが重要です。同時に、成功への鍵は、品質、タイミング、コストの組み合わせだけでなく、プロジェクト参加者の結果に対する満足度でもあります。



原則として、分析タスクの完了期限を取得するには、請負業者自身の専門家による評価で十分ですが、紛争が発生した場合は、実用的なアプローチを適用できます。..。分析のためのタスクの労働強度の評価の客観性を高めるために、オンライン計算機を使用することができます。これにより、分析作業を実施するための人件費を計画および見積もることができます。このツールを使用すると、プロジェクトの詳細に応じて、計画された作業のリストを作成し、それらの文言を明確にすることができます。計画された作業のそれぞれについて、人件費の最小、最大、および最も可能性の高い見積もりが考慮されます。計算の結果、タスクの予想される複雑さが形成され、最適な時間準備金が計算されます。これは保険のために残しておく必要があります。分析のために問題を設定するために生成された説明は、JIRA問題説明フィールドに直接コピーできます。



記事「JIRA：プロジェクトの境界」で説明されている一般的な属性に加えて"、JIRAの"分析 "タイプの各問題について、次の追加の（カスタム）属性のセットが経験的に決定されました。





上記を考慮して、ソフトウェア開発の利益のために「分析」タイプのタスクを実装するためのアナリストの以前に与えられた一連のアクションを明確にしましょう。



1.必要に応じて、担当アナリストはJIRAでタスクをスケジュールして、顧客の代表者と情報調査を実施する必要があります（これらのタスクは関連する要件にリンクされています）。



会議の前に、最初の概算として、顧客と話し合うことができるユーザーインターフェイスレイアウトを作成することをお勧めします。情報調査を実施する際には、お客様の視点から（ユーザーストーリー-ユーザーストーリー）、主なビジネスプロセスについてお客様と話し合う必要があります。）、顧客が最終結果を見る別の方法。 



情報調査の基本は、自動化されたプロセスの機能について詳しく教えてくれる有能な従業員にインタビューすることであるという意見によく会いました。ただし、商用顧客の利益のために開発に役立つことは、政府にとって最も予期しない結果をもたらす可能性があります。白髪のベテランの話に基づいて形成されたプロセスの説明が、現在の規制文書の主要な要件と矛盾していることが判明したとき、私は繰り返し状況に遭遇しました。そして、これは、アナリストが何かを誤解したという事実によってではなく、ベテランが「これを一生やりました」という事実によって説明されました。



したがって、主題の専門家と会う前に、自動化が期待されるプロセスを規制するという観点から規制文書を分析する必要があります。同時に、規制文書も究極の真実ではないことを理解することが重要です。多くの場合、公平な分析では、規制文書には常に曖昧さと矛盾が含まれます（例外は、原則として「血で書かれた」文書です）。ここにあなたが注意を払うべき最も一般的な不一致のいくつかがあります：

• 分類の基本原則の違反。たとえば、同じグループ内で異なる兆候が混在している場合（赤、緑、暖かい）。
• 考慮されていない属性に基づく報告文書の作成。
• ;
• - ;
• — - , .

これらの規制の矛盾を解決することは、顧客の代表者と会う際の重要な問題の1つです。この決定を記録するために、情報調査の結果として、参加者、場所、および時間を示すプロトコルを作成する必要があります。プロトコルは、明確にするために顧客に提示されます（電子メールは対応するタスクに添付されます）。その後、情報調査のタスクを「完了」状態に移行することができます。このJIRAタスクは、プロトコルの承認について顧客から確認を受け取った後、「クローズ」ステータスに転送されます。



2.2。  指定された要件と情報調査の結果に基づいて、設計ソリューションが形成されます。担当のアナリストは、プロジェクトマネージャーおよびプログラマーと調整する必要があります（それぞれについて、適切なサブタスクが作成されます）。設計ソリューションが営業日に内部承認に合格しなかった場合、タスクは「保留中」ステータス（プロジェクトマネージャーへの通知）に転送されます。内部承認に合格すると、設計ソリューションはレビュー（必要に応じて承認）のために顧客に送信されます。すべての提出の詳細は、タスクへのコメントに記録されます。設計ソリューションが顧客側にある間、タスクは「保留中」のステータスに転送されます。



3.3。プロジェクトソリューションが合意された場合（または承認が遅れており、期限が切れていることが明らかな場合）、担当のアナリストはそれに基づいて開発、テスト、および文書化のタスクを策定します。この場合、設計ソリューションを実装するための人件費（この設計ソリューションに関連する開発タスクの人件費の合計として）の予備評価を実行する必要があります。この評価に基づいて、関連する要件の実施のタイミングを明確にする必要があります。



4. 顧客との合意（この事実を確認する手紙はJIRAに保存されます）の後、設計ソリューションを準備するタスクを「完了」ステータスに移すことができます。

つづく 

現在、政府機関のお客様向けのソフトウェア設計は、ほとんどの場合、GOST34シリーズの要件に従って編成されています。同時に、最終的な設計文書がこのGOSTに正確に準拠することを提唱し、顧客の代表者のほとんどは、開発されたソフトウェアをテストするために提供される文書に加えて、ドラフトおよび技術プロジェクトの承認の枠組み内で設計ソリューションを承認する必要があることを「忘れる」ことがよくあります。また、ドラフトと技術設計が合意された場合でも、フォームに完全に準拠した非現実的な期限のためにコンテンツが無視されることは珍しくありません。これは、生命の安全に直接関係しないシステムの設計に特に当てはまります。そのため、プロジェクトの1つで、1人の副長が「人生を教えた」彼が一晩でウィキペディアを使用して500ページの技術プロジェクトを構築した方法について話します。原則として、まったく異なる人々がそのような「設計上の決定」の結果を解きほぐす必要があります。



これらの困難な状況では、ここで説明するアプローチにより、実装されたソリューションの一貫性を維持しながら、ソフトウェア機能の反復的なビルドアップを編成できます。これは、無駄のないソフトウェア開発の原則に対応します。一方、説明されている設計ソリューションのターゲット設定により、最小限のコストで顧客の「Procrustean」要件を満たすドキュメントをそれらに基づいてコンパイルすることが可能になります。



分析作業を基本的なアクションに分割することで、トレーニングのレベルが異なる複数の従業員のアクションを調整することも可能になり、その結果、LANITでのプロジェクトのアナリストの能力マトリックスが自然に形成されます。これについては次の記事で説明します。



PSこの記事は、政府機関の利益のためにカスタムソフトウェアプロジェクトに関するチームの非公式な規制として使用する「おいしいソフトウェアのタイムリーな準備のためのルール」と呼ばれる一連の記事の一部です。このシリーズには、次の記事が含まれています。-

「不眠症と神経衰弱の治療薬としてのJIRA」-JIRAを使用してプロジェクトの作業を整理するための主なアイデア。

-「JIRA：プロジェクトの境界」-プロジェクトの統合に関する基本的な規定と、すべてのタイプのJIRAタスクの一般的な要件。

-「JIRA：要件管理」-提案されたモデル内の顧客要件の実装の登録、明確化、および制御の主要な機能。

-「設計ソリューション：ルールに従ってプレイする」-分析作業管理の主な側面と開発者向けの問題ステートメントの形成。

このサイクルの枠組みの中で、以下は、出版のために準備されている：

- 「アナリスト・コンピタンスのマトリックス」 -カスタム・ソフトウェア・プロジェクトにアナリストの成熟度のレベルを評価するための基準を、

-「問題がプロジェクトに隠れている場所」-ソフトウェアプロジェクトの現在の状態の運用評価の基準（メトリック）。



このシリーズの記事の主なラベルは、管理効率の向上に基づいて、ソフトウェアプロジェクトの品質を進化的に向上させることです。言い換えれば、 CMMIモデルのレベルで成長の適用された方法を形成すること。

ソフトウェアプロジェクトでJIRAをより効率的に使用する方法を理解した場合は、アイデアを共有してください。これらのアイデアを説明する場合にのみ、「どういうわけか」や「どういうわけか」というフレーズは避けてください。みんなで話し合ってください。コメントのコメント/提案/疑問/願いを待っています。