1. University of Southern California Center for Systems and Software Engineering Course Overview CSCI 577a Software Engineering I Barry Boehm August 24, 2009

2. University of Southern California Center for Systems and Software Engineering Outline Software Engineering Definition and Learning Objectives –Importance of trust, honoring commitments –Comparison of CS 510 and CS577a Class Overview –Nature of Projects –Incremental Commitment Model –Project Structure, Schedule, and Risks Course Mechanics 08/25/08©USC-CSSE2

3. University of Southern California Center for Systems and Software Engineering CS 577 Learning Objectives 08/25/08©USC-CSSE3 “ Software Engineering:” The disciplines which distinguish the coding of a computer program from the development of a software product. Prepare you for software leadership careers through the 2040’s -Agility, discipline, COTS/OSS, model / service-based systems Integrate all these considerations -Via value-based, Incremental Commitment Model (ICM) project experience Stages Issues

4. University of Southern California Center for Systems and Software Engineering Most Important Learning Objective: Honoring Commitment Leadership is built on a bedrock of trust Trust is built on a bedrock of commitments Two major commitments in CS577a –Commitment to USC copyright and academic integrity standards Checked via copying-identification tools –Commitment to your team and clients to collaborate, produce high quality artifacts or schedule Checked via FCR, DCR peer assessments 5% of grade based on honoring commitments –Can be up to 2 grade-level loss –Or F in course for plagiarism 08/25/08©USC-CSSE4

5. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE5

6. University of Southern California Center for Systems and Software Engineering Reuse of Others’ Work Personal Use (read, experiment with) –OK, within your access rights Offered for credit or sale (class, journal, product) –OK within your access and usage rights –Also need to acknowledge source Team projects for course –Reuse among team members usually OK, but check Powerful tools used to detect unauthorized reuse –Serious penalties at USC and elsewhere –Best to check access and usage rights –When in doubt, acknowledge the source –Mark copy-and-paste placeholders for replacement 08/25/08©USC-CSSE6

7. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE7

8. University of Southern California Center for Systems and Software Engineering Software Engineering Is Not Well-Practiced Today -Standish Group CHAOS Report 2004 08/25/08©USC-CSSE8 Succeeded Failed Averages 143% of original budget 182% of original schedule 52% of original functionality Challenged CS577: 92% on-time, client satisfactory

9. University of Southern California Center for Systems and Software Engineering Traditional vs. Emerging SW Processes TraditionalEmerging Contract-oriented Your problem; win-lose Collaboration-oriented Our problem; win-win SequentialCyclic, concurrent Procedure-drivenRisk-driven Programming-drivenReuse-driven Many interlocking milestonesCritical anchor points with subsidiary milestones Focus on discipline & controlMix of flexibility & discipline 08/25/08©USC-CSSE9

10. University of Southern California Center for Systems and Software Engineering Comparison of CS 510 and CS 577a 08/25/08©USC-CSSE10 COCOMO II Extensions Microeconomics – Decision Theory Agile and Rapid Development People Management 2 Midterms, Final VBSE Framework ICM WinWin Spiral – Risk Management Planning & Control – COCOMO II Business Case Analysis S/W - System Architecting Operational Concept & Rqts. Definition – WinWin System – Prototyping OO Analysis & Design – Rational Software Modeler Team Project (DEN: IIV&V) CS 510 CS 577a VBSE Theory, Practice

11. University of Southern California Center for Systems and Software Engineering Outline Software Engineering Definition and Learning Objectives –Importance of trust, honoring commitments –Comparison of CS 510 and CS577a Class Overview –Nature of Projects –Incremental Commitment Model –Project Structure, Schedule, and Risks Course Mechanics 08/25/08©USC-CSSE11

12. University of Southern California Center for Systems and Software Engineering e-Services Projects Overview Clients identify prospective projects –Operational capabilities or feasibility explorations –Fall: 12 weeks to prototype, analyze, design, plan, validate –Spring: 12 weeks to develop, test, transition –MS-level, 5-6 person, CS 577 project course Clients, CSSE, ITS negotiate workable projects –Useful results within time constraints –Operationally supportable as appropriate Clients work with teams to define, steer, evaluate projects –Exercise prototypes, negotiate requirements, review progress –Mutual learning most critical success factor 08/25/08©USC-CSSE12

