CGI POC
1.0.0
Github: https://github.com/cgi-zahid/cgi-poc
Aplicação: [https://mycalerts.com]
Obter credencial de administrador e amostra do usuário final
CGI's approach to the Pre-Qualified Vendor Pool for Digital Services – Agile Development (PQVP DS-AD) effort employed user-centric design techniques, a sprint based development workflow and modern and open-source technologies to design and build MyCAlerts, our implementation of Working Prototype B. MyCAlerts allows California residents to establish and manage user profiles, subscribe to receive severe fire/weather/flood/ad hoc alerts, e rastrear suas notificações anteriores. Os usuários podem receber notificações por meio de SMS (Short Message Service) e e-mail com base nas informações de localização da rua e de contato fornecidas em seu perfil de usuário. O MyCalerts permite que usuários administrativos autorizados rastreem e visualizem eventos e enviem notificações de eventos ad hoc de emergência e não emergenciais.
Começamos com uma revisão do projeto de RFI. A CGI estabeleceu nossa equipe e começou a correr Planejamento. Determinamos a arquitetura e ambientes técnicos que usaríamos. Implantamos nossas ferramentas de desenvolvedor padrão e recursos de colaboração ágil, para criar um aplicativo "Hello World" (uma página de login simples) para testar nossa estrutura de pilha técnica e integração contínua/implantação contínua (CI/CD).
Após o recebimento da RFI final, nosso gerente de produto (PM) liderou uma sessão de análise de protótipo. A equipe se reuniu e realizou uma sessão de planejamento e dimensionamento para avaliar a complexidade, o interesse da equipe e os riscos de cada protótipo. Com grande entusiasmo, nossa equipe selecionou o protótipo de trabalho B.
Com base nas entrevistas iniciais do usuário, o PM selecionou os três conjuntos de dados considerados mais relevantes para os usuários da CA. Ele optou por pesquisar as seguintes notificações de emergência automatizadas: incêndios florestais (serviço de limites de incêndio ativo do USGS Geomac - a cada 15 minutos), inundações (meditório do rio - serviço atual e previsto da NOAA - a cada 6 horas) e severo (serviço de riscos climáticos da NOAA - a cada 15 minutos).
No pontapé inicial, nosso primeiro-ministro forneceu sua visão para o protótipo e um roteiro de alto nível para a conclusão do trabalho. A equipe estabeleceu funções e responsabilidades, bem como um contrato de equipe colaborativa. Solidificamos e estabelecemos nossas relações de trabalho de equipe. Usando os requisitos de roteiro e protótipo, a equipe desenvolveu uma série inicial de histórias de usuários. Nosso PM priorizou essas histórias, juntamente com as histórias de configuração de infraestrutura de UX/UI e técnicas para estabelecer nosso backlog de produtos.
Nosso designer de UX/UI facilitou uma abordagem de design de design de usuário - de design do usuário, envolvendo os usuários cedo com o uso de entrevistas e pesquisas persona. Aproveitamos o AngularJS, juntamente com os padrões e o conjunto de componentes do Guia de estilo dos EUA Web-Design (USWDS) para implementar um aplicativo Web acessível moderno. Também testamos a conformidade ADA 508 e WCAG 2.0. Tornamos usuários de várias idades, funções, experiências e origens. Durante a Sprint 1, entrevistamos os usuários e nossos resultados foram rapidamente transformados em fletos de arame, aproveitando um design responsivo que acomoda plataformas de mesa e móveis. Esses fluxos de arame foram continuamente refinados com base na entrada do usuário. Nossos fluxos de arame forneceram um visual para comunicar a aparência do protótipo aos desenvolvedores. Além do design inicial, os usuários foram contratados por meio de testes de usabilidade e sua entrada foi avaliada e priorizada por meio de histórias de melhoria que foram adicionadas no backlog do produto para inclusão em sprints subsequentes.
Seguimos um processo ágil (Figura 1) dos ciclos semanais de sprint, com cada ciclo a partir de quarta -feira e terminando na terça -feira seguinte.
Figura 1 - Nosso processo ágil 
A cada semana, os rituais de sprint incluíam: Stand-up-de segunda a sexta-feira às 8:45-9:00 Facilitado pelo treinador Agile. Os membros da equipe de desenvolvimento relataram o trabalho concluído desde a última sessão; Trabalho planejado antes da próxima sessão e de qualquer bloqueador. Os bloqueadores identificados foram limpos pelo treinador e gerente de entrega do Agile. O Stand-Up forneceu um ótimo fórum para coordenação em toda a equipe.
Backlog Helfing - Segunda -feira, nosso PM revisou e repriorizou itens de backlog. O treinador Agile e o gerente de entrega apoiaram a revisão e confirmaram histórias de usuário acordadas com a "Definição de Ready" da equipe.
Sprint Review - terça -feira de manhã, a equipe apresentou histórias de usuários concluídas no sprint ao PM para revisão e aprovação. Histórias de usuário aprovadas alinhadas com a "Definição de done" da equipe.
Sprint Retrospective - terça -feira de manhã, a equipe refletiu sobre como suas ferramentas, processos e colegas se apresentaram no sprint recentemente concluído. Cada membro da equipe foi solicitado a identificar um traço de melhoria que eles queriam ver a equipe começar a fazer; Um que eles queriam que a equipe parasse de fazer e que eles queriam que a equipe continuasse. Facilitado pelo treinador ágil, as características de início/stop/stop/stop/stop identificadas foram consolidadas e as próximas etapas definidas pela equipe.
Sprint Planning - terça -feira à tarde, uma sessão de uma hora para a PM e a equipe discutiram e concordaram com interativamente a carga útil do próximo sprint. O dimensionamento dos itens no sprint foi coordenado pelo treinador ágil e gerente de entrega. Planejitpoker.com foi usado para estimativa de histórias.
Veja nosso álbum de fotos de equipe para obter exemplos visuais da equipe e nosso processo ágil em ação.
A cada iteração, o protótipo ficou cada vez mais alinhado à visão do PM, bem como às necessidades de nossos usuários. Nosso roteiro de alto nível incluiu várias histórias de usuários que, em última análise, não foram incluídas no protótipo de trabalho. Isso incluía pesquisa de pico para um aplicativo de cliente nativo do iOS e funcionalidade de notificação de push nativa. Embora ambos não estivessem no produto mínimo viável (MVP) publicado (MVP), eles estão incluídos no backlog do produto, artefatos de arquitetura e código -fonte do GitHub.
Ao longo do processo, a equipe conseguiu coordenar o trabalho e monitorar o progresso usando nossa placa Scrum. Usamos a JIRA para rastrear histórias de usuários em um quadro eletrônico (assim como bugs) e mantivemos um quadro físico na sala da equipe. Utilizamos o Confluence para compartilhamento de documentos e HipChat como nossa ferramenta de colaboração de equipe. As métricas foram rastreadas para que a equipe entendesse como eles estavam e possíveis áreas para melhorar os processos a cada sprint. As métricas mostraram à equipe sua velocidade de desenvolvimento, atraso técnico e qual a porcentagem de pontos da história foi implementada a cada sprint.
Para todas as decisões tecnológicas, consideramos opções abertas, resultando em uma pilha predominantemente de código aberto. Nossa meta de tecnologia era um aplicativo moderno baseado em navegador, mas também investigamos a possibilidade de um aplicativo móvel nativo no iOS.
Figura 2 - Nossa pilha de tecnologia 
Do ponto de vista do DevOps:
Testamos e implantamos o protótipo na infraestrutura do Azure da Microsoft como uma solução de serviço (IAAS). Utilizamos a solução de monitoramento do Azure para o monitoramento contínuo de infraestrutura, incluindo redes e nova relíquia para monitoramento contínuo de desempenho de aplicativos. Utilizamos os principais dados dos indicadores de desempenho (KPI) para ajustar nossa solução e aplicação de infraestrutura.
Nossa solução usou o GitHub para documentar o código e os testes de unidade em nosso repositório público do GitHub. Nossa estrutura do GitHub possui ramificações de mestre e integração, além de ramificações de recursos. O desenvolvimento de histórias individuais foi feito em um ramo de recursos em um ambiente local. Antes de verificar o código, os desenvolvedores emitiram uma solicitação de tração para acionar uma revisão do código. Depois que a revisão do código foi aprovada, o código foi mesclado na filial de integração, acionando o processo de integração contínua.
A Figura 3 exibe a visualização das ferramentas e a migração de código de alto nível do desenvolvimento para a produção usando nosso processo CI/CD.
Figura 3 - Integração e implantação contínuas (ferramentas) 
Jenkins recuperou o código do Github, construiu o aplicativo e executou testes de unidade. Se todos os testes de unidade foram aprovados, o Docker criou uma imagem de distribuição. Empregamos uma abordagem moderada de CD para o ambiente de teste todas as noites para evitar interferir nos testes funcionais contínuos. As implantações ad hoc foram acomodadas conforme necessário. Depois que uma compilação foi implantada para testar, nosso conjunto de testes funcional (usando selênio) foi executado automaticamente.
Figura 4 - Integração e implantação contínuas (visualização do processo) 
Aqui está uma visão geral das etapas que seguimos em nossa abordagem:
um. O desenvolvedor define seu ambiente de desenvolvimento local usando arquivos do Docker para imitar o ambiente de operações e cria ramificações de recursos do ramo mestre do GitHub (etapa 0).
b. O desenvolvedor cria testes de unidade (etapa 1) e grava o código -fonte apropriado (etapa 2) para implementar uma história/recurso do usuário.
c. Para mesclar o teste de unidade e o código -fonte, o desenvolvedor envia uma solicitação de tração; A revisão de código de gatilhos por um desenvolvedor de pares; O revisor aprova/ nega a mesclagem no ramo de integração; Finalmente, o desenvolvedor resolve as observações de revisão de código. Depois que a revisão do código é aprovada, a filial do recurso é mesclada na filial de integração (Etapa 4).
d. Os testadores criam scripts funcionais automatizados (etapa 3), que são mesclados na filial de integração (Etapa 4).
e. Em um cronograma pré-determinado, Jenkins compila o código-fonte e todos os testes de unidade são executados automaticamente (etapa 5).
f. Se os testes da unidade falharem, uma notificação será enviada sobre a falha e o desenvolvedor a corrige na filial do recurso correspondente (etapa 15). As etapas 4 e 5 são repetidas até que os testes da unidade passem.
g. Depois que os testes de unidade passam, Jenkins executa arquivos do Docker para criar as imagens do Docker para a interface do usuário e o back -end (Etapa 6).
h. O Docker empurra as imagens para o Registro do Azure (Etapa 7) e as implanta para o ambiente de teste em que os testes funcionais são executados automaticamente (Etapa 8).
eu. Se os testes funcionais falharem, uma notificação será enviada (etapa 14) e os desenvolvedores corrigem os problemas (etapa 15). As etapas 4, 5, 6, 7 e 8 são repetidas até que os testes funcionais passem.
j. Depois que os testes funcionais são bem -sucedidos, uma notificação é enviada sobre a execução bem -sucedida do teste (etapa 9).
k. O controle de qualidade realiza testes ad-hoc/manuais. Se eles falharem, o desenvolvedor será notificado para corrigir o problema (etapa 15). As etapas 4, 5, 6, 7, 8, 9 e 10 são repetidas até que os testes ad-hoc passem.
l. Depois que o erro é corrigido, a filial de integração é mesclada com a tag de produção na ramificação Master (Etapa 11).
m. Finalmente, a imagem criada para teste é implantada no ambiente de produção (etapa 12).
Nosso código -fonte está estruturado para seguir nossa arquitetura distribuída e o software usado para implementá -lo. O front -end é armazenado na pasta angular e o back -end na pasta DropWizard. Também temos pastas para testes funcionais automatizados na pasta selênio.
A interface do usuário é construída usando o AngularJS. Dentro da pasta angular, a pasta do aplicativo inclui subpastas para imagens, idioma, folhas de estilo em cascata, scripts e vistas. A pasta Scripts contém controladores, fábrica e serviços. A pasta Controllers, por sua vez, hospeda os arquivos JavaScript, enquanto a pasta View contém arquivos HTML. Os testes de unidade são mantidos separadamente do código na pasta de teste.
O front -end se comunica com o back -end usando APIs RESTful. O código do front -end que chama os Serviços reside na subpasta Services na pasta Scripts.
O aplicativo back -end implementa a lógica de negócios, se comunica com serviços externos, envia notificações e interage com o banco de dados. O back -end é implementado usando o DropWizard, que fornece uma estrutura Java com suporte de descanso e JUNIT. A lógica de negócios e os pontos de extremidade estão na pasta de recursos, e a implementação de serviços está na pasta de serviço.
O aplicativo também implementa os invólucros de API externos (implementados aqui) para recuperar dados de fontes de dados externas.
Os testes de unidade residem na pasta de teste.
O aplicativo se comunica com o banco de dados relacional (MySQL) usando o Hibernate. Utilizamos as validações Jaxb Bean padrão para validação de dados. Os objetos de acesso a dados e objetos de modelo estão localizados na pasta DAO.
um. Atribuído um (1) líder e deu a essa pessoa autoridade e responsabilidade e responsabilizou essa pessoa pela qualidade do protótipo enviado
Durante a avaliação de RFI, o CGI selecionou um gerente de produto (PM) com base em sua experiência técnica e de gerenciamento. A CGI deu à PM Final Decision Toman Authority sobre o design e o desenvolvimento do protótipo.
b. Reuniu uma equipe multidisciplinar e colaborativa que inclui, no mínimo, cinco (5) das categorias de trabalho, conforme identificado no Anexo B: PQVP DS-AD Category Descrições
Sob a liderança do primeiro -ministro, a CGI reuniu uma equipe multidisciplinar com várias capacidades técnicas e ágeis.
Nossa equipe:
c. Entendeu o que as pessoas precisavam, incluindo pessoas no processo de desenvolvimento e design do protótipo;
O CGI seguiu uma abordagem centrada no usuário para o design e o desenvolvimento do nosso protótipo. Nosso designer de UX/UI envolveu os usuários cedo com o uso de entrevistas e pesquisas persona. Os resultados da entrevista foram rapidamente transformados em fluxos de arame. Os fluxos de arame foram refinados com base em pesquisas de usuários, bem como no teste de usabilidade com nossos usuários. Os Flows Wire fornecem uma maneira rápida e visual de se comunicar aos desenvolvedores, a aparência do protótipo desejado, para que o desenvolvimento pudesse começar assim que o PM aprovasse as histórias iniciais.
Aplicamos técnicas e ferramentas de design, incluindo entrevistas persona, desenvolvimento de arame, teste de usabilidade e UX enxuta para desenvolver nossa interface do usuário. Para suportar uma interface baseada em navegador responsiva, alavancamos as diretrizes do US Web Design (USWD) para os padrões da Web modernos e o AngularJs. A aplicação desses padrões, juntamente com a contribuição dos usuários, nos permitiu criar um protótipo simples e intuitivo para navegar e usar. Também testamos a conformidade ADA 508 e WCAG 2.0, usando ferramentas automatizadas para testar o suporte a leitores adaptativos e outras opções de baixa visão.
d. Usou pelo menos um mínimo de três (3) técnicas e/ou ferramentas de "design centrado no usuário";
Utilizamos entrevistas de personas, fluxos de arame e testes de usabilidade como nossas principais ferramentas para desenvolver um design para o nosso protótipo focado nas necessidades e desejos de nossos usuários.
e. Github usado para documentar o código cometidos;
Os compromissos podem ser vistos no github: https://github.com/cgi-zahid/cgi-poc
f. Swagger usou para documentar a API RESTful e forneceu um link para a API Swagger;
Toda a comunicação com a camada do meio foi feita usando a API REST. O nível médio expõe a API REST usando o JAX RX e está documentado em Swagger.
g. Cumpriu a Seção 508 da Lei dos Americanos com Deficiência e o WCAG 2.0;
Como parte de nossos testes de usabilidade, testamos a conformidade com 508 e WCAG 2.0. Utilizamos testes automatizados para testar a legibilidade e a baixa visão. Abordamos erros como parte do nosso processo de atraso. Outros resultados dos testes foram avaliados para determinar qual adicionar ao backlog e aqueles que não se aplicaram ao nosso protótipo.
Utilizamos o ACTF Adesigner para nossos testes 508.
h. Criou ou usou um guia de estilo de design e/ou uma biblioteca de padrões;
O UX/UI criou um guia de estilo usando os padrões de design da web dos EUA. Nosso esquema de cores foi selecionado com base nas cores do estado da Califórnia e aprovado pelo feedback do usuário. A aplicação dos padrões de design da web dos EUA, juntamente com a entrada dos usuários, nos permitiu criar um protótipo que era simples e intuitivo para navegar e usar.
eu. Realizou testes de usabilidade com pessoas;
Como parte de nossa abordagem centrada no usuário, incorporamos testes de usabilidade em nosso processo. Os testes de usabilidade foram realizados através de pesquisas de usuário em nossos wireframes, bem como feedback de usuários que testaram nosso protótipo ao longo de nossos sprints. O feedback dos testes de usabilidade foi avaliado por PM e UX Designer para determinar o que incluir no backlog. Com base na direção do PM, novas histórias foram criadas, priorizadas e colocadas em nossa lista de pendências.
j. Usou uma abordagem iterativa, onde o feedback informou o trabalho subsequente ou versões do protótipo;
Dentro de cada sprint, foram avaliadas as entradas recebidas do gerente de produto, testadores de usabilidade e defeitos identificados durante o teste, priorizados e incorporados na lista de pendências como parte de nossa abordagem iterativa. A cada demonstração, o protótipo ficou cada vez mais alinhado à visão do PM, bem como às necessidades de nossos usuários.
k. Criou um protótipo que funciona em vários dispositivos e apresenta um design responsivo;
Nosso código tem testado usando vários dispositivos e trabalha com vários navegadores da Web. Além disso, nosso código foi testado usando dispositivos Apple e Android.
Testamos em:
l. Usado pelo menos cinco (5) tecnologias modernas e de código aberto, independentemente da camada arquitetônica (front-end, back-end etc.);
Utilizamos as seis (6) tecnologias modernas e de código aberto:
É fornecida uma lista de todas as nossas tecnologias: lista de tecnologia. As linhas destacadas em verde na planilha são as tecnologias modernas e de código aberto.
m. Implantou o protótipo em uma infraestrutura como um provedor de serviço (IAAS) ou plataforma como serviço (PAAS) e indicou qual provedor eles usaram;
Usamos o Azure como nosso provedor de IaaS.
n. Desenvolveu testes de unidade automatizados para seu código;
Antes de verificar o código nos desenvolvedores de ramificações de recursos, faça uma solicitação de tração para acionar uma revisão de código. Depois que a revisão do código é aprovada, o código é mesclado na filial de integração, que aciona o processo de implantação contínua.
o. Configurar ou usar um sistema de integração contínua para automatizar a execução de testes e implantar continuamente seu código para o provedor de IaaS ou PaaS;
Usamos Jenkins para integração contínua. Ele pega código do GitHub e compila e executa testes. Se o código passar nos testes, o Docker criará uma imagem. A imagem é implantada no ambiente de teste do sistema, onde um teste funcional de ponta a ponta é realizado usando o selênio.
p. Configuração ou gerenciamento de configuração usada;
Os registros de contêineres do Azure foram usados para armazenar e gerenciar nossas imagens do Docker, permitindo -nos gerenciar a configuração
q. Configurar ou usar monitoramento contínuo;
Azure e New Relic foram usados para monitorar continuamente a saúde do meio ambiente e o aplicativo
r. Implantou seu software em um contêiner de código aberto, como o Docker (ou seja, utilizou a virtualização no nível do sistema operacional);
Nós implantamos nosso software usando o Docker
s. Forneceu documentação suficiente para instalar e executar seu protótipo em outra máquina;
Abaixo está um link para nossas instruções de instalação.
Instruções
t. O protótipo e as plataformas subjacentes usadas para criar e executar o protótipo são licenciadas abertamente e gratuitas.
Usamos plataformas abertamente licenciadas e gratuitas
Lista de ferramentas
Nosso processo para o design e desenvolvimento de nosso protótipo seguiu e atendeu a muitos dos padrões descritos no manual dos Serviços Digitais dos EUA. Fornecemos um documento detalhado no GitHub, que vincula nossas evidências, bem como nossa resposta a cada item.
Nosso manual de manual de serviços digitais nos EUA respostas
