1. CSCI 577a Software Engineering I Dr. Barry Boehm August 27, 2012
Course Overview
CSCI 577a
Software Engineering I
Dr. Barry Boehm
August 27, 2012

2. Outline Software Engineering Definition and Learning Objectives
Importance of trust, honoring commitments
Comparison of CS 510 and CS 577a
Class Overview
Nature of Projects
Incremental Commitment Spiral Model
Project Structure, Schedule, and Risks
Course Mechanics
8/27/12
(c) USC CSSE 2

3. CS 577 Learning Objectives
“Software Engineering:” The disciplines which distinguish the coding of a computer program from the development of a software product.
Stages
Issues
Prepare you for software leadership careers through the 2040’s
Agility with discipline; COTS/OSS, model, service-based and network centric systems
Integrate all these considerations
Via value-based, Incremental Commitment Spiral Model (ICSM) and
project experience
8/27/12
(c) USC CSSE 3

4. 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 on 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
8/27/12
(c) USC CSSE 4

5. 8/27/12
(c) USC CSSE 5

6. 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
8/27/12
(c) USC CSSE 6

7. 8/27/12
(c) USC CSSE 7

8. Failed Challenged Succeeded
Software Engineering Is Not Well-Practiced Today -Standish Group CHAOS Report 2004
Failed
Challenged
Succeeded
Averages
143% of original budget
182% of original schedule
52% of original functionality
CS577: 92% on-time, client satisfactory
8/27/12
(c) USC CSSE 8

9. Traditional vs. Emerging SW Processes
Contract-oriented
Your problem; win-lose
Collaboration-oriented
Our problem: win-win
Sequential
Cyclic, concurrent
Procedure-driven
Risk-driven
Programming-driven
Reuse-driven
Many interlocking milestones
Critical anchor points with subsidiary milestones
Focus on discipline & control
Mix of flexibility & discipline
8/27/12
(c) USC CSSE 9

10. Comparison of CS 510 and CS 577a
VBSE Theory, Practice
COCOMO II Extensions
Microeconomics
Decision Theory
Agile and Rapid
Development
People Management
2 Midterms, Final
S/W - System
Architecting
Operational Concept &
Rqts. Definition
WinWin System
Prototyping
OO Analysis & Design
Visual Paradigm
Team Project
(DEN: IIV&V)
VBSE Framework
ICSM
WinWin Spiral
Risk Management
Planning & Control
COCOMO II +
Business Case Analysis
8/27/12
(c) USC CSSE 10

11. 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 Spiral Model
Project Structure, Schedule, and Risks
Course Mechanics
8/27/12
(c) USC CSSE 11

12. 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
Fall: 12 weeks to do it ALL (some projects)
MS-level, 5-6 person, CS 577 project course
Clients, CSSE, USC Professors: 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
8/27/12
(c) USC CSSE 12

13. Stakeholder Win-Win Approach
Builds trust through observed actions
Stakeholders
Win Conditions
Students, Employers
Full range of Sw Engineering Skills
Real-client project experience
Non-outsourceable skills
Advanced Sw technology experience
Project clients
Useful applications
Advanced Sw technology understanding
Moderate time requirements
Faculty, Profession
Educate future Sw Engineering leaders
Better Sw Engineering technology
Applied on real-client projects
8/27/12
(c) USC CSSE 13

14. 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
5-8 projects; students; 5-8 clients
Software, personnel, and facilities preparation
2-week transition period
then the student teams disappear
Tools and techniques: WinBook; Benefits Chain; Rational Software Modeler, Subversion; USC COCOMO II; MS Project; USC Incremental Commitment Spiral Model method
Reworked annually based on student & client feedback
8/27/12
(c) USC CSSE 14

15. Instructional Incremental Commitment Spiral Model – Software Engineering
8/27/12
(c) USC CSSE

16. The Incremental Commitment Life Cycle Process: Overview
Stage I: Definition
Stage II: Development and Operations
Anchor Point Milestones
Concurrently engr. Incr.N (ops), N+1 (devel), N+2 (arch)
Concurrently engr. OpCon, rqts, arch, plans, prototypes
8/27/12
(c) USC CSSE 16

17. The Incremental Commitment Life Cycle Process: Overview
Stage I: Definition
Stage II: Development and Operations
Anchor Point Milestones
The Incremental Commitment Life Cycle Process: Overview
This slide shows how the ICM spans the life cycle process from concept exploration to operations. Each phase culminates with an anchor point milestone review. At each anchor point, there are 4 options, based on the assessed risk of the proposed system. Some options involve go-backs. These options result in many possible process paths.
The life cycle is divided into two stages: Stage I of the ICM (Definition) has 3 decision nodes with 4 options/node, culminating with incremental development in Stage II (Development and Operations). Stage II has an additional 2 decision nodes, again with 4 options/node.
One can use ICM risk patterns to generate frequently-used processes with confidence that they fit the situation. Initial risk patterns can generally be determined in the Exploration phase. One then proceeds with development as a proposed plan with risk-based evidence at the VCR milestone, adjusting in later phases as necessary. For complex systems, a result of the Exploration phase would be the Prototyping and Competition Plan discussed above.
Risks associated with the system drive the life cycle process. Information about the risk(s) (feasibility assessments) supports the decision to proceed, adjust scope or priorities, or cancel the program.
Synchronize, stabilize concurrency via FEDs
Risk patterns determine life cycle process
8/27/12
July 2008
©USC-CSSE
©USC-CSSE
(c) USC CSSE 17 17

18. 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
8/27/12
(c) USC CSSE 18

19. NRC HSI Case Study: Scalable remotely controlled operations
2:1 too hard to staff
Need 1:4
8/27/12
(c) USC CSSE 19

20. 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
8/27/12
(c) USC CSSE 20

