Software engineering overview of selby boehm book
Download
1 / 97

Software Engineering: Overview of Selby - PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on

Software Engineering: Overview of Selby/Boehm book. Barry Boehm, USC CS 510 Fall 2011 [email protected] http://csse.usc.edu. Outline. What have we learned? (chapter 8) Some book highlights People and values (chapters 7, 9) Economics (chapters 2, 3) Processes (chapters 4, 6)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Engineering: Overview of Selby' - tahmores


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software engineering overview of selby boehm book

Software Engineering:Overview of Selby/Boehm book

Barry Boehm, USC

CS 510

Fall 2011

[email protected]

http://csse.usc.edu


Outline
Outline

  • What have we learned? (chapter 8)

  • Some book highlights

    • People and values (chapters 7, 9)

    • Economics (chapters 2, 3)

    • Processes (chapters 4, 6)

    • Risk Management (chapter 5)

    • Top-10 lists (chapter 1)

  • Where are we going? (chapter 10)

©USC-CSSE



1950 s thesis engineer software like hardware
1950’s Thesis: Engineer Software Like Hardware

  • Hardware-oriented:

    • Software applications: airplanes, bridges, circuits

    • Economics: Boehm supervisor, 1955

      • “We’re paying $600/hour for that computer, and $2/hour for you, and I want you to act accordingly.”

    • Professional Societies: Association for Computing Machinery, IEEE Computer Society

    • Software Processes: SAGE (Semi-Automated Ground Environment)

      • 1 MLOC air defense system, real-time, user-intensive

      • Successful development of highly unprecedented system

      • Hardware-oriented waterfall-type process

©USC-CSSE


The SAGE Software Development Process - (Benington, 1956)“We were successful because we were all engineers”.

©USC-CSSE


1960 s antithesis software is not like hardware four brooks factors plus two
1960’s Antithesis: Software Is Not Like Hardware- Four Brooks factors plus two

  • Invisibility: like the Emperor’s Magic Cloth

  • Complexity: Royce, “for a $5M procurement, need a 30-page spec for hardware, and a 1500-page spec for software”

  • Conformity: executed by computers, not people

  • Changeability: up to a point, then becomes difficult

  • Doesn’t wear out: different reliability, maintenance phenomena

  • Unconstrained: can program antigravity, time travel, interpenetration, …

©USC-CSSE


1960 s antithesis software crafting
1960’s Antithesis: Software Crafting

  • Flexible materials, frequent changes as above

  • SW demand exceeded supply of engineers

    • Music, history, art majors

    • Counter culture: question authority

    • Cowboy programmers as heroes

    • Code-and-fix process

    • Hacker culture (Levy, 1984)

      • Collective code ownership

      • Free software, data, computing access

      • Judge programmers by the elegance of their code

©USC-CSSE


1960 s progress and problems
1960’s Progress and Problems

  • Better infrastructure: OS, compilers, utilities

  • Computer Science Departments

  • Product Families: OS-360, CAD/CAM, math/statistics libraries

  • Some large successes: Apollo, ESS, BofA check processing

  • Problems: 1968, 1969 NATO Reports

    • Failure of most large systems

    • Unmaintainable spaghetti code

    • Unreliable, undiagnosable systems

©USC-CSSE


1970 s antithesis formal and waterfall approaches
1970’s Antithesis: Formal and Waterfall Approaches

  • Structured Methods

    • Structured programming (Bohm-Jacopini: GO TO unnecessary)

      • Formal programming calculus: Dijkstra, Hoare, Floyd

      • Formalized Top-Down SP: Mills, Baker

  • Waterfall Methods

    • Code and fix too expensive (100:1 for large systems)

    • Precede code by design (De Marco SD, Jackson JSD/JSP)

    • Precede design by requirements (PSL/PSA, SA, SREM)

©USC-CSSE


The royce waterfall model 1970 explicit feedback do it twice
The Royce Waterfall Model (1970)- Explicit feedback- “Do it twice”

©USC-CSSE


Increase in software cost to fix vs phase 1976

Increase in Software Cost-to-fix vs. Phase (1976)

1000

1000

Larger Software Projects

500

500

IBM-SSD

GTE

200

200

100

100

Relative cost to fix defect

Relative cost to fix defect

80%

Median (TRW Survey)

50

50

20%

SAFEGUARD

20

20

Smaller Software Projects

10

10

5

5

2

2

1

1

Requirements Design Code Development

Requirements Design Code Development

Acceptance Operation

Acceptance Operation

test

