1. University of Southern California Center for Systems and Software Engineering Fall 2014 Barry Boehm, USC Course Overview and ICSM Principle 1 CS 510 Software Management and Economics

2. University of Southern California Center for Systems and Software Engineering © USC-CSSE2 Outline Course objective –Help you learn to be a successful software manager –For a career lasting through the 2050’s. Software management learning objectives –What does a successful SW manager need to deal with? Overview of Course –Programmatics, schedule, academic integrity Current and future software and management challenges ICSM Overview –Principle 1: Stakeholder value-based guidance Enterprise Success Theorem Enterprise Success Realization Theorem This Week’s Assignment 8/25/2014

3. University of Southern California Center for Systems and Software Engineering © USC-CSSE3 What Does A Successful Software Manager Need to Deal With? T 8/25/2014

4. University of Southern California Center for Systems and Software Engineering © USC-CSSE4 What Does A Successful Software Manager Need to Deal With? People: customers, users, architects, designers, programmers, testers, lawyers, venture capitalists, suppliers, politicians, … Products: requirements, designs, code, documentation, plans, tools, data, facilities, equipment, … Projects: proposals, presentations, contracts, deliverables, budgets, schedules, milestones, … Resources: time, money, space, communications, skills, … Technology: software, hardware, domain technology, COTS, OSS, clouds, apps, widgets, big data… Organizations and Cultures: top management, marketing, sales, development, finance, customer/user organizations, … Changes in all of the above 8/25/2014

5. University of Southern California Center for Systems and Software Engineering © USC-CSSE5 Outline Course objective –Help you learn to be a successful software manager –For a career lasting through the 2050’s. Software management learning objectives –What does a successful SW manager need to deal with? Overview of Course –Programmatics, schedule, academic integrity Current and future software and management challenges ICSM Overview –Principle 1: Stakeholder value-based guidance Enterprise Success Theorem Enterprise Success Realization Theorem This Week’s Assignment 8/25/2014

6. University of Southern California Center for Systems and Software Engineering © USC-CSSE6 Comparison of CS 510 and CS 577a COCOMO II Extensions Microeconomics – Decision Theory Agile and Rapid Development People Management 2 Midterms, Final ICSM Principles and Practices WinWin – Risk Management Planning & Control – COCOMO II Business Case Analysis S/W - System Architecting Operational Concept & Rqts. Definition – Winbook System – Prototyping OO Analysis & Design – Visual Paradigm Team Project (DEN: IV&V) CS 510 CS 577a VBSE Theory, Practice 8/25/2014

7. University of Southern California Center for Systems and Software Engineering © USC-CSSE7 CS 510 Course Schedule Overview Aug 25 – Sep 29 ICSM Principles and Practices, COCOMO II,Cost Estimation, Business Case Analysis Oct 1 Midterm Exam I Oct 6 – Nov 10Software Microeconomics, Risk Management, ICSM Stages and Phases Nov 13 Midterm Exam II Nov 17 – Dec 3 Contracting, Ethics, Maturity Models, Past and Future Trends Dec 10 Final Exam 8/25/2014

8. University of Southern California Center for Systems and Software Engineering © USC-CSSE8 CS 510 Programmatics - I Basis of grade. Final Exam, 30%; 2 midterms: 20%; Homework exercises: 50%. Text. Boehm, Lane, Koolmanojwong, Turner, The Incremental Commitment Spiral Model, Addison Wesley, 2014 Instructor. Prof. Barry Boehm, SAL 328, (213) 740-8163, Fax (213) 740-4927; boehm@usc.eduboehm@usc.edu Office hours: Monday and Wednesday, 11am -12noon or by appointment. Teaching Assistants and Office Hours. Jim Alstad, MW 10-11am or by appointment Anandi Hira, Thursday 2-4pm or by appointment Email: csci510@usc.educsci510@usc.edu Web page: http://sunset.usc.edu/classes/cs510_2014 8/25/2014

9. University of Southern California Center for Systems and Software Engineering © USC-CSSE9 CS 510 Questionnaire and Acknowledgement Please fill out and return. Name: _________________________________________________ Student ID #: ___________________________________________ Dept./Degree Program: __________________________________ Job, Employer: _________________________________________ Software Work Experience (years): _______________________ Phone, fax numbers: ____________________________________ E-mail Address: ________________________________________ Acknowledgement: I acknowledge the importance of USC's academic integrity standards (with respect to plagiarism, referencing others' work, etc.), and agree to abide by them. Signature: ______________________________________________ 8/25/2014

