Documente Academic
Documente Profesional
Documente Cultură
Requirements
Analysis
Design and
Specification
Coding and
unit testing
Integration and
system testing
Maintenance
Feasibility study
• Systems Engineering and Information
Engineering
• Abstract definition of the problem
• Formulation of alternative strategies
• Examination of alternatives
– Resources required and available
– Development cost and time
– Cost-benefit analysis
Requirement Analysis
• Requirement Analysis
– Interviews and discussions
– Incomplete views
– Ambiguities and contradictions
• Requirements Specification
• User manual
• System test plan
• End product - SRS Document
Design
• Translation of SRS into a structure that is
suitable for implementation
• Traditional design approach
– Structured Analysis – DFD
– Architectural design
– Detailed design
• Object oriented design
– Identification of objects and relationships
– Detailed design
• End product – A set of design documents
Coding and Unit Testing
• Translation of designs to source code
• Testing each program module
• End product – a set of program modules
that are individually tested.
Integration and Unit Testing
• Partial integration and testing
• System testing
– Alpha testing
– Beta testing
– Acceptance testing
Maintenance
• Corrective
• Perfective
• Adaptive
Variations of waterfall model
(Royce, 1970)
Requirements
Analysis
Design and
Specification
Coding and
unit testing
Integration and
system testing
Maintenance
Variations of Waterfall Model
Feasibility Study
Validation (Boehm, 1981)
Software Plans and
Requirements Analysis
Validation
Product Design
Verification
Detailed Design
Verification
Coding
unit testing
Integration
Product Verification
Implementation
System Test
Maintenance
Revalidation
Waterfall Model (Pressman, 2005)
Communication
project initiation
requirements gathering
Planning
Estimating
scheduling
tracking
Modeling
Analysis
Design
Construction
code test
Deployment
delivery,
support
feedback
Assumptions of waterfall model
• Unidirectional flow of control among the phases
• Downward flow of primary information and
developmental effort.
• Work can be divided according to phases
among different classes of specialists.
• It is possible to associate a goal for each phase
(the exit condition)
• Output of one phase is used as input to the next
phase after review, verification and validation
(Limited iterative flow)
Assumptions of waterfall model
• Output of each phase is frozen.
– Baseline – check point
– Configuration management
• It is possible to create different
development tools suitable to the
requirements of each phase
• Phases provide the basis for management
and control
Economic rationally Behind
Waterfall Model (Boehm)
• All phases and their associated goals are
necessary
• Any different ordering of the phases will
produce a less successful software.
Usefulness of the waterfall model
• Complete specification of the system before it is
built
• Understanding interaction of the components
before coding
• More accurate tracking of the project and early
discovery of the schedule slippage
• Documentation for ease of testing and
maintenance
• Reduced development and maintenance cost
• More structured and manageable system.
Shortfalls of Waterfall Model
• Protracted Integration and Late Design Breakage
– Blocking state of developers
– Working version takes long time to come up
– Non-optimal-fixes, little time for redesign, late delivery of a non-
maintainable product
• Late Risk Resolution
– Risk: the probability of missing cost, schedule, feature, or quality
goal
– High at the requirement phase
• Requirement driven Functional decomposition
– customers must state all requirements explicitly
– All the requirements are equally important and do not change over
the SDLC
– Decomposition of requirements to functions and sub functions
• Adversarial stakeholder relationship
As a result
Real projects rarely follow this model
A Critique of the Waterfall Model
• rigid
• monolithic
• Heavily document driven hence
bureaucratic
As a result
Many refinements are proposed
• Incremental Model
• Evolutionary Model
• Spiral Model
The Incremental model
• Applying linear sequence in a staggering
manner
• First increment is the core product
• Focuses on the delivery of an operational
product
• Useful when staffing is inadequate
• Technical risk can be handled
The Incremental model
Communication
Planning
Software Functionality and Features
Modeling
Construction
Deployment
Calendar Time
The RAD Model
(Rapid application development)
Communication
• Shortfalls Modeling
Modeling
– Commitment of the
Deployment
team members
Construction
– Appropriate Team #n
modularization Modeling
Planning
– Not suitable for high
Construction
technical risk projects
Component Based Models
-Software Reuse
Requirements Detail Design of the
Remaining
Components
Design of
Architecture
Coding and Unit of
the Remaining
Components
Component
Specification
Delivery
Advantages of Software Reuse
• Increases system reliability
• Reduces overall project risk due to less
uncertainty in cost estimates
• Effective use of specialists in developing generic
components than in a wide array of variety of
products
• Embodiment of organizational standards in
reusable components, such as user interface
and error handling procedures
• Reduction of software development time.
Guideline for Software Reuse
• Generalized
– Names, operations, exceptions
• Documented
• Availability of test cases
Common Problems of
Software Reuse
• Portability
– Transportation
– Adaptation
• Customization
Cleanroom Software Development
• Suitable for the systems that have stringent
safety, reliability and security requirements.
• Formal specification of the requirements
• Incremental development strategy
• Structured programming
• Static verification of the individual build using
mathematically based correctness argument
• Statistical testing with the help of reliability
growth models
The Prototyping Model
• Iterative in nature
• Customers are unsure of Communication
their requirement
• Developers are unsure of Quick Plan
the development
environment Deployment,
delivery and
• Can be applied with any feedback
other paradigm Modeling and
• Evolutionary or quick design
throwaway Construction of
the Prototype
Evolutionary Vs. Throwaway
Prototyping
• Both types assume that at the outset some abstract,
incomplete set of requirements has been specified.
• Both allows user feedback
• Evolutionary prototype is delivered to the customer with
minimal changes.
• Throwaway prototype is used just to collect user
requirements. Hence the actual deliverable is developed
afterwards.
• Evolutionary prototype is difficult to maintain
• Throwaway prototype is not suitable for testing non-
functional requirements
Benefits of Prototyping
• Resolves communication gap and misunderstanding between
software developer and users.
• Missing user services may be detected
• Difficult to use or confusing user services may be identified
and refined
• Resolves inconsistencies and incompleteness in the users’
requirements
• Helps in gaining user confidence
• Helps in writing specifications
• Correct specifications of the requirements reduces
requirements-related errors and therefore overall
development cost
• Training user before delivering the product
• Test cases developed during prototyping can be used for
testing the final product.
Guidelines for developing the
prototype
• Objective of the prototype must be explicitly
stated to the user
– Validate functional requirement
– Validate user interfaces
• Requires cost
– Non-functional features can be ignored
– Need not maintain error handling routines
– Need not adhere to the quality and reliability standard
– Suitable tools or development languages may be
used
• Usable components
• Executable specification language – z specification language
• Forth generation language – SQL
• Very high-level language – Smalltalk, Prolog or Lisp
Shortfalls of Prototyping
Risk Analysis
Risk Analysis
P4
Risk Analysis
P3
Operational
Risk Analysis P2 prototype
P1
Final Dev, s/w dev s/w Req Lifecycle Mgmt Detailed
Intgr & plan plan Control Plan Control Plan Design
Test Plan
Reqts
Validations Code
User Need
Conventional Approach
Shortfall
Inappropriateness
Lateness
Adaptability
t0 t1 t2 t3 t4
Longevity
Phasewise distribution of effort
• 40-20-40 rule
– Analysis & Design (40%)
– Coding and Debugging (20%),
– Testing and Checkouts (40%)
• Wolverton (1974)
Requirements Analysis – 8%
Preliminary Design – 18% 46%
Interface Definition – 4%
Detailed Design – 16%
Code and debug – 20%
Development testing – 21% 34%
Validation testing – 13%
Phasewise distribution of effort
• Thibodeeau and Dodson (1984)
– Analysis & Design (37%)
– Coding and Debugging (20%),
– Testing and Checkouts (43%)
• Fagan (1986)
– Snail Shaped Curve Coding
Planning
Requirements
Design Testing
Lifecycle Phase Interrelationships
Time
Analysis
Design
Person-Hour
Coding and Unit Testing
Loading
Test and
Validation
Extensions
Design
and
Coding
Modification
Plan Functional
Maintenance
Spec
Time
Unified Process Model
• Ivar Jacobson, Grady Booch, and James
Rumbaugh (1999)
– Use-case driven
– Architecture centric
– Iterative and Incremental
– Static and dynamic models
Phases of Unified Process Model
Inception Phase
Vision Document, Elaboration Phase
initial use-case
Use-case model,
model,
Supplementary
initial project
Requirement Construction Phase
glossary,
including non-
Design Model ,
Initial business functional Analysis
case, model, Software Components,
Initial risk Software architecture Integrated software
assessment, description, increment,
Project plan – Executable test plan and
Phases and architectural procedure,
iterations prototype,
Test cases,
Preliminary design
Support Transition Phase
model,
documentation – user
Project Plan, manual, Delivered software
Preliminary user’s increment,
installation manual,
manual Beta test reports,
description of the
current increment General user
feedback
The Agile View of the Process
(Beck, 2001)
Backlog item
expanded by
Sprint team
member
Sprint
Backlog 30 Days
Demo