CGI POC
1.0.0
Github: https://github.com/cgi-zahid/cgi-poc
Anwendung: [https://mycalerts.com]
Erhalten Sie Administrator- und Beispiel -Endbenutzer -Anmeldeinformationen
Der Ansatz von CGI zum vorqualifizierten Anbieterpool für digitale Dienste-Agile Development (PQVP DS-AD), die benutzerorientierte Designtechniken, ein Sprint-basierter Entwicklungs-Workflow sowie moderne und offene Source-Technologien verwendet haben, um Mykallerts zu entwerfen und zu bauen, Mycalerts, unsere Implementierung von Arbeitsprototypen. Mycalerts. Verfolgen Sie ihre früheren Benachrichtigungen. Benutzer können Benachrichtigungen über Short Message Service (SMS) und E-Mail an der Grundlage der in ihrem Benutzerprofil bereitgestellten Straßenstand und Kontaktinformationen erhalten. Mit MyCalerts können autorisierte Verwaltungsbenutzer Ereignisse verfolgen und visualisieren und Benachrichtigungen über Ad-hoc-Notfall- und Nicht-Notfall-Ereignisse senden.
Wir begannen mit einer Überprüfung des RFI -Entwurfs. CGI gründete unser Team und begann mit Sprint 0 Planung. Wir haben die technische Architektur und die Umgebungen bestimmt, die wir verwenden würden. Wir haben unsere Standard -Entwickler -Tools und agile Ressourcen für die Zusammenarbeit bereitgestellt, um eine „Hello World“ -Anwendung (eine einfache Anmeldeseite) zu erstellen, um unseren technischen Stapel- und Continuous Integration/Continuous Deployment (CI/CD) -Frahmen zu testen.
Nach Erhalt des endgültigen RFI leitete unser Produktmanager (PM) eine Prototyp -Analysesitzung. Das Team kam zusammen und hielt eine Planungs- und Größensitzung ab, um die Komplexität, das Teaminteresse und die Risiken jedes Prototyps zu bewerten. Mit großer Begeisterung wählte unser Team Arbeitsprototyp B.
Basierend auf anfänglichen Benutzerinterviews wählte der PM die drei Datensätze aus, die für CA -Benutzer am relevant sind. Er entschied sich für die folgenden automatisierten Notfallbenachrichtigungen: Waldbrände (Active Fire Bord Service von USGS Geomac - Alle 15 Minuten), Überschwemmungen (Flussmessgeräte - Aktueller und prognostizierter Service von NOAA - alle 6 Stunden) und Unwetter (Weather Hazards Service von NOAA - alle 15 Minuten).
Beim Kickoff lieferte unser Premierminister seine Vision für den Prototyp und eine hohe Roadmap für die Fertigstellung der Arbeit. Das Team hat Rollen und Verantwortlichkeiten sowie eine kollaborative Teamvereinbarung festgelegt. Wir haben unsere Teamarbeitsbeziehungen festgenommen und aufgebaut. Unter Verwendung der Roadmap- und Prototyp -Anforderungen entwickelte das Team eine erste Reihe von Benutzergeschichten. Unsere PM priorisierte diese Geschichten zusammen mit UX/UI und technischer Infrastruktur -Setup -Geschichten, um unseren Produkt -Rückstand zu etablieren.
Unser UX/UI -Designer hat einen benutzerorientierten - benutzerorientierten Designansatz erleichtert, indem sie Benutzer frühzeitig durch die Verwendung von Persona -Interviews und -Ervorens einbezogen haben. Wir haben AngularJs zusammen mit den Standards und Komponenten des USWDS-Leitfadens (USWDS) -Stile zur Implementierung einer modernen, zugänglichen Webanwendung genutzt. Wir haben auch für ADA 508 und WCAG 2.0 Compliance getestet. Wir haben Benutzer unterschiedlicher Alters, Rollen, Erfahrungen und Hintergründe getroffen. Während des Sprint 1 befragten wir Benutzer und unsere Ergebnisse wurden schnell in Wireflows verwandelt, in denen ein reaktionsschnelles Design verwendet wurde, das sowohl Desktop- als auch mobile Plattformen entspricht. Diese Drahtflows wurden basierend auf der Benutzereingabe kontinuierlich verfeinert. Unsere Drahtflows bildeten ein Bild, um den Entwicklern das Erscheinungsbild des Prototyps zu vermitteln. Über das anfängliche Design hinaus wurden die Benutzer durch Usability -Tests beteiligt, und ihre Eingaben wurden bewertet und durch Verbesserungsgeschichten priorisiert, die dann im Produkt Rückstand zur Aufnahme in nachfolgende Sprints hinzugefügt wurden.
Wir verfolgten einen agilen Prozess (Abbildung 1) von wöchentlichen Sprintzyklen, wobei jeder Zyklus am Mittwoch begann und am folgenden Dienstag endete.
Abbildung 1 - unser agiler Prozess 
Jede Woche wurden Sprint-Rituale gehörten: Stand-up-Montag bis Freitag um 8:45-9:00 Uhr vom Agile-Trainer erleichtert. Die Mitglieder des Entwicklungsteams berichteten über die seit der letzten Sitzung abgeschlossenen Arbeiten. Geplante Arbeit vor der nächsten Sitzung und alle Blocker. Die identifizierten Blocker wurden vom Agile Coach und Liefermanager gelöscht. Stand-up bot ein großartiges Forum für die Koordination im gesamten Team.
Backlog -Pflege - Montag, unser Premierminister überprüft und wiederholte Rückstandsgegenstände. Der Agile Coach und der Liefermanager unterstützten die Überprüfung und bestätigten die Benutzergeschichten, die mit der „Definition von Ready“ des Teams übereinstimmten.
Sprint Review - Dienstagmorgen präsentierte das Team abgeschlossene Benutzergeschichten im Sprint dem PM zur Überprüfung und Genehmigung. Genehmigte Benutzergeschichten, die auf die „Definition von Fertig“ des Teams ausgerichtet sind.
Sprint Retrospektive - Dienstagmorgen dachte das Team darüber nach, wie ihre Werkzeuge, Prozesse und Kollegen auf dem kürzlich abgeschlossenen Sprint ausgeführt wurden. Jedes Teammitglied wurde gebeten, ein Verbesserungsmerkmal zu identifizieren, das das Team begann. Einer wollten das Team aufhören und eine, die das Team weitergeht. Von dem Agile -Trainer erleichtert, wurden die identifizierten Start-/Stop/Fort -Merkmale konsolidiert und die nächsten Schritte, die vom Team definiert wurden.
SPRINT -Planung - Dienstagnachmittag, eine einstündige Sitzung für den Premierminister und das Team diskutierten interaktiv und vereinbarten die Nutzlast des nächsten Sprint. Die Größe der Gegenstände im Sprint wurde vom Agile Coach und Liefermanager koordiniert. Planitpoker.com wurde zur Schätzung der Story verwendet.
In unserem Team -Fotoalbum finden Sie visuelle Beispiele des Teams und unserem agilen Prozess in Aktion.
Mit jeder Iteration wurde der Prototyp zunehmend auf die Vision des PM sowie die Bedürfnisse unserer Benutzer ausgerichtet. Unsere High-Level-Roadmap enthielt mehrere Benutzergeschichten, die letztendlich nicht in den Arbeitsprototyp aufgenommen wurden. Dazu gehörten Spike Research für eine native Client -Anwendung für iOS und native Push -Benachrichtigungsfunktionen. Während sich beide nicht im veröffentlichten minimal lebensfähigen Produkt (MVP) befanden, sind sie im Produkt -Rückstand, Architekturartefakte und GitHub -Quellcode enthalten.
Während des gesamten Prozesses war das Team in der Lage, die Arbeiten zu koordinieren und den Fortschritt mithilfe unseres Scrum -Boards zu überwachen. Wir haben JIRA verwendet, um Benutzergeschichten auf einem elektronischen Board (sowie Fehler) zu verfolgen und ein physisches Board im Teamraum zu pflegen. Wir haben Confluence für das Teilen von Dokumenten und das Hipchat als Tool für die Zusammenarbeit von Teamkollaborien verwendet. Metriken wurden verfolgt, sodass das Team verstand, wie es es ging und potenzielle Bereiche zur Verbesserung der Prozessverbesserung mit jedem Sprint. Metriken zeigten dem Team ihre Entwicklungsgeschwindigkeit, technische Rückstände und wie viel Prozent der Story -Punkte tatsächlich mit jedem Sprint implementiert wurden.
Für jede technologische Entscheidung haben wir offene Optionen berücksichtigt, was zu einem Stapel führte, der überwiegend Open Source ist. Unser Technologieziel war eine moderne Webanwendung auf Browserbasis, aber wir haben auch die Möglichkeit einer nativen mobilen App auf iOS untersucht.
Abbildung 2 - Unser Technologiestapel 
Aus dem Gesichtspunkt von DevOps:
Wir haben den Prototyp auf der Azure Infrastructure (IAAS) von Microsoft Azure Infrastructure (IaaS) getestet und bereitgestellt. Wir haben die Überwachungslösung von Azure für die kontinuierliche Überwachung der Infrastruktur einschließlich der Netzwerk und für die kontinuierliche Überwachung der Anwendungsleistung verwendet. Wir haben die KPI-Daten der wichtigsten Leistungsindikatoren (KPI) verwendet, um unsere Infrastrukturlösung und -anwendung zu optimieren.
Unsere Lösung verwendete GitHub, um Code und Unit -Test in unserem öffentlichen Github -Repository zu dokumentieren. Unsere Github -Struktur verfügt über Master- und Integrationszweige sowie Spielzweige. Die Entwicklung einzelner Geschichten wurde in einer Feature -Niederlassung in einer lokalen Umgebung durchgeführt. Vor dem Einchecken des Code haben die Entwickler eine Pull -Anfrage zur Auslösung einer Codeüberprüfung veröffentlicht. Sobald die Code -Überprüfung genehmigt wurde, wurde Code in den Integrationszweig zusammengeführt, wodurch der kontinuierliche Integrationsprozess ausgelöst wurde.
In Abbildung 3 werden die Tools -Ansicht und die Code -Migration auf hoher Ebene von der Entwicklung bis zur Produktion unter Verwendung unseres CI/CD -Prozesses angezeigt.
Abbildung 3 - kontinuierliche Integration und Bereitstellung (Tools) 
Jenkins hat den Code aus GitHub abgerufen, die Anwendung erstellt und Unit -Tests durchgeführt. Wenn alle Unit -Tests bestanden wurden, hat Docker ein Verteilungsbild erstellt. Wir haben jeden Abend einen moderierten CD -Ansatz für die Testumgebung verwendet, um die laufenden Funktionstests zu vermeiden. Ad -hoc -Bereitstellungen wurden nach Bedarf untergebracht. Sobald ein Build zum Testen bereitgestellt wurde, wurde unsere Funktionstestsuite (mit Selenium) automatisch ausgeführt.
Abbildung 4 - Kontinuierliche Integration und Bereitstellung (Prozessansicht) 
Hier finden Sie einen Überblick über die Schritte, die wir in unserem Ansatz befolgt haben:
A. Entwickler legt seine lokale Entwicklungsumgebung mithilfe von Docker -Dateien fest, um die Operations -Umgebung nachzuahmen und Feature -Zweige aus der GitHub Master -Zweigstelle (Schritt 0) zu erstellen.
B. Der Entwickler erstellt Unit -Tests (Schritt 1) und schreibt den entsprechenden Quellcode (Schritt 2), um eine Benutzergeschichte/eine Funktion/Funktion zu implementieren.
C. Um den Unit -Test und den Quellcode zusammenzuführen, gibt Entwickler eine Pull -Anfrage vor. Triggers Code -Überprüfung durch einen Peer -Entwickler; Prüfer genehmigt/ verweigert die Verschmelzung in die Integrationszweig; Schließlich löst der Entwickler die Beobachtungen der Codeüberprüfung. Sobald die Code -Überprüfung genehmigt wurde, wird der Feature -Zweig in den Integrationszweig (Schritt 4) zusammengefasst.
D. Tester erstellen automatisierte Funktionskripte (Schritt 3), die im Integrationszweig (Schritt 4) zusammengeführt werden.
e. In einem vorbestimmten Zeitplan erstellt Jenkins den Quellcode und alle Unit-Tests werden automatisch ausgeführt (Schritt 5).
F. Wenn die Unit -Tests fehlschlagen, wird eine Benachrichtigung über den Fehler gesendet und der Entwickler behebt ihn im Korrespondenz -Feature -Zweig (Schritt 15). Die Schritte 4 und 5 werden wiederholt, bis die Einheitstests bestehen.
G. Sobald die Unit -Tests bestanden haben, führt Jenkins Docker -Dateien aus, um die Docker -Bilder für die Benutzeroberfläche und das Backend zu erstellen (Schritt 6).
H. Docker drückt die Bilder in die Azure -Registrierung (Schritt 7) und setzt sie dann in die Testumgebung ein, in der die Funktionstests automatisch ausgeführt werden (Schritt 8).
ich. Wenn die Funktionstests fehlschlagen, wird eine Benachrichtigung gesendet (Schritt 14) und die Entwickler die Probleme beheben (Schritt 15). Die Schritte 4, 5, 6, 7 und 8 werden wiederholt, bis die Funktionstests bestehen.
J. Sobald die Funktionstests erfolgreich sind, wird eine Benachrichtigung über die erfolgreiche Testausführung gesendet (Schritt 9).
k. QA führt Ad-hoc/Manual-Tests durch. Wenn diese ausfallen, wird der Entwickler benachrichtigt, um das Problem zu beheben (Schritt 15). Die Schritte 4, 5, 6, 7, 8, 9 und 10 werden wiederholt, bis die Ad-hoc-Tests bestehen.
l. Sobald der Fehler behoben ist, wird der Integrationszweig im Master -Zweig (Schritt 11) mit dem Produktions -Tag zusammengeführt.
M. Schließlich wird das zum Testen erstellte Bild in der Produktionsumgebung bereitgestellt (Schritt 12).
Unser Quellcode ist strukturiert, um unsere verteilte Architektur und die Software zu befolgen, die zur Implementierung verwendet wird. Das Frontend ist im Winkelordner und im Backend im Dropwizard -Ordner gespeichert. Wir haben auch Ordner für automatisierte Funktionstests im Selen -Ordner.
Die Benutzeroberfläche wird mit AngularJs gebaut. Innerhalb des Angular -Ordners enthält der App -Ordner Unterordner für Bilder, Sprache, Kaskadierungsstylesheets, Skripte und Ansichten. Der Skriptsordner enthält Controller, Fabrik und Dienste. Der Ordner für Controller hostet wiederum die JavaScript -Dateien, während der Ordner Ansicht HTML -Dateien enthält. Unit -Tests werden im Testordner getrennt vom Code gehalten.
Das Frontend kommuniziert mit dem Backend mit erholsamen APIs. Der Frontend -Code, in dem sich die Dienste aufrufen, befindet sich im Diensteunterordner im Ordner Skripts.
Die Anwendungs -Backend implementiert die Geschäftslogik, kommuniziert mit externen Diensten, sendet Benachrichtigungen und interagiert mit der Datenbank. Das Backend wird mit DropWizard implementiert, das einen Java -Framework mit REST- und JUNIT -Unterstützung bietet. Geschäftslogik und Endpunkte befinden sich im Ressourcenordner, und die Implementierung von Diensten befindet sich im Serviceordner.
Die Anwendung implementiert auch externe API -Verpackungen (hier implementiert), um Daten aus externen Datenquellen abzurufen.
Unit -Tests befinden sich im Testordner.
Die Anwendung kommuniziert mit der relationalen Datenbank (MySQL) mitheiges Hibernate. Wir verwenden Standard -JAXB -Bean -Validierungen zur Datenvalidierung. Die Datenzugriffsobjekte und Modellobjekte befinden sich im DAO -Ordner.
A. Zugewiesen einen (1) Führer und gab dieser Person Autorität und Verantwortung und machte diese Person für die Qualität des eingereichten Prototyps verantwortlich
Während der RFI -Bewertung wählte CGI eine Produktmanagerin (PM) aus, die auf seiner technischen und Managementerfahrung basiert. CGI gab der PM endgültige Entscheidungsbehörde für die Gestaltung und Entwicklung des Prototyps.
B. Zusammengestellt ein multidisziplinäres und kollaboratives Team, das mindestens fünf (5) der Arbeitskategorien umfasst, wie in Anhang B: PQVP DS-Ad-Arbeitskategorie Beschreibungen identifiziert
Nach der Führung des Premierministers stellte CGI ein multidisziplinäres Team mit verschiedenen technischen und agilen Fähigkeiten zusammen.
Unser Team:
C. Verstanden, was Menschen brauchten, indem Menschen in den Prototypentwicklungs- und -entwurfsprozess einbezogen werden;
CGI folgte einem benutzerorientierten Ansatz für die Gestaltung und Entwicklung unseres Prototyps. Unser UX/UI -Designer hat Benutzer frühzeitig durch den Einsatz von Persona -Interviews und -Emträufen engagiert. Die Interviewergebnisse wurden schnell in Drahtflüsse verwandelt. Die Wireflows wurden basierend auf Benutzerumfragen sowie Usability -Tests mit unseren Benutzern verfeinert. Die Drahtflows boten eine schnelle und visuelle Möglichkeit, den Entwicklern den gewünschten Prototyp -Erscheinungsbild zu kommunizieren, damit die Entwicklung beginnt, sobald der PM die ersten Geschichten genehmigt wurde.
Wir haben Designtechniken und Tools angewendet, darunter Persona -Interviews, Drahtflow -Entwicklung, Usability -Test und Lean UX, um unsere Benutzeroberfläche zu entwickeln. Um eine reaktionsschnelle Browser-basierte Schnittstelle zu unterstützen, haben wir die Richtlinien von US Web Design (USWD) für moderne Webstandards und AngularJs genutzt. Durch die Anwendung dieser Standards sowie die Eingaben von Benutzern konnten wir einen Prototyp erstellen, der einfach und intuitiv zu navigieren und zu verwenden war. Wir haben auch die Einhaltung von ADA 508 und WCAG 2.0 getestet und automatisierte Tools verwendet, um die Unterstützung für adaptive Leser und andere Optionen für niedrige Sehvermögen zu testen.
D. Verwendete mindestens mindestens drei (3) „benutzerzentrierte Design“ -Techniken und/oder Tools;
Wir haben Personas -Interviews, Wireflows und Usability -Tests als Haupttools verwendet, um ein Design für unseren Prototyp zu entwickeln, der sich auf die Bedürfnisse und Wünsche unserer Benutzer konzentrierte.
e. Verwendet GitHub, um Code -Commits zu dokumentieren;
Commits können in GitHub angezeigt werden: https://github.com/cgi-zahid/cgi-poc
F. Verwendete Prahlerei, um die erholsame API zu dokumentieren, und stellte einen Link zur Prahler -API zur Verfügung.
Die gesamte Kommunikation mit der mittleren Stufe wurde mit REST -API durchgeführt. Die mittlere Stufe enthält die Rest -API mit JAX RX und ist in der Prahlerei dokumentiert.
G. Eingehalten mit Abschnitt 508 der Americans with Disabilities Act und WCAG 2.0;
Im Rahmen unserer Usability -Tests haben wir auf die Einhaltung von 508 und WCAG 2.0 getestet. Wir haben automatisierte Tests verwendet, um auf Lesbarkeit und Sehvermögen zu testen. Wir haben Fehler im Rahmen unseres Backlog -Prozesses angesprochen. Andere Testergebnisse wurden bewertet, um zu bestimmen, welche zum Rückstand und diejenigen, die nicht für unseren Prototyp gelten, hinzugefügt werden sollen.
Wir haben Actf Adesigner für unsere 508 -Tests verwendet.
H. Erstellt oder verwendet einen Designstil -Handbuch und/oder eine Musterbibliothek;
UX/UI erstellt einen Style -Handbuch mit den US -amerikanischen Webdesignstandards. Unser Farbschema wurde basierend auf den Farben des Bundesstaates Kalifornien ausgewählt und durch Benutzerfeedback genehmigt. Durch die Anwendung der US -amerikanischen Webdesign -Standards zusammen mit den Eingaben von Benutzern konnten wir einen Prototyp erstellen, der einfach und intuitiv zum Navigieren und Gebrauch war.
ich. Usability -Tests mit Menschen durchgeführt;
Im Rahmen unseres benutzerorientierten Ansatzes haben wir Usability -Tests in unseren Prozess aufgenommen. Usability -Tests wurden durch Benutzerumfragen auf unseren Wireframes sowie durch Feedback von Benutzern durchgeführt, die unseren Prototyp in unseren Sprints getestet haben. Das Feedback der Usability -Tests wurde von PM- und UX -Designer bewertet, um festzustellen, was in den Rückstand einbezogen werden soll. Basierend auf der PM -Richtung wurden neue Geschichten erstellt, priorisiert und in unserem Rückstand platziert.
J. Verwendete einen iterativen Ansatz, bei dem Feedback nachfolgende Arbeiten oder Versionen des Prototyps informiert;
Innerhalb jedes Sprint wurden Eingaben des Produktmanagers, Usability -Tester und Defekte, die während der Tests identifiziert wurden, als Teil unseres iterativen Ansatzes bewertet, priorisiert und in den Rückstand aufgenommen. Bei jeder Demo wurde der Prototyp immer mehr auf die Vision des PM sowie die Bedürfnisse unserer Benutzer ausgerichtet.
k. Erstellt einen Prototyp, der auf mehreren Geräten funktioniert, und präsentiert ein reaktionsschnelles Design.
Unser Code wurde mit mehreren Geräten getestet und funktioniert mit mehreren Webbrowsern. Darüber hinaus wurde unser Code mit Apple- und Android -Geräten getestet.
Wir haben auf:
l. Verwendete mindestens fünf (5) moderne und open-Source-Technologien, unabhängig von der architektonischen Schicht (Frontend, Backend usw.);
Wir haben die folgenden sechs (6) modernen und Open-Source-Technologien verwendet:
Eine Liste aller unserer Technologien wird zur Verfügung gestellt: Technologieliste. Die in der Tabelle grün hervorgehobenen Reihen sind die modernen und Open -Source -Technologien.
M. Bereitstellung des Prototyps für eine Infrastruktur als Service (IAAS) oder Plattform als Service (PAAS) und gab an, welchen Anbieter sie verwendeten.
Wir haben Azure als unseren IaaS -Anbieter verwendet.
N. Entwickelte automatisierte Unit -Tests für ihren Code;
Bevor Sie den Code in die Feature -Zweigentwickler überprüfen, führen Sie eine Pull -Anfrage durch, um eine Codeüberprüfung auszulösen. Sobald die Code -Überprüfung genehmigt wurde, wird der Code in den Integrationszweig zusammengefasst, der den kontinuierlichen Bereitstellungsprozess auslöst.
O. Einrichten oder verwendet ein kontinuierliches Integrationssystem, um das Ausführen von Tests zu automatisieren und ihren Code kontinuierlich für ihren IaaS- oder PaaS -Anbieter bereitzustellen;
Wir haben Jenkins für die kontinuierliche Integration verwendet. Es greift Code von GitHub und erstellt und führt Tests aus. Wenn der Code die Tests besteht, erstellt Docker ein Bild. Das Bild wird in der Systemtestumgebung bereitgestellt, in der ein End -to -End -Funktionstest mit Selen durchgeführt wird.
P. Setup oder gebrauchte Konfigurationsverwaltung;
Azure Container Registries wurden verwendet, um unsere Docker -Bilder zu speichern und zu verwalten, mit denen wir die Konfiguration verwalten können
Q. Einrichtung oder gebrauchte kontinuierliche Überwachung;
Azure und New Relic wurden verwendet, um die Gesundheit der Umwelt und die Anwendung kontinuierlich zu überwachen
R. Bereitete ihre Software in einem Open-Source-Container wie Docker ein (dh eine Virtualisierung auf Betriebssystemebene);
Wir haben unsere Software mit Docker bereitgestellt
S. Bereitete ausreichende Dokumentation zur Installation und Ausführung ihres Prototyps auf einer anderen Maschine vor;
Im Folgenden finden Sie einen Link zu unseren Installationsanweisungen.
Anweisungen
T. Prototypen und zugrunde liegende Plattformen, die zum Erstellen und Ausführen des Prototyps verwendet werden, sind offen lizenziert und kostenlos.
Wir haben offen lizenzierte und kostenlose Plattformen verwendet
Liste der Tools
Unser Prozess für die Gestaltung und Entwicklung unseres Prototyps folgte und erfüllte viele der im US Digital Services Playbook beschriebenen Standards. Wir haben ein detailliertes Dokument zu GitHub bereitgestellt, das mit unseren Beweisen verbunden ist, sowie unsere Antwort auf jeden Artikel.
Unsere US Digital Service Playbook -Antworten