10. University of Southern California Center for Systems and Software Engineering © USC-CSSE10 Academic Integrity Acknowledgement Single most-serious offense: Plagiarism –Using other people’s work without crediting them –Homework, exams, class exercises, individual assignments Minor first offense: You lose one grade level –E.g., B+ instead of A- Major first offense or second offense: F for the course 8/25/2014

11. University of Southern California Center for Systems and Software Engineering © USC-CSSE11 We are Serious About Plagiarism –And experienced in finding it 8/25/2014

12. University of Southern California Center for Systems and Software Engineering © USC-CSSE12 Outline Course objective –Help you learn to be a successful software manager –For a career lasting through the 2050’s. Software management learning objectives –What does a successful SW manager need to deal with? Overview of Course –Programmatics, schedule, academic integrity Current and future software and management challenges ICSM Overview –Principle 1: Stakeholder value-based guidance Enterprise Success Theorem Enterprise Success Realization Theorem This Week’s Assignment 8/25/2014

13. University of Southern California Center for Systems and Software Engineering 8/25/2014 Current and Future Process Challenges-I The Four D’s: Dynamism, Dependability, Doubt, Diversity Dynamism: Rapid pace of change –In competition, mission priorities, technology, widgets, apps, Commercial Off-the-Shelf (COTS), cloud services –Need incremental development to avoid obsolescence –Need concurrent vs. sequential processes –Need both prescience and rapid adaptability Dependability: Always-on, never-fail systems –Need well-controlled, high-assurance processes –Need to synchronize and stabilize concurrency –Need to balance assurance and agility 13© USC-CSSE

14. University of Southern California Center for Systems and Software Engineering 8/25/2014© USC-CSSE14 Dynamism: Increasing Pace of Change Technology change Related infrastructure and services change Marketplace dynamics Competition dynamics Organizational change Software is critical User agility aids critical

15. University of Southern California Center for Systems and Software Engineering Dependability: Cost of Downtime Survey Industry SectorLost Revenue/Hour: 2000 Energy$2.8 million Telecommunications $2.0 million Manufacturing $1.6 million Financial Institutions $1.4 million Information Technology $1.3 million Insurance $1.2 million Retail $1.1 million Pharmaceuticals $1.0 million Banking $996,000 Source: IT Performance Engineering & Measurement Strategies: Quantifying Performance Loss, Meta Group, October 2000. 8/25/201415© USC-CSSE

16. University of Southern California Center for Systems and Software Engineering 8/25/2014 Current and Future Process Challenges-II The Four D’s: Dynamism, Dependability, Doubt, Diversity Doubt: Emergence and human-intensiveness –Requirements not pre-specifiable –Budgets and schedules not pre-specifiable –Need for evolutionary growth –Need to manage uncertainty and risk Diversity: Enterprises and systems of systems (SoS) –Integrated supply chain: strategic planning, marketing, merchandising, outsourcing, just-in-time manufacturing, logistics, finance, customer relations management –Over 50 separately evolving external systems or services –Need to satisfice among multiple stakeholders –Wide diversity of needed capabilities –No one-size-fits-all solutions or processes 16© USC-CSSE

17. University of Southern California Center for Systems and Software Engineering Doubt: The Cones of Uncertainty – Need incremental vs. one-shot development Uncertainties in competition, technology, organizations, mission priorities 8/25/2014© USC-CSSE17

18. University of Southern California Center for Systems and Software Engineering Not just a million apps. A million great apps. 8/25/2014© USC-CSSE18 Shopping the App Store is a great experience because it’s easy to find the apps you want — and to discover new apps you didn’t even know you wanted. Browse freely by category. Or shop collections of apps and games handpicked by experts. Apple reviews everything on the App Store to guard against malware, so you’re buying and downloading from a trusted source. Diversity: The Proliferation of Choices

19. University of Southern California Center for Systems and Software Engineering Diversity: Avoid Procrustean Beds One-size-fits all policies and standards Procrustes: Greek Mythology –Rogue smith and bandit –Hostel with one-size-fits-all bed –Guests too small: stretch them to fit –Guests too large: lop off the offending parts 8/25/2014© USC-CSSE19

