!""#!$%&'(#)$*+,(-*(.&%/# &0*$1!"#$%&'(%)*$+ :%;$)*%<&%6!"#$%&'$()%$*+,-./**/%./+ 4.7&68'9"/6")& 0)1.%$2.3*%./'4"55*)6,&+-%$+./!"#$%& '($)*++,-.*%+-$%+ 2",-.*%+-$%+ 3%4567-%8 '*(9$(.4%)*":" ;-+<!"!"#$%&'%() *&+%,-)./011%$#2&3) 4)5%"%$&3)672&80"9 :)5$%&,%$)/&;,- :!",%$"&80"&3) <%&(%$'=2;!"#$%&##'()*+&## / 01+-%*++ '($)*++,-.*%+-$% Figure 1: Five OSP Dimensions 3. Requirements 3.1 Execute Scrum Sprints The contractor will execute a system development activity following the Scrum Systems Development Methodology. To reduce project risk, the contractor will comply with the following practices. 1. Scrum Master The Scrum Team will be lead by a Certified Scrum Master (CSM). 2. Dedicated Development Team The Scrum Team will be fully dedicated to the project. Team members will be expected to be fully committed (i.e., 100% of their time should be allocated to working down the Product Backlog). 3. Receive Guidance from the Product Owner The Scrum Team will work with the Product Owner, who will be only person authorized to change priority order on the Product Backlog. 4. Best Practices The contractor will perform the work following industry best practices as specified by the Scrum Alliance. Specific examples of this guidance include, but are not limited to, the Scrum Manifesto and the Scrum Papers. ***Each sprint will last four (4) calendar weeks and include activities to accomplish the tasks identified in section 4 of this SOW. 3.2 Standards and COTS The contractor will develop the system using the ASKME standards for software and design. In addition, integration with COTS products such as, but not limited to, SQL SERVER 2008, Microsoft IIS, Microsoft Internet Explore version 8, WebFocus for reporting, and pre-determined tools for Root Cause Analysis, Help Content Authoring, and Spell Checking, as outlined in ASKME services documentation, to be provided upon acceptance of this effort. 3.3 Earned Value Management (EVM) The ASKME MPR standard includes requirements to deliver data supporting Earned Value Management (EVM) roll-up for OSP activities defined in the ASKME EVM Plan. EVM data will Statement of Work!"#$"%& Date printed: 4/21/2011
be correlated to the ASKME WBS and acquisition milestones with progress reported for each applicable WBS work item and milestones within. Contractor may propose adjustments in format and details to conform to SCRUM and Agile best practices, or to achieve product and/or Sprint objectives, with explicit approval of the TOR and documented rationale and risk/impact assessments of changes. All such changes are subject to review and further elaboration as required by ASKME Services Management or other applicable Standards or Review groups as deemed necessary by the TOR. 4. Tasks This section defines the requirements in terms of tasks to be performed, the end results/deliverables to be achieved, and the schedule of key dates. 4.1 Project Management Plan (PMP) The contractor will draft a detailed project management plan (PMP) within two weeks of the project start date. This plan will specify project deliverables, schedules for project milestones and monthly reports, and the contractor project team. The PMP will be considered final (i.e., serve as this project s baseline) upon approval of the FAA or one week after the draft is delivered if no response is provided. Interviews with FAA staff will be scheduled and conducted on-site at the contractor when possible. The specific plan for Information System User Group (ISUG) meetings and interviews shall be determined between the contractor and OSP project managers. 4.2 Sprint Management and Performance Reporting The contractor shall provide sprint Monthly Performance Reports (MPRs) following the ASKME MPR standard format as defined In Section 10 of this document. Additional Sprint Metrics that will need to be reported against include: Product Backlog The contractor will maintain the OSP Product Backlog using a project management tool compatible with the Scrum methodology. The tool must allow the Project Owner to adjust story priority, Scrum Team to assign story points, track backlog burn down and provide on-line visibility via the internet. End of Sprint Reporting will include the Product backlog at the beginning and end of each sprint. Sprint Backlog The contractor will maintain the Sprint Backlog using a project management tool compatible with the Scrum methodology. The Sprint backlog will be developed according to best practice at the beginning of each sprint. The tool must allow the Project Owner to monitor task assignments, effort and burn-down via the internet. End of Sprint Reporting will include the entire Sprint Backlog completed stories and incomplete stories. Sprint Burn-down The contractor will provide internet access to the current Sprint Burn-down Chart. End of Sprint Reporting will include a copy of the final chart. Sprint Velocity Statement of Work '"#$"%& Date printed: 4/21/2011
End of Sprint Reporting will include a history of Sprint Velocity for all Sprints completed to date for the OSP project. This report will also include the actual cost to perform the corresponding sprint. Sprint Review At the conclusion of each sprint, the Scrum Team, Scrum Master, Product Owner and Stakeholders will engage in a Sprint Review. Essential elements of the review will include: Demonstration, Retrospective and Planning. Formal Notes will be prepared for each Sprint Review. 4.3 Develop Application Software The contractor will provide a dedicated Scrum Team and Scrum Master to deliver a scheduled level of effort performing software development and system integration tasks. The Scrum Team will draw assignments from the current sprint Backlog. Development will be done in compliance with AVS technology standards including SQL Server 2008, MS IIS and MS IE8. The contractor will employ ASKME web services as provided by the OSP project manager. Development will be done in compliance with FAA branding standards and Section 508 requirements. ASKME application standard templates, as provided by the OSP project manager, will be incorporated into all developed components and modules, as required. The contractor will ensure each developed component complies with the design and can be attributed back to the originating requirements as defined in (redacted). 4.3.1 Configuration Management The contractor will establish a code library to maintain positive control of the application code set. Each recorded software module will include references to the relevant sprint, story, requirement and developer. 4.3.2 Sprint Backlog The Scrum Team will maintain timely records of the level of effort committed to each story on the Sprint Backlog. 4.3.3 Documentation The contractor will provide timely updates to system documentation including modifications to the System Design Document reflecting the As Built design. All such documentation will be completed during the sprint when the software module was written or modified. A story can be considered complete only when the software module documentation is completed. The set of applicable documentation will include the: 1. As Built System Design Document (ICD), 2. Interface Control Document (ICD) reflects any applicable service calls, implemented service call methods, and deployment/installation guidance, and 3. Supporting User Guide documentation that will facilitate efficient development of the User Manual and Administration Guide. 4.4 Detailed System Design The contractor will develop detailed system designs incrementally. Each design activity will be attributed to a single story selected from the Product Backlog. A complete design will include Statement of Work ("#$"%& Date printed: 4/21/2011
documentation referencing detailed system design and system interfaces (as referenced in the Interface Control Document). 4.4.1 Product Backlog The contractor will select stories for detailed design from the OSP Product Backlog. Prioritization for design will be based on the priority order reflected in the Product Backlog. 4.4.2 Detailed Design Detailed designs must be in compliance with the AVS Enterprise Architecture, Technology Standards, and ASKME Enterprise Architecture. 4.4.3 Change Control The contractor will work closely with the OSP ISUG to ensure requirement and other design changes are evaluated and evaluated using a managed change control process. The OSP Product Owner is the only person authorized to approve changes to the Product Backlog. 4.5 Software Test & Acceptance The contractor will ensure each developed component complies with the design and can be attributed back to the originating requirements as defined in the ASKME OSP FRD and the Requirements Traceability Matrix. 4.5.1 Test & Evaluation Planning The contractor will plan and perform testing per the TEMP to assure each developed module is validated and delivers the allocated functionality. 4.5.2 Test & Analysis Reporting The contractor will document the results of each component level test and acceptance test. The results will be documented in the Test and Analysis Report (TAR) for each User Story. 4.5.3 Test Cases and Scripts Test case scripts and results will be retained for validation and regression testing. 4.5.4 Software Demonstration At the conclusion of each sprint, the contractor will demonstrate all completed user stories to the OSP ISUG for validation and acceptance. The contractor will be responsible for demonstrating new functionality within the test environment established for the application. The results of the demonstration can include two outcomes: (1) List of Corrective Actions, and (2) Approval for Production Release. Corrective actions will result in the contractor resolving the issues and may include returning the applicable User Story to the product backlog. 4.6 Build/Deploy Production Software Packages If, at the completion of the Sprint Software Demonstration, the Product Owner approves the release for installation to the production environment, the contractor will build the install package for software delivery to the AVS Enterprise Data Center in Oklahoma City, OK. The contractor Statement of Work )"#$"%& Date printed: 4/21/2011
will work with the AQS-230 OSP PM and AQS-250 Application Data Services staff to submit the package and validate installation. 5. Period of Performance [INITIATION AND PERformance Period Redacted at at request of management] 6. References 6.1 Applicable References for the Tasks OSP Documentation will be provided to the contractor as needed and when available. 6.2 AVS SDLC Overview AVS System Development Life Cycle (SDLC) methodology establishes procedures, practices, and guidelines governing the concept development; planning; requirements analysis; design; development; integration and test; implementation; and operations, maintenance and disposition of information systems within AVS. It should be used in conjunction with existing policy and guidelines for acquisition and procurement, as these areas are not discussed in the SDLC. The SDLC includes a total of nine phases during which defined project work products are created or modified. The ninth phase occurs when the system is disposed of and the task performed by the system is either eliminated or transferred to other systems. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap. The contractor shall provide all deliverables for this effort as they are described and documented in the AQS-200-001-WI SDLC. Access to or full documents for all references will be provided to the contractor, as needed. The TOR will reference the documents listed below for acceptance of deliverables for this task.! AQS-200-001-WI, System Development Life Cycle! AQS-200-001, Design & Development Control! AQS-200-001-WI4, Program/Project Management Plan (PMP) Development and Maintenance Work Instruction! FAA Data Architecture, latest version! AQS-200-003 AQS-200 IT Technical Standards! AQS-240-002-WI, SMS Notification and Deployment! AQS-250-004, Transitioning Applications to Operations! AVS Information Systems Security Protection: Requirements, Practices, and Procedures! AQS-200 Configuration Management Plan! AQS-200 Quality Assurance Plan! DOT, FAA, and AVS Orders such as the Privacy Policies and AVS Rules of System Use! AVS Architecture Guideline (the scope & purpose of this document needs to be referenced)! FAA Order 1370.93 - FAA Web Management! FAA Order 1700.6C - FAA Branding Policy, Use of the FAA Logo, FAA! Signature and DOT Seal Statement of Work *"#$"%& Date printed: 4/21/2011
! Security controls, NIST SP 800-53, SA-8 references Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A (NIST SP 800-27) located at csrc.nist.gov/publications/nistpubs/800-27a/sp800-27-reva.pdf 7. Personnel The government must be notified two weeks in advance of a change in key personnel and the resume of the new individual working on the project must be sent to the IT Program Manager for the Government s approval. Essential Personnel for this effort: Certified Scrum Master (CSM) System Architect (minimum 10 years experience) 8. Place of Performance The majority of work performed under this task shall be performed at the Contractor s site. However, some activities may need to be performed at the FAA headquarters building and field sites. Additional travel needs to be identified and added during this task. 9. Travel Travel may be required for these efforts. Local travel expenses are not reimbursable from the Government. 10. Deliverables and Reporting The Contractor shall submit deliverables according to the schedule agreed to by the Government. The Contractor shall report on scope, schedule, and resources using the ASKME Work Breakdown Structure (WBS) defined in the table below. Prior to work commencing, a reporting methodology will be agreed upon between the Contractor and the Government. Planned values for the design and program management documentation will need to be agreed upon by the Government and the contractor. Planned story points for each sprint will need to be agreed upon by the Government and the contractor. Deliverables:! Sprint progress Report will show on a monthly basis, the progress completed against the work planned for the most recent Sprint completed.! The Contractor shall provide documentation versions of both hard copies and electronic copies for each deliverable.! The Government COTR will approve delivery of completed documents at the end of each sprint to include, but not limited to: System Design Document, Requirements Traceability Matrix, and the Program Management Plan. The following table will form the basis for the Monthly Progress Report (MPR) along with notes detailing overall project status, issues/opportunities uncovered or encountered during the reporting period. Progress should be reported against each WBS in the table, with the exception of the items designated as Government FTE. The response to this SOW should Statement of Work!"#$"%& Date printed: 4/21/2011