CGI POC
1.0.0
Github: https://github.com/cgi-zahid/cgi-poc
Aplicación: [https://mycalerts.com]
Obtener la credencial de usuario final de administración y muestra
El enfoque de CGI para el grupo de proveedores precalificados para servicios digitales: desarrollo ágil (PQVP DS-AD) empleó técnicas de diseño centradas en el usuario, un flujo de trabajo de desarrollo basado en Sprint y tecnologías modernas y de código abierto para diseñar y construir micalertas, nuestra implementación de prototipo de trabajo B. MyCalerts de California permite a los residentes de California establecer y administrar los usuarios de los usuarios, suscribir a los mycalerts de graves/alertas/inundaciones de mycalerts. y rastrear sus notificaciones pasadas. Los usuarios pueden recibir notificaciones a través del servicio de mensajes cortos (SMS) y el correo electrónico según la información de ubicación de la calle y de contacto proporcionada en su perfil de usuario. MyCalerts permite a los usuarios administrativos autorizados rastrear y visualizar eventos y enviar notificaciones de eventos de emergencia y no emergencia ad hoc.
Comenzamos con una revisión del borrador de RFI. CGI estableció nuestro equipo y comenzó a sprint 0 de planificación. Determinamos la arquitectura técnica y los entornos que usaríamos. Implementamos nuestras herramientas de desarrollador estándar y recursos de colaboración ágiles, para crear una aplicación "Hello World" (una página de inicio de sesión simple) para probar nuestra pila técnica e integración continua/marco de implementación continua (CI/CD).
Al recibir el RFI final, nuestro Gerente de Producto (PM) dirigió una sesión de análisis de prototipo. El equipo se reunió y realizó una sesión de planificación y tamaño para evaluar la complejidad, el interés del equipo y los riesgos de cada prototipo. Con gran entusiasmo, nuestro equipo seleccionó el prototipo de trabajo B.
Según las entrevistas iniciales del usuario, el PM seleccionó los tres conjuntos de datos considerados más relevantes para los usuarios de CA. Elegió sondear para las siguientes notificaciones de emergencia automatizadas: incendios forestales (servicio de límites de incendio activos de USGS Geomac - cada 15 minutos), inundaciones (calibre fluvial - actual y servicio de pronóstico de NOAA - cada 6 horas) y clima severo (servicio de riesgos climáticos de NOAA - cada 15 minutos).
En el inicio, nuestro primer ministro proporcionó su visión para el prototipo y una hoja de ruta de alto nivel para completar el trabajo. El equipo estableció roles y responsabilidades, así como un acuerdo de equipo de colaboración. Solidificamos y establecimos las relaciones laborales de nuestro equipo. Utilizando la hoja de ruta y los requisitos de prototipo, el equipo desarrolló una serie inicial de historias de usuarios. Nuestro PM priorizó estas historias junto con UX/UI y historias de configuración de infraestructura técnica para establecer nuestra acumulación de productos.
Nuestro diseñador de UX/UI facilitó un enfoque de diseño centrado en el usuario - impulsado por el usuario al involucrar a los usuarios temprano mediante el uso de entrevistas y encuestas de personalidades. Aprovechamos AngularJS junto con los estándares y componentes establecidos desde la guía de estilo del diseño web de los EE. UU. (USWDS) para implementar una aplicación web accesible moderna. También probamos el cumplimiento de ADA 508 y WCAG 2.0. Aprovechamos a los usuarios de varias edades, roles, experiencias y antecedentes. Durante Sprint 1 entrevistamos a los usuarios y nuestros resultados se convirtieron rápidamente en flujos de alambre que aprovechan un diseño receptivo que acomoda plataformas de escritorio y móviles. Estos flujos de alambre se refinaron continuamente en función de la entrada del usuario. Nuestros flujos de alambre proporcionaron un visual para comunicar el aspecto del prototipo a los desarrolladores. Más allá del diseño inicial, los usuarios se involucraron a través de pruebas de usabilidad y su aporte se evaluó y priorizó a través de historias de mejora que luego se agregaron en la acumulación de productos para su inclusión en sprints posteriores.
Seguimos un proceso ágil (Figura 1) de ciclos de sprint semanales, con cada ciclo comenzando el miércoles y terminando el martes siguiente.
Figura 1 - Nuestro proceso ágil 
Cada semana, los rituales de sprint incluyeron: stand-up-de lunes a viernes a las 8:45-9:00 AM facilitados por el Agile Coach. Los miembros del equipo de desarrollo reportaron trabajo completado desde la última sesión; trabajo planificado antes de la próxima sesión y cualquier bloqueador. Los bloqueadores identificados fueron autorizados por el Agile Coach y el Gerente de Entrega. Stand-up proporcionó un gran foro para la coordinación en todo el equipo.
Backlog Grooming - Lunes, nuestro PM revisó y priorizó los artículos de cartera de pedidos. El Agile Coach y el gerente de entrega apoyaron la revisión y confirmó las historias de los usuarios acordadas con la "Definición de Ready" del equipo.
Sprint Review - Martes por la mañana, el equipo presentó historias de usuarios completadas en el sprint al primer ministro para su revisión y aprobación. Historias de usuarios aprobadas alineadas con la "definición de hecho" del equipo.
Sprint Retrospective: el martes por la mañana, el equipo reflexionó sobre cómo sus herramientas, procesos y compañeros se desempeñaron en el sprint recientemente completado. Se le pidió a cada miembro del equipo que identificara un rasgo de mejora que querían ver al equipo comenzar a hacer; Uno que querían que el equipo dejara de hacer y que quería que el equipo continuara. Facilitado por el entrenador ágil, los rasgos de inicio/detener/continuar identificados fueron consolidados y los siguientes pasos definidos por el equipo.
Planificación de sprint: el martes por la tarde, una sesión de una hora para el primer ministro y el equipo discutieron y acordaron interactivamente la carga útil del próximo sprint. El dimensionamiento de los artículos en el sprint fue coordinado por el Agile Coach y el gerente de entrega. Planitpoker.com se utilizó para la estimación de la historia.
Vea nuestro álbum de fotos del equipo para ver ejemplos visuales del equipo y nuestro proceso ágil en acción.
Con cada iteración, el prototipo se alineó cada vez más con la visión del PM, así como con las necesidades de nuestros usuarios. Nuestra hoja de ruta de alto nivel incluía varias historias de usuarios que finalmente no se incluyeron en el prototipo de trabajo. Estos incluyeron la investigación de picos para una aplicación de cliente nativo de iOS y la funcionalidad de notificación push nativa. Si bien ambos no estaban en el producto mínimo viable (MVP) publicado, se incluyen en la cartera de productos, los artefactos de arquitectura y el código fuente de GitHub.
A lo largo del proceso, el equipo pudo coordinar el trabajo y monitorear el progreso mediante el uso de nuestra placa Scrum. Utilizamos JIRA para rastrear historias de usuarios en una tabla electrónica (así como errores), y mantuvimos una placa física en la sala de equipo. Utilizamos Confluence para compartir documentos y Hipchat como herramienta de colaboración de nuestro equipo. Se rastrearon las métricas para que el equipo entendiera cómo les iba y las áreas potenciales para la mejora del proceso con cada sprint. Las métricas mostraron al equipo su velocidad de desarrollo, cartera técnica y qué porcentaje de puntos de historia realmente se implementó con cada sprint.
Para cada decisión tecnológica, consideramos opciones abiertas, lo que resulta en una pila que es predominantemente de código abierto. Nuestro objetivo tecnológico era una aplicación web moderna basada en el navegador, pero también investigamos la posibilidad de una aplicación móvil nativa en iOS.
Figura 2 - Nuestra pila de tecnología 
Desde el punto de vista de DevOps:
Probamos e implementamos el prototipo en la solución de Infraestructura Azure de Microsoft como Servicio (IaaS). Utilizamos la solución de monitoreo de Azure para el monitoreo continuo de infraestructura, incluida la red y la nueva reliquia para el monitoreo continuo del rendimiento de la aplicación. Utilizamos los datos de indicadores de rendimiento clave (KPI) para ajustar nuestra solución y aplicación de infraestructura.
Nuestra solución utilizó GitHub para documentar el código y la prueba unitaria en nuestro repositorio público de GitHub. Nuestra estructura de Github tiene ramas de maestría e integración, así como ramas de características. El desarrollo de historias individuales se realizó en una rama de características en un entorno local. Antes de registrar el código, los desarrolladores emitieron una solicitud de extracción para activar una revisión de código. Una vez que se aprobó la revisión del código, el código se fusionó en la rama de integración, desencadenando el proceso de integración continua.
La Figura 3 muestra la vista Herramientas y la migración de código de alto nivel desde el desarrollo hasta la producción utilizando nuestro proceso CI/CD.
Figura 3 - Integración e implementación continua (herramientas) 
Jenkins recuperó el código de GitHub, construyó la aplicación y ejecutó pruebas unitarias. Si se aprobaron todas las pruebas unitarias, Docker creó una imagen de distribución. Empleamos un enfoque de CD moderado para el entorno de prueba todas las noches para evitar interferir con las pruebas funcionales continuas. Las implementaciones ad hoc se acomodaron según sea necesario. Una vez que se implementó una compilación para probar, nuestro conjunto de pruebas funcionales (usando selenio) se ejecutó automáticamente.
Figura 4 - Integración e implementación continua (vista de proceso) 
Aquí hay una descripción general de los pasos que seguimos en nuestro enfoque:
a. El desarrollador establece su entorno de desarrollo local utilizando archivos Docker para imitar el entorno de operaciones y crea ramas de características de la rama maestra de GitHub (paso 0).
b. El desarrollador crea pruebas unitarias (Paso 1) y escribe el código fuente apropiado (Paso 2) para implementar una historia/función del usuario.
do. Para fusionar la prueba unitaria y el código fuente, el desarrollador envía una solicitud de extracción; Revisión del código de desencadenación por un desarrollador de pares; El revisor aprueba/ niega la fusión en la rama de integración; Finalmente, el desarrollador resuelve las observaciones de revisión del código. Una vez que se aprueba la revisión del código, la rama de características se fusiona en la rama de integración (paso 4).
d. Los probadores crean scripts funcionales automatizados (paso 3), que se fusionan en la rama de integración (paso 4).
mi. En un horario predeterminado, Jenkins compila el código fuente y todas las pruebas unitarias se ejecutan automáticamente (Paso 5).
F. Si las pruebas de la unidad fallan, se envía una notificación con respecto a la falla y el desarrollador la fija en la rama de características corresponsales (paso 15). Los pasos 4 y 5 se repiten hasta que pasan las pruebas de la unidad.
gramo. Una vez que pasan las pruebas de la unidad, Jenkins ejecuta archivos Docker para construir las imágenes de Docker para la interfaz de usuario y el backend (paso 6).
h. Docker empuja las imágenes al Registro de Azure (paso 7), y luego las implementa en el entorno de prueba donde las pruebas funcionales se ejecutan automáticamente (Paso 8).
i. Si las pruebas funcionales fallan, se envía una notificación (Paso 14) y los desarrolladores solucionan los problemas (Paso 15). Los pasos 4, 5, 6, 7 y 8 se repiten hasta que pasan las pruebas funcionales.
j. Una vez que las pruebas funcionales tienen éxito, se envía una notificación con respecto a la ejecución exitosa de la prueba (paso 9).
k. QA realiza pruebas ad-hoc/manuales. Si estos fallan, se notifica al desarrollador para solucionar el problema (paso 15). Los pasos 4, 5, 6, 7, 8, 9 y 10 se repiten hasta que pasan las pruebas ad-hoc.
l. Una vez que se corrige el error, la rama de integración se fusiona con la etiqueta de producción en la rama maestra (paso 11).
metro. Finalmente, la imagen creada para la prueba se implementa en el entorno de producción (paso 12).
Nuestro código fuente está estructurado para seguir nuestra arquitectura distribuida y el software utilizado para implementarla. El frontend se almacena en la carpeta Angular y el backend en la carpeta Dropwizard. También tenemos carpetas para pruebas funcionales automatizadas en la carpeta Selenium.
La interfaz de usuario está construida con angularjs. Dentro de la carpeta Angular, la carpeta de aplicaciones incluye subcarpetas para imágenes, lenguaje, hojas de estilo en cascada, scripts y vistas. La carpeta Scripts contiene controladores, fábrica y servicios. La carpeta de controladores a su vez aloja los archivos JavaScript, mientras que la carpeta View contiene archivos HTML. Las pruebas unitarias se mantienen por separado del código en la carpeta de prueba.
El frontend se comunica con el backend usando API RESTful. El código frontend que invoca los servicios reside en la subcarpeta de servicios en la carpeta Scripts.
El backend de la aplicación implementa la lógica comercial, se comunica con servicios externos, envía notificaciones e interactúa con la base de datos. El backend se implementa utilizando Dropwizard, que proporciona un marco Java con soporte REST y JUnit. La lógica de negocios y los puntos finales están en la carpeta de recursos, y la implementación de los servicios se encuentra en la carpeta de servicios.
La aplicación también implementa envoltorios API externos (implementados aquí) para recuperar datos de fuentes de datos externas.
Las pruebas unitarias residen en la carpeta de prueba.
La aplicación se comunica con la base de datos relacional (MySQL) utilizando Hibernate. Utilizamos validaciones estándar de Bean Jaxb para la validación de datos. Los objetos de acceso a datos y los objetos modelo se encuentran en la carpeta DAO.
a. Asignado un (1) líder y le dio a esa persona autoridad y responsabilidad y responsabilizó a esa persona por la calidad del prototipo presentado
Durante la evaluación de RFI, CGI seleccionó a un gerente de producto (PM) basado en su experiencia técnica y de gestión. CGI otorgó al PM Autoridad de toma de decisiones finales sobre el diseño y el desarrollo del prototipo.
b. Reunió un equipo multidisciplinario y de colaboración que incluye, como mínimo, cinco (5) de las categorías de trabajo identificadas en el Anexo B: Descripciones de categorías laborales PQVP DS-AD
Bajo el liderazgo del primer ministro, CGI reunió un equipo multidisciplinario con diversas capacidades técnicas y ágiles.
Nuestro equipo:
do. Entendió lo que la gente necesitaba, al incluir a las personas en el proceso de desarrollo y diseño de prototipos;
CGI siguió un enfoque centrado en el usuario para el diseño y el desarrollo de nuestro prototipo. Nuestro diseñador de UX/UI contrató a los usuarios temprano a través del uso de entrevistas y encuestas de personalidad. Los resultados de la entrevista se convirtieron rápidamente en flujos de alambre. Los flujos de alambre se refinaron según las encuestas de usuarios, así como las pruebas de usabilidad con nuestros usuarios. Los flujos de alambre proporcionaron una forma rápida y visual de comunicar a los desarrolladores el prototipo deseado se ve y se siente para que el desarrollo podría comenzar una vez que el PM aprobó las historias iniciales.
Aplicamos técnicas y herramientas de diseño que incluyen entrevistas de personal, desarrollo de flujo de cables, pruebas de usabilidad y UX Lean para desarrollar nuestra interfaz de usuario. Para admitir una interfaz receptiva basada en el navegador, aprovechamos las pautas de US Web Design (USWD) para estándares web modernos y AngularJS. La aplicación de estos estándares, junto con la entrada de los usuarios, nos permitió construir un prototipo que fuera simple e intuitivo de navegar y usar. También probamos el cumplimiento de ADA 508 y WCAG 2.0, utilizando herramientas automatizadas para probar el soporte de lector adaptativo y otras opciones de baja visión.
d. Utilizado al menos un mínimo de tres (3) técnicas y/o herramientas de "diseño centrado en el usuario";
Utilizamos entrevistas de personas, flujos de alambre y pruebas de usabilidad como nuestras principales herramientas para desarrollar un diseño para nuestro prototipo que se centró en las necesidades y deseos de nuestros usuarios.
mi. Usó GitHub para documentar el código compromisos;
Las commits se pueden ver en Github: https://github.com/cgi-zahid/cgi-poc
F. Usó arrogancia para documentar la API RESTFLE y proporcionó un enlace a la API Swagger;
Toda la comunicación con el nivel medio se realizó con API REST. Middle Tier expone la API REST usando Jax RX y está documentado en Swagger.
gramo. Cumplió con la Sección 508 de la Ley de Americanos con Discapacidades y WCAG 2.0;
Como parte de nuestras pruebas de usabilidad, probamos para el cumplimiento de 508 y WCAG 2.0. Utilizamos pruebas automatizadas para probar la legibilidad y la baja visión. Abordamos los errores como parte de nuestro proceso de backlog. Se evaluaron otros resultados de las pruebas para determinar qué agregar al acumulación y los que no se aplicaron a nuestro prototipo.
Utilizamos ACTF Adesigner para nuestras pruebas 508.
h. Creado o utilizado una guía de estilo de diseño y/o una biblioteca de patrones;
UX/UI creó una guía de estilo utilizando los estándares de diseño web de EE. UU. Nuestro esquema de color fue seleccionado en función de los colores del estado de California y aprobado por los comentarios de los usuarios. La aplicación de los estándares de diseño web de EE. UU. Junto con la entrada de los usuarios nos permitió construir un prototipo que fuera simple e intuitivo de navegar y usar.
i. Realizó pruebas de usabilidad con personas;
Como parte de nuestro enfoque centrado en el usuario, incorporamos pruebas de usabilidad en nuestro proceso. Las pruebas de usabilidad se realizaron a través de encuestas de usuarios en nuestras marcas alámbricas, así como comentarios de los usuarios que probaron nuestro prototipo en nuestros sprints. PM y UX Designer evaluó la retroalimentación de las pruebas de usabilidad para determinar qué incluir en la acumulación. Basado en la dirección de PM, se crearon, priorizaron y se colocaron nuevas historias, priorizadas y colocadas en nuestra cartera de pedidos.
j. Utilizó un enfoque iterativo, donde la retroalimentación informó el trabajo posterior o las versiones del prototipo;
Dentro de cada sprint, las entradas recibidas del Gerente de Producto, los probadores de usabilidad y los defectos identificados durante las pruebas se evaluaron, priorizaron e incorporaron a la acumulación como parte de nuestro enfoque iterativo. Con cada demostración, el prototipo se alineó cada vez más con la visión del PM, así como las necesidades de nuestros usuarios.
k. Creó un prototipo que funciona en múltiples dispositivos y presenta un diseño receptivo;
Nuestro código ha estado probando utilizando múltiples dispositivos y funciona con múltiples navegadores web. Además, nuestro código se ha probado utilizando dispositivos Apple y Android.
Probamos en:
l. Utilizado al menos cinco (5) tecnologías modernas y de código abierto, independientemente de la capa arquitectónica (frontend, backend, etc.);
Utilizamos las siguientes seis (6) tecnologías modernas y de código abierto:
Se proporciona una lista de todas nuestras tecnologías: lista de tecnología. Las filas resaltadas en verde en la hoja de cálculo son las tecnologías modernas y de código abierto.
metro. Implementó el prototipo en una infraestructura como proveedor de servicio (IaaS) o plataforma como servicio (PAAS), e indicó qué proveedor utilizaron;
Usamos Azure como nuestro proveedor de IaaS.
norte. Desarrolló pruebas unitarias automatizadas para su código;
Antes de controlar el código en la rama de características, los desarrolladores de la rama hacen una solicitud de extracción para activar una revisión del código. Una vez que se aprueba la revisión del código, el código se fusiona en la rama de integración que desencadena el proceso de implementación continua.
o. Configurar o utilizar un sistema de integración continua para automatizar la ejecución de pruebas e implementar continuamente su código en su proveedor IaaS o PaaS;
Utilizamos Jenkins para la integración continua. Toma el código de GitHub y compila y ejecuta pruebas. Si el código pasa las pruebas, entonces Docker crea una imagen. La imagen se implementa en el entorno de prueba del sistema donde se realiza una prueba funcional de extremo a extremo utilizando selenio.
pag. Configuración o gestión de configuración utilizada;
Los registros de contenedores de Azure se utilizaron para almacenar y administrar nuestras imágenes de Docker, lo que nos permite administrar la configuración
q. Configuración o monitoreo continuo utilizado;
Azure y nuevas reliquias se utilizaron para monitorear continuamente la salud del medio ambiente y la aplicación
r. Implementó su software en un contenedor de código abierto, como Docker (es decir, la virtualización de nivel de sistema operativo utilizado);
Implementamos nuestro software usando Docker
s. Proporcionó una documentación suficiente para instalar y ejecutar su prototipo en otra máquina;
A continuación se muestra un enlace a nuestras instrucciones de instalación.
Instrucciones
t. Las plataformas prototipo y subyacentes utilizadas para crear y ejecutar el prototipo tienen licencia abiertamente y gratuita.
Utilizamos plataformas con licencia abierta y gratuita
Lista de herramientas
Nuestro proceso para el diseño y el desarrollo de nuestro prototipo siguió y cumplió con muchos de los estándares descritos en el libro de jugadas de servicios digitales de EE. UU. Proporcionamos un documento detallado sobre GitHub que se vincula a nuestra evidencia, así como a nuestra respuesta a cada elemento.
Nuestras respuestas del libro de jugadas de servicios digitales de EE. UU.
