SOFTWARE ENGINEERING

Presenting by:
B.Pranalini
INDEX
Unit 1 Part 2: Process Models
o Prescriptive Process Models
• The Waterfall Model
• Incremental Model
o Evolutionary Process Models
• The Prototyping Model
• The Spiral Model
o The Concurrent Development Model
o Specialized Process Models
o The Unified Process
o Personal and Team Process Models
o Agile Development.
PROCESS MODEL
• Help in the software development

• Guide the software team through a set of framework

activities

• Process Models may be linear, incremental or evolutionary

The Waterfall Model:

• Used when requirements are well understood in the

beginning

• Also called classic life cycle

• Begins with customer specification of Requirements and

progresses through planning, modeling, construction and
deployment

• This Model suggests a systematic, sequential approach to SW

development that begins at the system level and progresses
through analysis, design, code and testing
The Waterfall Model

5
Merits :
• It is systematic sequential approach for Software
Development
Demerits:
• The model requires requirements to be
explicitly spelled out in the beginning, which
is often difficult
• All Customer Requirements at the start of project may be
difficult
• Problems remain uncovered until testing phase
• Customer patience is needed, working version of the
software is delivered too late
 V-MODEL
• A variation in the representation of the waterfall
model is called the V-model.
• The V-model depicts the relationship of quality assurance
actions to the actions associated with communication,
modeling, and early construction activities.
• As a software team moves down the left side of the V,
basic problem requirements are refined into progressively
more detailed and technical representations of the
problem and its solution.
• Once code has been generated, the team moves up the
right side of the V, essentially performing a series of tests
(quality assurance actions) that validate each of the
models created as the team moved down the left side.
• In reality, there is no fundamental difference between the
classic life cycle and the V-model. The V-model provides a
way of visualizing how verification and validation actions
are applied to earlier engineering work
INCREMENTAL MODEL:
• Each linear sequence produces deliverable “increments” of
the software.
(Ex: a Word Processor delivers basic file mgmt., editing, in
the first increment; more sophisticated editing, document
production capabilities in the 2 increment; spelling and
grammar checking in the 3 increment).

• Software releases in increments

• 1st increment constitutes Core product

• Basic requirements are addressed

• Core product undergoes detailed evaluation by the customer

• As a result, of use and / or evaluation, plan is developed
for the next increment. Plan addresses the modification of
core product to better meet the needs of customer and the
delivery of additional features and functionality

• Process is repeated until the complete product is produced

• Incremental model suits such projects which is used when

initial requirements are reasonably well-defined and
compelling need to provide limited functionality quickly

• Functionality expanded further in later releases

• Software is developed in increments

Incremental Models: Incremental
Merits :
• Less number of developers required
• All the requirements need not be known at the
beginning of the project
• Technical risks can be managed
Demerits :
• Problems remain uncovered until testing phase
• Customer patience is needed, working version of the
software is delivered too late.
What is RAD Model?

RAD Model or Rapid Application Development model is a

software development process based on prototyping without
any specific planning. In RAD model, there is less attention
paid to the planning and more priority is given to the
development tasks. It targets at developing software in a
short span of time.
SDLC RAD modeling has following
phases
● Business Modeling
● Data Modeling
● Process Modeling
● Application Generation
● Testing and Turnover

RAD Model Diagram

It focuses on input-output source and destination of the information. It emphasizes on delivering
projects in small pieces; the larger projects are divided into a series of smaller projects. The main
features of RAD modeling are that it focuses on the reuse of templates, tools, processes, and code.

RAD Model in Software Engineering

Different Phases of RAD Model
RAD Model Activities performed in RAD Modeling
Phases

Business ● On basis of the flow of information and distribution between various business
Modeling channels, the product is designed

Data Modeling ● The information collected from business modeling is refined into a set of data
objects that are significant for the business

Process ● The data object that is declared in the data modeling phase is transformed to
Modeling achieve the information flow necessary to implement a business function

Application ● Automated tools are used for the construction of the software, to convert
Generation process and data models into prototypes

Testing and ● As prototypes are individually tested during every iteration, the overall testing
Turnover time is reduced in RAD.
 Advantages of RAD Model Disadvantages of RAD Model

● Flexible and adaptable to changes ● It can’t be used for smaller projects

