A licensed software engineer? - people.cs.aau.dkpeople.cs.aau.dk/~ivan/SOE2005F/SOEmm1.pdfPressman...

Software Engineering & Software Process

Software Engineering 1

A licensed software engineer?

Not Now,Not Like ThisWhy the ACM Council does not support the licensing of

software engineers at this time.

COMMUNICATIONS OF THE ACM February 2000/Vol.43,No.2

September 23, 1999The Mars Climate Orbiter was lost during its

Mars Orbit Insertion (MOI) rocket burn. It

appears that a mix up between English and

Metric units caused a navigation error which

may have sent the orbiter deep into the

atmosphere of Mars.

Reasons why not...the panel interviewed representatives of the Texas Board of

Professional Engineers, one of several groups developing such licensing programs. They were asked, !Why do you want to license software

engineers?" They replied, !To assure the public safety." Therefore, the science aspect of the licensing discussion is the question: Is there a test that will assure the person who passes the test will be quali#ed to write

programs that would never endanger the public? Will that person be quali#ed to sign o$ on program designs to assure they are sound, just as building designs are signed by structural architects to assure the building

is sound? The panel agreed there is no form of licensing that can be instituted today assuring the public safety. Indeed, no one knows how to do that. We do not have building codes for programs. We do not have a vocabulary of program design rich enough to discuss structural integrity.

Much more research is needed before such a test can be devised.

COMMUNICATIONS OF THE ACM February 2000/Vol.43,No.2

Pressman Ch. 1

• Introduction to Software Engineering

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

5

What is Software?

! software is engineered

! software doesn’t wear out

! software is complex


6

Wear vs. Deterioration

idealized curve

change

actual curve

Failurerate

Time

increased failure

rate due to side effects


7

Software Applications

! system software

! application software

! engineering/scientific software

! embedded software

! product-line software

! WebApps (Web applications)

! AI software


8

Software—New Categories

! Ubiquitous computing—wireless networks

! Netsourcing—the Web as a computing engine

! Open source—”free” source code open to the computing

community (a blessing, but also a potential curse!)

! Also … (see Chapter 32)

! Data mining

! Grid computing

! Cognitive machines

! Software for nanotechnologies


9

Legacy Software

! software must be adapted to meet the needs of new

computing environments or technology.

! software must be enhanced to implement new business

requirements.

! software must be extended to make it interoperable with

other more modern systems or databases.

! software must be re-architected to make it viable within a

network environment.

Why must it change?

Pressman Ch. 2

• A Generic View of Process


11

A Layered Technology

Software Engineering

a “quality” focus

process model

methods

tools


12

A Process Framework

Process framework

Framework activities

work tasks

work products

milestones & deliverables

QA checkpoints

Umbrella Activities


13

Framework Activities

! Communication! Planning! Modeling

! Analysis of requirements

! Design

! Construction! Code generation

! Testing

! Deployment


14

The CMMI

! The CMMI defines each process area in terms of

“specific goals” and the “specific practices” required to

achieve these goals.

! Specific goals establish the characteristics that must

exist if the activities implied by a process area are to be

effective.

! Specific practices refine a goal into a set of process-

related activities.

CMMI Model Components

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

Ability

Implementation

Verifying

to Perform

Commitment Directing

Implementation

Specific Goals

Implementation

Specific Practices

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

Ability

Implementation

Verifying

to Perform

Commitment Directing

Implementation

Specific Goals

Implementation

Specific Practices

Capability Maturity Model® Integration (CMMISM), Version 1.1

Basic Process Management Process Areas

OPF OPDResources and

coordination

OT

Standard processand other

assets

Training for projects and support groups in standard process and assets

Organization’sprocess needsand objectives

Standard processand other

assets

Senior

management

Organization’sbusiness objectives

Project Management,Support, and Engineering

process areas

Training needs

Improvement information(e.g., lessons learned, data, artifacts)

Process improvement

proposals; participation in

defining, assessing, and

deploying processes


Basic Project Management Process Areas

PPWhat to build

What to do

SAM

PMC

What

to monitor

Replan

Plans

Status, issues,

results

of progress and

milestone

reviews

Product component requirements,

technical issues,

completed product components,

acceptance reviews and tests

Engineering and Supportprocess areas

Status, issues, results

of process and product evaluations;

measures and analyses

Commitments

Measurement needs

Corrective action

Supplier

Supplier

agreement

Corrective

action


© 2003 by Carnegie Mellon University

