ca-api-deliverables.md

5. SCOPE OF SERVICES 5.1. The Contractor shall provide the following services and artifacts for the development of the Intake module. Sprint Zero Artifacts 5.2. The Contractor shall produce, review and gain agreement from the State for all Sprint Zero artifacts prior to commencing delivery sprints. 5.3. The Contractor shall produce a User Story Definition and Acceptance Criteria Format. 5.4. The Contractor shall produce Coding Standards (including style guidelines) and Commenting Standards, including Peer Review checklist. 5.5. The Contractor shall produce a Sprint-level Definition of Done that includes the following concepts: a. Code produced (all ‘to do’ items in code completed) b. Code commented, checked in and run against current mainline version in source control c. Peer reviewed (or produced with pair programming) and meeting development standards d. Builds without errors e. Unit tests written and passing f. Deployed to system test environment and passed system tests g. Passed Product Owner Acceptance Testing h. Any build/deployment/configuration changes implemented/documented/communicated i. Relevant documentation produced/updated (e.g., user needs, user stories, sketches, wireframes, clickable prototypes) j. Remaining hours for task set to zero and task closed State of California Solicitation RFP OSI 31801 12/21/2015 6:12 PM p. 185 State of California RFP OSI 31801 Office of Systems Integration Statement of Work December 21, 2015 4 5.6. The Contractor shall produce a Release-level Definition of Done that includes the following concepts: a. Release Notes Prepared b. Deployed to staging environment and integration, performance and load tests run c. Relevant documentation/diagrams produced and/or updated Sprint Planning and Execution 5.7. The Contractor shall use an Agile Sprint Planning and User Story Approval process for each Sprint. The Agile Sprint Planning process includes the following activities: Product Backlog refinement, user story creation, estimation and commitment. 5.8. The Contractor shall demonstrate that each user story has met the definition of done so that the State Product Owner can approve each user story as it is completed. 5.9. The Contractor shall utilize scrum-based agile processes (e.g., user story development, Product Backlog maintenance, user story user-acceptance, Sprint Retrospective, and Product Review). 5.10. The Contractor shall revise Sprint Zero artifacts during each Sprint Retrospective process, as appropriate. 5.11. The Contractor shall generate documentation within the code itself and within the version control system (e.g., through proper use of descriptive commit messages, issue tracking, pull requests, etc.). 5.12. The Contractor shall use Pivotal Tracker to manage the product backlog, user story acceptance, and maintain a scrum board. 5.13. The Contractor shall use Slack as the primary mechanism for project-related communication and real-time messaging, archiving and search for all project teams. 5.14. The Contractor shall provide a report at the conclusion of each sprint that documents the planned user stories, accepted user stories, open impediments, and technical debt. State of California Solicitation RFP OSI 31801 12/21/2015 6:12 PM p. 186 State of California RFP OSI 31801 Office of Systems Integration Statement of Work December 21, 2015 5 5.15. The Contractor shall adhere to Twelve-Factor Application design constraints (see http://12factor.net/). Modularity 5.16. The Contractor shall design the application architecture to ensure a separation of concerns and a reasonable degree of modularity between systems. 5.17. The Contractor shall adhere to the DRY (Don’t Repeat Yourself) principle to ensure that the codebase remains flexible. Code Style 5.18. The Contractor shall ensure that all code will be written to a language specific code-style guideline (e.g., PEP8 for Python). 5.19. The Contractor shall use an automated tool to evaluate the codebase and ensure compliance with the codestyle guideline (e.g., if the Contractor uses Python, PyLint may be used). Version Control System 5.20. The Contractor shall manage all assets (e.g., source code, automated tests, user stories, configuration files, knowledge transfer material, etc.) using GitHub. Code Review 5.21. The Contractor shall ensure all code written by one developer is reviewed by another developer before merging into the mainline codebase. 5.22. The Contractor shall follow industry standard code review practices (e.g., http://blog.fogcreek.com/increasedefect-detection-with-our-code-review-checklist-example/). State of California Solicitation RFP OSI 31801 12/21/2015 6:12 PM p. 187 State of California RFP OSI 31801 Office of Systems Integration Statement of Work December 21, 2015 6 Automated Testing 5.23. The Contractor shall create and execute automated unit testing. 5.24. The Contractor shall create and execute automated system tests to verify all Features of the software module. 5.25. The Contractor shall create and execute automated Product Owner Acceptance testing to verify all user facing functionality. 5.26. The Contractor shall run tests automatically on code merge into version control. 5.27. The Contractor shall use an automated tool that measures the amount of the codebase that is covered by tests (e.g., RCov may be used to measure test coverage of Ruby code). 5.28. The Contractor shall create and execute automated integration testing with other contractor developed modules. 5.29. The Contractor shall make the bugs identified during testing available to view real-time and on a historical basis. Load Tests 5.30. The Contractor shall create and execute load and performance tests at regular intervals, and at each release. 5.31. The Contractor shall provide a summary of all load and performance test results. Accessibility 5.32. The Contractor shall incorporate and test accessibility throughout the design and development processes (see section 508 Amendment to the Rehabilitation Act of 1973). 5.33. The Contractor shall use an automated accessibility testing tool (e.g., Pa11y). State of California Solicitation RFP OSI 31801 12/21/2015 6:12 PM p. 188 State of California RFP OSI 31801 Office of Systems Integration Statement of Work December 21, 2015 7 Issue Tracking 5.34. The Contractor shall use GitHub to keep track of all bugs and application issues. Mobile Friendly 5.35. The Contractor shall design the User Interface (UI) using responsive design. Logging and Monitoring 5.36. The Contractor shall implement centralized and continuous monitoring. 5.37. The Contractor shall implement centralized system logging. 5.38. The Contractor shall implement auditing. Security 5.39. The Contractor shall use an automated black/white box security scanning tool (e.g., HP Fortify, or https://hakiri.io) to ensure a minimal baseline of security at regular intervals, and at each release. 5.40. The Contractor shall provide the results of the security scans to the State. 5.41. The Contractor must adhere to the HTTPS-Only Standard as outlined in https://https.cio.gov/. 5.42. The Contractor shall adhere to the baseline moderate tailored NIST 800-53 (see Attachment). 5.43. The Contractor shall ensure adequate security controls using penetration testing, red teaming, etc. State of California Solicitation RFP OSI 31801 12/21/2015 6:12 PM p. 189 State of California RFP OSI 31801 Office of Systems Integration Statement of Work December 21, 2015 8 User Authentication 5.44. The Contractor shall ensure that Intake user authentication and authorization is integrated with the State’s authentication platform. Build and Deployment 5.45. The Contractor shall provide continuous integration of source code into the source code version control system. 5.46. The Contractor shall use a continuous source code build tool that enables continuous deployment of all applications into testing and staging environments. 5.47. The Contractor shall include mock test data that should be publicly accessible for development by other module Contractors and not include personally identifiable information (PII). 5.48. The Contractor shall use at least one of the following methods to deploy code changes to a staging environment under the control of the Contractor with the issuance of a single command: d. Containerization (e.g., Docker Engine, Rkt, and Warden) e. Configuration Management tools (e.g., Chef, Puppet, Salt, and Ansible) 5.49. The Contractor shall submit server images to State using a Deployment/Release tool at the conclusion of each sprint and upon major releases. 5.50. The Contractor shall deploy builds to the testing, staging and production environments that will be provided by the State.