20. University of Southern California Center for Systems and Software Engineering Software Procrustean Beds Pure Waterfall, Vee: Fixed Price and Spec Contract –Lop off needed changes as requirements creep Pure Agile: Easiest First; Dedicated On-Site Customer –Later scalability and assurance problems; single-failure point Voice of the Customer: Accept All “Requirements” –Gold-plating; neglect voices of acquirer, developer, owner Piling on Incompatible Constraints: No Way Out –Project Example: Waterfall, COTS, Ada, GOTS Reuse Inflexible Standards: No Choice But Tailoring Down –MIL-STD-498: choice of 23, 6, or 1 DID denied Overconstrained Maturity Models: Excluding Expertise –Software CMM: Exclude software group from system rqts. 8/25/2014© USC-CSSE20

21. University of Southern California Center for Systems and Software Engineering 8/25/2014 Current System Acquisition Methods Too easy to misinterpret as one-size-fits-all V-Model 1 Spiral Model 2 High level guidance assumes that acquirers have extensive acquisition experience... Without experience, too easy to misinterpret and auger in with disastrous results... 1 http://en.wikipedia.org/wiki/V-Model 2 http://en.wikipedia.org/wiki/Spiral_modelhttp://en.wikipedia.org/wiki/V-Modelhttp://en.wikipedia.org/wiki/Spiral_model 21© USC-CSSE

22. University of Southern California Center for Systems and Software Engineering Procrustean Example: DoD Acquisition Process 8/25/2014© USC-CSSE22

23. University of Southern California Center for Systems and Software Engineering © USC-CSSE23 Outline Course objective –Help you learn to be a successful software manager –For a career lasting through the 2050’s. Software management learning objectives –What does a successful SW manager need to deal with? Overview of Course –Programmatics, schedule, academic integrity Current and future software and management challenges ICSM Overview –Principle 1: Stakeholder value-based guidance Enterprise Success Theorem Enterprise Success Realization Theorem This Week’s Assignment 8/25/2014

24. University of Southern California Center for Systems and Software Engineering 8/25/2014 What is the ICSM? Risk-driven framework for determining and evolving best-fit system life-cycle process Integrates the strengths of phased and risk- driven spiral process models Synthesizes together principles critical to successful system development –Stakeholder value-based guidance –Incremental commitment and accountability –Concurrent multidiscipline engineering –Evidence and risk-driven decisions Principles trump diagrams… Principles used by 60-80% of CrossTalk Top-5 projects, 2002-2005 24© USC-CSSE

25. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model 8/25/201425© USC-CSSE

26. University of Southern California Center for Systems and Software Engineering 8/25/2014Copyright © USC-CSSE 26 Incremental Commitment in Gambling Total Commitment: Roulette –Put your chips on a number E.g., a value of a key performance parameter –Wait and see if you win or lose Incremental Commitment: Poker, Blackjack –Put some chips in –See your cards, some of others’ cards –Decide whether, how much to commit to proceed 26© USC-CSSE

27. University of Southern California Center for Systems and Software Engineering 8/25/2014 The Incremental Commitment Spiral Process: Phased View Anchor Point Milestones Synchronize, stabilize concurrency via FEDs Risk patterns determine life cycle process 27© USC-CSSE

28. University of Southern California Center for Systems and Software Engineering 8/25/2014 ICSM Activity Levels for Complex Systems 28© USC-CSSE

29. University of Southern California Center for Systems and Software Engineering 8/25/2014 Anchor Point Feasibility Evidence Descriptions Evidence provided by developer and validated by independent experts that: If the system is built to the specified architecture, it will –Satisfy the requirements: capability, interfaces, level of service, and evolution –Support the operational concept –Be buildable within the budgets and schedules in the plan –Generate a viable return on investment –Generate satisfactory outcomes for all of the success-critical stakeholders All major risks resolved or covered by risk management plans Serves as basis for stakeholders’ commitment to proceed Synchronizes and stabilizes concurrent activities Can be used to strengthen current schedule- or event-based reviews 29© USC-CSSE

30. University of Southern California Center for Systems and Software Engineering 8/25/201430© USC-CSSE

31. University of Southern California Center for Systems and Software Engineering © USC-CSSE31 Outline Course objective –Help you learn to be a successful software manager –For a career lasting through the 2050’s. Software management learning objectives –What does a successful SW manager need to deal with? Overview of Course –Programmatics, schedule, academic integrity Current and future software and management challenges ICSM Overview –Principle 1: Stakeholder value-based guidance Enterprise Success Theorem Enterprise Success Realization Theorem This Week’s Assignment 8/25/2014