● It is useful when you have to reduce ● Not all application is compatible with RAD
the overall project risk

● It is adaptable and flexible to changes ● When technical risk is high, it is not suitable

● It is easier to transfer deliverables as ● If developers are not committed to delivering

scripts, high-level abstractions and software on time, RAD projects can fail
intermediate codes are used

● Due to code generators and code ● Reduced features due to time boxing, where
reuse, there is a reduction of manual features are pushed to a later version to finish a
coding release in short period

● Due to prototyping in nature, there is a ● Reduced scalability occurs because a RAD

possibility of lesser defects developed application begins as a prototype and
evolves into a finished application

● Each phase in RAD delivers highest ● Progress and problems accustomed are hard to
priority functionality to client track as such there is no documentation to
demonstrate what has been done
Evolutionary Process Models:
• Software like all complex systems evolves over a period of
time.
• Business and product requirements often change
as development proceeds, making a straight-line
path to an end product unrealistic
• Some of the core product or system requirements are well
understood but the details of product or system extensions
have yet to be defined.
• Solution is to adapt Evolutionary Model which is
Iterative
• Types of evolutionary models
– Prototyping
– Spiral model
The Prototyping Model:

• Prototyping is used when customers requirements are

fuzzy.

• OR the developer may not be sure of the efficiency of

algorithm, the adaptability of an Operating System or
the form that Human Computer interaction should
take

• But we have to throw away the prototype once the

customer requirements are clear & met for better quality.
The product must be rebuilt using software
engineering practices for long term quality.
Evolutionary Models: Prototyping
STEPS IN PROTOTYPING

• Begins with requirement gathering

• Identify whatever requirements are known
• Outline areas where further definition is mandatory
• A quick design occur
• Quick design leads to the construction of prototype
• Prototype is evaluated by the customer
• Requirements are refined
• Prototype is turned to satisfy the needs of customer
The Prototyping Model:

Merits:
• Prototyping helps in requirement gathering & can be
applied at any stage of the project.

Demerits:
• Customer insists to convert prototype in working version
by applying “few fixes”
• Developer may become comfortable with the
compromises done. “The-less-than-ideal-choice” may
become integral part of the system
• Use of inappropriate OS or PL
• Use of inefficient algorithm
Evolutionary Models: Spiral

Spiral Model is an evolutionary software process model that

couples the iterative nature of Prototyping with controlled &
systematic aspects of the Waterfall Model

Include new element : Risk element. Starts in middle and

continually visits the basic tasks of communication, planning,
modeling, construction and deployment
• The first circuit around the spiral might result in the
development of a product specification; subsequent
passes around the spiral might be used to develop a
prototype and then progressively more sophisticated
versions of the software.
• Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are
adjusted based on feedback derived from the customer
after delivery.
• In addition, the project manager adjusts the planned
number of iterations required to complete the software.
Merits:
• Risk is considered as each iteration is made
• Spiral Model can be applied throughout the life of
the computer software.

Demerits:
• It is difficult to convince customers that the
evolutionary approach is controllable
• Considerable risk assessment expertise required
• If major risk is uncovered, problems will occur
Concurrent Development Model:

•Also called concurrent engineering

•Constitutes a series of framework activities, software engineering

action, tasks and their associated states

•All activities exist concurrently but reside in different states

•Applicable to all types of software development

•Event generated at one point in the process trigger transitions

among the states
Fig: One element of the
concurrent process model
• Figure above provides a schematic representation of one
Software engineering task within the modeling activity for the
concurrent process model.
• The activity – modeling- may be in any one of the states noted
at any given time. All activities exist concurrently but reside in
different states
• For example, early in the project the communication activity
has completed its first iteration and exists in the awaiting
changes state. The modeling activity which existed in the
inactive state while initial communication was completed now
makes a transition into underdevelopment state. If, however,
the customer indicates the changes in requirements must be
made, the modeling activity moves from the under
development state into the awaiting changes state.
Concurrent Development Model:

Merits:
• Applicable to all types of Software development & provides an
accurate picture of the current state of project.

