1. Software Acquisition Management Policy ImplementationCME260 Lesson 1 - Defense Acquisition Management System Lesson 2 - Software Development Life-cycle Lesson 3 - Software Surveillance Process Lesson 4 - Common DCMA Software Professional (SP) Activities

2. John Eget 646 872 1929 Welcome – Instructor Introduction

3. Administrative Details Classroom Logistics: • Emergency exits • Restrooms and break rooms • Telephones and cell phones • Computer usage • Turning Point • Parking lot • Breaks and lunch

4. Administrative Remarks • Grading and tests: 80 percent is required to pass posttest • Attendance: participation is required for this training • During training, the Instructors are your onsite supervisors • PLAS codes: • Process: 071B – Software Professional Development Program (SPDP) Training • Training and Travel: NTRA2 – Travel for Training NTR04 – Attend Classroom Training • Monday through Friday: 0800 – 1700 hours Note: Plan your departure time accordingly; no early departures on last day unless told otherwise.

5. SPDP Certification

6. Module 1Software Development Life-cycle Objective: Provide information that Software Professionals (SPs) need during each phase of the Software Life-cycle and Defense Contract Management Agency (DCMA) activities

7. Module Objective Provide information that Software Professionals (SPs) need during each phase of the Software Life-cycle and Defense Contract Management Agency (DCMA) activities, including: • Elements of the Defense Acquisition Management System • Software Development Life-cycle • Software Surveillance Process • Common DCMA SP activities

8. What Will You Learn in This Module? • Acquisition framework • Timing of technical reviews • Software life-cycle products, processes, events (refresher) • Potential DCMA activities • Process Reviews • Process Proofing • Process Compliance • Product Examinations • Data Collection and Analysis

9. Lesson 1 Defense Acquisition Management System Objective: Recognize elements of the Defense Acquisition Management System

10. Lesson Objective • Recognize elements of the Defense Acquisition Management System

11. Defense Acquisition Management System Link to: Defense Acquisition Portal Material Material Note: Software development can occur in any acquisition phase, but is primarily in Engineering and Manufacturing Development.

12. Defense Acquisition Management System, Cont. Link to: Integrated Defense AT and L Life-cycle Management System Material Material Note: Software development can occur in any acquisition phase, but is primarily in Engineering and Manufacturing Development.

13. Question and Answer Software development can occur in any acquisition phase. • True • False

14. Lesson Summary • Recognized elements of the Defense Acquisition Management System

15. Lesson 2Software Development Life-cycle Objective: Identify some aspects of the Software Development Life-cycle

16. Lesson Objective • Identify some aspects of the Software Development Life-cycle

17. Software Life-cycle V Diagram FCA - -

18. Acquisition Life-cycle and Software Development Link to: Defense Acquisition Guidebook (DAG) Material Material Note: Software development can occur in any acquisition phase, but is primarily in Engineering and Manufacturing Development.

19. Systems Engineering/Technical Review Timing Link to: Defense Acquisition Guidebook (DAG) Link to: Technical Review Timing Review FCA – Functional Configuration Audit AOTR – Assessment of Operation Test Readiness ASR – Alternative System Review CDR – Critical Design Review FRP – Full Rate Production IBR – Integrated Baseline Review ISR – In-Service Review ITR – Initial Technical Review OTRR – Operational Test Readiness Review PCA – Physical Configuration Audit PDR – Preliminary Design Review PRR – Production Readiness Review SFR – System Functional Review SRR – System Requirements Review SVR – System Verification Review TRA – Technology Readiness Assessment TRR – Test Readiness Review

20. Requirements Traceability • Three Paths: • Interface • Software • Testing

21. Software Waterfall Life-cycle

22. Question and Answer What are the three paths in requirements traceability? • Software, coding, interface • Software, interface, testing • Interface, planning, coding • Design, software, testing

23. Lesson Summary • Identified some aspects of the Software Development Life-cycle

24. Lesson 3Software Surveillance Process Objective: Identify the Software Surveillance Process

25. Lesson Objective • Identify the Software Surveillance Process

26. Software Surveillance Process SSP needs to be updated?

27. Software Surveillance Planning Process Flowchart Overarching Flow

28. Program Measures • Planning for program measures • Core measures, mandatory and defined in the Software Acquisition Management Instruction (SAMI) • Contractually imposed standalone measures • Contractually imposed Technical Performance Measures (TPMs) • Contract Management Office (CMO) unique measures (optional, as determined by the SP) • Customer unique measures • Determine frequency needed and allocated • Determine method of analysis and thresholds • Determine CMO estimated hours per task and activity

29. Program Measures, Cont. • Execution of program measures • Collect and analyze data • Document and report analysis results • Take Action as Appropriate • Corrective Action Reports (CARs) • Continuous Improvement Opportunities (CIOs) • Reporting

