![Page 1: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/1.jpg)
James Nowotarski
18 September 2008
SE 325/425Principles and
Practices of Software Engineering
Autumn 2008
![Page 2: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/2.jpg)
2
Topic Duration
Key models/frameworks (cont.) 60 minutes
Requirements process 30 minutes
*** Break
Requirements process (cont.) 90 minutes
Wrap-up
Today’s Agenda
![Page 3: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/3.jpg)
3
“Why write your own application for word processing or e-mail or, for that matter, supply-chain management when you can buy a ready-made, state-of-the-art application for a fraction of the cost?”
“…more companies [are] replac[ing] customized applications with standardized ones”
Source: Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review, 81(5), 41-49.
Does SE Matter?
![Page 4: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/4.jpg)
4
Who is Fritz Bauer?
• Chairman of 1968 NATO Software Engineering Conference
• Credited with coining the term “software engineering”
![Page 5: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/5.jpg)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 5
What is software engineering?
l Software engineering is an engineering discipline that is concerned with all aspects of software production.
l Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.
![Page 6: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/6.jpg)
6
Software Engineering Body of Knowledge
Software requirementsSoftware designSoftware constructionSoftware testingSoftware maintenanceSoftware configuration managementSoftware engineering managementSoftware engineering processSoftware engineering tools and methodsSoftware quality
Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.org
What is SE?
tonight
![Page 7: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/7.jpg)
7
IT OutsourcingBest jobs in America
1. Software engineer
2. College professor
3. Financial adviser
4. Human resources manager
5. Physician’s assistant
6. Market research analyst
7. Computer/IT analyst
8. Real estate appraiser
9. Pharmacist
10. Psychologist
Source:Kalwarski, T., Mosher, D., Paskin, J. & Rosato, D. (2006, May). 50 best jobs in America. Money. Retrieved September 8, 2008, from http://money.cnn.com/magazines/moneymag/bestjobs/2006/
![Page 8: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/8.jpg)
8
Technology
ProcessPeople
The software engineering discipline consists of people, process, and technology components
Core Concepts
![Page 9: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/9.jpg)
9
Technology1
ProcessPeople
The focus of SE 425 is the process component of software engineering
Core Concepts
Technology1
ProcessPeople
… for the delivery of technology-enabled business solutions
1 SE is primarily concerned with the software subset of technology
![Page 10: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/10.jpg)
10
Systems development life cycle (SDLC) A description of the phases of an
information system
Planning Modeling Construction Deployment
Example
Core Concepts
SDLC is another synonym for software process
![Page 11: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/11.jpg)
11
SDLC model
• The iteration and control strategy adopted by a systems development initiative
• Examples- Waterfall- Iterative/Evolutionary/Spiral- Incremental- Agile
Core Concepts
![Page 12: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/12.jpg)
12
The waterfall model is the granddaddy of life cycle models
Core Concepts
Planning
Modeling
Construction
Deployment
![Page 13: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/13.jpg)
13
Protracted integration and late breakage
Conventional application of the waterfall model typically results in late integration and performance showstoppers
Dev
elop
men
t p
rogr
ess
(% c
oded
)
100%Late designbreakage
Original target date
Source: Royce, W. (1998). Software project management: A unified framework. Addison-Wesley.
Integrationbegins
What’s wrong with waterfall?
![Page 14: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/14.jpg)
14
Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases
M C DVersion 1
M C DVersion 2
M C DVersion 3
Core Concepts
![Page 15: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/15.jpg)
15
Incremental life cycle models advocate delivering the end product piecemeal
M C DVersion 1
M C DVersion 2
M C DVersion 3
Core Concepts
![Page 16: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/16.jpg)
16
Waterfall model
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Source: Royce, W. (1970). "Managing the Development of Large Software Systems."
![Page 17: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/17.jpg)
17
Rational Unified Process (RUP)
![Page 18: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/18.jpg)
18
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
![Page 19: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/19.jpg)
19
In RUP, end product is the result of development cycles
Version 1
Development CycleVersion 2
Development CycleVersion 3
Development Cycle
Product delivered to users
![Page 20: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/20.jpg)
20
Development cycle consists of phases
Development Cycle
Inception Elaboration Construction Transition
![Page 21: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/21.jpg)
21
Phase consists of IterationsDevelopment Cycle
Elaboration
Iterationn Iterationn+1
![Page 22: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/22.jpg)
22
Iteration consists of ActivitiesDevelopment Cycle
Elaboration
Iterationn+1IterationnR
A&D
C
T
R
A&D
C
T
Each phase contains one or more iterations
![Page 23: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/23.jpg)
23
Each Iteration is a mini-waterfall
R
A&D
C
T
R
A&D
C
T
R
A&D
C
T
![Page 24: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/24.jpg)
24
Iterative Advantages/Disadvantages
Advantages
Disadvantages
![Page 25: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/25.jpg)
26Copyright © 1997 by Rational Software Corporation
Risk
Transition
Inception
Elaboration
Construction
PreliminaryIteration
Architect.Iteration
Architect.Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
TransitionIteration
TransitionIteration
Post-deployment
Waterfall
Time
Risk Profile: Iterative vs. Waterfall
Iterative
![Page 26: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/26.jpg)
27
Is RUP = Waterfall in disguise?
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Inception
Elaboration
Construction
Transition
![Page 27: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/27.jpg)
28
Phase boundaries in waterfall are activities
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Phase
Phase
Phase
Phase
Phase
Phase
![Page 28: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/28.jpg)
29
Phase boundaries in RUP are milestones
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
RUP Phase
Milestone
![Page 29: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/29.jpg)
30
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
![Page 30: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/30.jpg)
31
Why focus on risk and change?
Life cycle phase
Co
st
of
ch
an
ge
Req Anal. Des. Impl. Test Prod
y = axp
![Page 31: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/31.jpg)
32
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
![Page 32: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/32.jpg)
33
Why emphasis on executable software?
“Without this first pass, the project manager is at the mercy of human judgment. With this first-pass ‘simulation,’ he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the case of computer program design . . . is invariably and seriously optimistic”
![Page 33: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/33.jpg)
34
RUP Artifacts by Phase and Discipline
Discipline Inception Elaboration Construction TransitionBusiness Modeling
RequirementsVisionUse Cases (20-80%)ActorsSoftware Req SpecGlossary
Analysis & Design Software Arch Doc
Implementation
Build PlanBuildTest Results
Test
Test PlanTest ScriptTest DataTest Results
Test Strategy
DeploymentDeployment Plan Training Materials
Support MaterialsAcceptance Test ResultsChange Requests
Product
Executable ArchitectureUser Interface PrototypeUser Interface DesignUse Case RealizationDesign ModelDatabase Design
Business Architecture
![Page 34: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/34.jpg)
35
RUP Artifacts by Phase and Discipline
Discipline Inception Elaboration Construction Transition
Configuration and Change Management
Project Management Risk ListRisk Mgmt PlanBusiness CaseQA PlanSoftware Dev Plan
Environment
Dev Case (Process)ToolsGuidelinesTemplatesSupport
CM PlanCM EnvironmentChange Requests
![Page 35: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/35.jpg)
36
Agile/Light/Lean Methods
Agile Software Development “Manifesto”
“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”
-- Agile Software Development Alliance, February 11-12, 2001, meeting at Snowbird ski resort
![Page 36: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/36.jpg)
37
Approach References
XP www.extremeprogramming.org
www.xprogramming.com
M. Marchesi et al, Extreme Programming Perspectives, Addison-Wesley, 2002.
Crystal A. Cockburn, Agile Software Development, Addison-Wesley, 2001
SCRUM K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.
Adaptive Software Development
J. Highsmith, Adaptive Software Development, Dorset House, 2000.
FDD S. Palmer, A Practical Guide to Feature-Driven Development, Prentice Hall, 2002.
Agile - General http://www.agilealliance.org/home
http://www.agilemodeling.com
Agile/Light/Lean Methods
![Page 37: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/37.jpg)
39
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
![Page 38: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/38.jpg)
40
XP Conceptual Framework
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Practices
![Page 39: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/39.jpg)
41
Phase boundaries in waterfall are activities
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Phase
Phase
Phase
Phase
Phase
Phase
![Page 40: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/40.jpg)
42
Phase boundaries in RUP are milestones
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
RUP Phase
Milestone
![Page 41: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/41.jpg)
43
XP winds the RUP model more tightly
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Each day on an XP project
FunctioningCode
![Page 42: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/42.jpg)
44
What is XP
Life cycle phase
Co
st
of
ch
an
ge
Req Anal. Des. Impl. Test Prod
y = axp
RUP – “In general, as the project progresses, you should be more careful about introducing change”
![Page 43: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/43.jpg)
45
What is XP
Time
Co
st
of
ch
an
ge
XP purports to change the curve so that the cost to find and repair software problems does not rise dramatically over time
![Page 44: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/44.jpg)
46
What is XP
Quality is assumedExcellent, orInsanely excellent
Quality Work
![Page 45: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/45.jpg)
47
What is XP
Test all the time Continuous integration Pair programming Coding standards Collective ownership Do simplest thing that will work today
“design tomorrow for tomorrow’s problems” Metaphor to aid in understanding the architecture Refactoring and evolutionary design
Key Practices/Features
![Page 46: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/46.jpg)
48
What is XP
Customer on-site as integral part of team Incremental planning
learning to driveprogrammers provide estimates
Short iterations, small releases2 month releases, 2 week iterations
40-hour week
Key Practices/Features (cont.)
![Page 47: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/47.jpg)
49
What is XP
Start design with a test Start coding with a test Test things that might break Testing is isolated Testing is integrated Testing is automated At least one dedicated tester
Begin with the end in mind . . .
![Page 48: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/48.jpg)
50
“Cruft is not allowed to accumulate”
DefinitionAn unpleasant substance, e.g., the dust
that accumulates under your bedResults of shoddy constructionExcess, superfluous junk, e.g., redundant
or superseded code Which XP practice(s) does this pertain
to?
![Page 49: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/49.jpg)
51
RUP vs. XP
Attribute RUP (“Heavyweight”) XP (“Lightweight”)
Time and Effort Allocation 2 weeks-6 months 2 weeks - 2 months
Architecture Stabilized during Elaboration phase
Just enough to support functionality
Scope of Activities and Artifacts
Broad Narrow
Few, simple. Omits: Business modeling Deployment
Project size Small to Very Large Small to Medium
Artifacts 25-30 in small project roadmap
roughly 30
Roles ~ 30 (5 in small project roadmap)
7
![Page 50: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/50.jpg)
52
Topic Duration
Key models/frameworks (cont.) 60 minutes
Requirements process 30 minutes
*** Break
Requirements process (cont.) 90 minutes
Wrap-up
Today’s Agenda
![Page 51: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/51.jpg)
53
Quote
“The hardest single part of building software is deciding what to build” – Fred Brooks
![Page 52: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/52.jpg)
54
Areas of most disruptive change
Software requirements Program design
- Winston W. Royce
![Page 53: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/53.jpg)
55
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
![Page 54: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/54.jpg)
56
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitation Requirementsengineeringtasks (Ch. 7-8)
![Page 55: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/55.jpg)
57
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitationRequirementsengineeringtasks (Ch. 7-8)
elaborationspecification
Chapter 7
Chapter 8
![Page 56: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/56.jpg)
58
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitationRequirementsengineeringtasks (Ch. 7-8)
elaborationspecification
Primarydeliverables
functional reqtsnon-functional reqts(aka quality reqts)
analysis modelsoftware reqts spec(SRS)
![Page 57: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/57.jpg)
IT project failure rates are high
59
Source: Standish Group, 2007
![Page 58: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/58.jpg)
60
Requirements failures #1 root cause (missing and incomplete)
Dr. Dobb’s Portal (www.ddj.com)
Users expect functionality they did not initially ask for (93%)
Requirements are incomplete (89%)
Requirements are unclear or ambiguous (85%)
![Page 59: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/59.jpg)
61
Requirements failures #1 root cause (missing and incomplete)
“[t]he focus on—and availability of—tools that manage requirements during the software development process is detracting attention from the far larger problem of whether or not requirements are accurate in the first place.” Schwaber, C. & Leganza, G. (2006, September 1). The root of the problem: Poor requirements. Forrester
Corroborated by other sources: Gartner, SEI, Standish
![Page 60: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/60.jpg)
62
What is a requirement?
A requirement can be defined simply as a property of a system, or a constraint upon the product or process by which the system is to be created
IEEE Std 610.12-1990 defines a requirement as
A condition or capability needed by a user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
![Page 61: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/61.jpg)
63
Functional vs. Quality Requirements
A functional requirement (FR) describes what the system needs to do.
Example: ‘The system shall display the current customer balance’.
![Page 62: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/62.jpg)
64
Functional vs. Quality Requirements
A quality requirement describes a constraint upon the solution space.
Examples: Performance, flexibility, reliability, usability, portability, maintainability, safety, and security.Also called “non-functional” requirements, “ilities”, or even “systemic” requirements. Emergent Properties: A quality requirement that is realized through the careful implementation of other requirements on which it depends. Example: “The query must return its results in less than three seconds” is only realizable once the architecture and much of the system functionality has been implemented.
![Page 63: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/63.jpg)
65
Quote
“It’s not enough to do good. It must be done well” – St. Vincent de Paul
![Page 64: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/64.jpg)
66
The Requirements Process
Elicitation: Proactively working with stakeholders to discover their needs, identify potential conflicts, and establish a clear scope and boundaries for the project.
Elaboration (Analysis): Gaining a deeper understanding of the product and its interactions.
Specification: Production of a series of documents that capture the system and software requirements in order to support their systematic review, evaluation, and approval.
Validation: Inspecting requirements to ensure their correctness.
Management: Issues such as software configuration management, traceability, impact analysis, and version control.
![Page 65: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/65.jpg)
67
Key Question: Deliverables
Steps Techniques
What does the system need to do?How well does it need to do it?
Systems requirements spec, incl:- Functional requirements- Quality requirements
1. Review as-is system2. Identify requirements of
to-be system
Re-engineering AHPInterviewing PrototypingObservationSurveys/Focus GroupsJoint Application Design (JAD)Benchmarking
Elicitation
Roles Estimating guidelines
Business analyst
![Page 66: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/66.jpg)
Begin with the end in mind - Sample SRSOverviewRevision HistoryTable of Contents1.0 Introduction
1.1 Purpose1.2 Scope1.3 References1.4 Assumptions and Dependencies
2.0 Use-Cases3.0 Requirements
3.1 Functional Requirements3.2 Quality Requirements
3.2.1 Usability3.2.2 Reliability3.2.3 Performance3.2.4 Supportability
4.0 Online User Documentation and Help System
Requirements5.0 Design Constraints6.0 Purchased Components7.0 Interfaces
7.1 User Interfaces7.2 Hardware
Interfaces7.3 Software Interfaces7.4 Communication
Interfaces8.0 Licensing Requirements9.0 Legal, Copyright, and Other
notices10.0 Applicable StandardsIndexGlossary
![Page 67: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/67.jpg)
69
Elicitation Techniques
Collaborative sessions are useful for brainstorming and problem solving activities.
A Joint Application Design (JAD) can bring together a small group of stakeholders to form initial goals and requirements.
Helps to avoid ambiguity
Helps to reduce scope creep
![Page 68: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/68.jpg)
70
Joint Application Design (JAD)
![Page 69: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/69.jpg)
71
Elicitation Techniques
Interviewing techniques are simple yet effective.
Structured around a specific set of questions
Closed ended
Open ended
Can be conducted in stages, so that responses from the first round can be used to generate a deeper set of more focused questions for the second round.
Can be expensive
![Page 70: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/70.jpg)
72
Elicitation Techniques
Observation involves observing the way users interact with an existing system.
Useful when users are unable to fully articulate their needs, or are too busy to attend other types of elicitation meetings. Observe how tasks are executed, problems, shortcuts, & areas for improvement. Sometimes referred to as “going to the gemba”Especially good for uncovering unstated requirements
“Exciting requirements” – Exceed user’s initial expectations
![Page 71: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/71.jpg)
73
Elicitation Techniques
Prototyping – taking an early set of requirements and using them to elicit further requirements.
Low fidelity models useful because for very little cost you can obtain useful feedback from the user. Higher fidelity prototypes enable the user to interact with something closer to the finished product.
![Page 72: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/72.jpg)
74
Elicitation Techniques
Analytic Hierarchy Process (AHP) – a mathematically-based prioritization technique
Represents the elements of any problem hierarchicallyGuides decision makers through a series of pairwise comparisonsResults in quantitative assessment of relative strength of requirements Developed by Dr. Thomas Saaty of the University of Pittsburgh
![Page 73: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/73.jpg)
75
Elicitation Techniques: AHP
Develop QualitySoftware Goal
ArchitectureChoice 1
ArchitectureChoice 2 Alternatives
Performance Usability FlexibilityQualityreqts
![Page 74: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/74.jpg)
76
Elicitation Techniques: AHP
Develop Software
Performance Usability Flexibility
ArchitectureChoice 1
ArchitectureChoice 2
Goal
Alternatives
Qualityreqts
.08 .64 .28
.41.59
![Page 75: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/75.jpg)
77
Context ModelsDetermine the boundaries of the system.
What is the system?What is the system’s environment?
Develop a context model that shows the context of the system within its environment.
Auto-TellerSystem
SecuritySystem
MaintenanceSystem
Branchaccounting
System
BranchcounterSystem
AccountDatabase
UsageDatabase
![Page 76: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/76.jpg)
78
Context Models
Understand the types of interaction the software system has with its adjacent systems.
Some adjacent systems cooperate with your system through two-way communication. Consider them black-box components of your system.
Some adjacent systems initiate events and interact with your system (i.e., people).
Some adjacent systems have one way communication but otherwise work autonomously.
Trigger events that must be specified.
Incoming communication may trigger an event to be specified. Also don’t forget TIMED events
![Page 77: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/77.jpg)
79
Model these interactions as Use Cases
Identify actors
Model their interactions with the system.
Through elicitation fully explore all the ways each actor may interact with the system.
Banking Software Product
Withdraw Money
Customer Teller
![Page 78: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/78.jpg)
80
Use Cases Typical interaction between a user and a computer
system Example: Word use cases
Make some text bold Create an index
Content: A few paragraphs of description Essential tool in requirements capture during Inception
and (mostly) during Elaboration Characteristics
Captures some user-visible function May be small or large Achieves a discrete goal for the user
![Page 79: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/79.jpg)
81
Requirement Qualities
Each individual requirement should be:
Concise
Correct
Non-ambiguous
Feasible
Verifiable
Traceable
Manageable
![Page 80: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/80.jpg)
82
Concise
A requirement should describe a single property of the desired system and should include no information beyond that necessary to describe the intended property.
It should be stated in clear, simple, and understandable terms.
Note the need to define terms such as “Emergency calls” and “Public” in the requirements definition document.
Emergency calls from the public shall be answered in the order in which they are received.
![Page 81: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/81.jpg)
83
Correct
A requirement should accurately describe the intended property of the intended system.
No information missing that is needed to define or implement the system.
The following requirement is obviously (or at least probably should be) incorrect:
When an ambulance crew is dispatched to pick-up a patient more than 2 miles away, they shall wait three minutes before departing in order to give the dispatch operator the chance to locate a closer crew.
![Page 82: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/82.jpg)
84
Non-ambiguous A requirement should be stated clearly and
understandably, in order to avoid ambiguous interpretations.
The following requirement is OBVIOUSLY ambiguous. Why?
How could you fix it?
When a call is received the dispatcher assigns the job to the best crew.
Shoes mustbe worn!
Dogs mustbe carried!
![Page 83: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/83.jpg)
85
Recurring patterns in missing/incomplete requirements
Example use case: (from RAVENFLOW)
User types in a login or a validation request. The system performs the Validate User process or the Verify Password process or the Login Bypass process
If the system determines that the account is pending parental consent, (what if false?) then the system alerts the user. (how?) Note: See the “Request Parental Consent” use case for information on how the system handles this
The system displays the calling application to the user
![Page 84: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/84.jpg)
86
Visualization
Example use case (from RAVENFLOW)
User types in a login or a validation request. The system performs the Validate User process or the Verify Password process or the Login Bypass process
If the system determines that the account is pending parental consent, (what if false?) then the system displays error #146 to the user Note: See the “Request Parental Consent” use case for information on how the system handles this
The system displays the calling application to the user
![Page 85: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/85.jpg)
87
What is wrong with this requirement?
“The same display shall also be able to generate a visible or audible caution/warning sign for the attention of the ambulance driver or medic.”
![Page 86: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/86.jpg)
88
Conjunctions are dangerous…
Disambiguate what the ‘and’ means…
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or input data shall be saved.
We can separate the requirement into multiple parts…
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts.
When the battery low warning lamp lights up the current workspace shall be saved.
The battery low warning lamp shall remain lit until the voltage rises above 3.7 Volts.
?? Go back to the stakeholder
![Page 87: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/87.jpg)
89
Conjunctions are dangerous…
Problems arise when readers try to puzzle out which part applies.
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace shall be saved.
Or disambiguate…
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and then the current workspace shall be saved.
![Page 88: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/88.jpg)
90
Conjunctions are dangerous…
What about this requirement?
An aircraft that is non-friendly and has an unknown mission or the potential to enter restricted airspace within 5 minutes shall raise an alert.
Again – disambiguate and/or precedence. Two options:
An aircraft that is non-friendly and (has an unknown mission or the potential to enter restricted airspace within 5 minutes) shall raise an alert.
If [an aircraft is non-friendly] and [has an unknown mission or the potential to enter restricted airspace within 5 minutes], the system shall <raise> <an alert>.
![Page 89: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/89.jpg)
91
Feasible
A requirement should be feasible from a technical, financial, and managerial perspective.
The following requirement is INFEASIBLE except possibly in a James Bond movie!
This is just overly optimistic wishful thinking because we didn’t specify anything about traffic congestion, location of the patient, distance to the hospital etc.
All patients shall be delivered to a hospital within 5 minutes of their pick-up.
![Page 90: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/90.jpg)
92
Verifiable
A requirement should be written in such a way as to provide a clear and testable acceptance criterion.
For example, it is not sufficient to specify that:
Instead, the requirement should be written in a verifiable form such as:
The dispatcher must be able to quickly identify the closest open emergency room.
The dispatcher must be able to identify the closest open emergency room within 1 second.
![Page 91: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/91.jpg)
93
Traceable
A requirement is traceable if it has been assigned a unique ID and if it is focused on one property.
For example a requirement stating that:
creates traceability problems because it involves tracking the implementation of crew allocations and ambulance allocations.
A driver and medic shall be assigned to an ambulance crew and the crew shall be assigned to an ambulance.
![Page 92: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/92.jpg)
Never build in let-out or escape clauses(if, when, but, except, unless, although)
The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is deployed.
The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has suppressed the alarm.
Don’t ramble
Provided that the designated input signals from the specified devices are received in the correct order where the system is able to differentiate the designators, the output signal shall comply with the required framework of section 3.1.5 to indicate the desired input state.
Refrain from designing the system
The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof hardened rubber shield.
![Page 93: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/93.jpg)
Avoid mixing different kinds of requirements Do not speculate
Users normally require early indication of intrusion into the system.
Do not play on ambiguous requirementsAlways make requirements as clear as possible
Do not use vague undefinable termsThe print dialog shall be versatile and user-friendly
Do not express possibilitiesThe reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed building.
Avoid wishful thinkingThe gearbox shall be 100% safe in normal operationThe network shall handle all unexpected errors without crashing.
![Page 94: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/94.jpg)
96
Manageable
Attributes should be used to support requirements management.
For example:
Date created
Date last edited
Priority (High, Mid, Low etc)
Status (Completed, Undergoing Change, Scheduled, Unassigned).
![Page 95: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/95.jpg)
97
Qualities of a Good Set of Requirements
Realistic: The requirements should represent realistic goals at both the product and project level.
Concise: The requirements as a whole should concisely describe the system that is to be developed. Long-winded requirements create greater opportunity for ambiguity and errors.
Complete: The requirements should collectively describe the entire system to be implemented with no information missing.
Consistent: Inconsistencies between requirements lead to conflicts that prohibit all of the requirements being implemented successfully. Inconsistencies should be identified and conflicts negotiated.
![Page 96: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/96.jpg)
98
Short demo
RAVEN (from RAVENFLOW)
Acts as central repository
Recorded demonstrations
www.ravenflow.com
www.requirementsdevelopment.com
![Page 97: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/97.jpg)
99
Visual Modeling Using UML
Actor A
Use Case 1
Use Case 2
Actor B
user : »ç¿ëÀÚ
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repositorydocument : Document
gFile : GrpFile
9: sortByName ( )
L1: Doc view request ( )
2: fetchDoc( )
5: readDoc ( )
7: readFile ( )
3: create ( )
6: fillDocument ( )
4: create ( )
8: fillFile ( )
Window95
¹®¼ °ü¸® Ŭ¶óÀ̾ðÆ®.EXE
WindowsNT
¹®¼ °ü¸® ¿£Áø.EXE
WindowsNT
Windows95
Solaris
ÀÀ¿ë¼ ¹ö.EXE
Alpha
UNIX
IBM
Mainframe
µ¥ÀÌŸº£À̽º¼ ¹ö
Windows95
¹®¼ °ü¸® ¾ÖÇø´Document
FileManager
GraphicFile
File
Repository DocumentList
FileList
user
mainWnd fileMgr : FileMgr
repositorydocument : Document
gFile
1: Doc view request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
6: fillDocument ( )
7: readFile ( )
8: fillFile ( )
9: sortByName ( )
ƯÁ¤¹®¼ ¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
È ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
È ̧é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.
Openning
Writing
ReadingClosing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close fileUse Case 3
Use casediagram Class diagram
Collaboration diagram
Sequence diagram
Component diagram
Statechartdiagram
Deployment diagram
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
DocumentList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( )
1
File
read( )
read() fill the code..
![Page 98: James Nowotarski 18 September 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader030.vdocuments.us/reader030/viewer/2022032723/56649d0f5503460f949e551a/html5/thumbnails/98.jpg)
100
Read Pressman Chapter 9 Assignment 5 – First presenters
For September 25