This readme.md file presents the communication of our project approach including the technical approach within a 2,000 word limit.

OUR RESULTS

[Read Our User Guide](TrinityTG-Prototype-User Guide-Thunderstruck .pdf).

Run the Prototype (codename Thunderstruck). This application allows California residents to receive emergency and non-emergency emails and SMS notifications from several identified sources. This application is geo-location aware, provides administrators to ability publish, track, analyze, and visualize related data. Full Requirements

OUR PROJECT APPROACH

The project approach was driven by a very compressed schedule with two distinct tracks of requirements

1. Responding to the Response for Inquiry (RFI) Requirement's administrative/Submission requirements

2. Building working open-source software using an Agile/iterative approach based on the Digital Services Playbook.

Responding to the RFI

Using TrinityTG's proven approach, the team managed the RFI response by tracking the state procurement site and monitoring the procurement GitHub site while breaking down the RFI so we could build-up our response. As our proposal team focused on the RFI response, our Director of Business Development led the resolution of requirement #2 as the Product Manager (play 6). Responding to the RFI is not documented beyond this brief description.

Building Working Software

We also turned to our proven approach to manage the software build. This included assembling our highly-qualified team and building our project playbook. Our Enterprise Agile Coach worked with the Product Manager (aka Product Owner) and the Delivery Manager (aka Scrum Master) to layout an Agile based project playbook that included a dedicated working area in our Sacramento office for the team to co-locate and collaborate. This playbook resulted in the software build described in our technical approach below. In this project approach section, we focus on the details that do not clearly fit within the "a. through t." punch list below.

Given the theoretical nature the engagement, we made many assumptions that are documented here. Our experienced multidisciplinary team (play 7) has over 250,000 hours delivering technical solutions to real people (play 1) in a primarily iterative manner (play 4). Our Enterprise Agile Coach raised the agility of the team (play 4) to complete the build iteration steps detailed in J. below. Also given the prototype project scope, timeline and staffing, budgets (play 5) and security (play 11) were not a factor in our project. We understood the emphasis was to quickly move through multiple, very short sprint/iterations to demonstrate our understanding of the process.

Given our proxy user base, the team identified and overcame the problem of how to focus on user centric design (play 1, play 2, and play 3). This difficulty was eased by using personas to simuluate or user community and to serve as the basis for our product manager to develop the user stories. This approach paid dividends when our proxy users studied their personas and 'got into character' for design, testing and training efforts.

Given our team's extensive experience with open-source tools, when the goal was to "default to open (play 13)", we were able to integrate nearly three times as many open-source tools than required by the RFI.

Evidence.

The evidence of our team's Agile process is documented within GitHub. This evidence includes our artifacts from our open-source Agile management tool "tree.taiga.io", "Action Shots" of the team during our Agile ceremonies and collaboration sessions, and many "screen prints" of code, smartphone photos of white boards as well as other more traditional documentation. The digital assets necessary to deploy and continue enhnancing this project are also available on GitHub.

OUR TECHNICAL APPROACH

a. Assigned one (1) leader and gave that person authority and responsibility and held that person accountable for the quality of the prototype submitted.

Using the Digital Services Playbook - Play 6 as a guide, we identified Jeremy Dean, Director of Business Development as our Product Manager.

b. Assembled a multidisciplinary and collaborative team that includes, at a minimum, five (5) of the labor categories as identified in Attachment B: PQVP DS-AD Labor Category Descriptions

Product Manager: Jeremy Dean
Delivery Manager: Michael Tomlin
Technical Architect: Shawn Sampo, Member, Open Source Initiate
Interaction Designer/User Researchers: Kelly Phan, Camille Dyer
Visual Designer: Kelly Phan
Back End Developer: Sam Ellis, Member, Open Source Initiate
Front End Developer: Shawn Sampo, Member, Open Source Initiate
Back End Developer (GIS): Charan Misha, Member, Open Source Initiate
Dev Ops Engineer: Sam Ellis, Member, Open Source Initiate
Quality Assurance: Camille Dyer
Agile Coach: Hiren Vashi, Agile related certifications Include: Scaled Agile Framework (SAFe®) Program Consultant 4.0 (SPC4), Certified Scrum Professional (CSP), Certified Scrum Master (CSM), PMI-Agile Certified Practitioner (PMI-ACP).

c. Understood what people needed, by including people in the prototype development and design process;

Using the Digital Services Playbook - Play 1 as a guide, we worked with available resources as both proxy and 'real' users as we developed user personas, user stories and user tested prototypes. The design process also included building wireframes and user survey's before and during the prototype development.

d. Used at least a minimum of three (3) “user-centric design” techniques and/or tools; (play 1, play 2, and play 3)

1. The initial user-centric design approach we used was to Follow the USDS Playbook published by the USDS.

We integrated the playbook into our trello boards for checklists/key questions to facilitate team access. Using the The Digital Services Playbook, our team managed the work in progress, including adding the detailed checklists. Evidence of completed checklist. This included completing Market Research.

2. The second user centric design approach included developing personas.

This user-centric approach summarized our target audience for product development. We further emphasised the personas to make sure our persona portraits were displayed in the team development area. This approach prompted our proxy users 'got into character' for design.

3. The third user-centric approach was using user stories as a basis for our design.

We used the open-source tree.taiga.io to manager our user stories, sprints and feedback at the core of our agile development process Screen Image through completion.

4. The fourth user centric design approach we followed was building wireframes.