30. Question and Answer What are the four steps of the SAMI software surveillance process? • Plan, execute, take action, review • Plan, do, check, act • Use, plan, do, take action • Plan, execute, review, report

31. Lesson Summary • Identified the Software Surveillance Process

32. Lesson 4Common DCMA Software Professional (SP) Activities Objective: List common DCMA SP activities related to software acquisition and surveillance management

33. Lesson Objective • List common DCMA SP activities related to software acquisition and surveillance management

34. DCMA Software Surveillance Execution Activities Execute Surveillance Plan

35. DCMA Software Surveillance Execution Activities, Cont. • Process Review • Process Proofing • Process Compliance • Product Examination • Inspection • Testing • Witness • Verification • Formal Reviews and Audits • Data Collection and Analysis • Accept Product

36. Processes for Review • Phase Dependent • Software Design • Software and System Formal Qualification Testing • Software Delivery • Phase Independent • Software Quality Assurance (SQA) • Risk Management • Software Configuration Management (SCM) • Software Management • Earned Value Management (EVM)

37. Products to Be Examined • Phase Dependent • Requirements (specification) • Requirements Traceability Matrix • Design Products • Code • Test Plans, descriptions,results • Developer files • Peer Review results • User and technical manuals • Phase Independent • Planning documents (e.g., Software Development Plan (SDP), SQA Plan, SCM Plan) • Schedules • Measures (metrics) • Status chart • Supplier SQA and SCM Records • Risk Records • Peer Review results

38. Measures to Be Analyzed • Phase Dependent • TPMs (if applicable) • Requirements stability and volatility • Software size • Requirements Traceability • Design changes • Phase Independent • Earned Value (if applicable) • Staffing profiles • Software development milestone and schedule • Software Quality audit results • Configuration Management, status accounting • Defects (types, closure, quantity) • Technical Progress Measure

39. Documentation The SP uses the Software Surveillance Record (SSR) log • SSR Log attributes: – Task and activity performed – Link to applicable Software Surveillance Plan (SSP), project name, or program PLAS code – Notes – Date performed – Name of SP(s) • Create a standalone document in user format (e.g., email, formal and/or informal report, journal record) containing the detailed results of the task or activity performed • Determine if results indicate that the SSP should be updated

40. Take Action as Appropriate

41. Question and Answer Product examination includes: • Inspection, Compliance, Proofing, Audits • Verification, Proofing, Data Compliance, • Inspection, Testing, Witness, Verification • Witness, Reviews, Verification, Testing

42. SAM Surveillance Steps Note: Documentation occurs at all steps of the Software Acquisition Management (SAM) Surveillance Process (i.e., SSR Log and Standalone Documentation).

43. Measurement and Analysis • Using the software development life-cycle, identify (at least) three software measures for each phase that would provide you with the most insight into program, process and product performance, status, and health

44. Metric Categories Software Measures and the Capability Maturity Model Integration (CMMI)

45. Metric Categories, Cont. Software Measures and the CMMI

46. Sanity Test for Software • Does the supplier have a current, credible Work Breakdown Structure (WBS)? • Does the supplier have a current, credible schedule, such as an Integrated Master Schedule (IMS) or software development schedule? • Does the supplier know what to deliver? • Does the supplier have a list of risks (Top 10, etc.)? If so, what are they? • Does the supplier know which external interfaces are not under its control and what are its critical dependencies? • Does the supplier know the size of the software deliverables? How did the supplier derive it? • Does the supplier know how many people on the project staff have significant domain knowledge? • Does the supplier know the project’s key domain areas?

47. Performance Analysis • Performance analysis determines whether the project is meeting its plans and targets (in terms of cost, schedule, and technical performance) • Look at: • Leading indicators • Compare planned to actual • Assess impact on cost, schedule, technical performance • Predictive analysis (look ahead) to see whether the schedule is going to be impacted or delayed. Is there a potential for cost overruns? • Critical path items to see if software is on the critical path • Analysis of each metric individual to see what additional supporting data may you need. Where is the data leading you?

48. Program Analysis Process Document Analysis Results on DMAR

49. Evaluation Criteria • Contractual requirements • Supplier plans and processes (may or may not be a contractual requirement) • CMMI, Institute of Electrical and Electronics Engineers (IEEE) 12207, etc. (if applicable) Note: If not on contract, you can use the criteria identified in CMMI, IEEE 12207, and the like to use as best practices to evaluate the supplier processes (we will use the CMMI criteria for Workshops).

50. What Is a Capability Model? • It establishes a process improvement road map upon which a route can be drawn from "where we are today" to "where we want to be" • Capability models are not processes • Notthe “how” but the “what” • Can be thought of as containing the characteristics and requirements for good processes