test

test

test

Phase in Which defect was fixed

Phase in Which defect was fixed

©USC-CSSE


1970 s problems with formal methods
1970’s: Problems with Formal Methods

  • Successful for small, critical programs

  • Largest proven programs around 10 KSLOC

  • Proofs show presence of defects, not absence

    • Defects in specification, proofs happen

  • Scalability of programmer community

    • Techniques require math expertise, $500/SLOC

    • Average coder in 1975 survey:

      • 2 years of college, SW experience

      • Familiar with 2 languages, applications

      • Sloppy, inflexible, in over his head, and undermanaged

©USC-CSSE



Reuse and object orientation
Reuse and Object Orientation

  • 1950’s: Math routines, utilities

  • 1960’s: McIlroy component marketplace, Simula – 67

  • 1970’s: Abstract data types, Parnas program families

  • 1980’s: Smalltalk, Eiffel, C++, OO methods, reuse libraries

  • 1990’s: Domain engineering, product lines, UML, pub-sub architectures

  • 2000’s: Model driven development, service oriented architectures

©USC-CSSE



People the most important factor sw engineering is of the people by the people and for the people
People: The Most Important Factor- SW engineering is of the people, by the people, and for the people

  • 1970’s: Weinberg Psychology of Computer Programming

  • 1980’s: COCOMO factor-of-10, Scandinavian Participatory Design, DeMarco-Lister Peopleware

  • 1990’s – 2000’s: Importance emphasized in both Agile and CMM cultures

    • Individuals and interactions over process and tools

    • People CMM, Personal Software Process

  • Overall migration from Reductionism toward Postmodernism (Toulmin)

    • Universal towards Local

    • General towards Particular

    • Timeless towards Timely

    • Written towards Oral

©USC-CSSE


Dual 1990 s early 2000 s antithesis maturity models and agile methods
Dual 1990’s – Early 2000’s Antithesis:- Maturity Models and Agile Methods

  • Predictability and Control: Maturity Models

    • Reliance on explicit documented knowledge

    • Heavyweight but verifiable, scalable

  • Time to Market and Rapid Change: Agile Methods

    • Reliance on interpersonal tacit knowledge

    • Lightweight, adaptable, not very scalable

©USC-CSSE


Agile and plan driven home grounds five critical decision factors
Agile and Plan-Driven Home Grounds: Five Critical Decision Factors

  • Size, Criticality, Dynamism, Personnel, Culture

Personnel

(% Level 1B) (% Level 2&3)

40

15

20

30

20

25

Dynamism(% Requirements – change/month)

Criticality

(Loss due to impact of defects)

10

30

a: Many Livesb: Single Lifec: Essential Fundsd: Discretionary Fundse: Comfort

a

b

0

35

0.3

c

1.0

d

e

3.0

10

30

3

Agile

90

10

70

30

Plan-driven

50

100

30

300

10

