Software Engineering of Standalone Programs Prof. Ruth Dameron, [email protected] Course web site...
-
Upload
brisa-bayless -
Category
Documents
-
view
216 -
download
2
Transcript of 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
Requirements Management
Visual Modeling
Automated Testing
Content Management
Change Management
Plan and ExecuteIterative ProjectsPlan and ExecuteIterative Projects
Measure Progress and Quality
Measure Progress and Quality
Collaborate & CommunicateProject Information
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
Requirements Management
Visual Modeling
Automated Testing
Content Management
Change Management
Requirements Management
Visual Modeling
Automated Testing
Content Management
Change Management
Plan and ExecuteIterative ProjectsPlan and ExecuteIterative Projects
Measure Progress and Quality
Measure Progress and Quality
Collaborate & CommunicateProject Information
Collaborate & CommunicateProject Information
Select and DeployBest Practices
Select and DeployBest Practices
Requirements Engineering
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
Requirements Engineering
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
SoftwareRequirements
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?
SoftwareRequirements
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
SoftwareRequirements
Quality attributes
Requirements Specification
Software function Performance External Interfaces Design Constraints Quality Attributes
SoftwareRequirements
Statement of Requirements Criteria
SoftwareRequirements
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.
Integration &Verification
Requirements Management
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.
SoftwareRequirements
Requirements Engineering
Requirements Verification
Requirements Analysis
Requirements Specification
Requirements Management
Requirements Elicitation
Release 1 Release 3Release 2
Requirements Engineering III
Requirements Management
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
Foundation
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
Foundation
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
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
SoftwareRequirements
Architecturaldesign
Detailed design & coding
Integration &Verification
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.