CGI POC
1.0.0
github : https://github.com/cgi-zahid/cgi-poc
응용 프로그램 : [https://mycalerts.com]
관리자 및 샘플 최종 사용자 자격 증명을 얻습니다
CGI의 디지털 서비스를위한 사전 자격 공급 업체 풀에 대한 CGI의 접근-민첩한 개발 (PQVP DS-AD) 노력 사용자 중심 설계 기술, 스프린트 기반 개발 워크 플로우 및 현대 및 오픈 소스 기술을 사용하여 MyCalerts를 설치하고 구축하기 위해 MyCalerts는 캘리포니아 주민들을 설립하고 관리 할 수있게 해줍니다. 과거 알림을 추적하십시오. 사용자는 짧은 메시지 서비스 (SMS)를 통해 알림을 받고 사용자 프로필에 제공된 스트리트로 위치 및 연락처 정보를 기반으로 이메일을받을 수 있습니다. MyCalerts를 통해 공인 관리자는 이벤트를 추적 및 시각화하고 임시 응급 상황 및 비 응급 이벤트에 대한 알림을 보낼 수 있습니다.
우리는 RFI 초안 검토로 시작했습니다. CGI는 우리 팀을 설립하고 Sprint 0 계획을 시작했습니다. 우리는 우리가 사용할 기술 아키텍처와 환경을 결정했습니다. 표준 개발자 도구 및 민첩한 협업 리소스를 배포하여 기술 스택 및 CI/CD (Continuous Integration/Continuous Deployment) 프레임 워크를 테스트하기 위해 "Hello World"응용 프로그램 (간단한 로그인 페이지)을 구축했습니다.
최종 RFI를 수령하면 PM (Product Manager)은 프로토 타입 분석 세션을 이끌었습니다. 팀은 모여 각 프로토 타입의 복잡성, 팀 관심 및 위험을 평가하기 위해 계획 및 사이징 세션을 개최했습니다. 열정으로 우리 팀은 작업 프로토 타입을 선택했습니다.
초기 사용자 인터뷰를 기반으로 PM은 CA 사용자와 가장 관련이있는 3 가지 데이터 세트를 선택했습니다. 그는 산불 (USGS GeOMAC의 활성 화재 경계 서비스 - 15 분마다 활성 화재 경계 서비스), 홍수 (River Gauge- NOAA의 현재 및 예측 서비스 - 6 시간마다) 및 심한 날씨 (NOAA의 날씨 위험 서비스 - 15 분마다)를 설문 조사하기로 결정했습니다.
킥오프에서 PM은 프로토 타입에 대한 비전과 작업 완료를위한 고급 로드맵을 제공했습니다. 팀은 역할과 책임뿐만 아니라 협업 팀 계약을 확립했습니다. 우리는 팀 업무 관계를 확고하고 확립했습니다. 로드맵 및 프로토 타입 요구 사항을 사용하여 팀은 초기 시리즈 사용자 스토리를 개발했습니다. PM은 UX/UI 및 기술 인프라 설정 스토리와 함께 이러한 스토리를 우선시하여 제품 백 로그를 설정했습니다.
UX/UI 디자이너는 페르소나 인터뷰 및 설문 조사를 통해 사용자를 조기에 참여시켜 사용자 중심 - 사용자 중심 설계 접근 방식을 촉진했습니다. 우리는 미국 웹 디자인 (USWD) 스타일 가이드의 표준 및 구성 요소와 함께 AngularJS를 활용하여 최신 액세스 가능한 웹 응용 프로그램을 구현했습니다. 또한 ADA 508 및 WCAG 2.0 준수를 테스트했습니다. 우리는 다양한 연령, 역할, 경험 및 배경을 가진 사용자를 활용했습니다. Sprint 1 동안 우리는 사용자를 인터뷰했으며 결과는 데스크탑과 모바일 플랫폼을 모두 수용하는 반응 형 디자인을 활용하여 와이어 플로로 빠르게 바뀌 었습니다. 이 와이어 플로우는 사용자 입력에 따라 지속적으로 정제되었습니다. 우리의 와이어 플로우는 프로토 타입의 모양과 느낌을 개발자에게 전달하는 시각적을 제공했습니다. 초기 설계 외에도 사용자는 유용성 테스트를 통해 참여했으며 개선 스토리를 통해 입력을 평가하고 우선 순위를 정한 다음, 후속 스프린트에 포함시키기 위해 제품 백 로그에 추가되었습니다.
우리는 매주 스프린트 사이클의 민첩한 과정 (그림 1)을 따랐으며 각주기는 수요일에 시작하여 다음 화요일에 끝납니다.
그림 1- 우리의 민첩한 과정 
매주 스프린트 의식은 다음과 같습니다. 스탠드 업-월요일-금요일 @ 8:45-9:00 AM 애자일 코치가 촉진했습니다. 개발 팀원들은 마지막 세션 이후 작업이 완료되었다고보고했다. 다음 세션과 모든 차단제 전에 계획된 작업. Agile Coach and Delivery Manager는 확인 된 차단제를 청소했습니다. 스탠드 업은 팀 전체의 조정을위한 훌륭한 포럼을 제공했습니다.
백 로그 그루밍 - 월요일, PM은 백 로그 항목을 검토하고 재현했습니다. 민첩한 코치와 배달 관리자는 검토를지지하고 팀의“준비 정의”와 동의 한 사용자 스토리를 확인했습니다.
Sprint Review- 화요일 아침, 팀은 검토 및 승인을 위해 Sprint에서 PM에 대한 사용자 스토리를 완성했습니다. 승인 된 사용자 스토리는 팀의 "완료 정의"와 연계되었습니다.
스프린트 회고 - 화요일 아침, 팀은 최근에 완성 된 스프린트에서 자신의 도구, 프로세스 및 동료가 어떻게 수행되는지에 대해 반영했습니다. 각 팀원은 팀이 시작하는 것을보고 싶은 하나의 개선 특성을 식별하도록 요청 받았습니다. 하나는 팀이하지 않기를 원했고 팀이 계속되기를 원했습니다. 민첩한 코치가 촉진 한 것으로 식별 된 시작/정지/계속 특성을 통합하고 다음 단계는 팀이 정의했습니다.
스프린트 계획 - 화요일 오후, PM과 팀을위한 1 시간 세션은 다음 스프린트의 페이로드에 대해 대화식으로 논의하고 동의했습니다. 스프린트의 품목 크기는 민첩한 코치 및 배달 관리자에 의해 조정되었습니다. planitpoker.com은 스토리 추정에 사용되었습니다.
팀의 시각적 예제와 Agile Process in Team 사진 앨범을 참조하십시오.
각 반복 할 때마다 프로토 타입은 PM의 비전과 사용자의 요구에 점점 더 정렬되었습니다. 우리의 고급 로드맵에는 궁극적으로 작업 프로토 타입에 포함되지 않은 몇 가지 사용자 스토리가 포함되었습니다. 여기에는 iOS 기본 클라이언트 응용 프로그램에 대한 스파이크 연구와 기본 푸시 알림 기능이 포함되었습니다. 둘 다 게시 된 최소 실행 가능한 제품 (MVP)에 없었지만 제품 백 로그, 아키텍처 아티팩트 및 GitHub 소스 코드에 포함됩니다.
이 과정 전체에서 팀은 스크럼 보드를 사용하여 작업을 조정하고 진행 상황을 모니터링 할 수있었습니다. 우리는 Jira를 사용하여 전자 보드 (버그뿐만 아니라)에서 사용자 스토리를 추적하고 팀 룸에서 실제 보드를 유지했습니다. 우리는 팀 협업 도구로서 문서 공유 및 hipchat에 합류를 사용했습니다. 메트릭이 추적되어 팀은 각 스프린트와의 프로세스 개선을위한 잠재적 인 영역과 잠재적 인 영역을 이해했습니다. 메트릭은 팀이 개발 속도, 기술 백 로그 및 각 스프린트와 함께 실제로 구현 된 스토리 포인트의 일부를 보여주었습니다.
모든 기술 결정에 대해, 우리는 공개 옵션을 고려하여 주로 오픈 소스 인 스택을 초래합니다. 우리의 기술 목표는 브라우저 기반 최신 웹 응용 프로그램 이었지만 iOS에서 기본 모바일 앱의 가능성을 조사했습니다.
그림 2 - 기술 스택 
DevOps 관점에서 :
우리는 Microsoft의 Azure 인프라에 대한 프로토 타입을 서비스 (IAAS) 솔루션으로 테스트하고 배포했습니다. 우리는 네트워킹을 포함한 지속적인 인프라 모니터링 및 지속적인 애플리케이션 성능 모니터링을위한 새로운 유물을 위해 Azure의 모니터링 솔루션을 사용했습니다. KPI (Key Performance Indicator) 데이터를 사용하여 인프라 솔루션 및 응용 프로그램을 미세 조정했습니다.
당사의 솔루션은 GitHub를 사용하여 코드 및 단위 테스트가 공개 GitHub 저장소에서 커밋됩니다. GitHub 구조에는 마스터 및 통합 브랜치와 기능 분기가 있습니다. 개별 스토리의 개발은 지역 환경의 기능 지점에서 이루어졌습니다. 코드를 확인하기 전에 개발자는 코드 검토를 트리거하기위한 풀 요청을 발행했습니다. 코드 검토가 승인되면 코드가 통합 브랜치로 병합되어 지속적인 통합 프로세스가 트리거되었습니다.
그림 3은 CI/CD 프로세스를 사용하여 도구보기와 개발에서 생산으로의 높은 수준 코드 마이그레이션을 표시합니다.
그림 3 - 지속적인 통합 및 배포 (도구) 
Jenkins는 Github에서 코드를 검색하고 응용 프로그램을 구축하고 단위 테스트를 실행했습니다. 모든 단위 테스트가 통과되면 Docker는 분포 이미지를 만들었습니다. 우리는 지속적인 기능 테스트를 방해하지 않기 위해 밤마다 테스트 환경에 중재 된 CD 접근법을 사용했습니다. 필요에 따라 임시 배포가 수용되었습니다. 빌드가 테스트를 위해 배치되면 기능 테스트 스위트 (셀레늄 사용)가 자동으로 실행되었습니다.
그림 4 - 지속적인 통합 및 배포 (프로세스보기) 
다음은 우리가 접근 한 단계에 대한 개요입니다.
에이. 개발자는 Docker 파일을 사용하여 로컬 개발 환경을 설정하여 운영 환경을 모방하고 GitHub 마스터 브랜치 (단계 0)에서 기능 분기를 만듭니다.
비. 개발자는 단위 테스트 (1 단계)를 생성하고 사용자 스토리/기능을 구현하기 위해 적절한 소스 코드 (2 단계)를 작성합니다.
기음. 장치 테스트 및 소스 코드를 병합하려면 개발자가 풀 요청을 제출합니다. 동료 개발자의 코드 검토를 트리거합니다. 검토자는 통합 지점에 합병을 승인/ 거부합니다. 마지막으로 개발자는 코드 검토 관찰을 해결합니다. 코드 검토가 승인되면 기능 분기는 통합 브랜치로 병합됩니다 (4 단계).
디. 테스터는 자동화 된 기능 스크립트 (3 단계)를 생성하며 통합 브랜치 (4 단계)에 병합됩니다.
이자형. 사전 결정된 일정에서 Jenkins는 소스 코드를 컴파일하고 모든 단위 테스트는 자동으로 실행됩니다 (5 단계).
에프. 단위 테스트가 실패하면 실패에 관한 알림이 전송되고 개발자는 통신 기능 분기에서이를 수정합니다 (15 단계). 4 단계와 5 단계는 단위 테스트가 통과 될 때까지 반복됩니다.
g. 단위 테스트가 통과되면 Jenkins는 Docker 파일을 실행하여 UI 및 백엔드의 Docker 이미지를 빌드합니다 (6 단계).
시간. Docker는 이미지를 Azure 레지스트리 (7 단계)로 푸시 한 다음 기능 테스트가 자동으로 실행되는 테스트 환경에 배치합니다 (8 단계).
나. 기능 테스트가 실패하면 알림이 전송되고 (14 단계) 개발자는 문제를 해결합니다 (15 단계). 4, 5, 6, 7 및 8 단계는 기능 테스트가 통과 될 때까지 반복됩니다.
J. 기능 테스트가 성공하면 성공적인 테스트 실행에 관한 알림이 전송됩니다 (9 단계).
케이. QA는 임시/수동 테스트를 수행합니다. 이러한 실패가 발생하면 개발자에게 문제를 해결하라는 통지를받습니다 (15 단계). 4, 5, 6, 7, 8, 9 및 10 단계는 임시 테스트가 통과 될 때까지 반복됩니다.
엘. 오류가 수정되면 통합 분기는 마스터 브랜치의 생산 태그와 병합됩니다 (11 단계).
중. 마지막으로 테스트를 위해 생성 된 이미지는 생산 환경에 배치됩니다 (12 단계).
소스 코드는 분산 아키텍처와이를 구현하는 데 사용되는 소프트웨어를 따르는 것으로 구성되었습니다. 프론트 엔드는 각도 폴더에 저장되고 Dropwizard 폴더에 백엔드가 저장됩니다. 또한 셀레늄 폴더에 자동화 된 기능 테스트를위한 폴더도 있습니다.
UI는 AngularJS를 사용하여 구축되었습니다. Angular 폴더 내에 앱 폴더에는 이미지, 언어, 계단식 스타일 시트, 스크립트 및보기에 대한 하위 폴더가 포함되어 있습니다. 스크립트 폴더에는 컨트롤러, 공장 및 서비스가 포함되어 있습니다. 컨트롤러 폴더는 차례로 JavaScript 파일을 호스팅하고 View 폴더에는 HTML 파일이 포함되어 있습니다. 단위 테스트는 테스트 폴더의 코드와 별도로 유지됩니다.
프론트 엔드는 RESTFUL API를 사용하여 백엔드와 통신합니다. 서비스를 호출하는 프론트 엔드 코드는 스크립트 폴더의 서비스 하위 폴더에 있습니다.
응용 프로그램 백엔드는 비즈니스 로직을 구현하고 외부 서비스와 통신하며 알림을 보내며 데이터베이스와 상호 작용합니다. 백엔드는 Dropwizard를 사용하여 구현되며 REST 및 JUNIT 지원이 포함 된 Java 프레임 워크를 제공합니다. 비즈니스 로직 및 엔드 포인트는 리소스 폴더에 있으며 서비스 구현은 서비스 폴더에 있습니다.
이 응용 프로그램은 외부 데이터 소스에서 데이터를 검색하기 위해 외부 API 래퍼 (여기에서 구현 된)를 구현합니다.
단위 테스트는 테스트 폴더에 있습니다.
응용 프로그램은 Hibernate를 사용하여 관계형 데이터베이스 (MySQL)와 통신합니다. 데이터 유효성 검사에는 표준 JAXB Bean 유효성 검사를 사용합니다. 데이터 액세스 개체 및 모델 객체는 DAO 폴더에 있습니다.
에이. 한 명 (1) 리더 1 명을 지정하고 그 사람의 권한과 책임을 부여하고 제출 된 프로토 타입의 품질에 대해 그 사람을 책임지게했습니다.
RFI 평가 중에 CGI는 기술 및 관리 경험을 바탕으로 제품 관리자 (PM)를 선택했습니다. CGI는 프로토 타입의 설계 및 개발에 대한 PM 최종 의사 결정 권한을 부여했습니다.
비. 첨부 파일 B : PQVP DS-AD 노동 범주 설명에 식별 된대로 최소한의 노동 범주의 5 개 (5)를 포함하는 다 분야 및 협력 팀을 조립했습니다.
PM의 리더십에 따라 CGI는 다양한 기술 및 민첩한 기능을 갖춘 다 분야 팀을 구성했습니다.
우리 팀 :
기음. 프로토 타입 개발 및 설계 프로세스에 사람들을 포함시켜 사람들이 필요한 것을 이해했습니다.
CGI는 프로토 타입의 설계 및 개발에 대한 사용자 중심의 접근 방식을 따랐습니다. UX/UI 디자이너는 페르소나 인터뷰 및 설문 조사를 통해 조기에 사용자를 참여 시켰습니다. 인터뷰 결과는 빠르게 와이어 플로로 바뀌었다. 와이어 플로우는 사용자 설문 조사와 사용자와의 유용성 테스트를 기반으로 개선되었습니다. 와이어 플로우는 PM이 초기 스토리를 승인 한 후 개발자와 같은 프로토 타입 모양과 느낌을 개발자에게 신속하고 시각적으로 전달하는 방법을 제공했습니다.
우리는 페르소나 인터뷰, 와이어 플로 개발, 유용성 테스트 및 린 UX를 포함한 디자인 기술과 도구를 적용하여 UI를 개발했습니다. 반응 형 브라우저 기반 인터페이스를 지원하기 위해 현대 웹 표준 및 AngularJS에 대한 USWD (Us Web Design)의 지침을 활용했습니다. 이러한 표준을 사용자의 입력과 함께 적용하면 탐색 및 사용에 간단하고 직관적 인 프로토 타입을 구축 할 수있었습니다. 또한 ADA 508 및 WCAG 2.0 규정 준수를 테스트하여 자동화 된 도구를 사용하여 적응 형 리더 지원 및 기타 낮은 비전 옵션을 테스트했습니다.
디. 최소한 3 개의 "사용자 중심 설계"기술 및/또는 도구를 사용했습니다.
우리는 사용자의 요구와 요구에 중점을 둔 프로토 타입을위한 디자인을 개발하기위한 주요 도구로 페르소나 인터뷰, 와이어 플로 및 유용성 테스트를 사용했습니다.
이자형. GitHub를 사용하여 코드 커밋을 문서화했습니다.
커밋은 github : https://github.com/cgi-zahid/cgi-poc에서 볼 수 있습니다
에프. 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를 사용했습니다.
시간. 디자인 스타일 가이드 및/또는 패턴 라이브러리를 만들거나 사용했습니다.
UX/UI는 미국 웹 디자인 표준을 사용하여 스타일 가이드를 만들었습니다. 우리의 색 구성표는 캘리포니아 주 색상을 기반으로 선택되었으며 사용자 피드백에 의해 승인되었습니다. 사용자의 입력과 함께 미국 웹 디자인 표준을 적용하면 탐색 및 사용에 간단하고 직관적 인 프로토 타입을 구축 할 수있었습니다.
나. 사람들과 유용성 테스트를 수행했습니다.
사용자 중심 접근 방식의 일환으로 사용성 테스트를 프로세스에 통합했습니다. 유용성 테스트는 와이어 프레임에 대한 사용자 설문 조사와 스프린트 전체의 프로토 타입을 테스트 한 사용자의 피드백을 통해 수행되었습니다. 유용성 테스트의 피드백은 백 로그에 포함 할 내용을 결정하기 위해 PM 및 UX 디자이너가 평가했습니다. PM Direction을 기반으로 새로운 이야기가 만들어지고 우선 순위를 정하고 백 로그에 배치되었습니다.
J. 피드백이 후속 작업이나 프로토 타입의 버전에 정보를 제공하는 반복적 인 접근법을 사용했습니다.
각 스프린트 내에서 제품 관리자로부터받은 입력, 유용성 테스터 및 테스트 중에 식별 된 결함을 반복적 인 접근 방식의 일부로 평가, 우선 순위를 정하고 백 로그에 통합했습니다. 각 데모마다 프로토 타입은 PM의 비전과 사용자의 요구에 점점 더 정렬되었습니다.
케이. 여러 장치에서 작동하는 프로토 타입을 만들고 반응 형 디자인을 제시합니다.
우리의 코드는 여러 장치를 사용하여 테스트하고 있으며 여러 웹 브라우저에서 작동합니다. 또한 우리의 코드는 Apple 및 Android 장치를 사용하여 테스트되었습니다.
우리는 다음을 테스트했습니다.
엘. 건축 계층 (프론트 엔드, 백엔드 등)에 관계없이 최소 5 개의 현대 및 오픈 소스 기술을 사용했습니다.
우리는 다음 6 개의 현대 및 오픈 소스 기술을 사용했습니다.
모든 기술의 목록이 제공됩니다 : 기술 목록. 스프레드 시트에서 녹색으로 강조 표시된 행은 현대 및 오픈 소스 기술입니다.
중. 서비스 (IAAS) 또는 플랫폼 (PAAS) 공급자로서 인프라에 프로토 타입을 배포했으며 어떤 공급자가 사용했는지 표시했습니다.
우리는 Azure를 IAAS 제공 업체로 사용했습니다.
N. 코드에 대한 자동화 된 단위 테스트를 개발했습니다.
기능 분기 개발자에 코드를 확인하기 전에 풀 요청을 수행하여 코드 검토를 트리거합니다. 코드 검토가 승인되면 코드는 통합 분기에 병합되어 지속적인 배포 프로세스를 트리거합니다.
영형. 설정 또는 지속적인 통합 시스템을 사용하여 테스트 실행을 자동화하고 IAA 또는 PAAS 제공 업체에 코드를 지속적으로 배포했습니다.
우리는 지속적인 통합을 위해 Jenkins를 사용했습니다. GitHub에서 코드를 잡고 테스트를 컴파일하고 실행합니다. 코드가 테스트를 통과하면 Docker는 이미지를 만듭니다. 이미지는 Selenium을 사용하여 END -END 기능 테스트가 수행되는 시스템 테스트 환경에 배치됩니다.
피. 설정 또는 중고 구성 관리;
Azure Container Registries는 Docker 이미지를 저장하고 관리하는 데 사용하여 구성을 관리 할 수 있습니다.
큐. 설정 또는 사용 된 지속적인 모니터링;
Azure 및 New Relic은 환경의 건강과 응용 프로그램의 건강을 지속적으로 모니터링하는 데 사용되었습니다.
아르 자형. Docker와 같은 오픈 소스 컨테이너에 소프트웨어를 배포했습니다 (즉, 운영 시스템 수준 가상화를 활용).
Docker를 사용하여 소프트웨어를 배포했습니다
에스. 다른 컴퓨터에 프로토 타입을 설치하고 실행하기에 충분한 문서를 제공했습니다.
아래는 설치 지침에 대한 링크입니다.
지침
티. 프로토 타입 및 기본 플랫폼은 프로토 타입을 생성하고 실행하는 데 사용되는 기본 플랫폼은 공개적으로 라이센스가 부여되며 무료입니다.
우리는 공개 라이센스 및 무료 충전 플랫폼을 사용했습니다
도구 목록
프로토 타입의 설계 및 개발 프로세스는 미국 디지털 서비스 플레이 북에 요약 된 많은 표준을 따랐습니다. 우리는 Github에 대한 자세한 문서를 제공하여 증거와 연결되어 있으며 각 항목에 대한 응답을 제공했습니다.
미국 디지털 서비스 플레이 북 응답
