Project Name System Functional Review SFR Software Section

Project Name System Functional Review (SFR) Software Section Date of Review Name Organization Job Title Phone # E-mail

Overview p p p p Software Development team Integrated Mater Schedule (IMS) Highlighted with Software Milestones Software Entrance Criteria Software Development Strategy Software Development Process Requirements Analysis and Allocation Methodology System Specifications Tree Contract Data Requirements List (CDRL) Safety, Information Assurance and Security Requirements Software Supplier Management Software Measurement Software Risk Assessment with Mitigation Strategies Issues and Concerns 12/10/2007 System functional Review (SFR) 2

Software Development Team p p Include Contractor and Government personnel. Show the Government counterpart to the Contractor key software leadership. 12/10/2007 System functional Review (SFR) 3

Integrated Master Schedule (IMS) Highlighted with Software Milestones p p p Show a graphical representation of the IMS highlighting the software milestones. * Show all dates critical to the software team, such as test periods, integration dates, when hardware prototypes will be available, laboratory completion dates, etc. Include Non-Advocate Review dates and CMMI appraisal dates. *If an incremental development implementation method is employed provide software milestones for each increment. 12/10/2007 System functional Review (SFR) 4

Software Entrance Criteria p p List the SETR Handbook entrance criteria applicable to the software. Show which criteria have been meet (green) and which criteria is yellow, red, or not applicable. n For those not met indicate when the will be met or if the Government has concurred and accepts that risk. 12/10/2007 System functional Review (SFR) 5

Requirements Analysis and Allocation Methodology p p List the documents to be incorporated into the requirements tools with minimum of tracing CDP to SSS to SRS (or SRD) to SDD to Test Plan to Test Procedures and a goal of including the interface documents. Functionally describe each software unit and/or CSCI and identify the software requirements specifications (Sw. RS) allocated to it based on the proposed system solution. 12/10/2007 System functional Review (SFR) 6

System Specifications Tree p Show system specification tree highlighting all software related documentation. n Include documentation from legacy programs and subcontractors. 12/10/2007 System functional Review (SFR) 7

Contract Data Requirements List (CDRL) p Provide complete list of CDRL in relations to the SETR reviews. * n Preference is to use the documentation nomenclature from ISO/EIA 12207. 1. *If an incremental software developmental strategy is implemented, the expectation is there will be a new or updated version of all CDRL associated with that increment. 12/10/2007 System functional Review (SFR) 8

Software Supplier Management p Software Process, Programmatic Requirements Flowed Down Via SOWs. n n SETR, CMMI, ISO/EIA 12207, DO-178 B, Software Security Requirements etc. Measurement Report Template, Formal Review Templates p n Added Per Increment 1 Lessons Learned Deliverables, Etc. p Software Supplier Compliance and Performance Management (SSCPM) n Distinct Function Within Software Organization p n Level of Oversight Determined by Multiple Factors p p p 12/10/2007 Do Prime Software Acquisition Managers have proper training? System functional Review (SFR) Type, Size of Development Effort If COTS, amount of new, unmodified reused DO-178 B Safety Level CMMI Capability of Supplier Assessment of Risk Others 9

Software Development Strategy p Describe the Software Development Strategy including any updates since SRR. * n Include the status of the Software Development Plan. *If incremental Show incremental plan including resource planning, i. e. staff, lab, aircraft. p Show the preliminary capabilities that will be provided by each increment. p 12/10/2007 System functional Review (SFR) 10

Software Development Process p Show the software development process including any updates since SRR. n n n Identify preliminary set of development tools and show where & how they are used during the development process. Include Quality Assurance, Configuration Control (including Change Control), and Requirements Management. Show the estimates for size, cost, and schedule were developed. p p 12/10/2007 Show Equivalent Source Lines of Code (ESLOC) is calculated for all suppliers, including subs. Show growth was planned in. System functional Review (SFR) 11

Safety, Information Assurance and Security Requirements p p Describe how safety, Information Assurance (IA), and security requirements will be addressed. Include Hazard Analyses, Accreditation, and standards being followed. 12/10/2007 System functional Review (SFR) 12

