CGI POC
1.0.0
Github: https://github.com/cgi-zahid/cgi-poc
Application: [https://mycalert.com]
Obtenir l'administrateur et les échantillons d'identification de l'utilisateur final
L'approche de CGI à la pool de fournisseurs pré-qualifiée pour les services numériques - développement agile (PQVP DS-AD) Effort utilisé des techniques de conception centrées sur l'utilisateur, un flux de travail de développement basé sur Sprint et des technologies modernes et open-source pour concevoir et créer MyCalerts, notre mise en œuvre du ProTotype de travail B. et suivre leurs notifications passées. Les utilisateurs peuvent recevoir des notifications via un service de messages court (SMS) et un e-mail en fonction de l'emplacement de la rue et des coordonnées fournies dans leur profil utilisateur. MyCalerts permet aux utilisateurs administratifs autorisés de suivre et de visualiser les événements et d'envoyer des notifications d'événements d'urgence ad hoc et de non-urgence.
Nous avons commencé par un examen du projet de RFI. CGI a établi notre équipe et a commencé Sprint 0 Planning. Nous avons déterminé l'architecture technique et les environnements que nous utiliserions. Nous avons déployé nos outils de développeur standard et nos ressources de collaboration Agile, pour créer une application «Hello World» (une page de connexion simple) pour tester notre framework technique de pile et d'intégration continue / déploiement continu (CI / CD).
À la réception de la RFI finale, notre chef de produit (PM) a dirigé une session d'analyse de prototypes. L'équipe s'est réunie et a tenu une session de planification et de dimensionnement pour évaluer la complexité, l'intérêt de l'équipe et les risques de chaque prototype. Avec un grand enthousiasme, notre équipe a sélectionné le prototype de travail B.
Sur la base des premiers interviews utilisateur, le PM a sélectionné les trois ensembles de données jugés les plus pertinents pour les utilisateurs de l'AC. Il a choisi de sonder pour les notifications d'urgence automatisées suivantes: Incendies (service de limites de feu actifs de l'USGS Geomac - toutes les 15 minutes), les inondations (jauge de rivière - service de courant et de prévision de la NOAA - toutes les 6 heures) et des intempéries (service de risques météorologiques de la NOAA - toutes les 15 minutes).
Au coup d'envoi, notre PM a fourni sa vision du prototype et une feuille de route de haut niveau pour l'achèvement des travaux. L'équipe a établi des rôles et des responsabilités ainsi qu'un accord d'équipe collaboratif. Nous avons solidifié et établi nos relations de travail d'équipe. En utilisant la feuille de route et les exigences du prototype, l'équipe a développé une première série d'utilisateurs. Notre PM a priorisé ces histoires avec UX / UI et des histoires de configuration technique d'infrastructure pour établir notre arriéré de produit.
Notre concepteur UX / UI a facilité une approche de conception axée sur les utilisateurs - en engageant les utilisateurs tôt grâce à l'utilisation d'entretiens et de sondages Persona. Nous avons exploité AngularJS avec les normes et les composants ensemble du guide de style Web-Design (USWDS) pour implémenter une application Web accessible moderne. Nous avons également testé la conformité ADA 508 et WCAG 2.0. Nous avons exploité les utilisateurs de divers âges, rôles, expériences et antécédents. Au cours de Sprint 1, nous avons interviewé les utilisateurs et nos résultats ont été rapidement transformés en fil de fil tirant parti d'une conception réactive pour accueillir les plates-formes de bureau et mobiles. Ces wireflows ont été affinés en continu en fonction de l'entrée utilisateur. Nos wileflows ont fourni un visuel pour communiquer l'apparence du prototype aux développeurs. Au-delà de la conception initiale, les utilisateurs ont été engagés grâce à des tests d'utilisation et leur entrée a été évaluée et prioritaire grâce à des histoires d'amélioration qui ont ensuite été ajoutées dans l'arriéré du produit pour l'inclusion dans les sprints ultérieurs.
Nous avons suivi un processus agile (figure 1) des cycles de sprint hebdomadaires, chaque cycle commençant mercredi et se terminant le mardi suivant.
Figure 1 - Notre processus agile 
Chaque semaine, les rituels de sprint comprenaient: Stand-up - du lundi au vendredi à 8h45 - 9h00 facilité par l'entraîneur agile. Les membres de l'équipe de développement ont déclaré que les travaux ont été terminés depuis la dernière session; Travail planifié avant la prochaine session et tous les bloqueurs. Les bloqueurs identifiés ont été effacés par l'entraîneur agile et le responsable de la livraison. Le stand-up a fourni un excellent forum pour la coordination à travers l'équipe.
Toiletage du carnet de commandes - Lundi, notre PM a examiné et redirisé les articles du carnet de commandes. L'Agile Coach and Delivery Manager a soutenu l'examen et les histoires d'utilisateurs confirmées étaient d'accord avec la «définition de Ready» de l'équipe.
Revue de Sprint - mardi matin, l'équipe a présenté des histoires d'utilisateurs terminés dans le Sprint au PM pour examen et approbation. Les utilisateurs approuvés sont alignés sur la «définition de Done» de l'équipe.
Sprint Retrospective - Mardi matin, l'équipe a réfléchi à la façon dont leurs outils, processus et pairs se sont déroulés sur le sprint récemment achevé. Chaque membre de l'équipe a été invité à identifier un trait d'amélioration qu'il voulait voir l'équipe commencer à faire; Celui qu'ils voulaient que l'équipe cesse de faire et celle qu'ils voulaient que l'équipe continue. Facilitées par l'entraîneur agile, les traits de départ / arrêt / continues identifiés ont été consolidés et les prochaines étapes définies par l'équipe.
Sprint Planning - mardi après-midi, une séance d'une heure pour le PM et l'équipe a discuté de manière interactive et convenu de la charge utile du prochain sprint. Le dimensionnement des articles dans le sprint a été coordonné par l'entraîneur agile et le responsable de la livraison. Planitpoker.com a été utilisé pour l'estimation de l'histoire.
Voir notre album photo d'équipe pour des exemples visuels de l'équipe et notre processus agile en action.
À chaque itération, le prototype est devenu de plus en plus aligné sur la vision du PM, ainsi que sur les besoins de nos utilisateurs. Notre feuille de route de haut niveau comprenait plusieurs utilisateurs qui n'étaient finalement pas inclus dans le prototype de travail. Ceux-ci comprenaient des recherches de Spike pour une application client native iOS et une fonctionnalité de notification push native. Bien que les deux n'étaient pas dans le produit minimum viable (MVP) affiché, ils sont inclus dans l'arriéré du produit, les artefacts d'architecture et le code source GitHub.
Tout au long du processus, l'équipe a pu coordonner le travail et suivre les progrès en utilisant notre carte Scrum. Nous avons utilisé Jira pour suivre les utilisateurs sur une carte électronique (ainsi que des bogues), et avons maintenu une planche physique dans la salle d'équipe. Nous avons utilisé Confluence pour le partage de documents et Hipchat comme outil de collaboration d'équipe. Les métriques ont été suivies afin que l'équipe ait compris comment elle allait et des zones potentielles d'amélioration des processus à chaque sprint. Les mesures ont montré à l'équipe leur vitesse de développement, son arriéré technique et quel pourcentage de points d'histoire a été réellement mis en œuvre avec chaque sprint.
Pour chaque décision technologique, nous avons envisagé des options ouvertes, ce qui se traduit par une pile qui est principalement open source. Notre objectif technologique était une application Web moderne basée sur un navigateur, mais nous avons également étudié la possibilité d'une application mobile native sur iOS.
Figure 2 - Notre pile technologique 
Du point de vue DevOps:
Nous avons testé et déployé le prototype sur l'infrastructure Azure de Microsoft en tant que solution de service (IAAS). Nous avons utilisé la solution de surveillance d'Azure pour une surveillance continue des infrastructures, y compris le réseautage et une nouvelle relique pour la surveillance des performances continue des applications. Nous avons utilisé les données clés des indicateurs de performance (KPI) pour affiner notre solution et notre application d'infrastructure.
Notre solution a utilisé GitHub pour documenter le code et les tests unitaires dans notre référentiel GitHub public. Notre structure GitHub a des branches maître et d'intégration ainsi que des branches de fonctionnalités. Le développement d'histoires individuelles a été réalisé dans une branche de fonctionnalités dans un environnement local. Avant de vérifier le code, les développeurs ont émis une demande de traction pour déclencher une révision du code. Une fois l'examen du code approuvé, le code a été fusionné dans la branche d'intégration, déclenchant le processus d'intégration continue.
La figure 3 affiche la vue des outils et la migration de code de haut niveau du développement à la production à l'aide de notre processus CI / CD.
Figure 3 - Intégration continue et déploiement (outils) 
Jenkins a récupéré le code de GitHub, construit l'application et exécuté des tests unitaires. Si tous les tests unitaires passaient, Docker a créé une image de distribution. Nous avons utilisé une approche CD modérée de l'environnement de test tous les soirs pour éviter d'interférer avec les tests fonctionnels en cours. Les déploiements ad hoc ont été adaptés au besoin. Une fois qu'une version a été déployée pour tester, notre suite de tests fonctionnels (à l'aide du sélénium) s'est déroulée automatiquement.
Figure 4 - Intégration continue et déploiement (vue du processus) 
Voici un aperçu des étapes que nous avons suivies dans notre approche:
un. Le développeur définit leur environnement de développement local à l'aide de fichiers Docker pour imiter l'environnement d'opérations et crée des branches de fonctionnalités à partir de la branche maître GitHub (étape 0).
né Le développeur crée des tests unitaires (étape 1) et écrit le code source approprié (étape 2) pour implémenter un user story / une fonctionnalité.
c. Pour fusionner le test unitaire et le code source, le développeur soumet une demande de traction; déclenche l'examen du code par un développeur par les pairs; L'examinateur approuve / nie la fusion dans la branche d'intégration; Enfin, le développeur résout les observations de la revue du code. Une fois l'examen du code approuvé, la branche des fonctionnalités est fusionnée dans la branche d'intégration (étape 4).
d. Les testeurs créent des scripts fonctionnels automatisés (étape 3), qui sont fusionnés dans la branche d'intégration (étape 4).
e. Sur un calendrier prédéterminé, Jenkins compile le code source et tous les tests unitaires sont exécutés automatiquement (étape 5).
f. Si les tests unitaires échouent, une notification est envoyée concernant la défaillance et le développeur le corrige dans la branche de fonctionnalité correspondante (étape 15). Les étapes 4 et 5 sont répétées jusqu'à ce que les tests unitaires passent.
g. Une fois que l'unité teste, Jenkins exécute des fichiers Docker pour construire les images Docker pour l'interface utilisateur et le backend (étape 6).
h. Docker pousse les images vers le registre Azure (étape 7), puis les déploie dans l'environnement de test où les tests fonctionnels sont exécutés automatiquement (étape 8).
je. Si les tests fonctionnels échouent, une notification est envoyée (étape 14) et les développeurs résolvent les problèmes (étape 15). Les étapes 4, 5, 6, 7 et 8 sont répétées jusqu'à ce que les tests fonctionnels passent.
J Une fois que les tests fonctionnels ont réussi, une notification est envoyée concernant l'exécution du test réussi (étape 9).
k. QA effectue des tests ad hoc / manuels. Si ceux-ci échouent, le développeur est informé de résoudre le problème (étape 15). Les étapes 4, 5, 6, 7, 8, 9 et 10 sont répétées jusqu'à ce que les tests ad hoc passent.
l. Une fois l'erreur fixe, la branche d'intégration est fusionnée avec la balise de production dans la branche maître (étape 11).
m. Enfin, l'image créée pour les tests est déployée dans l'environnement de production (étape 12).
Notre code source est structuré pour suivre notre architecture distribuée et le logiciel utilisé pour l'implémenter. Le frontend est stocké dans le dossier angulaire et le backend dans le dossier Dropwizard. Nous avons également des dossiers pour les tests fonctionnels automatisés dans le dossier de sélénium.
L'interface utilisateur est construite à l'aide d'AngularJS. Dans le dossier angulaire, le dossier de l'application comprend des sous-dossiers pour les images, la langue, les feuilles de styles en cascade, les scripts et les vues. Le dossier Scripts contient des contrôleurs, des usines et des services. Le dossier Controllers héberge à son tour les fichiers JavaScript, tandis que le dossier Affichage contient des fichiers HTML. Les tests unitaires sont conservés séparément du code dans le dossier de test.
Le frontend communique avec le backend à l'aide d'API RESTful. Le code Frontend invoquant les services réside dans le sous-dossier Services dans le dossier Scripts.
Le backend d'application implémente la logique métier, communique avec les services externes, envoie des notifications et interagit avec la base de données. Le backend est implémenté à l'aide de Dropwizard, qui fournit un framework Java avec le support REST et JUnit. La logique commerciale et les points de terminaison sont dans le dossier des ressources et la mise en œuvre des services est dans le dossier de service.
L'application implémente également les emballages API externes (implémentés ici) pour récupérer des données à partir de sources de données externes.
Les tests unitaires résident dans le dossier de test.
L'application communique avec la base de données relationnelle (MySQL) en utilisant Hibernate. Nous utilisons des validations standard de bean JAXB pour la validation des données. Les objets d'accès aux données et les objets modèles sont situés dans le dossier DAO.
un. A attribué un (1) leader et a donné à cette personne l'autorité et la responsabilité et a tenu cette personne responsable de la qualité du prototype soumis
Au cours de l'évaluation RFI, CGI a sélectionné un chef de produit (PM) en fonction de son expérience technique et de gestion. CGI a donné au PM la décision finale de la prise de décision sur la conception et le développement du prototype.
né Assemblé une équipe multidisciplinaire et collaborative qui comprend, au minimum, cinq (5) des catégories de main-d'œuvre identifiées dans l'attachement B: PQVP DS-AD Catégorie de travail descriptions
Sous la direction du PM, CGI a réuni une équipe multidisciplinaire avec diverses capacités techniques et agiles.
Notre équipe:
c. Compris ce dont les gens avaient besoin, en incluant des personnes dans le processus de développement et de conception du prototype;
CGI a suivi une approche centrée sur l'utilisateur de la conception et du développement de notre prototype. Notre concepteur UX / UI a engagé les utilisateurs tôt grâce à l'utilisation d'interviews et de relevés Persona. Les résultats de l'entretien ont été rapidement transformés en fil de fil. Les wireflows ont été raffinés en fonction des enquêtes utilisateur ainsi que des tests d'utilisation avec nos utilisateurs. Les wireflows ont fourni un moyen visuel rapide et visuel de communiquer aux développeurs l'apparence et la sensation du prototype souhaité afin que le développement puisse commencer une fois que le PM a approuvé les histoires initiales.
Nous avons appliqué des techniques de conception et des outils, notamment des entretiens Persona, du développement de fil de fil, des tests d'utilisation et des UX Lean pour développer notre interface utilisateur. Pour prendre en charge une interface basée sur un navigateur réactif, nous avons exploité les lignes directrices de la conception Web américaine (USWD) pour les normes Web modernes et AngularJS. L'application de ces normes, ainsi que les entrées des utilisateurs, nous ont permis de créer un prototype simple et intuitif à naviguer et à utiliser. Nous avons également testé la conformité ADA 508 et WCAG 2.0, en utilisant des outils automatisés pour tester la prise en charge des lecteurs adaptatifs et d'autres options de basse vision.
d. Utilisé au moins un minimum de trois (3) techniques et / ou outils de conception centrée sur l'utilisateur;
Nous avons utilisé des interviews, des filmes de fil et des tests d'utilisation comme principaux outils pour développer une conception pour notre prototype qui s'est concentré sur les besoins et les désirs de nos utilisateurs.
e. GHUBUB utilisé pour documenter les commits de code;
Les engins peuvent être consultés dans GitHub: https://github.com/cgi-zahid/cgi-poc
f. Utilisé Swagger pour documenter l'API RESTful et a fourni un lien vers l'API Swagger;
Toute communication avec le niveau intermédiaire a été effectuée à l'aide de l'API REST. Le niveau intermédiaire expose l'API REST à l'aide de JAX RX et est documenté en fanfaronnade.
g. Respecté l'article 508 de la loi sur les Americans with Disabilities et WCAG 2.0;
Dans le cadre de nos tests d'utilisation, nous avons testé pour 508 et la conformité WCAG 2.0. Nous avons utilisé des tests automatisés pour tester la lisibilité et la faible vision. Nous avons abordé les erreurs dans le cadre de notre processus de backlog. D'autres résultats de test ont été évalués pour déterminer lequel ajouter à l'arriéré et ceux qui ne s'appliquaient pas à notre prototype.
Nous avons utilisé ACTF ADESIGNER pour nos tests 508.
h. Créé ou utilisé un guide de style design et / ou une bibliothèque de motifs;
UX / UI a créé un guide de style utilisant les normes de conception Web américaines. Notre jeu de couleurs a été sélectionné en fonction de l'état de couleurs de Californie et approuvé par les commentaires des utilisateurs. L'application des normes de conception Web américaines ainsi que les entrées des utilisateurs nous ont permis de créer un prototype qui était simple et intuitif à naviguer et à utiliser.
je. Effectué des tests d'utilisation avec des personnes;
Dans le cadre de notre approche centrée sur l'utilisateur, nous avons incorporé des tests d'utilisation dans notre processus. Les tests d'utilisation ont été effectués par le biais d'enquêtes utilisateur sur nos wireframes ainsi que des commentaires des utilisateurs qui ont testé notre prototype à travers nos sprints. Les commentaires des tests d'utilisabilité ont été évalués par PM et UX Designer pour déterminer ce qu'il faut inclure dans l'arriéré. Sur la base de PM Direction, de nouvelles histoires ont été créées, prioritaires et placées dans notre arriéré.
J Utilisé une approche itérative, où la rétroaction a informé les travaux ou versions ultérieurs du prototype;
Dans chaque sprint, les entrées reçues du chef de produit, les testeurs d'utilisabilité et les défauts identifiés lors des tests ont été évalués, prioritaires et incorporés dans l'arriéré dans le cadre de notre approche itérative. Avec chaque démo, le prototype est devenu de plus en plus aligné sur la vision du PM ainsi que sur les besoins de nos utilisateurs.
k. Créé un prototype qui fonctionne sur plusieurs appareils et présente une conception réactive;
Notre code a été testé à l'aide de plusieurs appareils et fonctionne avec plusieurs navigateurs Web. De plus, notre code a été testé à l'aide d'appareils Apple et Android.
Nous avons testé sur:
l. Utilisé au moins cinq (5) technologies modernes et open source, quelle que soit la couche architecturale (frontend, backend, etc.);
Nous avons utilisé les six (6) technologies modernes et open source:
Une liste de toutes nos technologies est fournie: Liste de technologie. Les lignes mises en évidence en vert sur la feuille de calcul sont les technologies modernes et open source.
m. Déployé le prototype sur une infrastructure en tant que fournisseur de service (IAAS) ou de plate-forme en tant que service (PAAS), et a indiqué quel fournisseur ils ont utilisé;
Nous avons utilisé Azure comme fournisseur IaaS.
n. A développé des tests unitaires automatisés pour leur code;
Avant de vérifier le code dans les développeurs de branche de fonctionnalités, effectuez une demande de traction pour déclencher une revue de code. Une fois l'examen du code approuvé, le code est fusionné dans la branche d'intégration qui déclenche le processus de déploiement continu.
o Configurer ou utiliser un système d'intégration continue pour automatiser l'exécution des tests et déployé en continu leur code à leur fournisseur IaaS ou PaaS;
Nous avons utilisé des jenkins pour une intégration continue. Il saisit le code de GitHub et compile et exécute des tests. Si le code passe les tests, Docker crée une image. L'image est déployée dans l'environnement de test système où un test fonctionnel de bout en bout est effectué à l'aide de sélénium.
p. Configuration ou gestion de la configuration utilisée;
Les registres des conteneurs Azure ont été utilisés pour stocker et gérer nos images Docker nous permettant de gérer la configuration
q. Configuration ou surveillance continue utilisée;
Azure et New Relic ont été utilisées pour surveiller en continu la santé de l'environnement et l'application
r. Déployé leur logiciel dans un conteneur open source, comme Docker (c'est-à-dire, utilisé la virtualisation au niveau du système opérationnel);
Nous avons déployé notre logiciel à l'aide de Docker
s. Fourni une documentation suffisante pour installer et exécuter leur prototype sur une autre machine;
Vous trouverez ci-dessous un lien vers nos instructions d'installation.
Instructions
t. Les prototypes et les plates-formes sous-jacentes utilisées pour créer et exécuter le prototype sont ouvertement sous licence et gratuitement.
Nous avons utilisé des plateformes ouvertement sous licence et gratuites
Liste des outils
Notre processus de conception et de développement de notre prototype a suivi et respecté de nombreuses normes décrites dans le livre de jeu des services numériques américains. Nous avons fourni un document détaillé sur GitHub qui relie nos preuves, ainsi que notre réponse à chaque élément.
Nos réponses au livre de jeu de services numériques américains