CMMI®!"

A House in Four Hours

!Building Industry Association, San Diego, CA, 1997.

Start at t0 t0 + 2hrs 45 min


CMMI®!"

Process Observations

Building the four-hour house as it parallels product development processes:

• Plan the work

• Monitor and measure the work

• Design before building the product

• Analyze and commit to the design

• Integrate the product

• Create team experience before, not during, the build

• Reuse knowledge of past designs and builds

• Utilize highly skilled staff


CMMI®!"

One Model, Two Representations

Maturity Level 5 OID, CAR

Maturity Level 4 OPP, QPM

Maturity Level 3 REQD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR

Overview Introduction Structure of the Model Model Terminology Maturity Levels, Common Features, and Generic Practices Understanding the Model Using the Model

Maturity Level 2 REQM, PP, PMC, SAM, MA, PPQA, CM

Appendixes

Engineering REQM, REQD, TS, PI, VER, VAL

Project Management PP, PMC, SAM IPM, RSKM, QPM

Process Management OPF, OPD, OT, OPP, OID

Process Management PAs - Goals - Practices

Support CM, PPQA, MA, CAR, DAR

Appendixes

CMMI-SE/SWStaged

Overview Introduction Structure of the Model Model Terminology Capability Levels and Generic Model Components Understanding the Model Using the Model

CMMI-SE/SWContinuous

CMMI-SW

Staged

Representation

CMMI-SW

Continuous

Representation


CMMI®!"

Understanding CMMI Representations

A representation allows an organization to pursue different improvement objectives and presents model components differently. The content is nearly identical in both representations.

So why both?

• The representation of each source model was different

- Software CMM—Staged

- SE-CMM, SECM—Continuous

• Ease adoption by legacy communities.

• Both representations provide inherent benefits.


CMMI®!"

Advantages of Each Representation

Continuous Representation Staged Representation

Provides maximum flexibility for order of process improvement

Predefined and proven path with case study and ROI data

High visibility of improvement within process areas

Focuses on organizational improvement

Easy upgrade from EIA 731 Easy upgrade from SW-CMM

Easy comparison to ISO 15504 Provides familiar benchmarking capability

Improvement of process areas can occur at different rates

Overall results summarized in a maturity level

CSSACepeda Systems & Software Analysis, Inc.

200209–CSSA0001 – Copyright 2004, CSSA, Inc.

Staged

Continuous

CMMI IN A NUTSHELL

PA PA

Cap

ab

ilit

y0

1

2

3

4

5

ProcessPA

ML 1

ML2

ML3

ML4

ML5

Organization

Maturity Level 5 OID, CAR

Maturity Level 4 OPP, QPM

Maturity Level 3 RM, TS,

PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR, OEI, IT, ISM

Maturity Level 2 REQM, PP,

PMC, MA, PPQA, CM, SAM

Process Areas (SE/SW/IPPD/

SS)Requirements Management (REQM)Project Planning (PP)Project Monitoring and Control (PMC)Measurement and Analysis (MA)Process and Product Quality Assurance (PPQA)Configuration Management (CM)Supplier Agreement Management (SAM)

Requirements Development (RD)Technical Solution (TS) Product Integration (PI)Verification (VER)Validation (VAL)Organizational Process Focus (OPF)Organizational Process Definition (OPD)Organizational Training (OT)Integrated Project Management (IPM)Risk Management (RSKM)Decision Analysis and Resolution (DAR)Organizational Environment for Integration (OEI)Integrated Teaming (IT)Integrated Supplier Management (ISM)

Organizational Process Performance (OPP)Quantitative Project Management (QPM)

Organizational Innovation & Deployment (OID)Causal Analysis and Resolution (CAR)

Support CM, PPQA, MA,

CAR, DAR, OEI

Engineering REQM, RD, TS, PI,

VER, VAL

Project

ManagementPP, PMC, SAM,

ISM, IPM, RSKM,

QPM, IT

Process

Management OPF, OPD, OT,

OPP, OID

" Two Representations Per CMMI Model " One Appraisal Method (SCAMPI)



BUSINESS CASE FOR CMMI (1 OF 3)

Reduced Development/ Maintenance Costs

Improved Productivity

Less Rework

Increased Revenue/Profitability

Improved Customer Satisfaction

Reduced Post-Release Defects

Measurable Improvements of Reliability and Quality

Repeat Business

Increased Product Sales

Reduced Cycle Time

Improved Process Performance

Enhanced Time-to-Market