32. University of Southern California Center for Systems and Software Engineering © USC-CSSE32 Principle 1 and Enterprise Success Theorem Stakeholder value-based guidance Theorem: Your enterprise will succeed if and only if it makes winners of your success-critical stakeholders Proof of “if”: Everyone that counts is a winner. Nobody significant is left to complain. Proof of “only if”: Nobody wants to lose. Prospective losers will refuse to participate, or will counterattack. The usual result is lose-lose. 8/25/2014

33. University of Southern California Center for Systems and Software Engineering © USC-CSSE33 Win-lose Generally Becomes Lose-lose Actually, nobody wins in these situations Proposed Solution“Winner”Loser Quick, Cheap, Sloppy Product Developer & Customer User Lots of “bells and whistles” Developer & UserCustomer Driving too hard a bargain Customer & UserDeveloper 8/25/2014

34. University of Southern California Center for Systems and Software Engineering © USC-CSSE34 Enterprise Success Realization Theorem Theorem: Your enterprise can realize success if and only if 1.You identify and involve all of the success critical stakeholders (SCSHs) –Dependency theory 2.You determine how the SCSHs want to win –Utility theory 3.You help the SCSHs determine and commit to a win-win course of action and solution –Decision theory 4.You adaptively control the course of action to continue to realize a win-win solution –Control theory 8/25/2014

35. University of Southern California Center for Systems and Software Engineering Case Study: Personnel Assignment You are running a project to develop a supply chain management system for a company in Boston –Need to select a system engineer (SE) to work with the client people in Bo ston. –Two primary candidates, Ann and George. –Both are equally capable, and very much want the job. Here is how a Theory X, Y, or Z manager would likely decide: –Theory X. I'm the boss. George was a good friend and classmate at USC. I'll give him the job. –Theory Y. I'll ask them for their most creative suggestions for doing the job, and pick the most creative. –Theory Z. We are a team, and don't want any favoritism. Each should have an equal chance. I'll flip a coin to decide. All three produce win-lose outcomes. How could you come up with a win-win approach? © USC-CSSE35 8/25/2014

36. University of Southern California Center for Systems and Software Engineering Personnel Selection: A Win-Win Approach Step 1. Identify the success-critical stakeholders (SCSHs): Ann and George Step 2. Determine how they want to win –Ann: I'd like a career path to marketing, and the SE job would be a good step in that direction. –George: my daughter is just starting college in the Boston area, and the Boston job would be an ideal way to keep in touch with her, along with being professionally satisfying. Step 3. Help the SCSHs find a win-win situation –Find a comparable marketing job for Ann, and a comparable Boston job for George –Determine which selection works best for both Ann and George © USC-CSSE36 8/25/2014

37. University of Southern California Center for Systems and Software Engineering Principle 1 Failure Story: The Too-Good Road Surface Assessment Robot Success-Critical Stakeholders –Roadbuilding Company Top Management: Profitability, Reputation Roadbuliders: Efficiency, Quality Quality Assurance: Quality, Reputation –Carnegie Mellon U. Robotics institute Strong robotics research, transition to usage Improvement Opportunity –Manual road assessment expensive, inaccurate –Robotic technology could cut costs, catch defects 8/25/2014© USC-CSSE37

38. University of Southern California Center for Systems and Software Engineering Road Surface Assessment Project Year 1. Alternative Operational Concepts, Designs –Best design: likely 100:1 cost savings, improved accuracy Year 2: Selection of Components, Detailed Design Year 3: Robot Development and Test –100:1 cost and time savings, all deviations caught –100x more deviations; 99% non-threatening –Requirement to report all deviations threatened reputation; unacceptable to quality assurance, top management Net result: Cancellation of production project –Huge technical success; sociotechnical failure –Kept in storage for 5 years; revived under new criteria 8/25/2014© USC-CSSE38

39. University of Southern California Center for Systems and Software Engineering 8/25/2014 Principle 1 Success Story: Symbiq Medical Infusion Pump Winner of 2006 HFES Best New Design Award Described in NRC HSI Report, Chapter 5 39© USC-CSSE

