softwareengg2012 lecture 03
TRANSCRIPT
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 1/44
Software EngineeringBS (Computer Science)
1
Lecture-03Date: 25-02-2012
Dr. S. N Ahsan
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 2/44
Software Engineering
1. Software Construction
2. Software Management
08.10.2011 Dr. S. N Ahsan, IQRA-University 2
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 3/44
Software Engineering
08.10.2011 Dr. S. N Ahsan, IQRA-University 3
Quality Focus
Process
Methods
Tools
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 4/44
Software Common Process Framework
08.10.2011 Dr. S. N Ahsan, IQRA-University 4
A common process framework is established by defining
a small number of framework activities that are applicable
to all software projects, regardless of their size or
complexity.
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 5/44
A Generic Process Framework1. Communication
2. Planning
3. Modeling4. Construction
5. Deployment
08.10.2011 Dr. S. N Ahsan, IQRA-University 5
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 6/44
Umbrella Activities
1. Software Project Tracking and Control
2. Risk Management
3. Software Quality Assurance4. Technical Reviews
5. Measurements
6. Software Configuration Management
7. Reusability Management
8. Work Product Preparation and Production
08.10.2011 Dr. S. N Ahsan, IQRA-University 6
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 7/4408.10.2011
Process Flow
1. Linear Process Flow
2. Iterative Process Flow
3. Evolutionary Process Flow
4. Parallel Process Flow
7Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 8/4408.10.2011
Software Process Models Prescriptive Process Models
1. Waterfall model (Royce, 1970) V-Model: The V-model depicts the relationship of quality assurance
actions to the actions associated with the different step of waterfall
model
2. Incremental Process Models
3. Evolutionary Process Models
Prototyping
Spiral model (Boehm, 1988)
4. Concurrent Models
Specialized Process Models
1. Component Based Development2. The Formal Methods Model
3. Aspect Oriented Software Development
The Unified Process
8Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 9/44
PRESCRIPTIVE-MODEL
9
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 10/44
Prescriptive Process Models
Developed to bring order and structure to
the software development process. To get
away from the chaos of most development processes.
But there is a strong balance between order
and chaos. Absolute order means absence of
variability. Absolute chaos makes coordinationand coherence impossible. Thus, a balance is
needed.
08.10.2011 10Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 11/4408.10.2011
Waterfall Model
Requirements
Design
Implementation
Maintenance
Testing
11Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 12/44
Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability Good for management control (plan, staff, track)
Works well when quality is more important than
cost or schedule
08.10.2011 12Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 13/44
Waterfall Deficiencies
All requirements must be known upfront The following phase should not start until the
previous phase has finished.
Deliverables created for each phase are
considered frozen – inhibits flexibility Integration is one big bang at the end
Little opportunity for customer to preview thesystem (until it may be too late)
08.10.2011 13Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 14/44
When to use the Waterfall Model
Requirements are very well known Product definition is stable
Technology is understood
New version of an existing product Porting an existing product to a new platform.
08.10.2011 14Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 15/44
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 16/44
V-Shaped Strengths
Emphasize planning for verification andvalidation of the product in early stages of
product development
Each deliverable must be testable Project management can track progress by
milestones
Easy to use
08.10.2011 16Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 17/44
V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in
requirements
08.10.2011 17Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 18/44
When to use the V-Shaped Model
Excellent choice for systems requiring highreliability – hospital patient control applications
All requirements are known up-front
When it can be modified to handle changingrequirements beyond analysis phase
Solution and technology are known
08.10.2011 18Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 19/44
Incremental Development Model
08.10.2011 Dr. S. N Ahsan, IQRA-University 19
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 20/44
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
08.10.2011 20Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 21/44
Incremental Model Weaknesses
Requires good planning and design Requires early definition of a complete and fully
functional system to allow for the definition ofincrements
Well-defined module interfaces are required(some will be developed long before others)
Total cost of the complete system is not lower
08.10.2011 21Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 22/44
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
08.10.2011 22Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 23/44
RAD Model
Rapid Application Development – anincremental model that emphasizes a short
development cycle.
Uses component-based construction method.
Does not work for all projects… particularly
large projects or when project is high risk.
08.10.2011 23Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 24/44
RAD Strengths
Reduced cycle time and improved productivitywith fewer people means lower costs
Time-box approach mitigates cost and schedulerisk
Customer involved throughout the completecycle, minimizes risk of not achieving customersatisfaction and business needs
Focus moves from documentation to code(WYSIWYG).
Uses modeling concepts to capture informationabout business, data, and processes.
08.10.2011 24Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 25/44
RAD Weaknesses
Accelerated development process must givequick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed torapid-fire activities in an abbreviated time
frame.
08.10.2011 25Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 26/44
When to use RAD
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments High performance not required
Low technical risks
System can be modularized
08.10.2011 26Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 27/44
Evolutionary Process Models
Software evolves over time (web pages are a prime example)
Limited version is needed to meet business
pressures. Time does not allow a full and complete system
to be developed.
Evolutionary models are iterative as software
engineers develop increasingly more completeand complex systems
08.10.2011 27Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 28/44
Prototyping (Evolutionary Model)
Prototypes are built when goals are general andnot specific.
Prototyping can be used as a standalone process
or by one of the processes presented.
The prototype serves as the first system. Users
get a feel for the actual system and devleopers
get something built quickly.
A prototype is intended for short term use buttoo often they are used much longer.
08.10.2011 28Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 29/44
08.10.2011
Prototyping (Evolutionary Model)
Requirements
Implementation
Design
Testing
Design
Implementation
Testing
Maintenance
29Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 30/44
Prototyping Strengths
Customers can “see” the system requirements asthey are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulatesawareness of additional needed functionality
08.10.2011 30Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 31/44
Prototyping Weaknesses
Tendency to abandon structured programdevelopment for “code-and-fix” development
Bad reputation for “quick-and-dirty” methods
Overall maintainability may be overlooked The customer may want the prototype
delivered.
Process may continue forever (scope creep)
08.10.2011 31Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 32/44
When to use Prototyping
Requirements are unstable or have to beclarified
As the requirements clarification stage of a
waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-
oriented development.
08.10.2011 32Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 33/44
The Spiral Model
An evolutionary model that couples the iterativenature of prototyping with the controlled,
systematic aspects of waterfall model.
Spiral model is often developed in a series of
releases or versions. Is Adobe or Microsoft
working on new releases?
Better for large projects.
08.10.2011 33Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 34/44
Spiral Model (Evolutionary Model)
08.10.2011 Dr. S. N Ahsan, IQRA-University 34
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 35/44
08.10.2011
Risk analysis
Risk analysis
Risk analysis
Risk analysis Proto-
type 1
Prototype 2
Prototype 3Opera-
tional protoype
Concept of Operation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
Code
Unit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Development plan
Requirements planLife-cycle plan
REVIEW
Spiral Model (Evolutionary Model)
35Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 36/44
Spiral Model Strengths
Provides early indication of insurmountablerisks, without much cost
Users see the system early because of rapid
prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
08.10.2011 36Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 37/44
Spiral Model Weaknesses
Time spent for evaluating risks too large for
small or low-risk projects
Time spent planning, resetting objectives, doingrisk analysis and prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-
development phase activities May be hard to define objective, verifiable
milestones that indicate readiness to proceedthrough the next iteration
08.10.2011 37Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 38/44
When to use Spiral Model
When creation of a prototype is appropriate When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because
of potential changes to economic priorities Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research andexploration)
08.10.2011 38Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 39/44
SPECIALIZED PROCESS MODELS
39
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 40/44
Component Based Development
COTS or Commercial Off-The-Shelfcomponents are becoming more available.
Most (not all) COTS components have targeted
functionality with good interfaces that enable
the component to be integrated.
This approach incorporates many of the aspects
of the spiral model.
08.10.2011 40Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 41/44
Formal Methods Development Model
Formal mathematical specification of thesoftware.
Specify, develop and verify by rigourous math
notation.
Eliminates ambiguity, incompleteness, and
inconsistency.
Used more where safety-critical software is
developed, e.g., aircraft avionics, medicaldevices, etc.
08.10.2011 41Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 42/44
Aspect-Oriented SW Development
Nearly all SW has localized features, functionsand information content.
User or customer concerns or needs must be
included. These can be high-level concerns like
security or lower-level such as marketing
business rules or systemic such as memory
management.
08.10.2011 42Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 43/44
Crosscutting Concerns
AOP addresses behaviors that span many, often
unrelated, modules. Core Concerns:
◦ Primary core functionality.
◦ Central functionality of a module.
Crosscutting Concerns:◦ System wide concerns that span multiple
modules.
◦ Cuts across the typical division of
responsibility. OOP creates a coupling between core and
crosscutting concerns.
AOP aims to modularize crosscutting concerns.
08.10.2011 43Dr. S. N Ahsan, IQRA-University
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 44/44
Aspects
In AOP crosscutting concerns are implemented in
aspects instead of fusing them into core modules.
Aspects are an additional unit of modularity.
Aspects can be reused.
By reducing code tangling it makes it easier tounderstand what the core functionality of a
module is.
An “aspect weaver” takes the aspects and the core
modules and composes the final system.