Performance

Bonuses for Early Delivery

Improved Professional Staff

Improved Employee Morale

Increased Developer and Maintainer Confidence

Reduced Employee Turnover and

Retraining Costs

Improved Competitive Advantage

Better Products – Not Just Software – Out Sooner And Cheaper



0

5

10

15

20

25

30

35

40


Improvements From Adopting SW-CMM (SEI, 1994)

Savings vs.

cost of

software

process

improvement

(median) 5:1

Pe

rce

nta

ge

Im

pro

ve

me

nt

Annual Medians

+35%

-19%

Tim

e t

o

Mark

et

-39%

Po

st-

Rele

ase

Defe

ct

Rep

ort

s

Pro

du

cti

vit

y

Current ROI Valueto Programs

(DACS, 1999)

Application of SPI to “Example Organization

With Example Projects”:

Development

Costs

Reduced

73%

Rework Costs Reduced 96%

Average

Schedule

Length

Reduced

37%

Post-Release

Defects

Reduced

80%

Weighted Risk

Likelihood

Reduced

92%

Return On

Investment

21:1

Expect Higher ROI For CMMI

200209–CSSA0001 –


Copyright 2004, CSSA, Inc.


DoD Contractors Have Additional Motivation To Transition To The CMMI

DoDCustomers

Associate

ContractorsSuppliers

Competitors

• May Require Organizational Maturity or Process Capability in RFP, Implicitly or Explicitly

• May Use Organizational Maturity or Process Capability As a Discriminator• Will Use

Organizational Maturity or Process Capability to Advise Customers

• Will Use Organizational Maturity or Process Capability to Competitive Advantage

• Improve Integration of

Products and Services

• Improve Integration of Products and Services

• Provide Insight Into Supplier Performance and Quality


27

Process Patterns

! Process patterns define a set of activities, actions, work

tasks, work products and/or related behaviors

! A template is used to define a pattern

! Typical examples:! Customer communication (a process activity)

! Analysis (an action)

! Requirements gathering (a process task)

! Reviewing a work product (a process task)

! Design model (a work product)


28

Process Assessment

! The process should be assessed to ensure that it meets

a set of basic process criteria that have been shown to

be essential for a successful software engineering.

! Many different assessment options are available: ! SCAMPI

! CBA IPI

! SPICE

! ISO 9001:2000


29

Assessment and Improvement

Software Process

Software Process

Assessment

is examined by identifies capabilities

and risk of

identifies

modifications to

Software Process

Improvement

Capability

Determinationleads to leads to

motivates


30

Personal Software Process (PSP)

! Recommends five framework activities:! Planning

! High-level design

! High-level design review

! Development

! Postmortem

! stresses the need for each software engineer to

identify errors early and as important, to

understand the types of errors


31

Team Software Process (TSP)

! Each project is “launched” using a “script” that

defines the tasks to be accomplished

! Teams are self-directed

! Measurement is encouraged

! Measures are analyzed with the intent of

improving the team process


32

The Primary Goal of Any Software Process:

High Quality

Remember:

High quality = project timeliness

Why?

Less rework!

Software Engineering?

• A traditional metaphor:Software Engineering as Software

• A competing metaphor:Software Enginering as Cultivation

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34

What is Software?

Software is a set of items or objects that form a “configuration” that includes • programs • documents • data ...

Watts Humphrey

!When a process is under statistical control, repeating the work roughly the same way will produce roughly the same result. To obtain consistently better results, it is thus necessary to improve the process. If the process is not under statistical control, sustained progress is not possible until it is"

W. S. Humphrey, Managing the Software Process, 1. ed. Reading, Massachusetts: Addison-

Wesley Publishing Company, 1989.

Leon Osterveil

Osterweil advocated, !that we describe software processes by !programming" them much as we !program" computer applications. We refer to the activity of expressing software process descriptions with the aid of programming techniques as process programming, and suggest that this activity ought to be at the center of what software engineering is all about"

L. J. Osterweil, “Software Processes are Software Too,” presented at Proceedings of the

Ninth International Conference on Software Engineering, Monterey, CA, 1987.

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

www.agilemanifesto.org

A licensed software engineer? - people.cs.aau.dkpeople.cs.aau.dk/~ivan/SOE2005F/SOEmm1.pdfPressman...

Documents

Transcript of A licensed software engineer? - people.cs.aau.dkpeople.cs.aau.dk/~ivan/SOE2005F/SOEmm1.pdfPressman...