310414TESTING1 TESTINGTESTING 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING.
CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to...
Transcript of CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to...
![Page 1: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/1.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Lecture 4
Wael Aboulsaadat
![Page 2: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/2.jpg)
University of Toronto
Introduction to Software Development Lifecycle
SDLC
![Page 3: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/3.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
The Software Crisis: why?
Monolithic development is not effective for modern system development. No process control No product or process guarantees No true management No client confidence No process visibility / traceability No metrication No communication=> no quality!
![Page 4: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/4.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Breaking the Monolithic Model
Done by introducing “steps” into the software development process.
Steps in the development process are called “phases” (or “stages”).
Phases must be self contained and pre-defined. Phases should decrease abstraction as they
progress.
![Page 5: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/5.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Installation
Typical Phases in Software Development
Requirements
Analysis
Feasibility
Design
Implementation
Testing
Maintenance
Retirement
StatementElicitation
Strategy planning
Feasibility study
DetailedSystem
IntegrationComponent
SupportOperations
DetailedSystem
![Page 6: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/6.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
![Page 7: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/7.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
A Software Development Phase
A software development phase: is a delimited period of time within the process of
development of a software system. has a definite starting set of data and a definite
set of results. is based on the results set of earlier phases.
![Page 8: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/8.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Some Advantages of Phased Development
Phased development Offers benchmarking Offers insight Offers mile-stoning niches Offers a documentation-building framework Offers a definite progression sequence Offers possibilities for prototyping Allows end-user and client participation Offers possibilities for better testing strategies
![Page 9: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/9.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
A Development Milestone
A software development milestone is a scheduled event… for which some project member or manager is
accountable. is used to measure progress.
A milestone typically includes: a formal review. the issuance of documents. the delivery of a (sometimes intermediate) product.
![Page 10: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/10.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Development Models Development model definition:
A particular interaction configuration of development phases leading to a final software product.
![Page 11: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/11.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Life Cycle A life-cycle…
is a finite and definite period of time. starts when a software product is conceived. ends when the product is no longer available or
effective for use. Any life-cycle is organised in (composed of)
phases
![Page 12: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/12.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
The Development Life-Cycle
(aka The Software Development Process)
A project is a set of activities, interactions and results.
A life-cycle or a software process is the organisational framework for a project.
![Page 13: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/13.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
The Nature of an Effective Development Model (DM)An effective DM is one that: Effectively links the phases it includes Focuses phases towards a definite goal Provides mechanisms for the controlled
decrease of system abstraction Includes definite milestones Is transparent Is traceable between adjacent phases
![Page 14: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/14.jpg)
University of Toronto
Code-and-Fix model!
![Page 15: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/15.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Code-and-Fix Model No design No
specifications Maintenance
nightmare
The easiest way to develop software
The most expensive way
Typically used by a start-up…
Implement the 1st
Version
Modify until client is satisfied
Postdelivery Maintenance
Maintenance
Development
![Page 16: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/16.jpg)
University of Toronto
Waterfall Model
![Page 17: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/17.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Waterfall model: Linear & Sequential
![Page 18: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/18.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Traditional Artifacts
Needs Analysis &Concept Definition
RequirementsSpecification
Design
Implementation
Integration & Test
Mission Statement
RequirementsDocumentation
DesignSpecification
Code
Test Plans,Procedures,& Results
![Page 19: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/19.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Verification Techniques
User Interviews/Requirements Tracing
Design Reviews
Code Inspections/Static Analysis
Structural &Functional Testing
ProblemReport Analysis
Needs Analysis &Concept Definition
RequirementsSpecification
Design
Implementation
Integration & Test
Operation &Maintenance
Retirement
Needs Analysis &Concept Definition
RequirementsSpecification
Design
Implementation
Integration & Test
Operation &Maintenance
Retirement
Needs Analysis &Concept Definition
RequirementsSpecification
Design
Implementation
Integration & Test
Operation &Maintenance
Retirement
![Page 20: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/20.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Waterfall Model Drawbacks
sequential nature late tangible product maturity
late feedbackto both customer and developer
minimal risk managementfor both customer and developer
late testing maturity
![Page 21: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/21.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Pros and Cons of the Waterfall MethodPros Cons
1. Simple and easy to use. 2. Easy to manage due to
the rigidity of the model – each phase has specific deliverables and a review process.
3. Phases are processed and completed one at a time.
4. Works well for smaller projects where requirements are very well understood.
1. Adjusting scope during the life cycle can kill a project
2. No working software is produced until late during the life cycle.
3. High amounts of risk and uncertainty.
4. Poor model for long and ongoing projects.
5. Poor model where requirements are at a moderate to high risk of changing
![Page 22: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/22.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Winburg Case Study – The Real World Is Different Episode 1: The first version is implemented
Episode 2: A fault is found The product is too slow because of an implementation fault
Episode 3: The requirements change A faster algorithm is used
Episode 4: A new design is adopted Development is complete
Epilogue: A few years later, these problems recur
![Page 23: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/23.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Moving Target Problem!!... Even if the reasons for the change are good, the software product can be
adversely impacted Dependencies will be induced
Any change made to a software product can potentially cause a regression fault A fault in an apparently unrelated part of the software
If there are too many changes The entire product may have to be redesigned and re-implemented
Change is inevitable Growing companies are always going to change If the individual calling for changes has sufficient clout, nothing can be
done about it
There is no solution to the moving target problem
![Page 24: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/24.jpg)
University of Toronto
Rapid Prototyping
![Page 25: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/25.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Rapid Prototyping + Waterfall
UpdateRequirements
ChooseFunctionality
BuildPrototype
InitialRequirements
WriteSpecification
CreateSoftware
WriteTest Plan
![Page 26: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/26.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Rapid Prototyping Model Linear model
“Rapid”
![Page 27: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/27.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Motivation behind Rapid Prototype Model
Increases likelihood that customers and developers are on the same page at time t0
At t1 (>t0) the delivered function is higher for the rapid prototyping approa
Shows overall, that function is closer to needs than the waterfall model
![Page 28: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/28.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
The Rapid Prototyping Model
Goal: explore requirements Without building the complete product
Start with part of the functionality That will (hopefully) yield significant insight
Build a prototype Focus on core functionality, not in efficiency
Use the prototype to refine the requirements Repeat the process, expanding functionality
![Page 29: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/29.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
What is Prototyping?
A definition (A. Davis):A prototype is a partial implementation of a system, constructed primarily to enable customer, end-user, or developer to learn about the problem and/or its solution.
Types: evolutionary / throw-away horizontal / vertical
![Page 30: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/30.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
The (Rapid) Prototyping Model
Goals: to break away from the sequential nature. to speed up feedback. to minimise risks
for both customer and developer to be incomplete but executable. to be cheap and fast.
![Page 31: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/31.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Horizontal Prototyping
func. 1 func. nabstract
physical
![Page 32: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/32.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Vertical Prototyping
func. 1 func. nabstract
physical
![Page 33: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/33.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Decision
Throwaway Prototyping Model
Requirementsspecification
Some minimaldevelopment
The prototype
Discardprototype
not acceptable acceptable
Go on with normal system development
![Page 34: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/34.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
A Visual Representation of The Evolutionary Prototyping Model
Requirementsspecification
Some initialdevelopment
Prototypeversion 1
Some moredevelopment
Prototypeversion 2
etc.
Continue till prototype is
matured
![Page 35: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/35.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Analysis of The Prototyping Model
Improves: breaks the sequential nature. supports fast feedback. offers an opportunity for risk management.
Problems: has no definite (i.e. strictly defined) organisational
structure.
![Page 36: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/36.jpg)
University of Toronto
V-Model
![Page 37: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/37.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
The V-Model
Requirements
System Design
Detailed Design
Implementation
Acceptance Test
Integration Test
Module Test
![Page 38: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/38.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Analysis of the V-Model
Improves testing strategies Does not particularly improve:
sequential nature feedback developmental risk management
![Page 39: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/39.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Miller’s Law At any one time, we can concentrate on only
approximately seven chunks (units of information)
To handle larger amounts of information, use stepwise refinement Concentrate on the aspects that are currently the most
important Postpone aspects that are currently less critical Every aspect is eventually handled, but in order of current
importance
This is an incremental process
![Page 40: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/40.jpg)
University of Toronto
Incremental Model
![Page 41: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/41.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Testing
Implementation
The Incremental Model
Requirements
Global System Design
Maintenance
Detailed design
Testing
Implementation
Detailed design
Testing
Implementation
Detailed design
![Page 42: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/42.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Motivation behind Incremental Model
Deliberately built to satisfy fewer requirements initially, but facilitates incorporation of new requirements which increases adaptability
Initial development time is reduced because of limited functionality
Software can be enhanced more easily for a longer period of time
Stair steps show series of well-defined, planned, discrete builds of the system
![Page 43: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/43.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Analysis of The Incremental Model
Assumes independent sub-systems. Improves (by delivering smaller units):
feedback (in steps) testing
Avoids the production of a monolithic product. Does not particularly improve:
developmental risk management Sequential nature (still present in sub-systems)
![Page 44: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/44.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Incremental Model Strengths
Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced
![Page 45: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/45.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Incremental Model Weaknesses Still requires good planning and design.. Requires early definition of a complete and fully
functional system to allow for the definition of increments
Well-defined module interfaces are required (some will be developed long before others)
Total cost of the complete system is not lower
![Page 46: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/46.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
When to use the Incremental Model Risk, funding, schedule, program complexity, or
need for early realization of benefits. Most of the requirements are known up-front but
are expected to evolve over time A need to get basic functionality to the market
early On projects which have lengthy development
schedules On a project with new technology
![Page 47: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/47.jpg)
University of Toronto
Agile Model
![Page 48: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/48.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Agile SDLC Somewhat controversial new approach…
A collection of new paradigms characterized by Less emphasis on analysis and design Earlier implementation (working software is
considered more important than documentation) Responsiveness to change Close collaboration with the client
![Page 49: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/49.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Agile SDLC – cont’d
Speed up or bypass one or more life cycle phases
Usually less formal and reduced scope
Used for time-critical applications
![Page 50: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/50.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Manifesto for Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
![Page 51: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/51.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Some Agile Methods Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Clear Dynamic Software Development Method
(DSDM) Rapid Application Development (RAD) Scrum Extreme Programming (XP) Rational Unify Process (RUP)
![Page 52: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/52.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Extreme Programming - XP For small-to-medium-sized teams developing
software with vague or rapidly changing requirements
Coding is the key activity throughout a software project
Communication among teammates is done with code
Life cycle and behavior of complex objects defined in test cases – again in code
![Page 53: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/53.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
XP Practices (1-6)1. Planning game – determine scope of the next release
by combining business priorities and technical estimates
2. Small releases – put a simple system into production, then release new versions in very short cycle
3. Metaphor – all development is guided by a simple shared story of how the whole system works
4. Simple design – system is designed as simply as possible (extra complexity removed as soon as found)
5. Testing – programmers continuously write unit tests; customers write tests for features
6. Refactoring – programmers continuously restructure the system without changing its behavior to remove duplication and simplify
![Page 54: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/54.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
XP Practices (7 – 12)7. Pair-programming -- all production code is written with
two programmers at one machine8. Collective ownership – anyone can change any code
anywhere in the system at any time.9. Continuous integration – integrate and build the
system many times a day – every time a task is completed.
10. 40-hour week – work no more than 40 hours a week as a rule
11. On-site customer – a user is on the team and available full-time to answer questions
12. Coding standards – programmers write all code in accordance with rules emphasizing communication through the code
![Page 55: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/55.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
XP is “extreme” becauseCommonsense practices taken to extreme levels
If code reviews are good, review code all the time (pair programming)
If testing is good, everybody will test all the time If simplicity is good, keep the system in the simplest design
that supports its current functionality. (simplest thing that works)
If design is good, everybody will design daily (refactoring) If architecture is important, everybody will work at defining
and refining the architecture (metaphor) If integration testing is important, build and integrate test
several times a day (continuous integration) If short iterations are good, make iterations really, really short
(hours rather than weeks)
![Page 56: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/56.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Unusual Features of XP The computers are put in the center of a large room lined
with cubicles
A client representative is always present
Software professionals cannot work overtime for 2 successive weeks
No specialization
Refactoring (design modification)
![Page 57: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/57.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Evaluating Agile Processes and XP XP has had some successes with small-scale software
development However, medium- and large-scale software development is very
different
The key decider: the impact of agile processes on postdelivery maintenance Refactoring is an essential component of agile processes Refactoring continues during maintenance Will refactoring increase the cost of post-delivery maintenance, as
indicated by preliminary research?
![Page 58: CSC301: Introduction to Software Engineering Lecture 4 · 2015. 7. 7. · CSC301: Introduction to Software Engineering The Software Crisis: why? Monolithic development is not effective](https://reader036.fdocuments.us/reader036/viewer/2022071015/5fce21d3c7c80f4f4e13e248/html5/thumbnails/58.jpg)
University of Toronto
CSC301: Introduction to Software Engineering
Evaluating Agile Processes and XP (contd)
Agile processes are good when requirements are vague or changing
It is too soon to evaluate agile processes There are not enough data yet
Even if agile processes prove to be disappointing Some features (such as pair programming) may be adopted as mainstream
software engineering practices