software engineering of standalone programs prof. ruth dameron, [email protected] course web site...

Software Engineering of Standalone Programs

Prof. Ruth Dameron, [email protected] web site with course materials is under WebCT

–Need an identikey and password–Call 303-735-HELP

Course web site contents

Go to http://webct.colorado.edu/–Login if you have identikey and user-password

Lecture material -- PowerPoint files–Print in “handout” or in Notes format–“Pure black and white”

Homework assignmentsSome additional items such as short articles or book

excerptsOther course information

–syllabus with reading assignments, holidays– textbook information, PowerPoint lecture files– final exam information–office hours, contact information

Part of a wholeSoftware Engineering Certificate -- 9 hrs graduate credit

–http://ece.colorado.edu/~swengctf/–Software Engineering of Standalone Programs–Software Engineering of Multiprogram Systems–Software Engineering of Distributed Systems

The links at the above web site point to course materials that are not under control of WebCT. –Their purpose is to let you see what is covered in the 3 courses–Warning: Lecture notes that match the ones I use in class

PLUS your homework assignments are the ones that are under WebCT.

Requirements Engineering

Slides originally developed byMichael Madigan

StorageTekManager, PAL Engineering

Cobb’s Paradox

"We know why projects fail, we know how to prevent their failure -- so why do they still fail?”

Martin CobbTreasury Board of Canada Secretariat

Ottawa, Canada

Project Resolution

Resolution Type 1

Project Success

Resolution Type 2

Challenged

Resolution Type 3

Impaired

Cost Overruns

16%4%

9%

10%

30%

31%

<20%21% - 50%51% - 100%101%-200%201%-400%>400%

Percent Over Budget

Time Overruns

14%

18%

20%

36%

11% 1%

<20%

21%-50%

51-100%

101%-200%

201%-400%

>400%

Percent of Time Under Estimated

Content Deficiencies

27%

22%

39%

7% 5%<25%25-49%50-74%75-99%100%

Percent of Originally Planned Functionality

Project Success Factors

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18

Oth

er

Use

r

Invo

lvem

en tEx

ecut

ive

Man

agem

ent

Supp

ort

Pro

per

Pla

nnin

gR

ealis

tic

Exp

ecta

tion

Com

pete

nt S

taff

Sm

alle

r Pro

ject

Mile

ston

es

Cle

ar S

tate

men

t

of R

equi

rem

ents

Ow

ners

hip

Cle

ar V

isio

n

and

Obj

ectiv

esH

ard-

Wor

king

Focu

sed

Sta

ff

Top Ten Project Success Factors

1. user involvement2. executive management support3. clear statement of requirements4. proper planning5. realistic expectations6. smaller project milestones 7. competent staff8. ownership9. clear vision and objectives10. hard-working, focused staff

Properties of Challenged Projects

Lack

of E

xecu

tive

Sup

port

12.8 12.3 11.8

7.5 7 6.4 5.9 5.3 4.3 3.7

23

0

5

10

15

20

25

Oth

er

Lack

of U

ser

Invo

lvem

ent In

c.

Req

uire

men

ts &

Sp

ecs

Tech

nolo

gy

Inco

mpe

tenc

e

Unr

ealis

tic

Exp

ecta

tion

Lack

of R

esou

rces

Cha

ngin

g

Req

uire

men

ts &

S

pecs

Unc

lear

O

bjec

tives

Unr

ealis

tic T

ime

Fram

eN

ew T

echn

olog

y

Top Ten Challenged Project Factors

1. Lack of user involvement2. Incomplete requirements and specifications3. Changing requirements and specifications4. Lack of executive support5. Technology Incompetence6. Lack of Resources7. Unrealistic expectations8. Unclear objectives9. Unrealistic timeframe10. New technology

Properties of Impaired Projects

Unr

ealis

tic

Exp

ecta

tions

Lack

of E

xecu

tive

Sup

port

Lack

of P

lann

ing

Cha

ngin

g

Req

uire

men

ts &

S

pecs

13.112.4

10.69.9

9.38.7

8.17.5

6.3

4.3

9.9

0

2

4

6

8

10

12

14

Oth

er

Inco

mpl

ete

Req

uire

men

ts

Lack

of U

ser

Invo

lvem

ent

Lack

of