Demerits:
• Problem to Project planning. How many number of iterations
are to be planned? Uncertainty…
• Process may fall in chaos if the evolutions occurs too fast
without a period of relaxation. On the other hand if the speed is
too slow productivity could be affected.
• Software processes are focussed on flexibility & extendability,
rather than on high quality.
Specialized Process Models:
Specialized process models use many of the characteristics of
one or more of the conventional models presented so far, however
they tend to be applied when a narrowly defined software
engineering approach is chosen. They include,

⮚ Components based development

⮚The Formal Methods Model

⮚Aspect oriented software development

Components Based Development :
•In this approach, Commercial Off-The-Shelf (COTS) Software
components, developed by vendors who offer them as products are
used in the development of software.

•Characteristics resemble to spiral model.

•The component-based development model constructs applications

from prepackaged software components.

•Modeling and construction activities begin with the identification of

candidate components.

•These components can be designed as either conventional software

modules or object-oriented classes or packages of classes.
The component-based development model incorporates
the following steps (implemented using an evolutionary
approach):

1. Available component-based products are researched

and evaluated for the application domain in question.

2. Component integration issues are considered.

3. A software architecture is designed to accommodate

the components.

4. Components are integrated into the architecture.

5. Comprehensive testing is conducted to ensure proper

functionality.
🞆 Merits:
⮚Leads to software reuse, which provides number of
benefits
• 70% reduction in development cycle time
• 84 % reduction in project cost
• Productivity index goes up to 26.2 ( Norm : 16.9)
🞆 Demerits:
⮚Component Library must be robust.
⮚Performance may degrade
 The Formal Methods Model:
• The Formal methods model encompasses a set of activities that
lead to formal mathematical specification of computer software.

• It consists of specifications, development & verification by

applying rigorous mathematical notation. Example, Clean Room
Software Engineering (CRSE) is used by some software
development organizations.

• When formal methods are used during design, they serve as a

basis for program verification and therefore enable to discover
and correct errors that might otherwise go undetected.
🞆 Merits:
⮚Eliminate many of the problems that are difficult to
overcome using other Software Engineering
Paradigms.
⮚Ambiguity, Incompleteness & Inconsistency can be
discovered & corrected easily by using formal
methods of mathematical analysis.
⮚It offers the promise of defect-free
software.
🞆 Demerits:
⮚Development is time consuming & expensive
⮚ Extensive training is required
⮚Difficult to use with technically unsophisticated
customers
Aspect Oriented Software Development (AOSD):
• A set of localized features, functions & information contents are used
while building complex software.
• These localized s/w characteristics are modeled as components (e.g.
OO classes) & then constructed within the context of a system
architecture.
• Certain “concerns” (Customer required properties or areas of
technical interest) span the entire architecture i.e. Cross cutting
Concerns like system security, fault tolerance etc.
• AOSD is often referred to as aspect-oriented programming (AOP)
• AOP is a relatively new software engineering paradigm that
provides a process and methodological approach for defining,
specifying, designing, and constructing aspects—“mechanisms
beyond subroutines and inheritance for localizing the expression of
a crosscutting concern”
• Grundy [Gru02] provides further discussion of aspects in the
context of what he calls aspect-oriented component engineering
(AOCE):
⮚ AOCE uses a concept of horizontal slices through vertically-
decomposed software components, called “aspects,” to
characterize cross-cutting functional and non-functional
properties of components.
⮚ Common, systemic aspects include user interfaces, collaborative
work, distribution, persistency, memory management,
transaction processing, security, integrity and so on.
• A distinct aspect-oriented process has not yet matured.
• However, it is likely that such a process will adopt characteristics
of both evolutionary and concurrent process models.
• The evolutionary model is appropriate as aspects are identified and
then constructed.
🞆 Merits:
⮚It is similar to component based development for
aspects
🞆 Demerits:
⮚Component Library must be robust.
⮚Performance may degrade
Unified Process Model
The Unified Process, Ivar Jacobson, Grady Booch, and James
Rumbaugh discuss the need for a:

■ use-case driven: The Unified Process recognizes the

importance of customer communication and streamlined
methods for describing the customer’s view of a system (the
use case).

■ architecture-centric:It emphasizes the important role of

software architecture and “helps the architect focus on the right
goals, such as understandability, reliance to future changes, and
reuse”.

■ iterative and incremental: It suggests a process flow that is