21. Win Win Spiral Anchor Points
(Risk-driven level of detail for each element)
Milestone Element
Architecting Commitment
Development 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
- via analysis, measurement, prototyping, simulation, etc.
- Business case analysis for requirements, feasible
architectures
Definition of System
Requirements
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
*WWWWWHH: Why, What, When, Who, Where, How, How Much
8/27/12
(c) USC CSSE 21

22. The Model-Clash Spider Web: Master Net
- Stakeholder value propositions (win conditions)
8/27/12
(c) USC CSSE 22

23. 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
ICSM provides techniques for avoiding these
8/27/12
(c) USC CSSE 23

24. ICSM Model Integration: Valuation Phase
Domain Model
WinWin
Taxonomy
Basic Concept
of Operation
Frequent
Risks
Stakeholders,
Primary win conditions
Negotiation
Model
IKIWISI Model,
Prototypes,
Properties Models
Environment
Models
WinWin Agreements, Shared Vision
Viable
Architecture
Options
Updated Concept
Life Cycle Plan
elements
Outstanding
ACR risks
Requirements
Description
ACR Rationale
ACR Package
Anchor Point
determines
identifies
situates
exercise
focus
use of
guides
determination of
validate
inputs for
provides
initialize
adopt
identify
update
achieve
iterate to
feasibility,
consistency
determines exit
criteria for
validates readiness of i n t a l z e s
8/27/12
(c) USC CSSE 24

25. Team Structure Six-person, on-campus teams (augmented by DEN students)
Each artifact should have a lead producer and a co-producer
DEN students do IIV&V, Issue/Bug tracking, etc.
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 and project selected by Wednesday, Sept :00 4:00pm
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 : Friday Sept. 7, After Class, E-Quad
8/27/12
(c) USC CSSE 25

26. Timelines: Fall 2012 Sept. 12: Teams formed; projects selected;
2:00 - 3:20 pm CS 577a class Session with clients (OHE122)
3:30 – 4:30 pm hands on WWW training (in an ITS classroom) for clients only
Sept 12-14: Site visit
During the semester: Sept. 12 – Dec. 7
Intermediate consultation, prototype reviews, WinWin negotiation, scheduled weekly meetings with team, prototype evaluations, on-campus win-win negotiation participation & off campus follow up, Identify other success-critical stakeholders
Oct. 29-Nov 2: FCR ARB meetings
Dec 3 -7: DCR ARB meetings
Dec. 10: Submit Client evaluation form
DCR: Development Commitment Review; FCR: Foundations Commitment Review; VCR: Valuation Commitment Review; WWW: WikiWinWin
8/27/12
(c) USC CSSE 26

27. Timelines: Spring 2013 Jan. - Feb. : Work with teams:
Rebaseline prototype, prioritize requirements
Plan for CS 577b specifics, including transition strategy, key risk items
Participate in ARB review
Feb – May : Scheduled Weekly Meetings with Teams to:
Discuss status and plans
Provide access to key transition people for strategy and readiness discussions
Mar 27: Core Capability Drivethrough
Apr : Project Transition Readiness ARB Reviews
Apr 19: Installation and Transition
Install Product
Execute Transition Plan
Apr 29: Operational Commitment Review for Initial Operational Capability
May 7: Client Evaluations
(C) 2012 USC-CSSE 27

28. Top 10 Risk Items: 1989 and 1995 1989 1995 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
8/27/12
(c) USC CSSE 28

29. Top 10 System Risk Items: 1995 and 2007
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
2007
1 Architecture complexity; quality tradeoffs
2 Requirements volatility; rapid change
3 Acquisition and contracting process mismatches
4 Customer-developer-user team cohesion
5 Budget and schedule constraints
6 Requirements mismatch
7 Personnel shortfalls
8 COTS and other independently evolving systems
9 Migration complexity
10 User interface mismatch
8/27/12
(c) USC CSSE

30. 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 end-user needs
Performance: #bits; #bits/sec; overhead sources
External tasks: Client/Operator preparation, commitment for transition
8/27/12
(c) USC CSSE 30

31. 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
8/27/12
(c) USC CSSE 31

32. 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 Spiral Model
Project Structure, Schedule, and Risks
Course Mechanics
8/27/12
(c) USC CSSE 32

33. Academic Integrity Acknowledgement
Single most-serious offense: Plagiarism
Using other people’s work, directly or indirectly, 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/27/12
(c) USC CSSE 33

34. We are Serious About Plagiarism And experienced in finding it
8/27/12
(c) USC CSSE 34

35. Early Assignments
1st Class (Done in class; DEN students – or fax to DEN office [if you miss 1st 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)
Next Monday: Labor Day – No Class
Next Wednesday 09/05
PC-1 : Incremental Commitment Spiral Model
Submit thru DEN;
if no DEN account, submit printout before class at SAL 329 before 12pm
Next Friday 09/07
EF-3: Online "Questionnaire for CSCI 577a: Software Engineering I--Fall 2012" [on line ONLY] (10 points)
Submit thru class website
8/27/12
(c) USC CSSE 35

36. Individual Responsibilities
Homework assignments
Selected pre-class and in-class exercises
Drop lowest 1 in-class quiz
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
120 points, due after Development Commitment packages submitted
Effort reports; Review other peoples artifacts
Presentation at two project reviews (ARB’s)
Academic integrity!
8/27/12
(c) USC CSSE 36

37. Lecture Format for In-class Exercises, etc.
Pre-Class
Exercise (some classes; relates
readings to lecture
and to ICSM)
Lecture &
Discussion
(beginning with
short review of
where we are)
In-Class
Exercise
Post-Class
Homework
(some classes)
Details and due
dates on course
schedule
To be done
before class
Elaboration
of pre-class
exercise;