CGI POC
1.0.0
github：https：//github.com/cgi-zahid/cgi-poc
アプリケーション：[https://mycalerts.com]
管理者とサンプルのエンドユーザー資格情報を取得します
デジタルサービスのための事前に資格のあるベンダープールに対するCGIのアプローチ - アジャイル開発（PQVP DS-AD）の取り組みユーザー中心の設計技術、スプリントベースの開発ワークフロー、モダンおよびオープンソーステクノロジーを採用して、マイカラートを設計および構築し、ワーキングプロトタイプB.マイケラートを獲得するために、ユーザープロフィールを獲得するために、ワーキングプロトタイプを獲得します。アラート、および過去の通知を追跡します。ユーザーは、街路居住とユーザープロファイルで提供される通りの位置と連絡先情報に基づいて、短いメッセージサービス（SMS）と電子メールを介して通知を受信できます。 MyCalertsにより、認定された管理ユーザーは、イベントを追跡および視覚化し、アドホックな緊急事態および非緊急イベントの通知を送信できます。
RFIドラフトのレビューから始めました。 CGIはチームを設立し、Sprint 0の計画を開始しました。使用する技術的なアーキテクチャと環境を決定しました。標準の開発者ツールとアジャイルコラボレーションリソースを展開して、「Hello World」アプリケーション（簡単なログインページ）を構築して、技術スタックと継続的な統合/継続的展開（CI/CD）フレームワークをテストしました。
最終的なRFIを受け取ると、プロダクトマネージャー（PM）がプロトタイプ分析セッションを主導しました。チームは集まり、各プロトタイプの複雑さ、チームの関心、リスクを評価するために計画とサイジングセッションを開催しました。私たちのチームは非常に熱意を持って働くプロトタイプBを選択しました。
最初のユーザーインタビューに基づいて、PMはCAユーザーに最も関連するとみなされる3つのデータセットを選択しました。彼は、次の自動緊急通知の投票を選択しました：山火事（USGS Geomacからのアクティブな火災境界サービス - 15分ごと）、洪水（NOAAからの河川ゲージと予測サービス - 6時間ごと）、悪天候（NOAAからの気象危険サービス - 15分ごと）。
キックオフで、私たちのPMは、プロトタイプに対するビジョンと、作業を完了するための高レベルのロードマップを提供しました。チームは、役割と責任、そして共同チーム契約を確立しました。私たちはチームの仕事上の関係を固めて確立しました。ロードマップとプロトタイプの要件を使用して、チームは最初の一連のユーザーストーリーを開発しました。私たちのPMは、これらのストーリーをUX/UIおよび技術インフラストラクチャのセットアップストーリーとともに、製品のバックログを確立しました。
UX/UIデザイナーは、ペルソナインタビューと調査を使用してユーザーを早期に引き付けることにより、ユーザー中心のユーザー主導のデザインアプローチを促進しました。 Angularjsは、最新のアクセス可能なWebアプリケーションを実装するために、米国Webデザイン（USWDS）スタイルガイドの標準とコンポーネントセットを活用しました。また、ADA 508およびWCAG 2.0コンプライアンスをテストしました。さまざまな年齢、役割、経験、背景のユーザーを利用しました。スプリント1の間にユーザーにインタビューし、デスクトッププラットフォームとモバイルプラットフォームの両方に対応するレスポンシブなデザインを活用して、結果はすぐにワイヤフローに変わりました。これらのワイヤフローは、ユーザーの入力に基づいて継続的に洗練されていました。私たちのWireflowsは、プロトタイプのルックアンドフィールを開発者に伝えるためのビジュアルを提供しました。初期設計を超えて、ユーザーはユーザビリティテストを通じてエンゲージメントされ、その後のスプリントに含めるために製品バックログに追加された改善ストーリーを通じて、ユーザーは評価され、優先順位を付けました。
毎週のスプリントサイクルのアジャイルプロセス（図1）に従い、各サイクルは水曜日に始まり、次の火曜日に終了しました。
図1-アジャイルプロセス
毎週スプリントの儀式には、スタンドアップ - 月曜日から金曜日の午前8時45分 - 午前9時がアジャイルコーチが促進します。開発チームのメンバーは、前回のセッション以降に完了した作業を報告しました。次のセッションとブロッカーの前に計画された作業。特定されたブロッカーは、アジャイルコーチと配達マネージャーによってクリアされました。スタンドアップは、チーム全体で調整のための素晴らしいフォーラムを提供しました。
バックログのグルーミング - 月曜日、私たちのPMはバックログアイテムをレビューし、再生しました。アジャイルコーチと配信マネージャーがレビューをサポートし、チームの「準備の定義」に同意したユーザーストーリーを確認しました。
スプリントレビュー - 火曜日の朝、チームはレビューと承認のためにPMにスプリントで完成したユーザーストーリーを提示しました。チームの「完了の定義」に沿った承認されたユーザーストーリー。
スプリントレトロスペクティブ - 火曜日の朝、チームは、最近完成したスプリントでのツール、プロセス、ピアがどのように実行されたかを振り返りました。各チームメンバーは、チームが始めたいと思っていた1つの改善特性を特定するように求められました。チームがやめたいと思っていたものと、チームが継続してほしいと思ったもの。アジャイルコーチによって促進された特定されたスタート/ストップ/連続特性は統合され、チームによって定義された次のステップが統合されました。
スプリント計画 - 火曜日の午後、PMとチームの1時間のセッションは、次のスプリントのペイロードについてインタラクティブに議論し、同意しました。スプリントのアイテムのサイジングは、アジャイルコーチと配達マネージャーによって調整されました。 Planitpoker.comは、ストーリーの推定に使用されました。
チームの視覚的な例と、実際のアジャイルプロセスについては、チームフォトアルバムをご覧ください。
反復ごとに、プロトタイプはPMのビジョンとユーザーのニーズにますます整合しました。当社の高レベルのロードマップには、最終的に機能するプロトタイプに含まれていないユーザーストーリーがいくつか含まれていました。これらには、iOSネイティブクライアントアプリケーションのスパイク調査とネイティブプッシュ通知機能が含まれていました。どちらも投稿された最小限の製品（MVP）には含まれていませんが、製品のバックログ、アーキテクチャアーティファクト、GitHubソースコードに含まれています。
プロセス全体を通して、チームはスクラムボードを使用して作業を調整し、進捗を監視することができました。 Jiraを使用して、電子ボード（およびバグ）のユーザーストーリーを追跡し、チームルームで物理ボードを維持しました。 Confluenceをドキュメント共有に使用し、Hipchatはチームコラボレーションツールとして使用しました。メトリックが追跡されたため、チームは各スプリントでプロセス改善の潜在的な領域を理解しました。メトリックは、チームに開発速度、技術的なバックログ、および各スプリントで実際に実装されたストーリーポイントの割合を示しました。
すべてのテクノロジー決定について、オープンオプションを検討し、主にオープンソースのスタックを作成しました。当社のテクノロジーターゲットは、ブラウザベースの最新のWebアプリケーションでしたが、iOSでネイティブモバイルアプリの可能性も調査しました。
図2 - 当社のテクノロジースタック
DevOpsの観点から：
MicrosoftのAzure Infrastructureのプロトタイプをサービス（IAAS）ソリューションとしてテストおよび展開しました。ネットワーキングを含む継続的なインフラストラクチャモニタリングのためにAzureの監視ソリューションを使用し、継続的なアプリケーションパフォーマンス監視に新しい遺物を使用しました。主要なパフォーマンスインジケーター（KPI）データを使用して、インフラストラクチャソリューションとアプリケーションを微調整しました。
私たちのソリューションでは、GitHubを使用して、コードとユニットテストが公開されているGitHubリポジトリに記録されました。 GitHub構造には、マスターおよび統合ブランチがあり、機能分岐があります。個々のストーリーの開発は、ローカル環境の機能ブランチで行われました。コードを確認する前に、開発者はコードレビューをトリガーするためのプルリクエストを発行しました。コードレビューが承認されると、コードが統合ブランチに統合され、継続的な統合プロセスがトリガーされました。
図3は、CI/CDプロセスを使用して、開発から生産への高レベルコードの移行と、高レベルのコードの移行を示しています。
図3 - 継続的な統合と展開（ツール） 
JenkinsはGithubからコードを取得し、アプリケーションを構築し、単体テストを実行しました。すべてのユニットテストが合格した場合、Dockerは分布画像を作成しました。進行中の機能テストへの干渉を避けるために、毎晩テスト環境に緩和されたCDアプローチを採用しました。必要に応じて、アドホックな展開が収容されました。ビルドをテストするために展開すると、機能テストスイート（セレンを使用）は自動的に実行されました。
図4 - 継続的な統合と展開（プロセスビュー） 
以下は、アプローチで従った手順の概要です。
a。開発者は、dockerファイルを使用してローカル開発環境を設定して、オペレーション環境を模倣し、GitHubマスターブランチから機能ブランチを作成します（ステップ0）。
b。開発者は、ユニットテスト（ステップ1）を作成し、適切なソースコード（ステップ2）を書き込み、ユーザーストーリー/機能を実装します。
c。ユニットテストとソースコードをマージするために、開発者はプルリクエストを提出します。ピア開発者によるコードレビューをトリガーします。レビューアは、統合ブランチへのマージを承認/拒否します。最後に、開発者はコードレビューの観察結果を解決します。コードレビューが承認されると、機能ブランチが統合ブランチにマージされます（ステップ4）。
d。テスターは、統合分類（ステップ4）にマージされる自動化された機能スクリプト（ステップ3）を作成します。
e。事前に決定されたスケジュールで、Jenkinsはソースコードをコンパイルし、すべての単体テストが自動的に実行されます（ステップ5）。
f。単位テストが失敗した場合、障害に関して通知が送信され、開発者はそれを特徴的な特徴ブランチで修正します（ステップ15）。ステップ4と5は、単位テストが通過するまで繰り返されます。
g。ユニットテストが通過すると、JenkinsはDockerファイルを実行して、UIとバックエンドのDocker画像を作成します（ステップ6）。
h。 Dockerは画像をAzureレジストリ（ステップ7）にプッシュし、機能テストが自動的に実行されるテスト環境にそれらを展開します（ステップ8）。
私。機能テストが失敗した場合、通知が送信され（ステップ14）、開発者は問題を修正します（ステップ15）。ステップ4、5、6、7、8は、機能テストが通過するまで繰り返されます。
j。機能テストが成功すると、成功したテスト実行に関する通知が送信されます（ステップ9）。
k。 QAはアドホック/マニュアルテストを実行します。これらが失敗した場合、開発者は問題を修正するように通知されます（ステップ15）。ステップ4、5、6、7、8、9、10は、アドホックテストが通過するまで繰り返されます。
l。エラーが修正されると、統合ブランチはマスターブランチの生産タグとマージされます（ステップ11）。
m。最後に、テスト用に作成された画像は、生産環境に展開されます（ステップ12）。
ソースコードは、分散アーキテクチャとそれを実装するために使用されるソフトウェアに従うように構成されています。フロントエンドは、Angularフォルダーに保存され、バックエンドはDropWizardフォルダーに保存されます。また、Seleniumフォルダーに自動化された機能テスト用のフォルダーもあります。
UIはAngularJSを使用して構築されています。 Angularフォルダー内には、アプリフォルダーには、画像、言語、カスケードスタイルシート、スクリプト、ビュー用のサブフォルダーが含まれています。スクリプトフォルダーには、コントローラー、工場、サービスが含まれています。コントローラーフォルダーは順番にJavaScriptファイルをホストし、ビューフォルダーにはHTMLファイルが含まれています。ユニットテストは、テストフォルダー内のコードとは別に保持されます。
フロントエンドは、RESTFUL APIを使用してバックエンドと通信します。サービスを呼び出すフロントエンドコードは、スクリプトフォルダーの下にサービスサブフォルダーにあります。
アプリケーションバックエンドは、ビジネスロジックを実装し、外部サービスと通信し、通知を送信し、データベースと対話します。バックエンドは、DropWizardを使用して実装されており、JavaフレームワークをRESTおよびJUNITサポートを提供します。ビジネスロジックとエンドポイントはリソースフォルダーにあり、サービスの実装はサービスフォルダーにあります。
また、このアプリケーションは、外部のAPIラッパー（ここに実装）を実装して、外部データソースからデータを取得します。
ユニットテストはテストフォルダーにあります。
アプリケーションは、冬眠を使用してリレーショナルデータベース（MySQL）と通信します。データ検証には、標準のJAXB Bean検証を使用します。データアクセスオブジェクトとモデルオブジェクトは、DAOフォルダーにあります。
a。 1人のリーダーを割り当て、その個人の権限と責任を与え、提出されたプロトタイプの質についてその人物を責任を負わせた
RFI評価中、CGIは技術および管理の経験に基づいてプロダクトマネージャー（PM）を選択しました。 CGIは、PMにプロトタイプの設計と開発に関する最終的な意思決定権限を与えました。
b。添付ファイルB：PQVP DS-AD労働カテゴリの説明で特定されているように、少なくとも5つの労働カテゴリを含む学際的かつ共同チームを組み立てました。
首相のリーダーシップの下、CGIは、さまざまな技術的およびアジャイルな機能を備えた学際的なチームを集めました。
私たちのチーム：
c。プロトタイプ開発と設計プロセスに人々を含めることにより、人々が必要とするものを理解しました。
CGIは、プロトタイプの設計と開発に対するユーザー中心のアプローチに従いました。 UX/UIデザイナーは、ペルソナのインタビューと調査を使用して、早期にユーザーを引き付けました。インタビューの結果はすぐにワイヤーフローに変わりました。ワイヤフローは、ユーザー調査とユーザーとのユーザビリティテストに基づいて洗練されました。 WireFlowsは、PMが最初のストーリーを承認したら開発を開始できるように、開発者に希望のプロトタイプのルックアンドフィールを開発者に通信するための迅速で視覚的な方法を提供しました。
UIを開発するために、ペルソナインタビュー、ワイヤーフロー開発、ユーザビリティテスト、リーンUXなどの設計技術とツールを適用しました。応答性の高いブラウザベースのインターフェイスをサポートするために、最新のWeb標準とAngularJSのUS Web Design（USWD）のガイドラインを活用しました。これらの標準を適用して、ユーザーからの入力により、ナビゲートして使用するのがシンプルで直感的なプロトタイプを作成することができました。また、ADA 508およびWCAG 2.0コンプライアンスをテストし、自動化されたツールを使用して、適応型リーダーサポートやその他の低視力オプションをテストしました。
d。少なくとも3つの「ユーザー中心の設計」テクニックおよび/またはツールを使用しました。
私たちは、ユーザーのニーズと欲求に焦点を当てたプロトタイプの設計を開発するための主なツールとして、ペルソナのインタビュー、ワイヤーフロー、ユーザビリティテストを使用しました。
e。 GitHubを使用してコードコミットを文書化しました。
コミットはgithubで見ることができます：https：//github.com/cgi-zahid/cgi-poc
f。 Swaggerを使用してRestful APIを文書化し、Swagger APIへのリンクを提供しました。
中間層とのすべての通信は、REST APIを使用して行われました。 Middle Tierは、Jax RXを使用してREST APIを公開し、Swaggerで文書化されています。
g。障害者法およびWCAG 2.0のアメリカ人のセクション508を遵守しました。
ユーザビリティテストの一環として、508およびWCAG 2.0コンプライアンスをテストしました。自動テストを使用して、読みやすさと低視力をテストしました。バックログプロセスの一部としてエラーに対処しました。他のテスト結果を評価して、バックログに追加するものとプロトタイプに適用されなかったものを決定しました。
508テストにACTF Adesignerを使用しました。
h。デザインスタイルガイドおよび/またはパターンライブラリを作成または使用しました。
UX/UIは、米国のWebデザイン標準を使用してスタイルガイドを作成しました。私たちの配色は、カリフォルニアの色の状態に基づいて選択され、ユーザーのフィードバックによって承認されました。米国のWebデザイン標準をユーザーからの入力とともに適用することで、ナビゲートして使用するのがシンプルで直感的なプロトタイプを作成することができました。
私。人と一緒にユーザビリティテストを実行しました。
ユーザー中心のアプローチの一環として、ユーザビリティテストをプロセスに組み込みました。ユーザビリティテストは、ワイヤーフレームのユーザー調査と、スプリント全体でプロトタイプをテストしたユーザーからのフィードバックを通じて行われました。ユーザビリティテストからのフィードバックは、PMおよびUXデザイナーによって評価され、バックログに何を含めるかを決定しました。 PM方向に基づいて、新しいストーリーが作成され、優先順位付けされ、バックログに配置されました。
j。フィードバックが後続の作業またはプロトタイプのバージョンに通知する反復アプローチを使用しました。
各スプリント内で、プロダクトマネージャー、ユーザビリティテスター、およびテスト中に特定されたユーザビリティテスターから受け取った入力が評価され、優先順位付けされ、反復アプローチの一部としてバックログに組み込まれました。デモごとに、プロトタイプは、PMのビジョンとユーザーのニーズにますます調整されました。
k。複数のデバイスで動作するプロトタイプを作成し、レスポンシブデザインを提示します。
私たちのコードは、複数のデバイスを使用してテストしており、複数のWebブラウザーで動作します。さらに、コードはAppleおよびAndroidデバイスを使用してテストされています。
テストしました：
l。アーキテクチャ層（フロントエンド、バックエンドなど）に関係なく、少なくとも5つの最新およびオープンソーステクノロジーを使用しました。
次の6つの最新のオープンソーステクノロジーを使用しました。
すべてのテクノロジーのリストが提供されています：テクノロジーリスト。スプレッドシートのグリーンで強調表示されている行は、モダンでオープンソースのテクノロジーです。
m。インフラストラクチャにプロトタイプをサービス（IAAS）またはプラットフォームとしてサービス（PAAS）プロバイダーとして展開し、使用したプロバイダーを示しました。
AzureをIAASプロバイダーとして使用しました。
n。コードの自動ユニットテストを開発しました。
機能ブランチ開発者にコードをチェックする前に、コードレビューをトリガーするためにプルリクエストを行います。コードレビューが承認されると、コードが統合分類にマージされ、継続的な展開プロセスがトリガーされます。
o。継続的な統合システムをセットアップまたは使用して、テストの実行を自動化し、コードをIAASまたはPAASプロバイダーに継続的に展開しました。
継続的な統合にはJenkinsを使用しました。 GitHubからコードを取得し、テストをコンパイルして実行します。コードがテストに合格した場合、Dockerは画像を作成します。画像はシステムテスト環境に展開され、セレンを使用してエンドツーエンドの機能テストが実行されます。
p。設定または使用された構成管理。
Azureコンテナレジストリは、Docker画像を保存および管理するために使用され、構成を管理できます
Q継続的監視をセットアップまたは使用しました。
Azureと新しい遺物は、環境とアプリケーションの健康を継続的に監視するために使用されました
r。 Dockerなどのオープンソースコンテナにソフトウェアを展開しました（つまり、動作システムレベルの仮想化を利用）。
Dockerを使用してソフトウェアを展開しました
s。プロトタイプを別のマシンにインストールおよび実行するのに十分なドキュメントを提供しました。
以下は、インストール手順へのリンクです。
説明書
t。プロトタイプの作成と実行に使用されるプロトタイプおよび基礎となるプラットフォームは、公然とライセンスされ、無料で行われます。
オープンにライセンスされた無料のプラットフォームを使用しました
ツールのリスト
当社のプロトタイプの設計と開発のためのプロセスは、米国のデジタルサービスプレイブックで概説されている多くの標準に続き、満たしています。 GitHubの詳細なドキュメントを提供しました。これは、証拠にリンクするだけでなく、各アイテムへの応答も提供しました。
米国のデジタルサービスプレイブックの回答