iterative and incremental, providing the evolutionary feel that is
essential in modern software development.
A BRIEF HISTORY
• A “unified method” that would combine the
best
features of each of their individual object-
oriented analysis and design methods and
adopt additional features proposed by other
experts in object-oriented modeling.
• The result was UML—a unified modeling
language that contains a robust notation for
the modeling and development of object-
oriented systems.
The Unified Process (UP)

inception
 PHASES OF UNIFIED PROCESS
• The figure above depicts the phases of the UP and relates them to
the generic activities.
• The Inception phase of the UP encompasses both customer
communication and planning activities.
⮚ By collaborating with the customer and end-users, business requirements
for the software are identified, a rough architecture for the system is
proposed, and a plan for the iterative, incremental nature of the ensuing
project is developed.
• The elaboration phase encompasses the planning and modeling
activities of the generic process model.
⮚ Elaboration refines and expands the preliminary use-cases that were
developed as part of the inception phase and expands the architectural
representation to include five different views of the software - the use-
case model, the analysis model, the design model, the implementation
model, and the deployment model.
• The construction phase of the UP is identical to the construction
activity defined for the generic software process.
⮚ Using the architectural model as input, the construction phase
develops or acquires the software components that will make each
use-case operational for end-users.

• The transition phase of the UP encompasses the latter stages of the

generic construction activity and the first part of the generic
deployment activity.
⮚ Software is given to end-users for beta testing, and user feedback
reports both defects and necessary changes.
⮚ At the conclusion of the transition phase, the software increment
becomes a usable software release “user manuals, trouble-shooting
guides, and installation procedures”.
• The production phase of the UP coincides with the
development activity of the generic process.
⮚ The on-going use of the software is monitored, support for
the operating environment is provided and defect reports
and requests for changes are submitted and evaluated.

• A Software Engineering workflow is distributed across

all UP phases.
Common Fears for Developers

•The project will produce the wrong product.

•The project will produce a product of inferior quality.
•The project will be late.
•We’ll have to work 80 hour weeks.
•We’ll have to break commitments.
•We won’t be having fun.
Agile Development
In 2001, Kent Beck and 16 other noted software developers,
writers, and consultant signed the “Manifesto for Agile
Software Development.” It stated:

“We are uncovering better ways of developing software by

doing it and helping others do it. Through this work we
have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
-- Kent Beck et al.
That is, while there is value in the items on the right, we
value the items on the left more.”
 What is “Agility”?
•Effective (rapid and adaptive) response to change (team members,
new technology, requirements)
•Effective communication in structure and attitudes among all team
members, technological and business people, software engineers and
managers
•Drawing the customer into the team. Eliminate “us and them”
attitude.
Planning in an uncertain world has its limits and plan must be
flexible.
•Organizing a team so that it is in control of the work performed
•Eliminate all but the most essential work products and keep them
lean.
•Emphasize an incremental delivery strategy as opposed to
intermediate products that gets working software to the customer as
rapidly as feasible.
What is “Agility”?

Yielding …
• Rapid, incremental delivery of software
• The development guidelines stress delivery over
analysis and design although these activates are not
discouraged, and active and continuous communication
between developers and customers.
 Agility and the Cost of Change
• The conventional wisdom in software development (supported by
decades of experience) is that the cost of change increases
nonlinearly as a project progresses (Figure, solid black curve).
• It is relatively easy to accommodate a change when a software team
is gathering requirements (early in a project)

Figure: Change costs

as a function
of time in
development
• Proponents of agility argue that a well-designed agile
process “flattens” the cost of change curve (Figure, shaded,
solid curve), allowing a software team to accommodate
changes late in a software project without dramatic cost and
time impact.
• Agile process encompasses incremental delivery.
• When incremental delivery is coupled with other agile
practices such as continuous unit testing and pair
programming, the cost of making a change is attenuated.
Principles of Agility

1. Our highest priority is to satisfy the customer through early

and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development.

Agile processes harness change for the customer’s
competitive advantage.

3. Deliver working software frequently, from a couple of weeks

to a couple of months, with a preference to the shorter time
scale.

4. Business people and developers must work together daily

throughout the project.
Principles of Agility

5. Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the
job done.

6. The most efficient and effective method of conveying