This allowed our team to quickly have our users visualize and course correct our requirements and UX design.

5. The fifth user centric approach was a brainstorming exercise to develop scenarios:

We used each persona as the main character of his/her story. We developed a story around specific of the events that relate to the need of receiving notification by each persona. We developed a simple story about the daily life of an individual persona and included emotional and physical characteristics. We made some assumptions and also created a social context in which the persona exists.

e. Used GitHub to document code commits;

We used GitHub to document our code commits. The GitHub repository is here. An example of the commits can be found here: GitHub Screen Shot

f. Used Swagger to document the RESTful API, and provided a link to the Swagger API;

Our team used Swagger to document the RESTful API. Swagger Live Link(http://avp2017webapp.azurewebsites.net/swagger/index.html), GitHub Image link.

g. Complied with Section 508 of the Americans with Disabilities Act and WCAG 2.0;

We completed overall accessible testing to meet Section 508 of the Americans with Disabilities Act and WCAG 2.0.The results

h. Created or used a design style guide and/or a pattern library;

We created and used a design style guide. Link

i. Performed usability tests with people;

Our residents test users performed usability testing. In addition to our users outside the project team, we also solicited volunteers from outside the team to perform additional user testing. Our focus was to identify 'real' users that we associated with our personas to make sure we could trace user stories to completion. We completed a survey to campture resutls. Results

j. Used an iterative approach, where feedback informed subsequent work or versions of the prototype;

The iterative development approach was 'baked into' our Agile methodology guided by our resident Enterprise Agile Coach (Hiren)

1. At the beginning of the project, the team set up the facilities including the collaborative work area, gathered supplies, selected the tools, and configured the architecture.
2. Set up team collaboration site in tree.taiga.io with the product backlog used to guide the development team
3. Periodically product owner and development team groomed product backlog (used Planning Poker)
4. At the beginning of each sprint, we identified the sprint goal and the sprint backlog during sprint planning meeting
5. Held daily scrum meetings at the same time and place with visibility of the Kanban task board. image
6. Team co-location with visible persona's with clearly identified roles and sprint goals Images
7. Our Sprint Demos served as multiple versions of the prototype and allowed us to gather feedback from Product Owner and proxy users based on personas.
8. Sprint Retrospectives to help course correct the process
   ###k. Created a prototype that works on multiple devices, and presents a responsive design;
   Our prototype works on multiple devices and presents a responsive design. We tested our site on an iPad, PC based laptop, PC based tablet, Mac based Laptop and an Android Phone. This is evidenced by the following images links ###l. Used at least five (5) modern and open-source technologies, regardless of architectural layer (frontend, backend, etc.);
   List of Open-Source Software
9. .NET Core https://docs.microsoft.com/en-us/dotnet/articles/core/
10. MySQL https://www.mysql.com/
11. Angular.js https://angularjs.org/
12. Bootstrap http://getbootstrap.com/
13. JQuery https://jquery.com/
14. Report.js http://bi-joe.github.io/report.js/
15. JWT (we conform to an standard, but used no library to implement this)
16. MySqlConnector https://github.com/mysql-net/MySqlConnector
17. tree.tiaga.io - project management - http://tree.taiga.io
18. xUnit for unit testing - https://github.com/xunit/xunit
19. Docker https://aws.amazon.com/docker/

m. Deployed the prototype on an Infrastructure as a Service (IaaS) or Platform as Service (PaaS) provider, and indicated which provider they used;

We deployed the prototype on an Azure Platform as Service (PaaS) provided by Microsoft. The screen images below are presented as our evidence

n. Developed automated unit tests for their code;

Automated unit tests are developed to validate the return types and verify that the controllers return what is expected. An example of unit test outputs link.
An example of our embedded unit test for sprint 1 link

o. Setup or used a continuous integration system to automate the running of tests and continuously deployed their code to their IaaS or PaaS provider;

Visual Studio’s test framework was combined with xUnit, and open source testing platform for automate Unit and Integration testing. Unit testing is handled through test scripts and cases written with xUnit and integration testing is performed using Visual Studio’s built in browser driver. All test cases are run automatically when the project is built. Evidence

p. Setup or used configuration management;

We used the built-in configuration management tools within .net core and the Azure hosting environment. Evidence

q. Setup or used continuous monitoring;

We Setup and use continuous monitoring. Heartbeat tests conducted via Azure Application Insights. Tests are run every 5 minutes, email alerts are sent for each failure to the administrators. Evidence

r. Deployed the software in an open-source container, such as Docker (i.e., utilized operating-system-level virtualization);

We have deployed our software in an open-source Docker container. The Docker Instructions here assume that you already have .NET Core 1.0.1, Git, a local MySQL DB using the [script](https://github.com/sellisttg/AVP/blob/master/AVP GitHub docs/Setup-script-for-local-db-AVP2017DB.sql), and Docker clients installed. We have included a "starter" file link that would require the users credentials. The TrinityTG credentials used in our prototype appsettings.json file has been redacted from the public repository as a security precaution.

s. Provided sufficient documentation to install and run their prototype on another machine

This prototype application is depoyed as a web application that only requires a browser to access. No locally installed software is needed. The server based installation and development assets are covered under r. above. The application url is http://avpwebappui.azurewebsites.net/thunderstruck.html.

t. Prototype and underlying platforms used to create and run the prototype are openly licensed and free of charge.

In addition to each individual open-source license associated with item l. above, TrinityTG's prototype open-source license is here