40. University of Southern California Center for Systems and Software Engineering 8/25/2014 Symbiq IV Pump ICSM Process - I Exploration Phase –Stakeholder needs interviews, field observations –Initial user interface prototypes –Competitive analysis, system scoping –Commitment to proceed Valuation Phase –Feature analysis and prioritization –Display vendor option prototyping and analysis –Top-level life cycle plan, business case analysis –Safety and business risk assessment –Commitment to proceed while addressing risks 40© USC-CSSE

41. University of Southern California Center for Systems and Software Engineering 8/25/2014 Symbiq IV Pump ICSM Process - II Foundations Phase –Modularity of pumping channels –Safety feature and alarms prototyping and iteration –Programmable therapy types, touchscreen analysis –Failure modes and effects analyses (FMEAs) –Prototype usage in teaching hospital –Commitment to proceed into development Development Phase –Extensive usability criteria and testing –Iterated FMEAs and safety analyses –Patient-simulator testing; adaptation to concerns –Commitment to production and business plans 41© USC-CSSE

42. University of Southern California Center for Systems and Software Engineering 8/25/2014 Principles Satisfaction: Symbiq IV Pump 1.Stakeholder value-based guidance –Extensive involvement of users, buyers, funders, regulators –Extensive use of prototyping, safety analysis methods 2.Incremental commitment and accountability –Expanding system definition and evidence elaboration –Decision to start with composable 1- and 2-channel pumps 3.Concurrent multidiscipline engineering –Concurrent evaluation of display, alarm, pump suppliers –Concurrent definition, evaluation of safety and business cases 4.Evidence and risk-driven decisions –Evidence-based reviews of technical and business feasibility –Outstanding risks covered by next-phase risk mitigation plans 42© USC-CSSE

43. University of Southern California Center for Systems and Software Engineering First Homework: Due Wed. Sept. 3 Identify violations of Principle 1 from the standpoints of additional stakeholders of the Master Net project covered in Lecture 2: –Bank of America Top Management: Efficiency, Reputation –B of A Quality Assurance: Quality, Reputation Identify approaches for avoiding the resulting failures of the Master Net project –Concise bulleted recommendations acceptable 8/25/2014© USC-CSSE43

44. University of Southern California Center for Systems and Software Engineering 8/25/2014Copyright © USC-CSSE References - I Beck, K., Extreme Programming Explained, Addison Wesley, 1999. Boehm, B., "Some Future Software Engineering Opportunities and Challenges," In Sebastian Nanz (Ed.): The Future of Software Engineering, Springer Berlin Heidelberg, 2011, pp. 1-32.The Future of Software Engineering Boehm, B., Brown, W., Basili, V., and Turner, R., “Spiral Acquisition of Software- Intensive Systems of Systems, CrossTalk, Vol. 17, No. 5, pp. 4-9, 2004. Boehm, B. and Lane J., "21st Century Processes for Acquiring 21st Century Software- Intensive Systems of Systems." CrossTalk: Vol. 19, No. 5, pp.4-9, 2006. Boehm, B., and Lane, J., “Using the ICSM to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, October 2007, pp. 4-9. Boehm, B., and Lane, J., “A Process Decision Table for Integrated Systems and Software Engineering,” Proceedings, CSER 2008, April 2008. Boehm, B. et al., Software Cost Estimation with COCOMO II, Prentice Hall, 2000. Boehm, B. and Lane, J., "Evidence-Based Software Processes," New Modeling Concepts for Today's Software Processes, Springer Lecture Notes in Computer Science, 2010, Volume 6195/2010, pp. 62-73.New Modeling Concepts for Today's Software Processes Boehm, B., Lane, J., Koolmanojwong, S., and Turner, R., “An Evidence-Based SE Data Item Description,” Proceedings, CSER 2013, Elsevier, www.sciencedirect.comwww.sciencedirect.com Boehm, B., Lane, J., Koolmanojwong, S., and Turner, R., The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, Addison Wesley, 2014. Checkland, P., Systems Thinking, Systems Practice, Wiley, 1980 (2nd ed., 1999). Electronic Industries Alliance (1999); EIA Standard 632: Processes for Engineering a System Highsmith, J., Adaptive Software Development, Dorset House, 2000 Huang, L., Boehm, B., Hu, H., Lv,J., and Qian, C., “Applying Value-Based Software Process: an ERP Example,” Intl. J. Software and informatics, July 2008, pp. 1-15. 44© USC-CSSE

