Description of different models along with their multiple phases to design a software.

1. SOFTWARE PROCESS
MODELS

2. NEED FOR MODELING A PROCESS
• When a team writes down a description of its
development process it forms a common
understanding of the activities, resources and
constraints involved in software development.
• Creating a process model helps the team find
inconsistencies, redundancies and removals in the
process, as these problems are noted and corrected
the process becomes more effective.
• The model reflects the goals of development and
shows explicitly how the product characteristics are
to be achieved.

3. • Each development is different and a process has to
be tailored for different situations, the model helps
people to understand these differences.

4. PRESCRIPTIVE MODELS
• Advocates an orderly approach to software
engineering.
• They prescribes
– A set of process elements,
– Framework activities,
– Software engineering actions,
– Tasks,
– Work products,
– Quality assurance and change control mechanism for
each project.

5. WATER FALL MODEL
• ADVANTAGES
• The model suggests that software engineers should
work in a series of stages.
• Before completing each stage, they should perform
quality assurance (verification and validation).
• The waterfall model also recognizes, to a limited
extent, that you sometimes have to step back to
earlier stages.

6. WHEN TO USE
• Requirements of the complete system are clearly
defined and understood.
• Major requirements must be defined.
• There is a need to get a product to the market early.
• A new technology is being used.
• Resources with needed skill set are not available
• There are some high risk features and goals.

8. DISADVANTAGES
• The model implies that you should attempt to complete a given
stage before moving on to the next stage
• Does not account for the fact that requirements constantly
change.
• It also means that customers can not use anything until the
entire system is complete.
• The model makes no allowances for prototyping.
• It implies that you can get the requirements right by simply
writing them down and reviewing them.
• The entire functionality is developed and then tested all
together at the end.
• Major design problems may not be detected till very late.
• The model implies that once the product is finished, everything
else is maintenance.

9. INCREMENTAL PROCESS MODEL
• Development occurs as a succession of releases
with increasing functionality.
• Combines elements of the water fall model applied
in an iterative fashion.
• Each linear sequence produces deliverables of the
software.
• Customers provide feedback on each release, used
in deciding requirements and improvements for
next release.
• There is no “maintenance” phase – each version
includes both problem fixes as well as new features.

10. ADVANTAGES
• Customers get usable functionality earlier than with
waterfall.
• Early feedback improves likelihood of producing a
product that satisfies customers.
• The quality of the final product is better
– The core functionality is developed early and tested
multiple times (during each release)
– Only a relatively small amount of functionality added in
each release: easier to get it right and test it thoroughly
– Detect design problems early and get a chance to
redesign

12. DISADVANTAGES
• Needs good planning and design.
• Needs a clear and complete definition of the whole
system before it can be broken down and built
incrementally.
• Total cost is higher than waterfall.

13. RAD DEVELOPMENT MODEL
• RAD is an incremental software process model that
emphasizes a short development cycle.
• Using Component based construction approach.

14. Team # n
M o d e lin g
business m odeling
dat a m odeling
process m odeling
Co n st ru ct io n
com ponent reuse
aut om at ic code
generat ion
t est ing
Team # 2
Communicat ion
Mo d eling
business m odeling
dat a m odeling
process m odeling
Planning
Co nst ruct io n
Team # 1
com ponent reuse
aut om at ic code
generat ion
t est ing
Mode ling
business modeling
dat a modeling
process modeling
Const ruct ion
component reuse
aut omat ic code
generat ion
t est ing
6 0 - 9 0 days
De ployme nt
int egrat ion
deliv ery
feedback

15. ADVANTAGES & DISADVANTAGES
•
•
•
•
RAD reduces the development time
Reusability of components help to speed up development.
All functions are modularized so it is easy to work with.
For large projects RAD require highly skilled engineers in
the team.
• Both end customer and developer should be committed to
complete the system in a much abbreviated time frame
• If commitment is lacking RAD will fail.
• RAD is based on Object Oriented approach and if it is
difficult to modularize the project the RAD may not work
well.

16. EVOLUTIONARY SOFTWARE
PROCESS MODELS