13. University of Southern California Center for Systems and Software Engineering Stakeholder Win-Win Approach Builds trust through observed actions 08/25/08©USC-CSSE13 StakeholdersWin Conditions Students, Employers Full range of SW Engr. Skills Real-client project experience Non-outsourceable skills Advanced SW tech. experience Project clientsUseful applications Advanced SW tech. understanding Moderate time requirements Faculty, ProfessionEducate future SW Engr. leaders Better SW Engr. technology Applied on real-client projects

14. University of Southern California Center for Systems and Software Engineering Software Engineering Project Course (CS 577) Fall: Develop Life Cycle Architecture Packages –Ops. Concept, Requirements, Prototype, Architecture, Plan –Feasibility Rationale, including business case –Results chain linking project results to desired outcomes –20 projects; 120 students; about 20 clients Spring: Develop Initial Operational Capability –6-10 projects; 30-50 students; 6-10 clients –Software, personnel, and facilities preparation –2-week transition period –then the student teams disappear Tools and techniques: WikiWinWin; Benefit Chain; Rational Software Modeler, Subversion; USC COCOMO II; MS Project; USC Incremental Commitment Model method –Reworked annually based on student & client feedback 08/25/08©USC-CSSE14

15. University of Southern California Center for Systems and Software Engineering Instructional Incremental Commitment Model – Software Engineering

16. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE16

17. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE17

18. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE18 The Incremental Commitment Life Cycle Process: Overview Stage I: DefinitionStage II: Development and Operations Anchor Point Milestones Concurrently engr. OpCon, rqts, arch, plans, prototypes Concurrently engr. Incr.N (ops), N+1 (devel), N+2 (arch)

19. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE19©USC-CSSE The Incremental Commitment Life Cycle Process: Overview Stage I: DefinitionStage II: Development and Operations Anchor Point Milestones Synchronize, stabilize concurrency via FEDs Risk patterns determine life cycle process

20. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE20 Pass/Fail Feasibility Rationales 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

21. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE21 NRC HSI Case Study: Scalable remotely controlled operations 2:1 too hard to staff Need 1:4

22. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE22 Total vs. Incremental Commitment – 1:4 RPV Total Commitment –Winning bidder: $800M; PDR in 120 days; 1:4 capability with agent technology in 40 months –PDR: many outstanding risks, undefined interfaces –$800M, 40 months: “halfway” through integration and test –1:1 IOC after $3B, 80 months Incremental Commitment –$25M, 6 mo. to VCR: may beat 2:1 with agent technology, but not 1:4 –$75M, 8 mo. to ACR: agent technology may do 1:1; some risks –$225M, 10 mo. to DCR: validated architecture, high-risk elements –$675M, 18 mo. to IOC: viable 1:1 capability –1:1 IOC after $1B, 42 months

23. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE23 Win Win Spiral Anchor Points (Risk-driven level of detail for each element) *WWWWWHH: Why, What, When, Who, Where, How, How Much Milestone ElementArchitecting CommitmentDevelopment Commitment Definition of Operational Concept Top-level system objectives and scope - System boundary - Environment parameters and assumptions - Evolution parameters Operational concept - Operations and maintenance scenarios and parameters - Organizational life-cycle responsibilities (stakeholders) Elaboration of system objectives and scope of increment Elaboration of operational concept by increment Top-level functions, interfaces, quality attribute levels, including: - Growth vectors and priorities - Prototypes Stakeholders’ concurrence on essentials Elaboration of functions, interfaces, quality attributes, and prototypes by increment - Identification of TBD’s( (to-be-determined items) Stakeholders’ concurrence on their priority concerns Top-level definition of at least one feasible architecture - Physical and logical elements and relationships - Choices of COTS and reusable software elements Identification of infeasible architecture options Choice of architecture and elaboration by increment - Physical and logical components, connectors, configurations, constraints - COTS, reuse choices - Domain-architecture and architectural style choices Architecture evolution parameters Elaboration of WWWWWHH* for Initial Operational Capability (IOC) - Partial elaboration, identification of key TBD’s for later increments Assurance of consistency among elements above All major risks resolved or covered by risk management plan Identification of life-cycle stakeholders - Users, customers, developers, maintainers, interoperators, general public, others Identification of life-cycle process model - Top-level stages, increments Top-level WWWWWHH* by stage Assurance of consistency among elements above - via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures Definition of System Requirements Definition of System and Software Architecture Definition of Life- Cycle Plan Feasibility Rationale System Prototype(s) Exercise key usage scenarios Resolve critical risks Exercise range of usage scenarios Resolve major outstanding risks

24. University of Southern California Center for Systems and Software Engineering 08/25/08©USC-CSSE24 The Model-Clash Spider Web: Master Net - Stakeholder value propositions (win conditions)

25. University of Southern California Center for Systems and Software Engineering Models and Model Clashes Software is an invisible product We use models to help visualize it and its processes –Product, process, property, and success models Each model makes some simplifying assumptions –COTS-based product model: COTS capabilities determine requirements –Sequential waterfall process model: requirements determine capabilities Model clashes hard to find, cause major frustrations, rework, overruns –ICM provides techniques for avoiding these 08/25/08©USC-CSSE25

26. University of Southern California Center for Systems and Software Engineering ICM Model Integration: Valuation Phase 08/25/08©USC-CSSE26 Domain Model WinWin Taxonomy Basic Concept of Operation Frequent Risks Stakeholders, Primary win conditions WinWin Negotiation Model IKIWISI Model, Prototypes, Properties Models Environment Models WinWin Agreements, Shared Vision Viable Architecture Options Updated Concept of Operation Life Cycle Plan elements Outstanding ACR risks Requirements Description ACR Rationale ACR Package Anchor Point Model determines identifies determines situatesexercise focus use of focus use of determines guides determination of validate inputs for provides initializeadoptidentify update achieveiterate to feasibility, consistency determines exit criteria for validates readiness of initializesinitializes

27. University of Southern California Center for Systems and Software Engineering Team Structure Six-person teams –Each artifact should have a lead producer and a co-producer Project Manager generally the lead for Feasibility Rationale 1. Ensures consistency among the team members’ artifacts (and documents this in the Rationale). 2. Leads the team’s development of plans for achieving the project results, and ensures that project performance tracks the plans. Teams formed by Wednesday, Sept. 9 2:30pm –Web questionnaires should help in team formation (EF-3) Start forming teams now! –What are your skills? What roles would you prefer? –What skills does your team need? Who does them? –What projects does your team prefer? Note: Team Mixer Activity : Wednesday August 31, 2:00, E-Quad 08/25/08©USC-CSSE27

28. University of Southern California Center for Systems and Software Engineering 08/21/09©USC-CSSE28 Timelines: Fall 2009 Sept. 9: Teams formed; projects selected; Sept 10: Site visit Sept 11: 11:00 - 12:30 hands on WWW training (ITS lab) 12:30 - 1:50 CS 577a class Session with clients (OHE122) During the semester: Sept. 10 – Dec. 10 Intermediate consultation, prototype reviews, WikiWinWin negotiation, scheduled weekly meetings with team, prototype evaluations, on-campus win- win negotiation participation & off campus follow up, Identify other success- critical stakeholders Oct 1 : VCR preparation and teleconference meeting Oct. 19-23: FCR ARB meetings Nov 30- Dec 4: DCR ARB meetings Dec. 11: Submit Client evaluation form DCR: Development Commitment Review; FCR: Foundations Commitment Review; VCR: Valuation Commitment Review; WWW: WikiWinWin

29. University of Southern California Center for Systems and Software Engineering 08/21/09©USC-CSSE29 Jan. 11- Feb. 12: Work with teams: –Rebaseline prototype, prioritize requirements –Plan for CS 577b specifics, including transition strategy, key risk items –Participate in ARB review Feb 15 – May 7: Scheduled Weekly Meetings with Teams to: –Discuss status and plans –Provide access to key transition people for strategy and readiness discussions Mar 8 – 26: Core Capability Drivethrough Apr 15 - Apr 16: Project Transition Readiness ARB Reviews Apr 20: Installation and Transition –Install Product –Execute Transition Plan May 4-5: Operational Commitment Review for Initial Operational Capability May 7: Client Evaluations Timelines: Spring 2010

30. University of Southern California Center for Systems and Software Engineering Top 10 Risk Items: 1989 and 1995 08/25/08©USC-CSSE30 1989 1. Personnel shortfalls 2. Schedules and budgets 3. Wrong software functions 4. Wrong user interface 5. Gold plating 6. Requirements changes 7. Externally-furnished components 8. Externally-performed tasks 9. Real-time performance 10. Straining computer science 1995 1. Personnel shortfalls 2. Schedules, budgets, process 3. COTS, external components 4. Requirements mismatch 5. User interface mismatch 6. Architecture, performance, quality 7. Requirements changes 8. Legacy software 9. Externally-performed tasks 10. Straining computer science

31. University of Southern California Center for Systems and Software Engineering Primary CS577 Risk Items Personnel: commitment; compatibility; ease of communication; skills (management, Web/Java, Perl, CGI, data compression, …) Schedule: project scope; IOC content; critical- path items (COTS, platforms, reviews, …) COTS: see next chart; multi-COTS Rqts, UI: mismatch to Library user needs Performance: #bits; #bits/sec; overhead sources External tasks: Client/Operator preparation, commitment for transition 08/25/08©USC-CSSE31

32. University of Southern California Center for Systems and Software Engineering COTS and External Component Risks COTS risks: immaturity; inexperience; COTS incompatibility with application, platform, other COTS; controllability Non-commercial off-the shelf components: Open source, reuse libraries, government, universities, etc. –Qualification testing; benchmarking; inspections; reference checking; compatibility analysis 08/25/08©USC-CSSE32

33. University of Southern California Center for Systems and Software Engineering Outline Software Engineering Definition and Learning Objectives –Importance of trust, honoring commitments –Comparison of CS 510 and CS577a Class Overview –Nature of Projects –Incremental Commitment Model –Project Structure, Schedule, and Risks Course Mechanics 08/25/08©USC-CSSE33

34. University of Southern California Center for Systems and Software Engineering 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 of second offense: F for the course 08/25/08©USC-CSSE34

35. University of Southern California Center for Systems and Software Engineering We are Serious About Plagiarism –And experienced in finding it 08/25/08©USC-CSSE35

36. University of Southern California Center for Systems and Software Engineering Early Assignments 1st Class (Done in class; DEN students-email / fax to DEN office [if you miss 1 st class(es), get from Class Website]: –EF-1: Basic Questionnaire : Commitment Form (10 points) submit signed version ASAP to TAs –EF-2: Academic Integrity and Copyright Agreement (10 points) submit signed version ASAP to Tas 2nd Class: –PC-1 : Incremental Commitment Model (15 points) Submit thru DEN; https://www.uscden.net/webapps/login if no DEN account, submit printout before class at SAL 329 before 12pm 3rd Class: –EF-3: Online "Questionnaire for CSCI 577a: Software Engineering I--Fall 2008" (10 points) Submit thru class website http://greenbay.usc.edu/csci577/fall2009/site/index.html 08/25/08©USC-CSSE36

37. University of Southern California Center for Systems and Software Engineering Individual Responsibilities Homework assignments Selected pre-class and in-class exercises –Drop lowest 1 pre-class and lowest 1 in-class. Acquire Book: USC bookstore, Amazon, B&N,... –Boehm et al., Software Cost Estimation With COCOMOII Contribute to team project –Lead on one artifact; on other co-lead –Part of Honoring commitment grade (70 points) Individual Critique –160 points, due after Development Commitment packages submitted Effort reports; Review other peoples artifacts Presentation at two project reviews (ARB’s) Academic integrity! 08/25/08©USC-CSSE37

38. University of Southern California Center for Systems and Software Engineering To be done before class Elaboration of pre-class exercise; Details and due dates on course schedule Pre-Class Exercise (some classes; relates readings to lecture and to ICM) Lecture & Discussion (beginning with short review of where we are) In-Class Exercise Post-Class Homework (some classes) Lecture Format for In-class Exercise