45. University of Southern California Center for Systems and Software Engineering 8/25/2014Copyright © USC-CSSE References -II International Standards Organization, Information Technology Software Life Cycle Processes, ISO/IEC 12207, 1995 ISO, Systems Engineering – System Life Cycle Processes, ISO/IEC 15288, 2008. Krygiel, A., Behind the Wizard’s Curtain; CCRP Publication Series, July, 1999, p. 33 Lane, J. and Boehm, B., "System of Systems Cost Estimation: Analysis of Lead System Integrator Engineering Activities", Information Resources Management Journal, Vol. 20, No. 2, pp. 23-32, 2007. Lane, J. and Valerdi, R., “Synthesizing SoS Concepts for Use in Cost Estimation”, Proceedings of IEEE Systems, Man, and Cybernetics Conference, 2005. Madachy, R., Boehm, B., Lane, J., "Assessing Hybrid Incremental Processes for SISOS Development", USC CSSE Technical Report USC-CSSE-2006-623, 2006. Maier, M., “Architecting Principles for Systems-of-Systems”; Systems Engineering, Vol. 1, No. 4 (pp 267-284). Maier, M., “System and Software Architecture Reconciliation,” Systems Engineering 9 (2), 2006, pp. 146-159. Northrop, L., et al., Ultra-Large-Scale Systems: The Software Challenge of the Future, Software Engineering Institute, 2006. Pew, R. W., and Mavor, A. S., Human-System Integration in the System Development Process: A New Look, National Academy Press, 2007. Rechtin, E. Systems Architecting, Prentice Hall, 1991. Schroeder, T., “Integrating Systems and Software Engineering: Observations in Practice,” OSD/USC Integrating Systems and Software Engineering Workshop, http://csse.usc.edu/events/2007/CIIForum/pages/program.html, October 2007. http://csse.usc.edu/events/2007/CIIForum/pages/program.html USC CSSE, ICSM Electronic Process Guide, http://greenbay.usc.edu/IICMSw/index.htm#publish.icm.base- usc/customcategories/icm_welcome_page_D99DA7B2.html http://greenbay.usc.edu/IICMSw/index.htm#publish.icm.base- usc/customcategories/icm_welcome_page_D99DA7B2.html 45© USC-CSSE

46. University of Southern California Center for Systems and Software Engineering 8/25/2014Copyright © USC-CSSE List of Acronyms B/LBaselined C4ISRCommand, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance CDConcept Development CDRCritical Design Review COTSCommercial Off-the-Shelf DCRDevelopment Commitment Review DIDevelopment Increment DoDDepartment of Defense ECRExploration Commitment Review EVMSEarned Value Management System FCRFoundations Commitment Review FEDFeasibility Evidence Description FMEAFailure Modes and Effects Analysis FRPFull-Rate Production GAOGovernment Accountability Office GUIGraphical User Interface 46© USC-CSSE

47. University of Southern California Center for Systems and Software Engineering 8/25/2014Copyright © USC-CSSE List of Acronyms (continued) HMIHuman-Machine Interface HSIHuman-System Interface HWHardware ICSMIncremental Commitment Model IOCInitial Operational Capability IRRInception Readiness Review IS&SEIntegrating Systems and Software Engineering LCOLife Cycle Objectives LRIPLow-Rate Initial Production MBASEModel-Based Architecting and Software Engineering NDINon-Developmental Item NRCNational Research Council OCOperational Capability OCROperations Commitment Review OO&DObserve, Orient and Decide OODAObserve, Orient, Decide, Act O&MOperations and Maintenance 47© USC-CSSE

48. University of Southern California Center for Systems and Software Engineering 8/25/2014Copyright © USC-CSSE List of Acronyms (continued) PDRPreliminary Design Review PMProgram Manager PRPublic Relations PRRProduct Release Review RUPRational Unified Process SoSSystem of Systems SoSESystem of Systems Engineering SSESystems and Software Engineering SWSoftware SwESoftware Engineering SysESystems Engineering Sys EngrSystems Engineer S&SESystems and Software Engineering USD (AT&L)Under Secretary of Defense for Acquisition, Technology, and Logistics VCRValidation Commitment Review V&VVerification and Validation WBSWork Breakdown Structure WMIWarfighter-Machine Interface 48© USC-CSSE