Size(# of personnel)

Culture(% thriving on chaos vs. order)

©USC-CSSE


Cots the future is here
COTS: The Future Is Here

  • Escalate COTS priorities for research, staffing, education

    • Software is not “all about programming” anymore

    • New processes required

*

  • CBA: COTS-Based Application

  • * Standish Group CHAOS 2000 (54%)

©USC-CSSE


Persistence of legacy systems
Persistence of Legacy Systems

1939’s Science Fiction World of 2000

Actual World of 2000

  • Before establishing new-system increments

    • Determine how to undo legacy system

©USC-CSSE


Outline1
Outline

  • What have we learned? (chapter 8)

  • Some book highlights

    • People and values (chapters 7, 9)

    • Economics (chapters 2, 3)

    • Processes (chapters 4, 6)

    • Risk Management (chapter 5)

    • Top-10 lists (chapter 1)

  • Where are we going? (chapter 10)

©USC-CSSE


People and values software engineering is of by and for the people
People and Values:Software Engineering Is Of, By, and For the People

  • Of the people

    • People invest in software with an expectation of a valuable return

  • By the people

    • Software is developed by people

  • For the people

    • People use the software to generate value

  • All are success-critical stakeholders

    • As are system administrators, interoperators, and often the general public

©USC-CSSE


Theory w enterprise success theorem and informal proof
Theory W: Enterprise Success Theorem the People– And informal proof

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.

©USC-CSSE


Theory w winwin achievement theorem
Theory W: WinWin Achievement Theorem the People

Making winners of your success-critical stakeholders requires:

  • Identifying all of the success-critical stakeholders (SCSs).

  • Understanding how the SCSs want to win.

  • Having the SCSs negotiate a win-win set of product and process plans.

  • Controlling progress toward SCS win-win realization, including adaptation to change.

©USC-CSSE


Initial vbse theory 4 1 with apurva jain
Initial VBSE Theory: 4+1 the People- with Apurva Jain

  • Engine: Theory W (stakeholder win-win): What values are important?

    • Enterprise Success Theorem

    • Theory of Justice

    • Win-Win Equilibrium and Negotiation

  • Four Supporting Theories

    • Utility Theory: How important are the values?

      • Multi-attribute utility; Maslow need hierarchy

    • Decision Theory: How do values determine decisions?

      • Investment theory; game theory; statistical decision theory

    • Dependency Theory: How do dependencies affect value realization?

      • Results chains; value chains; cost/schedule/performance tradeoffs

    • Control Theory: How to monitor and control value realization

      • Feedback control; adaptive control; spiral risk control

©USC-CSSE


Initial vbse theory 4 1 process with a great deal of concurrency and backtracking
Initial VBSE Theory: 4+1 Process the People– With a great deal of concurrency and backtracking

©USC-CSSE


The Model-Clash Spider Web: the PeopleMaster Net

- Stakeholder value propositions (win conditions)

©USC-CSSE



Red cells indicate lack of consensus. the People

Oral discussion of cell graph reveals unshared information, unnoticed assumptions, hidden issues, constraints, etc.

©USC-CSSE


Expectations management unaffordable response time

$100M the People

Required Architecture:

Custom; many cache processors

$50M

Original Architecture:

Modified

Client-Server

Original Cost

Original Spec

After Prototyping

5

3

1

2

4

Response Time (sec)

Expectations Management:Unaffordable Response Time

©USC-CSSE


Economics chapters 2 3
Economics (Chapters 2, 3) the People

  • COCOMO II and importance of people factors

    • Composite factor-of-10 influence

  • Economics of software productivity and reuse

    • Product line return on investment model (COPLIMO)

    • Realized growth of software productivity

  • Systems engineering return on investment

    • How much architecting is enough?

©USC-CSSE


COCOMO II. 2000 Productivity Ranges the People

Scale Factor Ranges: 10, 100, 1000 KSLOC

e.g., for RESL: 1.18, 1.38, 1.63

Development Flexibility (FLEX)

Team Cohesion (TEAM)

Develop for Reuse (RUSE)

Precedentedness (PREC)

Architecture and Risk Resolution (RESL)

Platform Experience (PEXP)

Data Base Size (DATA)

Required Development Schedule (SCED)

Language and Tools Experience (LTEX)

Process Maturity (PMAT)

Storage Constraint (STOR)

Use of Software Tools (TOOL)

Platform Volatility (PVOL)

Applications Experience (AEXP)

Multi-Site Development (SITE)

Documentation Match to Life Cycle Needs (DOCU)

Required Software Reliability (RELY)

Personnel Continuity (PCON)

Time Constraint (TIME)

Programmer Capability (PCAP)

Analyst Capability (ACAP)

Product Complexity (CPLX)

1

1.2

1.4

1.6

1.8

2

2.2

2.4

Productivity Range

©USC-CSSE


  • Based on COCOMO II software cost model

    • Statistically calibrated to 161 projects, representing 18 diverse organizations

  • Based on standard software reuse economic terms

    • RCR: Relative cost of reuse

    • RCWR: Relative cost of writing for reuse

  • Avoids overestimation

    • Avoids RCWR for non-reused components

    • Adds life cycle cost savings

  • Provides experience-based default parameter values

  • Simple Excel spreadsheet model

    • Easy to modify, extend, interoperate

©USC-CSSE


©USC-CSSE the People


Usual hardware software trend comparison
Usual Hardware-Software the People Trend Comparison

  • Different counting rules

  • Try counting software as Lines of Code in Service (LOCS)

    =  (#platforms) *

    (#object LOCS/platform)

Log N

New transistors

in service/year

HW

SW

New Source Lines of Code/year

Time

©USC-CSSE




Roi of systems engineering
ROI of Systems Engineering the People

  • Strong evidence of systems engineering ROI for software projects

    • Using architecture and risk resolution as proxy

    • No comparable evidence for hardware-software projects

  • Useful in determining how much architecting is enough

    • Less Big Design Up Front for small agile projects

    • Considerably more for very large projects

      • Analysis used to reschedule > 10,000 KSLOC projects

    • How much may vary with other factors

      • More for high assurance; less for rapid change

©USC-CSSE



Cocomo ii resl calibration
COCOMO II RESL Calibration the People

  • Regression analysis: 23 factors, 161 data points

    • Size range: 2.6 – 1,300 KSLOC; 5 above

      1,000 KSLOC

  • Overall Pred(.30) = 75%

    • 80% with local calibration

  • Effect of RESL: range of .0707 in exponent increase

    • Statistically significant: t-value = 2.08

    • Independent of other 22 factors

©USC-CSSE


Effect of scale on roi
Effect of Scale on ROI the People

©USC-CSSE


How much architecting is enough

10000 the People

KSLOC

Sweet Spot

100 KSLOC

Sweet Spot Drivers:

Rapid Change: leftward

High Assurance: rightward

10 KSLOC

How Much Architecting is Enough?

Percent of Project Schedule Devoted to Initial Architecture and Risk Resolution

Added Schedule Devoted to Rework

(COCOMO II RESL factor)

Total % Added Schedule

©USC-CSSE


Processes chapters 4 6
Processes (Chapters 4, 6) the People

  • Waterfall, V-model problems

    • 1-second response time case study above

    • Overdone separation of concerns

  • Spiral model problems

    • Getting started: Win-Win Spiral Model

    • Intermediate milestones

    • Too easy to misinterpret

  • Incremental Commitment Model

    • Based on underlying process principles

    • Principles can strengthen waterfall, V, RUP, spiral models

©USC-CSSE


The separation of concerns legacy
The the People“Separation of Concerns” Legacy

“The notion of ‘user’ cannot be precisely defined, and therefore has no place in CS or SE.”

  • Edsger Dijkstra, ICSE 4, 1979

    “Analysis and allocation of the system requirements is not the responsibility of the SE group but is a prerequisite for their work.”

  • Mark Paulk at al., SEI Software CMM* v.1.1, 1993

* Capability Maturity Model

©USC-CSSE


Resulting project social structure

I wonder when the People

they'll give us our

requirements?

SOFTWARE

AERO.

ELEC.

G & C

MGMT.

MFG.

COMM

PAYLOAD

Resulting Project Social Structure


From the spiral model to the icm
From the Spiral Model to the ICM the People

  • Need for intermediate milestones

    • Anchor Point Milestones (1996)

  • Avoid stakeholder success model clashes

    • WinWin Spiral Model (1998)

  • Avoid model misinterpretations

    • Essentials and variants (2000-2005)

  • Clarify usage in DoDI 5000.2

    • Initial phased version (2005)

  • Explain SoS spiral usage to GAO

    • Underlying spiral principles (2006)

  • Provide framework for human-systems integration

    • National Research Council report (2007)

©USC-CSSE


Life cycle anchor points
Life Cycle Anchor Points the People

  • Common System/Software stakeholder commitment points

    • Defined in concert with Government, industry affiliates

    • Coordinated with Rational’s Unified Software Development Process

  • Life Cycle Objectives (LCO)

    • Stakeholders’ commitment to support system architecting

    • Like getting engaged

  • Life Cycle Architecture (LCA)

    • Stakeholders’ commitment to support full life cycle

    • Like getting married

  • Incremental Operational Capabilities (OCs)

    • Stakeholders’ commitment to support operations

    • Like having children

©USC-CSSE


(Risk-driven level of detail for each element) the People

Milestone Element

Life Cycle Objectives (LCO)

Life Cycle Architecture (LCA)

  • 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

Definition of

Operational

Concept

  • Exercise key usage scenarios

  • Resolve critical risks

  • Exercise range of usage scenarios

  • Resolve major outstanding risks

System Prototype(s)

  • 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

Definition of System

Requirements

  • 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

  • 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

Definition of System

and Software

Architecture

  • Elaboration of WWWWWHH* for Initial Operational

  • Capability (IOC)

  • - Partial elaboration, identification of key TBD’s for later

  • increments

  • 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

Definition of Life-

Cycle Plan

  • Assurance of consistency among elements above

  • - via analysis, measurement, prototyping, simulation, etc.

  • - Business case analysis for requirements, feasible architectures

Feasibility

Rationale

  • Assurance of consistency among elements above

  • All major risks resolved or covered by risk management

  • plan

*WWWWWHH: Why, What, When, Who, Where, How, How Much

Spiral 2005 Anchor Points

©USC-CSSE


Pass fail feasibility rationales
Pass/Fail Feasibility Rationales the People

  • 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

©USC-CSSE



Process model principles
Process Model Principles the People

  • Success-critical stakeholder satisficing

  • Incremental growth of system definition and stakeholder commitment

    3,4. Concurrent, iterative system definition and development cycles

    Cycles can be viewed as sequential concurrently-performed phases or spiral growth of system definition

    5. Risk-based activity levels and anchor point commitment milestones

©USC-CSSE





Risk driven scalable spiral model increment view
Risk-Driven Scalable Spiral Model: the PeopleIncrement View

©USC-CSSE


Risk driven scalable spiral model increment view1
Risk-Driven Scalable Spiral Model: the PeopleIncrement View

©USC-CSSE


Process principles in crosstalk 2002 top 5 software projects
Process Principles in the PeopleCrossTalk 2002 Top-5 Software Projects

©USC-CSSE


Example icm hci application symbiq medical infusion pump winner of 2006 hfes best new design award
Example ICM HCI Application: the PeopleSymbiq Medical Infusion PumpWinner of 2006 HFES Best New Design Award

©USC-CSSE


Symbiq iv pump icm process i
Symbiq IV Pump ICM Process - I the People

  • 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

©USC-CSSE


Symbiq iv pump icm process ii
Symbiq IV Pump ICM Process - II the People

  • Architecting 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

©USC-CSSE


Icm summary
ICM Summary the People

  • Current processes not well matched to future challenges

    • Emergent, rapidly changing requirements

    • High assurance of scalable performance and qualities

  • Incremental Commitment Model addresses challenges

    • Assurance via evidence-based milestone commitment reviews, stabilized incremental builds with concurrent V&V

      • Evidence shortfalls treated as risks

    • Adaptability via concurrent agile team handling change traffic and providing evidence-based rebaselining of next-increment specifications and plans

    • Use of critical success factor principles: stakeholder satisficing, incremental growth, concurrent engineering, iterative development, risk-based activities and milestones

  • Major implications for funding, contracting, career paths

©USC-CSSE


Implications for funding contracting career paths
Implications for Funding, Contracting, Career Paths the People

  • Incremental vs. total funding

    • Often with evidence-based competitive down-select

  • No one-size-fits all contracting

    • Separate instruments for build-to-spec, agile rebaselining, V&V teams

      • With funding and award fees for collaboration, risk management

      • Compatible regulations, specifications, and standards

      • Compatible acquisition corps education and training

    • Generally, schedule/cost/quality as independent variable

      • Prioritized feature set as dependent variable

  • Multiple career paths

    • For people good at build-to-spec, agile rebaselining, V&V

    • For people good at all three

      • Future program managers and chief engineers

©USC-CSSE


Risk management chapters 5 7
Risk Management (Chapters 5, 7) the People

  • Risk management strategies

    • Buying information

    • Risk avoidance

    • Risk transfer

    • Risk reduction

    • Risk acceptance

  • Software-intensive system of systems risks

©USC-CSSE


Is this a risk
Is This A Risk? the People

  • We just started integrating the software

    • and we found out that COTS* products A and B have incompatible HCI’s

  • We’ve got too much tied into A and B to change

  • Our best solution is to build a wrapper around A to make its HCI reasonable compatible with B

  • This will take 3 months and $300K

  • It will also delay integration and delivery by at least 3 months

    *COTS: Commercial off-the-shelf

©USC-CSSE


Is this a risk1

We just started integrating the software the People

and we found out that COTS* products A and B have incompatible HCI’s

We’ve got too much tied into A and B to change

*******

No, it is a problem

Being dealt with reactively

Risks involve uncertainties

And can be dealt with pro-actively

Earlier, this problem was a risk

Is This A Risk?

©USC-CSSE


Earlier this problem was a risk
Earlier, This Problem Was A Risk the People

  • A and B are our strongest COTS choices

    • But there is some chance that they have incompatible HCI’s

    • Probability of loss P(L)

  • If we commit to using A and B

    • And we find out that users can’t live with their HCI differences

    • We’ll add more cost and delay delivery by at least 3 months

    • Size of loss S(L)

  • We have a risk exposure of

    RE = P(L) * S(L)

©USC-CSSE


Risk management strategies buying information
Risk Management Strategies: the People- Buying Information

  • Let’s spend $30K and 2 weeks prototyping the integration of A and B’s HCI’s

  • This will buy information on the magnitude of P(L) and S(L)

  • If RE = P(L) * S(L) is small, we’ll accept and monitor the risk

  • If RE is large, we’ll use one/some of the other strategies

©USC-CSSE


Other risk management strategies
Other Risk Management Strategies the People

  • Risk Avoidance

    • COTS product C is almost as good as B, and its HCI is compatible with A

    • Delivering on time is worth more to the customer than the small performance loss

  • Risk Transfers

    • If the customer insists on using A and B, have them establish a risk reserve.

    • To be used to the extent that A and B have incompatible HCI’s to reconcile

  • Risk Reduction

    • If we build the wrapper right now, we add cost but minimize the schedule delay

  • Risk Acceptance

    • If we can solve the A and B HCI compatibility problem, we’ll have a big competitive edge on the future procurements

    • Let’s do this on our own money, and patent the solution

©USC-CSSE


Top 10 risks software intensive systems of systems crosstalk may 2004
Top-10 Risks: Software-Intensive Systems of Systems the People- CrossTalk, May 2004

  • Acquisition management and staffing

  • Requirements/architecture feasibility

  • Achievable software schedules

  • Supplier integration

  • Adaptation to rapid change

  • Quality factor achievability and tradeoffs

  • Product integration and electronic upgrade

  • Software COTS and reuse feasibility

  • External interoperability

  • Technology readiness

©USC-CSSE


Average change processing time 2 systems of systems
Average Change Processing Time: the People2 Systems of Systems

  • Average number of days to process changes

©USC-CSSE


Effect of unvalidated software schedules
Effect of Unvalidated Software Schedules the People

  • Original goal: 18,000 KSLOC in 7 years

    • Initial COCOMO II, SEER runs showed infeasibility

    • Estimated development schedule in months for closely coupled SW with size measured in equivalent KSLOC (thousands of source lines of code):

      Months =~ 5 * 3√KSLOC

  • Solution approach: architect for decoupled parallel development;

  • Schedule As Independent Variable (SAIV) process

©USC-CSSE


10000

KSLOC

Percent of Project Schedule Devoted to Initial Architecture and Risk Resolution

Added Schedule Devoted to Rework

(COCOMO II RESL factor)

Total % Added Schedule

Sweet Spot

100 KSLOC

Sweet Spot Drivers:

Rapid Change: leftward

High Assurance: rightward

10 KSLOC

©USC-CSSE


The SAIV* Process Model the People

  • Cross Talk, January 2002 (http://www.stsc.hill.af.mil/crosstalk)

1. Shared vision and expectations management

2. Feature prioritization

3. Schedule range estimation and core-capability determination

- Top-priority features achievable within fixed schedule with 90% confidence

4. Architecting for ease of adding or dropping borderline-priority features

- And for accommodating past-IOC directions of growth

5. Incremental development

- Core capability as increment 1

6. Change and progress monitoring and control

- Add or drop borderline-priority features to meet schedule

  • *Schedule As Independent Variable; Feature set as dependent variable

  • Also works for cost, schedule/cost/quality as independent variable

©USC-CSSE


Supplier integration rapid adaptability to change
Supplier Integration: the PeopleRapid Adaptability to Change

  • Risk #4/5. Inflexible subcontracting will be a major source of delays and shortfalls.

  • Strategy #4/5. Develop subcontract provisions enabling flexibility in evolving deliverables. Develop an award fee structure based on objective criteria for:

    - Schedule Preservation

    - Cost Containment

    - Technical Performance

    - Architecture and COTS Compatibility

    - Continuous Integration Support

    - Program Management

    - Risk Management

©USC-CSSE


Top 10 lists chapter 1
Top-10 Lists (Chapter 1) the People

  • Top-10 risk lists

    • Software: 1989, 1995

    • Systems: 2007

  • Defect reduction top-10 list

  • COTS integration top-10 list

©USC-CSSE


Top 10 risk items 1989 and 1995
Top 10 Risk Items: 1989 and 1995 the People

1995

1989

  • Personnel shortfalls

  • Schedules and budgets

  • Wrong software functions

  • Wrong user interface

  • Gold plating

  • Requirements changes

  • Externally-furnished components

  • Externally-performed tasks

  • Real-time performance

  • Straining computer science

  • Personnel shortfalls

  • Schedules, budgets, process

  • COTS, external components

  • Requirements mismatch

  • User interface mismatch

  • Architecture, performance, quality

  • Requirements changes

  • Legacy software

  • Externally-performed tasks

  • Straining computer science

©USC-CSSE


The top ten software risk items 1995
The Top Ten Software Risk Items: 1995 the People

Risk Item

Risk Management Techniques

1. Personnel Shortfalls

Staffing with top talent; key personnel

agreements; incentives; team-building; training;

tailoring process to skill mix; peer reviews

2. Unrealistic schedules

and budgets

Business case analysis; design to cost; incremental

development; software reuse; requirements descoping;

adding more budget and schedule

3. COTS; external components

Qualification testing; benchmarking; prototyping; reference checking; compatibility analysis; vendor analysis; evolution support analysis

4. Requirements mismatch;

gold plating

Stakeholder win-win negotiation; business case

analysis; mission analysis; ops-concept formulation;

user surveys; prototyping; early users’ manual;

design/develop to cost

5. User interface mismatch

Prototyping; scenarios; user characterization

(functionality, style, workload)

©USC-CSSE


The top ten software risk items concluded
The Top Ten Software Risk Items (Concluded) the People

6. Architecture, performance,

quality

Architecture tradeoff analysis and review boards;

simulation; benchmarking; modeling; prototyping;

instrumentation; tuning

7. Requirements changes

High change threshold; information

hiding; incremental development (defer

changes to later increments)

8. Legacy software

Design recovery; phaseout options analysis;

wrappers/mediators; restructuring

9. Externally-performed

tasks

Reference checking; pre-award audits;

award-fee contracts; competitive design

or prototyping; team-building

10. Straining Computer

Science capabilities

Technical analysis; cost-benefit analysis;

prototyping; reference checking

©USC-CSSE


Defect reduction top 10 list
Defect Reduction Top-10 List the People

  • Defect-fixing delays can escalate fix costs by a factor of 100

©USC-CSSE


Defect reduction top 10 list1
Defect Reduction Top-10 List the People

  • Defect-fixing delays can escalate fix costs by a factor of 100

  • Current software projects spend 40-50% on avoidable rework

  • About 80% of rework costs come from 20% of the defects

  • About 80% of the defects come from 20% of the modules

  • About 90% of the downtime comes from 10% of the defects

  • Peer reviews catch about 60% of the defects

  • Perspective-based reviews catch about 35% more defects

  • Disciplined personal practices can reduce defects by 75%

  • Highly-reliable software products cost about an extra 50%

    • Much higher for formal safety and security certification

  • About 40-50% of user programs contain nontrivial defects

©USC-CSSE


COTS Top-10 Empirical Hypotheses-I the People

- Basili & Boehm, Computer, May 2001, pp. 91-93

  • Over 99% of all executing computer instructions come from COTS

    • Each has passed a market test for value

  • More than half of large-COTS-product features go unused

  • New COTS release frequency averages 8-9 months

    • Average of 3 releases before becoming unsupported

  • CBS life-cycle effort can scale as high as N2

    • N = # of independent COTS products in a system

  • CBS post-deployment costs exceed development costs

    • Except for short-lifetime systems

©USC-CSSE


COTS Top-10 Empirical Hypotheses-II the People

  • Less than half of CBS development effort comes from glue code

    • But glue code costs 3x more per instruction

  • Non-development CBS costs are significant

    • Worth addressing, but not overaddressing

  • COTS assessment and tailoring costs vary by COTS product class

  • Personnel factors are the leading CBS effort drivers

    • Different skill factors are needed for CBS and custom software

  • CBS project failure rates are higher than for custom software

    • But CBS benefit rates are higher also

©USC-CSSE


Outline2
Outline the People

  • Motivation and Context

  • A 20th Century View

  • A 21st Century View

  • Conclusions

    • Timeless principles and aging practices

©USC-CSSE


The future of systems and software
The Future of Systems and Software the People

  • Eight surprise-free trends

    • Increasing integration of SysE and SwE

    • User/Value focus

    • Software Criticality and Dependability

    • Rapid, Accelerating Change

    • Distribution, Mobility, Interoperability, Globalization

    • Complex Systems of Systems

    • COTS, Open Source, Reuse, Legacy Integration

    • Computational Plenty

  • Two wild-card trends

    • Autonomy Software

    • Combinations of Biology and Computing

  • ©USC-CSSE


    Pareto 80 20 distribution of test case value bullock 2000
    Pareto 80-20 distribution of test case value the People[Bullock, 2000]

    Actual business value

    100

    100

    80

    80

    % of

    % of

    60

    60

    Value

    Value

    Automated test

    Automated test

    for

    for

    generation tool

    generation tool

    all tests have equal value*

    Correct

    Correct

    -

    -

    40

    40

    Customer

    Customer

    Billing

    Billing

    20

    20

    5

    5

    10

    10

    15

    15

    Customer Type

    Customer Type

    *Usual SwE assumption for all requirements, objects, defects, …

    ©USC-CSSE



    Globalization the world is flat friedman 2005
    Globalization: the People“The World is Flat”- Friedman, 2005

    • Information processing functions can be performed almost anywhere in the world

      • Low-cost global fiber-optic communications

      • Overnight global delivery services

    • Significant advantages in outsourcing to low-cost suppliers

      • But significant risks also

    • Competitive success involves pro-actively pursuing advantages

      • While keeping risks manageable

    ©USC-CSSE


    What does a sisos look like network centric air traffic control
    What does a SISOS look like? the People- Network-Centric Air Traffic Control

    ©USC-CSSE


    Integrated enterprise architectures
    Integrated Enterprise Architectures the People

    Federal Enterprise Architectural Framework (FEAF)

    DOD Architectural Framework (DODAF)

    Zachman Framework

    ©USC-CSSE


    Computational plenty process implications
    Computational Plenty: the PeopleProcess Implications

    • New platforms: smart dust, human prosthetics (physical, mental)

      • New applications: sensor networks, nanotechnology

    • Enable powerful self-monitoring software

      • Assertion checking, trend analysis, intrusion detection, proof-carrying code, perpetual testing

    • Enable higher levels of abstraction

      • Pattern programming, programming by example with dialogue

      • Simpler brute-force solutions: exhaustive case analysis

    • Enable more powerful software tools

      • Based on domain, programming, management knowledge

      • Show-and-tell documentation

      • Game-oriented software engineering education

    ©USC-CSSE


    Wild cards autonomy and bio computing
    Wild Cards: the PeopleAutonomy and Bio-Computing

    • Great potential for good

      • Robot labor; human shortfall compensation

        • 5 Senses, healing, life span, self-actualization

      • Adaptive control of the environment

      • Redesigning the world for higher quality of life

        • Physically, biologically, informationally

    • Great potential for harm

      • Loss of human primacy: computers propose, humans decide

      • Overempowerment of humans

        • Accidents, terrorism, Enron California brownouts

      • New failure modes: adaptive control instability, self-modifying software, commonsense reasoning, bio-computer mismatches

      • V&V difficulties: cooperating autonomous agents, biocomputing

    • Forms and timing of new capabilities still unclear

    ©USC-CSSE


    Outline3
    Outline the People

    • Motivation and Context

    • A 20th Century View

    • A 21st Century View

    • Conclusions

      • Timeless principles and aging practices

    ©USC-CSSE


    Timeless principles and aging practices
    Timeless Principles (+) and Aging Practices (-) the People

    • From the 1950’s

      + Don’t neglect the sciences

      + Look before you leap (avoid premature commitments)

      • Avoid inflexible sequential processes

    • From the 1960’s

      + Think outside the box

      + Respect software’s differences

      - Avoid cowboy programming

    ©USC-CSSE


    Timeless principles and aging practices1
    Timeless Principles (+) and Aging Practices (-) the People

    • From the 1970’s

      + Eliminate errors early

      + Determine the system’s purpose

      • Avoid top-down development and reductionism

    • From the 1980’s

      + These are many roads to increased productivity

      + What’s good for products is good for processes

      - Be skeptical about silver bullets

    ©USC-CSSE


    Timeless principles and aging practices2
    Timeless Principles (+) and Aging Practices (-) the People

    • From the 1990’s

      + Time is money and value to people

      + Make software useful to people

      • Be quick, but don’t hurry

    • From the 2000’s

      + If change is rapid, adaptability trumps repeatability

      + Consider and satisfice all of your stakeholders’ value propositions

      - Avoid falling in love with your slogans (e.g. YAGNI)

    ©USC-CSSE


    Timeless principles and aging practices3
    Timeless Principles (+) and Aging Practices (-) the People

    • For the 2010’s

      + Keep your reach within your grasp

      + Have an exit strategy

      • Don’t believe everything you read

        • “It’s true because I read it on the Internet”

    ©USC-CSSE


    Future challenges for sw engineering education student careers go through 2050 s
    Future Challenges for SW Engineering Education the People- Student careers go through 2050’s

    • Keeping courseware continually up-to-date

    • Anticipating future trends and preparing students for them

    • Separating timeless principles from aging practices

    • Making small student projects relevant to large industry practices

    • Participating in research; incorporating results in courses

    • Helping students learn how to learn

    • Offering lifelong learning to practitioners

    ©USC-CSSE


    ad