Res

ourc

es

Did

n’t N

eed

any

Long

erLa

ck o

f IT

Man

agem

ent

Tech

nolo

gy

Illite

racy

Top Ten Impaired Project Factors

1. Incomplete requirements2. Lack of user involvement3. Lack of resources4. Unrealistic Expectations5. Lack of executive support6. Changing requirements & specs7. Lack of planning8. Didn’t need anymore9. Lack of IT management10. Technology illiteracy

Case Studies

FAILED SUCCESS

SUCCESS CRITERIA POINTS DMV AA HYATT BANCO

1. User Involvement 19 NO (0) NO (0) YES (19) YES (19)

2. Executive Management Support 16 NO (0) YES (16) YES (16) YES (16)

3. Clear Statement of Requirements 15 NO (0) NO (0) YES (15) NO (0)

4. Proper Planning 11 NO (0) NO (0) YES (11) YES (11)

5. Realistic Expectations 10 YES (10) YES (10) YES (10) YES (10)

6. Smaller Project Milestones 9 NO (0) NO (0) YES (9) YES (9)

7. Competent Staff 8 NO (0) NO (0) YES (8) YES (8)

8. Ownership 6 NO (0) NO (0) YES (6) YES (6)

9. Clear Vision & Objectives 3 NO (0) NO (0) YES (3) YES (3)

10. Hard-Working, Focused Staff 3 NO (0) YES (3) YES (3) YES (3)

High Level Software Concepts

Model Based (System) Architecture Software Engineering (MBASE)

Iterative Development(agile methods)

The Model-Clash Spider Web: Master Net7

MBASE Integration Framework7

Process models

Life cycle anchorpoints

Risk managementKey practices

Success models

Business caseIKIWISI

Stakeholder win-win

Property modelsCost

SchedulePerformance

Reliability

Product models

Domain modelRequirementsArchitecture

CodeDocumentation

Planning and control

Milestone content

Evaluation andanalysis

Processentry/exitcriteria

Productevaluation

criteria

What Does a Process Do for You?

A software development process gives you The information you need When you need it In a form that you can use

– As much or as little as you need– Easy to find what you need

Introducing the Rational Unified Process Process Made PracticalProcess Made Practical

Proj. ManagementEnvironment

Business Modeling

ImplementationTest

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Disciplines

Iterations

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Dynamic structure

Sta

tic s

tru

ctu

re

Best PracticesProcess Made Practical Best Practices

Process Made Practical

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

Unified Software Project ManagementTools

Unified Tools for the Project Team Tools

Unified Tools for the Project Team

Requirements Management

Visual Modeling

Automated Testing

Content Management

Change Management


Visual Modeling

Automated Testing

Content Management

Change Management

Plan and ExecuteIterative ProjectsPlan and ExecuteIterative Projects

Measure Progress and Quality


Collaborate & CommunicateProject Information


Unified Software Project Management: an integrated solution to deploy, plan,

execute, and monitor best practices

Unified Software Project Management: an integrated solution to deploy, plan,

execute, and monitor best practices

ToolsUnified Tools for the Project Team

ToolsUnified Tools for the Project Team


Visual Modeling

Automated Testing

Content Management

Change Management


Visual Modeling

Automated Testing

Content Management

Change Management

Plan and ExecuteIterative ProjectsPlan and ExecuteIterative Projects





Select and DeployBest Practices

Select and DeployBest Practices


The disciplined application of scientific principles and techniques for developing, communicating, and managing

requirements.6

Systems Requirements Engineering Lifecycle

User Requirements

SystemRequirements

SystemArchitecture

User Requirements

User RequirementsComponentDevelopment

IntegrationTest

AcceptanceTest

System Development

Capability Development

Component Development

Component Development Lifecycle

SoftwareRequirements

Architecturaldesign

Detailed design & coding

Integration &Verification

User RequirementsUser

RequirementsUser RequirementsComponentDevelopment


R e q u ire m e nts E licita t ion R e q u irem e n ts A n a lys is

R e q u ire m en ts S p e c ifica tion R e q u ire m en ts V e rif ica tion

R e qu irem e nts M a n ag e m e nt

R e q u ire m e n ts E ng in ee ring

R e q u ire m e nts E licita t ion R e q u irem e n ts A n a lys is