information to and within a development team is face-to-face
conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
Principles of Agility

9. Continuous attention to technical excellence and good design

enhances agility.

10. Simplicity - the art of maximizing the amount of work not

done - is essential.

11. The best architectures, requirements, and designs emerge

from self-organizing teams.

12. At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.
Extreme Programming (XP)

•The most widely used agile process, originally proposed by Kent

Beck
•XP Planning
–Begins with the creation of user stories
–Agile team assesses each story and assigns a cost
–Working together, Stories are grouped to for a deliverable
increment
–A commitment is made on delivery date
–After the first increment project velocity is used to help
define subsequent delivery dates for other increments
Extreme Programming (XP)

•XP Design
–Follows the KIS principle
–Encourage the use of CRC cards (see Chapter 8)
–For difficult design problems, suggests the creation of
spike solutions — a design prototype
–Encourages refactoring — an iterative refinement of
the internal program design
•XP Coding
–Recommends the construction of a unit test for a store
before coding commences
–Encourages pair programming
•XP Testing
–All unit tests are executed daily
–Acceptance tests are defined by the customer and
executed to assess customer visible functionality
Extreme Programming (XP)
Other Agile Processes

•Adaptive Software Development (ASD)

•Scrum
•Feature Driven Development
 Adaptive Software Development (ASD)

• Originally proposed by Jim Highsmith (2000) focusing

on human collaboration and team self-organization as
a technique to build complex software and system.
• ASD — distinguishing features
• Mission-driven planning- make more considered
decisions
• Component-based focus-decomposition of the design into
individual functional or logical components
• Uses “time-boxing” - time management technique(fixed
time)
• Explicit consideration of risks
• Emphasizes collaboration for requirements gathering
• Emphasizes “learning” throughout the process
 Three Phases of ASD

1. Speculation:
• project is initiated and adaptive cycle planning is
conducted.
• Adaptive cycle planning uses project initiation
information- the customer’s mission statement, project
constraints (e.g. delivery date), and basic requirements to
define the set of release cycles (increments) that will be
required for the project.
• Based on the information obtained at the completion of
the first cycle, the plan is reviewed and adjusted so that
planned work better fits the reality.
 Three Phases of ASD
2. Collaborations are used to multiply their talent and creative output
beyond absolute number (1+1>2). It encompasses communication
and teamwork, but it also emphasizes individualism, because
individual creativity plays an important role in collaborative
thinking.
It is a matter of trust. 1) criticize without animosity, 2) assist without
resentments, 3) work as hard as or harder than they do. 4) have the
skill set to contribute to the work at hand, 5) communicate problems
or concerns in a way that leas to effective action.
3. Learning: As members of ASD team begin to develop the
components, the emphasis is on “learning”. Highsmith argues that
software developers often overestimate their own understanding of
the technology, the process, and the project and that learning will
help them to improve their level of real understanding. Three ways:
focus groups, technical reviews and project postmortems.
Adaptive Software Development (ASD)
 Scrum
• A software development method Originally proposed by
Schwaber and Beedle (an activity occurs during a rugby
match) in early 1990.
• Scrum—distinguishing features
• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is
constructed
• Work units occurs in “sprints” and is derived from a “backlog” of
existing changing prioritized requirements
• Changes are not introduced in sprints (short term but stable) but in
backlog.
• Meetings are very short (15 minutes daily) and sometimes
conducted without chairs ( what did you do since last meeting?
What obstacles are you encountering? What do you plan to
accomplish by next meeting?)
• “demos” are delivered to the customer with the time-box allocated.
May not contain all functionalities. So customers can evaluate and
give feedbacks.
Scrum
Feature Driven Development
• Originally proposed by Peter Coad et al as a object-oriented
software engineering process model.
• FDD—distinguishing features
• Emphasis is on defining “features” which can be organized
hierarchically.
• a feature “is a client-valued function that can be
implemented in two weeks or less.”
• Uses a feature template
• <action> the <result> <by | for | of | to> a(n) <object>
• E.g. Add the product to shopping cart.
• Display the technical-specifications of the product.
• Store the shipping-information for the customer.
• A features list is created and “plan by feature” is conducted
• Design and construction merge in FDD
Feature Driven Development
THANK YOU