プロジェクトの方法論を選択したら、通常はそれを適応させ、補足する必要があります。 そのため、たとえば、多くの場合、XPでスクラムを補足します。 しかし、この場合でも、アーキテクチャの形成プロセスは十分に定義されていません。これは、数か月後の開発速度の劇的な低下またはプロジェクトの失敗の主な理由の1つです。
このシリーズの記事では、著者はスクラムのフレームワーク内での建築プロセスのビジョンを提示しています。これは、現在のプロジェクト（ CleanEngine ）を含むいくつかのプロジェクト（モバイルバンク）で開発されました。 アプローチの範囲：ビジネスクリティカル、ミッションクリティカル、ライフクリティカルなプロジェクト。
この記事では、カーネギーメロンソフトウェアエンジニアリングインスティテュート（SEI）建築学校の定義、用語、アプローチ、およびこの学校に関連する著者を使用しています。 また、チームは、たとえば自己組織化などのスクラムの基本原則に違反していないと想定されます。 同時に、スクラムが要求するように、チームが一流の専門家で構成される必要はありません。 チームでの十分な能力、スクラムマスターまたはアーキテクチャ所有者（後で彼について）。
最初の記事の紹介
サイクルの最初の記事では、開発の基礎、つまり要件を扱います。 分類、メンテナンスへのアプローチ、および形式化のオプションを提供します。 要件の形成はこの記事の範囲外ですが、アプローチの例があります。
定義
この記事の目的上、アーキテクチャとは、「Software Architecture in Practice（SAP）」という本に示されている定義として理解されています。「システムのソフトウェアアーキテクチャは、システムについて推論するために必要な構造のセットです。 。”私たちがまだアーキテクチャについて話している最下位レベルは、概念とエンティティです。 クラス、メソッド、属性などはこの概念を超えています。
利害関係者-プロジェクトの成功した実施から利益または損失を受け取る人。
アーキテクチャ要件（AT）の種類とその形式化
以下では、SEIに従って、アーキテクチャに影響を与え、アーキテクチャの決定を行うために必要/十分なシステム要件のタイプを検討します。 SAPでは、これらはアーキテクチャドライバーと呼ばれます。 これらの要件とその相互の影響に応じて、特定のアーキテクチャパターンと戦術が選択されます。
高レベル機能要件（FT）
英語の文献は、高レベル機能要件という名前で見つけることができます。
これらの要件は、システムが何をすべきか、どの機能を提供すべきかを説明していますが、一般的には遠い言葉です。 通常、これは顧客が操作するレベルです。 たとえば、買い手の個人アカウント、商品の検索と選択、カードによる支払い、売り手の個人アカウント、商品のカタログの維持、注文の即時通知。
このような要件は、短い文またはフレーズの形で説明できます。 どれほど便利なのか、主なことは本質を失わないことです。 ただし、それらを非常にグローバルなユーザーストーリーとして説明すると便利です。 そのため、建築の形成に携わる人々は、何をする必要があるかだけでなく、誰のために、またどのような目的のために必要かを見ることになるでしょう。 つまり トレーサビリティ要件。 これは、アーキテクチャの質、利害関係者の目標の達成にプラスの効果をもたらします。 また、これにより、将来、より小さなユーザーストーリーを抽出できるようになります。 また、それらはアーキテクチャに影響を与える可能性があります（通常は指定する）。
プロジェクト開始の段階（スプリント0、開始段階、開始段階）でもプロジェクトのビジョンにそれらを記述し、そこでサポートすると便利です。 同時に、タスクトラッカーで、選択した要件管理形式に応じて、大規模なユーザーストーリー、マイルストーン、イニシアチブなどとしてそれらを実施します。 たとえば、AtlassianのConfluenceとJiraを併用する場合、後者はEpicの作成に便利で、前者はプロジェクトビジョンの作成とEpicデータの統合に便利です。
もちろん、これらの要件の一部は時間の経過とともに無関係になるか、新しい要件が表示されます。 特に次のCusDevの後。 これはアーキテクチャに大きな影響を与えますが、通常は別のコンポーネントの外観によってのみ影響を受けます。
非機能要件/品質属性（AK）
英語では、非機能要件または品質属性という名前で文献を見つけることができます。
これらの要件は、システムが持つべき品質と程度を示しています。 たとえば、99.9999％の時間で利用可能である必要があり、メソッドの循環的複雑度は7未満である必要があります。これらは、製品の品質について話すために使用されるまさに言葉です：セキュリティ、信頼性、保守性など。
このようなシステム品質の属性は多数あります（一部の出版物によると、170以上）。 これらのシステムのどれを所有すべきかを決定することは、それらが互いに「入れ子になっている」という事実によって複雑になっています。 そのため、たとえば、パフォーマンスや信頼性がユーザビリティに「組み込まれている」とは言えません。 したがって、ISO 25010などの企業標準または業界標準は、このような特性の参照/チェックリストとしてよく使用されます。 顧客と一緒に座って、顧客と話し合ってこのISOを調べ、関連する品質属性を選択すると便利です。 このリストは品質計画の出発点にもなりますが、これは別のストーリーであり、場合によっては別のシリーズの記事です。
AKはしばしば互いに干渉します。 そのため、システムの信頼性を確保するには、多くの場合、パフォーマンスを犠牲にする必要があります。 また、パフォーマンスは保守性と矛盾します。 したがって、システムにとってより重要なものを理解し、適切な決定を下すには、このようなAKに優先順位を付けることが重要です。 たとえば、Androidアプリケーションをテスト（テスト容易性）でカバーすることが重要な場合、MVPパターンが適用される可能性が最も高くなります。 そのような必要性がなく、アプリケーションが複雑でない場合は、MVVMを残すほうがよい場合があります。
最後に、システムはいずれにせよこれらの品質を持っていますが、ある程度までは。 たとえば、システムのパフォーマンスをゼロまたは「フル」にすることはできません。 さらに、特性のわずかな増加は、アーキテクチャの大幅な変更と大幅な予算の増加を意味する場合があります。 したがって、考えられるすべてのAKのうち、システムにとって最も重要なAKのみが区別され、必要かつ十分なレベルを決定しようとします。
AKを実施するための最も具体的で厳密な形式の1つは、いわゆる「6パートシナリオ」です。
| フィールド | 価値 |
|---|---|
| 出所 | ユーザー |
| 刺激（トリガー） | ユーザーリクエスト |
| アーティファクト（影響を受けるアーティファクト） | システム |
| 環境 | 実行時（サードパーティサービスへの依存を除く） |
| 応答 | ユーザーはシステムを使用できます |
| 応答測定 | 99、999％の時間 |
これらは、ユーザーストーリーまたはエピックの受け入れ基準の1つとして適用できます。 これらは、完了の定義（完了基準）の一部にすることもできます。 AKは通常、システムの大部分またはシステム全体に関連するため、多くの場合、それらをEpicレベルで記述する必要があります。
より単純で厳密性の低い記述形式は、承認基準の1つの文に記載されています（たとえば、システムの応答速度は0.5秒でなければなりません）。 このような形式は、たとえば、どこで、誰によって、どのような条件下でこの受け入れ基準がテストされるかなど、完了基準が明確に続く場合、非常に受け入れられて十分です。 たとえば、ユーザーストーリーをステージング環境で公開し、特定の条件下で200リクエスト/秒で10分間テストする必要があります。
制約
一方、制約は、ビジネス上の制約（ビジネス上の制約）と技術的なもの（技術上の制約）に分けられます。 どのカテゴリに属していても、制限は、共有であっても、いかなる方法でも変更またはキャンセルできないことです。 満足しているかどうか。 これは、品質属性との主な違いです。品質属性はX％で満たされます。
たとえば、システムはWindows 8.0以降をサポートする必要があります。 .Netを使用します。ライセンスが購入され、企業文化はそれに基づいています。 制限は、予算、スタッフ、組織構造、オペレーティングシステム、ソフトウェア、開発ツール、ライブラリ、ハードウェアなどです。
制限がシステム全体に関連している場合は、プロジェクトのビジョンにリストできます。 システムのある部分に対しては、AKのように、受け入れ基準で対応するEpicを選択します。 形式は通常、短い文です。
プロジェクトビジョン
明確にするために、現在のプロジェクトのビジョンの目次を示します。 プロジェクトのビジョンは、一般的な基本情報が保持され、そこからすべてが発生する生きたドキュメントです。 プロジェクトの構成、いわば。 その構造は、特定のプロジェクト用に形成されています。
- 目的
- 問題と解決策
- 利害関係者と早期導入者
- 高レベルの機能要件
- 品質属性
- 制限事項
- 主な指標
- リスク
この場合、ドキュメントは開発の一部のみに関係します。 たとえば、他のプロジェクトでは、マーケティングとプロモーション、プロセスと役割、主要なパートナーなどに関するポイントがありました。
まとめ
そのため、この記事では、アーキテクチャ的に重要な要件のタイプ、それらの形式化および例を検討しました。 それらに関するより詳細な情報は、参照リストのソースにあります。 プロセスと役割については、次の記事で説明します。
文学
[SG] Scrum Guide、Ken Schwaber、Jeff Sutherland、2013
[SBoK] Scrum Body of Knowledge、Scrum Institute、2016
[SAP]実践的なソフトウェアアーキテクチャ、リックカズマン、ポールクレメンツ、レンバス、2012
[DAD]規律あるアジャイル配信、Scott Ambler and Mark Lines、2012
5. ISO 25010