R e q u ire m en ts S p e c ifica tion R e q u ire m en ts V e rif ica tion

R e qu irem e nts M a n ag e m e nt

R e q u ire m e n ts E ng in ee ring

Requirements Elicitation


Identify relevant sources of requirements (usually customer)

Determine what information is needed. Analyze the gathered information, looking for

implications, inconsistencies, or unresolved issues Confirm your understanding of the requirements with

the source Synthesize appropriate statements of the requirements

Outcome of good elicitation activities–The buyer/customer fully explore and fully understand their

requirements.–The buyer/customers are able to separate their wants from their

needs.–The buyer/customers are able to understand the capabilities

and limitations of computer technology.–The buyer/customers understand the alternative solutions and

impact of each alternative.–The buyer/customers understand the impact of the

requirements on the developer and themselves.–The developers are solving the right problem.–The developers have confidence that the system to be delivered

is feasible to build.–The developers have the trust and confidence of the customer.–The developers gain domain knowledge of the system

Outcome of poor elicitation effort

–The customer probably will be dissatisfied.–The customer and developer have to cope with

constantly changing requirements.–The developer is solving the wrong problem.–The developer has a difficult time building the system.

Requirements ElicitationUser Involvement Criteria2

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18

Oth

erUse

r

Invo

lvem

en tEx

ecut

ive

Man

agem

ent

Supp

ort

Pro

per

Pla

nnin

gR

ealis

tic

Exp

ecta

tion

Com

pete

nt S

taff

Sm

alle

r Pro

ject

Mile

ston

es

Cle

ar S

tate

men

t

of R

equi

rem

ents

Ow

ners

hip

Cle

ar V

isio

n

and

Obj

ectiv

esH

ard-

Wor

king

Focu

sed

Sta

ff

Project Success Factors

Do I have the right user(s)? Did I involve the user(s)early and often? Do I have a quality user(s)

relationship?

Do I make involvement easy? Did I find out what the user(s)

needs?


Requirements Analysis

Obtain Requirements from all possible sources (include but not limited to):–observation and measurements of the

current system– interviews with customers–current system documentation– feasibility studies–models and prototypes–competitive analysis


Quality attributes

Requirements Specification

Software function Performance External Interfaces Design Constraints Quality Attributes


Statement of Requirements Criteria


Do I have a concise vision? Do I have a functional analysis? Do I have a risk assessment? Do I have a business case? Can I measure the project?

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18Project Success Factors

Requirements Verification

To identify and resolve software problems and high risk issues early in the software cycle.

The assurance that the software requirement specification is in compliance with the system requirements, conforms to document standards, and is an adequate basis for the architectural design.



Basic responsibility is to keep project within costs, within budget, and to meet customers needs.

Estimate cost of system based on requirements.

Control the volatility of the requirements. Manage the requirements configuration of the

system Negotiate requirement changes Re-estimate cost of the system when

requirements change.


Release 1 Release 3Release 2

Requirements Engineering III







Foundation






Foundation











Successful Release Cycle Proportions

4N months

3N months

2N Months

Success Attributes that Requirements Engineering Affect

User InvolvementClear Statement of requirementsProper PlanningRealistic ExpectationsSmaller Project MilestonesClear Vision and ObjectivesHard Working, Focused Staff

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18 Project Success Factors

Requirements Engineering Conclusion


Architecturaldesign

Detailed design & coding


User RequirementsUser

RequirementsUser RequirementsComponent

Development

Software Requirements Engineering includes:–elicitation–analysis–specification–verification and validation–management of requirements

development process Affects 7 of 10 attributes of

successful projects

References

1 The Standish Group, Chaos, January 1995 2 The Standish Group, Unfinished Voyages, September 1995 3 Software Quality Measurement for Distributed Systems,

RADC-TR-83-175 4 Requirements Engineering, Thayer, SMC 10/97, version 2 5 Richard Thayer, Software Requirements Engineering, IEEE,

1997 6 STEP, Operational Requirements for Automated Capabilities,

STEP, 1991 7 MBASE, “Avoiding the Software Model-Clash Spiderweb,”

IEEE Computer, November, 2000, pp. 120-122.

software engineering of standalone programs prof. ruth dameron, [email protected] course web site...

Documents