17. • Business and product requirement often change as development
proceed.
• Software engineer need a process model that has been explicitly
designed to accommodate a product that evolves over time.
• Evolutionary models are iterative.
• Enables software engineers to develop increasingly more
complete version of the software.
• There are two types of evolutionary development:
– Exploratory development
• Start with requirements that are well defined
• Add new features when customers propose new requirements
– Throw-away prototyping
• Objective is to understand customer’s requirements (i.e. they often don’t know what they
want, hence poor requirements to start
• Use means such as prototyping to focus on poorly understood requirements, redefine
requirements as you progress

18. ADVANTAGES & DISADVANTAGES
• Advantages:
– Happier customers since we help them by defining
requirements
– Flexibility in modifying requirements
– Prototypes are very visual, hence no ambiguities
• Disadvantages:
– Hard to trace the “process” due to the ad-hoc nature
– Systems are often poorly structured
– Special tools and techniques may be required (for rapid
development) that may be incompatible
– Not cost-effective to produce documents

19. PROTOTYPING MODEL
• Customer defines a set of general objectives for
software but doesn’t identify the detail.
• Assist the software engineer and the customer to
better understand what is to be built when
requirement are fuzzy.

22. •
SPRIAL PROCESS MODEL
A hybrid model where the development of the system spirals
outward from an initial outline through to the final developed
system.
• Each loop in the spiral represents a phase of the software
process.
• Like the innermost loop might be concerned with system
feasibility, next loop with system requirements, next loop with
system design and so on.
• Each loop in the spiral is split into four sectors:
– Object Setting: set specific object for that phase.
– Risk assessment and reduction.
– Development and validation: select a development model
based on risk levels.
– Planning: decide if a next loop is required

24. ADVANTAGES & DISADVANTAGES
• Advantages
– Explicit consideration of risks (alternative solutions
are evaluated in each cycle).
– More detailed processes for each development
phase.
• Disadvantages
– Cost is high.
– Sometime difficult to implement or too time
consuming.

25. SPECIALIZED PROCESS MODELS

26. COMPONENT BASED DEVELOPMENT
• COTS (Commercial Off The Shelf) software components,
developed by vendors who offer them as products can
be used when software is to built.
• Provides targeted functionality with well defined
interfaces.
• Incorporates many of the characteristics of spiral
model.
• Regardless of technology to be used, it must follow the
steps like –
– Available component based products are researched and
evaluated for the current application.

27. – Component integration issues is to dealt.
– A software architecture is designed to accommodate the
components.
– Components are integrated into the architecture.
– Comprehensive testing is conducted to ensure proper
functionality.
• This model leads to software reuse.
• Provides software engineers with a number of
measureable benefits.

28. FORMAL METHODS MODEL
• Comprises set of activities that leads to formal
mathematical specification of computer software.
• Enables a software engineer to specify, develop and
verify a computer based system by applying
mathematical notation.
• Problems
of
ambiguity,
incompleteness
and
inconsistency can be managed by this method.
• Provides a base for verification therefore enable a
software engineer to discover and correct undetected
errors also.
• But using this method in current scenario is time
consuming and expensive.

29. • Extensive training is required for applying this
method as few developers have the necessary
background to work with this method.
• It is difficult to use the models as a communication
mechanism
for
technically
unsophisticated
customers.

30. ASPECT ORIENTED SOFTWARE DEVELOPMENT
• Complex software are being implemented as set of
localized features, functions and information
content referred as components.
• But it becomes crosscutting concerns when it flows
across multiple systems.
• Aspectual requirements define these crosscutting
concerns that have impact across the software
architecture.
• AOSD provides a process and methodological
approach for defining, specifying, designing and
constructing aspects.

31. UNIFIED PROCESS MODEL
• Comprises best features and characteristics of conventional
software process models.
• Emphasize importance of customer communication and
streamlined methods for describing the customers view of
system.
• Phases of Unified Process
– Inception = Involves customer communication and
planning activities.
– Elaboration
=
Encompasses
the
customer
communication and modeling activities of the generic
process model. Architectural representation using Use
Case Model, Analysis Model, Design Model,
Implementation Model and Deployment Model.

33. – Construction = Develops or acquires the software
components that will make each use case operational for
end users.
– Transition = Software is given to end user for beta testing
and user feedback reports both defects and necessary
changes.
– Production = Coincides with the deployment activity of
process. The on going use of software is monitored,
support for the operating environment is provided, and
defect reports and requests for changes are submitted
and evaluated.

34. Thanks