Software Engineering Process
Models
.
Dr. K. Rajesh Rao
Asst. Professor- Senior
Dept. of ICT, MIT
Process Models
• Defines a distinct set of activities, tasks, milestones and work
products that are required to engineer high quality software
• The process guides a software team through a set of
framework activities that are organized into a process flow
that may be linear, incremental or evolutionary.
1. Waterfall Model
• Requirements of a problem are reasonably well understood
when work flows from communication through deployment in
a reasonably linear fashion
1. Waterfall Model (contd..)
1.1 Advantages of waterfall model
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model – each
phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are
very well understood.
1.2 Disadvantages of waterfall model
• Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex projects.
• Poor model for long projects.
• Not suitable for the projects where requirements are at a moderate to high
risk of changing.
1.3 When to use the waterfall model
• Requirements are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.
2. Incremental Process Model
2.1 The Incremental Model
• Delivers a series of releases called increments, that
progressively more functionality for the customer as each
increment is delivered.
2.1 Incremental Model (contd..)
• If your customer demands delivery by a date that is impossible
to meet, suggest delivering one or more increments by that
date and the rest of the software (additional increments) later
Advantages of Incremental model:
• Generates working software quickly and early during the
software life cycle.
• More flexible – less costly to change scope and requirements.
• Easier to test and debug during a smaller iteration.
• Customer can respond to each built.
• Lowers initial delivery cost.
2.1 Incremental Model (contd..)
Disadvantages of Incremental model:
• 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.
When to use the Incremental model:
• Major requirements must be defined; however, some details can evolve with
time.
• 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.
2.2 The Rapid Application Development (RAD)
Model
• RAD is an incremental software process model that
emphasized a short development cycle.
• Rapid development is achieved by using a component based
construction approach.
• It is important to note that an incremental philosophy is also
used for all “agile” process models.
2.2 The RAD Model (contd..)
2.2 The RAD Model (contd..)
Drawbacks
• Requires sufficient human resources to create the right
number of RAD teams.
• If the system cannot be properly modularized
• High performance is an issue (due to system components
interface)
• When technical risks are high
3. Evolutionary Process Model
• Iterative process
3.1 Prototyping
• When your customer has a legitimate need but is clueless
about the details, develop a prototype as a first step
• Best fit
Developer may be unsure of the efficiency of an algorithm
The adaptability of an operating system
The form that human-machine interaction should take
3. Evolutionary Process Model (contd..)
• Quick plan- Visible to the customer
• Modeling Quick design- Prototype
3.1 Prototyping
Prototyping can be problematic!
• Haven’t consider software quality and long-term maintainability
• Inappropriate operating system or programming language or
inefficient algorithm may be implemented simply to demonstrate
capability.
Prototyping can be an effective paradigm for software engineering!!
• Customer and developer must both agree that the prototype is built
to serve as a mechanism for defining requirements.
• The actual software is engineered with an eye toward quality
3.2 The Spiral Model
• Is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the waterfall model.
• Software is developed in a series of evolutionary releases.
• During early iterations the release might be a prototype, later iterations
increasingly more complete versions of the engineered system are produced.
• A spiral model is divided into a set of framework activities defined by the
software engineering team.
• Cost and schedule are adjusted based on the feedback derived from the customer
after delivery.
• The project manager adjusts the planned number of iterations required to
complete the software.
3.2 The Spiral Model (contd..)
Why the spiral model is a realistic approach to the development
of large scale systems and software?
3.3 Specialized Process Models
3.3.1 Component-Based Development
• Vendor (who develop the software components) offer software components as
products, which can be used to built the software.
• These components provide targeted functionality with well-defined interfaces that
enable the component to be integrated into the software
• Regardless of the technology that is used to create the components, the component
based development model incorporates the following steps
Available component based products are researched and evaluated
Component integration issues are considered.
A software architecture is designed to accommodate the components.
Components are integrated into the architecture.
Comprehensive testing is conducted to ensure proper functionality
• Leads to 70% reduction in development cycle time and 84% reduction in project cost
3.4 The Unified Process
• Unified Process recognizes the importance of customer
communication and methods for describing the customer’s
view of a system (use-case).
• Unified Modeling Language (UML) that contains a robust
notation for the modeling and development of Object
Oriented system
3.4 The Unified Process (contd..)
• .
3.4 The Unified Process (contd..)
• .
Object Oriented System Development
• Traditional system development methodology and Object oriented
methodology are the two orthogonal views of software construction.
Traditional system development methodology focuses on the functions of
the system.
• Object oriented methodology focuses on the object (which combines data
and functionality).
• The main advantage of object oriented methodology is building self-
contained modules or objects that can be easily replaced, modified and
reused.
• The Unified Modeling Language (UML) is a standardized general-purpose
modelling language in the field of object-oriented software engineering.
• The Unified Modelling Language includes a set of graphic notation
techniques to create visual models of object-oriented software-intensive
Object Oriented System Development
• UML2 has many types of diagrams which are divided into two categories
as shown below
Requirement Gathering
• A requirement is a statement about an intended product that specifies what it should
do or how to do it. For requirements to be effectively implemented and measured,
they must be specific, unambiguous and clear.
• For example, a requirement may be that a specific button must enable printing of the
contents of the current screen.
• Functional requirements specify the software functionality that the developers must
build into the product to enable users to accomplish their tasks, thereby satisfying
the business requirements.
• In simpler words, functional requirements state what the system must do.
• Non-functional requirements define the system’s quality characteristics, example
scalability.
• Requirement gathering can be done by interviews, questionnaires, direct
observation, indirect observation, studying documentation, researching similar
products etc.