Software Measurement p Describe the Measurement Process including any updates since SRR, showing which measurements are used internally and which are sent to Government. n p For all functional areas/subsystems/configuration items list the measures to be developed and the periodicity. The next 5 slides define the set of software measures that should be considered for presentation at all major system and software reviews. 12/10/2007 System functional Review (SFR) 13

Measures p Software Size n p Software size is tracked with the source lines of code (SLOC), Equivalent SLOC (ESLOC), or function points indicators n Total planned size by language and type (new, unmodified reused, and deleted) n Total actual SLOC by language and type (new, unmodified reused, and deleted) 12/10/2007 Development Progress Profile n Development progress is tracked as a percentage complete of work n This measure tracks the progress made against initial plans and tracked against builds, preferably as a function of requirements completed n The measure tracks planned and actual work for the software requirements, software design, software implementation, and software test development activities System functional Review (SFR) 14

Measures p Computer Resource Utilization (CRU) Indicators n CRU indicators show percentage of resource utilization at present and the estimate at completion n The memory utilization measure tracks the percentage of the target computer memory resources used n The throughput utilization measures tracks the percentage of the target computer throughput or CPU used during worst case loading conditions n The Channel Utilization measure tracks the percentage of the target system channel and/or bus resources used 12/10/2007 p Build Release Indicators n The build plan measure report tracks the capability of the software to satisfy the functionality of each scheduled incremental build n Changes to the functionality of an incremental build may be an indicator of potential problems such as requirements growth or schedule slip, particularly if capability is pushed to a subsequent incremental build System functional Review (SFR) 15

Measures p Test Progress Indicators n n n The test progress measure tracks the progress made against initial plans for each formal build and tracked against test efforts leading toward the build for FQT The measure tracks monthly the planned and actual number of test cases completed, the number of test cases retested, the number of requirements tested, and the number of requirements verified The measure will be reported as planned and actual percent complete for each activity 12/10/2007 p Software Defect and Discrepancy Measures n During the test phases starting with software integration test and continuing through system test to ground and flight test, software discrepancies will be reported to track all problems found during these phases n Discrepancy report (DR) indicators will include number of DRs found and their priority n Discrepancy aging indicators will show by priority how long the discrepancies have been open in months System functional Review (SFR) 16

Measures p Requirements Volatility Indicators n n The requirements volatility measure tracks the total number of software requirements and the number of changes to those requirements p Software Design Volatility Indicators n The software design volatility measure tracks the total number of changes to the design artifacts n The software design volatility indicators to be tracked are: Indicators tracked are: p p 12/10/2007 Current total number of requirements p p Number of changed requirements p Number of added requirements p Planned and actuals (active and closed) cumulative number of changes Number of new software design change requests Cumulative number of open design change requests Number of design change requests open Number of deleted requirements System functional Review (SFR) 17

Measures p Software Staffing n n p The software staffing measure compares the monthly planned and actual staffing levels of a job to determine if there are sufficient personnel for completion of the program The software staffing indicators are: p p p 12/10/2007 Software Productivity n The Software Productivity will document the number of source lines of code per day for each configuration item n The productivity indicators will show planned (based on historical data) versus actual productivity over time Number of planned and actual software personnel Number of planned and unplanned software personnel losses Cumulative number of unplanned software personnel losses System functional Review (SFR) 18

Risk Assessment with Mitigation Strategies p p Use the standard Risk Cube. For “red” and “yellow” risks, show the mitigation plan. n Mitigation plan should show for each step the owner, completion date, and the resulting consequencelikelihood value for the completed mitigation step. 12/10/2007 System functional Review (SFR) 19

Issues and Concerns p This section should list any issues and concerns that do not qualify as a risk and that require the attention of the Government or Contractor Leadership. n n n List the issue or concern and the expected outcome. List the consequence should there be no action. Provide a need date for resolution. 12/10/2007 System functional Review (SFR) 20