Software engg. pressman_ch-3
-
Upload
dhairya-joshi -
Category
Technology
-
view
371 -
download
0
Transcript of Software engg. pressman_ch-3
![Page 1: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/1.jpg)
1
![Page 2: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/2.jpg)
Software life cycle model software life cycleseries of identifiable stages that a
software product undergoes during its lifetime
software life cycle modelIt is a descriptive and diagrammatic
representation of software life cycle
2
![Page 3: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/3.jpg)
Why Software life cycle model?It encourages development of s/w in a
systematic and discipline way
It is necessary to have precise understanding among team members otherwise it will lead to chaos and project failure
3
![Page 4: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/4.jpg)
PHASE ENTRY AND EXIT CRITERIA Every software life cycle model normally
define entry and exit criteria every phase
A phase can begin only when corresponding phase entry are satisfied
4
![Page 5: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/5.jpg)
99% complete syndrome When there is no clear specification of the
entry and exit criteria for every phase and if no life cycle model is followed
It becomes very difficult to chart the progress of the project
5
![Page 6: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/6.jpg)
Software process modelAttempt to organize the software life cycle
by defining activities involved in software production order of activities and their relationships
Goals of a software processstandardization, predictability, productivity,
high product quality, ability to plan time and budget requirements
![Page 7: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/7.jpg)
Code&FixThe earliest approach Write code Fix it to eliminate any errors that have
been detected, to enhance existing functionality, or to add new features
Source of difficulties and deficiencies impossible to predict impossible to manage
![Page 8: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/8.jpg)
Models are neededSymptoms of inadequacy: the software
crisisscheduled time and cost exceededuser expectations not metpoor quality
The size and economic value of software applications required appropriate "process models"
![Page 9: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/9.jpg)
The Waterfall Model
9
![Page 10: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/10.jpg)
Waterfall Model Assumptions
10
1. The requirements are knowable in advance of implementation.
2. The nature of the requirements will not change very much During development; during evolution
3. The requirements are compatible with all the key system stakeholders’ expectations e.g., users, customer, developers, maintainers,
investors
4. The right architecture for implementing the requirements is well understood.
5. There is enough calendar time to proceed sequentially.
![Page 11: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/11.jpg)
Process for Offshore?
11
Deploy
Analysis
Design
Accept. test
Construct
System test
![Page 12: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/12.jpg)
12
![Page 13: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/13.jpg)
Disadvantages of waterfall model
Real projects rarely follow sequential flow
Difficult for the customer to state all requirements
Customer to show patience. Working version of program will not be available until late in the project
13
![Page 14: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/14.jpg)
Evolutionary Models: Prototyping
14
![Page 15: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/15.jpg)
Prototyping modelThis begins with requirement gathering . Developer and customer meet and define overall objectives for the s/w
Then quick design occurs which focus on representation of those aspects of the s/w that are visible to customer
After the quick design prototype is build and then evaluated and feedback given
15
![Page 16: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/16.jpg)
16
![Page 17: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/17.jpg)
Evolutionary process modelsAll the linear sequential models are design
for straight line developmentIn waterfall model complete system will be
delivered after linear sequence is completedThe prototyping is designed to assist the
customer in understanding requirements
17
![Page 18: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/18.jpg)
Incremental Models: Incremental
18
![Page 19: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/19.jpg)
Incremental modelThe incremental model combines elements of
linear sequential model with iterative nature of prototyping
For example: word processing s/wFirst increment product is core product which
is used by customer in which modifications he can add
The process is repeated until the complete product is produced
19
![Page 20: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/20.jpg)
Usefulness of the model When staffing unavailable for whole
complete implementation by business deadline
Increments can be planned to manage technical risks
Best when: you encounter a difficult deadline that cant be changed
20
![Page 21: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/21.jpg)
21
If we rely on testing alone, defects created first are detected last
SystemRequirements
SoftwareRequirements
SoftwareDesign
SoftwareImplementation
UnitTesting
IntegrationTesting
SoftwareTesting
SystemTesting
system test plan
software test plan
integration plan
unit plan
ProductRelease
time
UserNeed
![Page 22: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/22.jpg)
Incremental Models: RAD Model
22
![Page 23: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/23.jpg)
Risk Exposure
23
![Page 24: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/24.jpg)
Unified Process Model
24
A software process that is:A software process that is:
use-case drivenuse-case driven architecture-centricarchitecture-centric iterative and incrementaliterative and incremental
Closely aligned with theClosely aligned with the
Unified Modeling Language Unified Modeling Language (UML)(UML)
![Page 25: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/25.jpg)
The Unified Process (UP)
25
inceptioninception
![Page 26: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/26.jpg)
UP Work Products
26
inceptioninception
![Page 27: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/27.jpg)
Lifecycle for Enterprise Unified Process
27
inceptioninception
![Page 28: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/28.jpg)
Synchronize-and Stabilize Model Microsoft’s life-cycle model Requirements analysis—interview
potential customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small
teams working in parallel
28
![Page 29: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/29.jpg)
Synchronize-and Stabilize Model (contd) At the end of the day—synchronize (test
and debug) At the end of the build—stabilize (freeze
build) Components always work together
› Get early insights into operation of product
29
![Page 30: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/30.jpg)
Evolutionary Models: The Spiral
30
![Page 31: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/31.jpg)
Spiral ModelSimplified form
Waterfall model plus risk analysis
Precede each phase byAlternativesRisk analysis
Follow each phase byEvaluationPlanning of next
phase 31
![Page 32: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/32.jpg)
Simplified Spiral Model
32
If risks cannot be resolved, project is immediately terminated
![Page 33: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/33.jpg)
Full Spiral ModelRadial dimension: cumulative cost to
dateAngular dimension: progress through
the spiral
33
![Page 34: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/34.jpg)
Full Spiral Model (contd)
34
![Page 35: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/35.jpg)
Analysis of Spiral ModelStrengths
Easy to judge how much to testNo distinction between development, maintenance
WeaknessesFor large-scale software only For internal (in-house) software only
35
![Page 36: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/36.jpg)
Object-Oriented Life-Cycle Models
Need for iteration within and between phasesFountain modelRecursive/parallel life cycleRound-trip gestaltUnified software development process
All incorporate some form of IterationParallelism Incremental development
DangerCABTAB
36
![Page 37: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/37.jpg)
Fountain ModelFeaturesOverlap
(parallelism)Arrows
(iteration)Smaller
maintenance circle
37
![Page 38: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/38.jpg)
Software Process Spectrum
38
lightweight heavyweightmiddleweight
XPSCRUM
DSDMFDD RUPdX
ICONIXCrystal Clear Crystal Violet
EUPOPEN
![Page 39: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/39.jpg)
ConclusionsDifferent life-cycle modelsEach with own strengthsEach with own weaknessesCriteria for deciding on a model include
The organization Its managementSkills of the employeesThe nature of the product
Best suggestion “Mix-and-match” life-cycle model
39
![Page 40: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/40.jpg)
40
![Page 41: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/41.jpg)
What is MDA in essence?Automated approach to translate high
level design to low level implementation by means of separation of concerns
From high-level model to running application
Risk proportional to expectations!41
![Page 42: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/42.jpg)
Finding the “right” language
42
Assembler
3GL
IDEs & 4GL
Model Driven Architecture
Computer Hardware
DeveloperA
uto
matio
n
Ab
straction
![Page 43: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/43.jpg)
Martin FowlerMartin Fowler
43
![Page 44: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/44.jpg)
Model Driven ArchitectureCan you actually have incremental MDA?
Or is it automated waterfall?
Need rigorous modelsNeed high quality requirements
Capture requirementsUnderstand requirements
44
![Page 45: Software engg. pressman_ch-3](https://reader038.fdocuments.us/reader038/viewer/2022110307/55598227d8b42a65298b5757/html5/thumbnails/45.jpg)
MDA or Offshore?Automation versus reduce cost of labor
ObjectivesReduce required intelligenceIncrease repetition
GoalReduce costs of development
45