Unit-1

• Syllabus
• Introduction to Software Engineering:
– The evolving role of software, changing nature of software,
software myths.
• A Generic view of process:
– Software engineering- a layered technology, a process framework,
the capability maturity model integration (CMMI), process
patterns, process assessment, personal and team process models.
• Process models:
– The waterfall model, incremental process models, evolutionary
process models, the unified process.
 What is Software ?
• Software is a set of instructions, data or programs used
to operate computers and execute specific tasks.
• It is the opposite of hardware, which describes the
physical aspects of a computer.

• Software is a generic term used to refer to applications,

scripts and programs that run on a device.

• It can be thought of as the variable part of a computer,

while hardware is the invariable part.
 What is Software ?
• Software is (1)
– instructions (computer programs) that when executed
provide desired features, function and performance,
– (2) data structures that enable the programs to adequately
manipulate information,
– and (3) documents that describe the operation and use of
the programs.
 What is Software Engineering ?
• The term is made of two words, software and engineering.
– Software is more than just a program code. A program is an executable
code, which serves some computational purpose.

– Software is considered to be collection of executable programming

code, associated libraries, drivers, tools and documentations.

– Software, when made for a specific requirement is called software

product.

• Engineering on the other hand

– is all about developing products, using well-defined, scientific

principles and methods.
Introduction to Software Engineering:
• Software engineering is an engineering branch
associated with development of software product
using well-defined scientific principles, methods and
procedures.

• The outcome of software engineering is an efficient

and reliable software product.
Introduction to Software Engineering:
• Definitions
• IEEE defines software engineering as:
– (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation and maintenance of
software; that is, the application of engineering to software.
– (2) The study of approaches as in the above statement.
• Fritz Bauer, a German computer scientist, defines
software engineering as:
– Software engineering is the establishment and use of sound
engineering principles in order to obtain economically software
that is reliable and work efficiently on real machines.
 Characteristics
• Software is a logical entity, it has certain distinguishable
characteristics:

1. Software is developed or engineered, it is not

manufactured in the classical sense.

2. Software does not wear out.

3. Although the industry is moving toward component

based assembly, most software continues to be custom
built.(reusability of components)
 Characteristics
• Accessibility. The degree to which a diverse group of peoples.
• Compatibility. The suitability of the software for use in a variety of
environments, such as with different OSes, devices and browsers.

• Efficiency. The ability of the software to perform well without wasting

energy, resources, effort, time or money.

• Functionality. Software's ability to carry out its specified functions.

• Installability. The ability of the software to be installed in a specified
environment.

• Localization. The various languages, time zones and other such features a
software can function in.

• Maintainability. How easily the software can be modified to add and

improve features, fix bugs, etc.

• Performance. How fast the software performs under a specific load.

 Characteristics
• Portability. The ability of the software to be easily transferred from one
location to another.

• Reliability. The software's ability to perform a required function under

specific conditions for a defined period of time without any errors.

• Scalability. The measure of the software's ability to increase or decrease

performance in response to changes in its processing demands.

• Security. The software's ability to protect against unauthorized access,

invasion of privacy, theft, data loss, malicious software, etc.

• Testability. How easy it is to test the software.

• Usability. How easy it is to use the software.

 Software Vs Hardware
• Software is developed or engineered; it is not manufactured in
the classical sense
– Impacts the management of software projects
• Software doesn't wear out
– Hardware bathtub curve compared to the software ascending
spiked curve
• Industry is moving toward component-based construction, most
software continues to be custom built
– it is still complex to build
– Reusable components are created so that engineers can concentrate on
innovative
elements of a design
– User interfaces are built with reusable components
– The data structures and processing details are kept in a library for
interface construction
Hardware Failure Curve
Software Failure Curve
Importance of Software Engineering
Product Life cycle
 SDLC
• Software Development Life Cycle (SDLC) is a process used by
the software industry to design, develop and test high quality
softwares.

• The SDLC aims to produce a high-quality software that meets

or exceeds customer expectations, reaches completion within
times and cost estimates.
 SDLC
• SDLC is the acronym of Software Development Life Cycle.

• It is also called as Software Development Process.

• SDLC is a framework defining tasks performed at each step in

the software development process.
 SDLC

SDLC Cycle
SDLC
 The evolving role of software
• The process of developing a software product using software engineering
principles and methods is referred to as software evolution.

• Today, software takes on a dual role.

– It is a product and,
– The vehicle for delivering a product.

• As a product,
– It delivers the computing potential embodied by computer hardware
or, more broadly, a network of computers that are accessible by local
hardware.

– Whether it resides within a cellular phone or operates inside a

mainframe computer.

– software is an information transformer—producing, managing,

acquiring, modifying, displaying information.
 The evolving role of software
• The vehicle used to deliver the product,
– -Controls other programs(OS)
– -Effects communication(Networking software)
– Creation and control of other programs (software tools and
environments).

– Software transforms personal data (e.g., an individual’s financial

transactions) so that the data can be more useful in a local context.

– It manages business information to enhance competitiveness.

– It provides a gateway to worldwide information networks (e.g.,

Internet) and provides the means for acquiring information in all of its
forms.
 The evolving role of software
• The role of computer software has undergone significant
change over a time span of little more than 50 years.
• Dramatic improvements in hardware performance,

• Profound changes in computing architectures,

• Vast increases in memory and storage capacity, and

• A wide variety of exotic input and output options have all

precipitated more sophisticated and complex computer-based
systems.
 Changing Nature of Software
The nature of software has changed a lot over the years.

1. System software:

Infrastructure software come under this category like compilers, operating

systems, editors, drivers, etc. Basically system software is a collection of programs
to provide service to other programs.

2. Real time software:

These software are used to monitor, control and analyze real world events as
they occur.
An example may be software required for weather forecasting. Such software will
gather and process the status of temperature, humidity and other environmental
parameters to forecast the weather.
 Changing Nature of Software
3. Embedded software:
This type of software is placed in “Read-Only- Memory (ROM)”of the
product and control the various functions of the product.

The product could be an aircraft, automobile, security system, signaling

system, control unit of power plants, Intelligent Software etc.

4. Business software :
This is the largest application area. The software designed to process business
applications is called business software.

Business software could be payroll, file monitoring system, employee

management, account management, Data warehousing tools, Management
information system, enterprise resource planning (ERP).
 Changing Nature of Software
5. Personal computer software :
The software used in personal computers are covered in this category.
Examples are word processors, computer graphics, multimedia and
animating tools, database management, computer games etc.
6. Artificial intelligence software:
Artificial Intelligence software makes use of non numerical algorithms to
solve complex problems that are not amenable to computation or
straight forward analysis.
Examples are expert systems, artificial neural network, signal processing
software etc.
7. Web based software:
The software related to web applications come under this category.
Examples are CGI, HTML, Java, Perl, DHTML etc.
 Software myths
• Software myths propagate false beliefs and confusion in the
minds of management, users and developers.

• Types of myths
– Management Myths

– Customer Myths

– Practitioner’s Myths
 Management Software Myths
• The manager who is responsible for developing software is
often under pressure regarding many attributes of the
software such as:

– The budget of the software.

– Delivering the software within the time limit.

– Enhance the quality of the software.

– Providing customer care services, etc.

 Management Software Myths
Myth1 Reality 1
The software building team has a Though there exists a book that has
book/manual that explains all all the standards and procedures
standards and procedures that are required to develop software.
required for developing software. But are the developers aware of its
existence?

Do they ever refer to such books?

Is the book complete?

Can it be referred to?

Does the book help the developers

to stick to the time-to-deliver even
maintain the quality of the
software?
 Management Software Myths
Myth2 Reality 2
If the project is behind In fact, adding up more people in the
schedule, increasing the number of team would rather delay the delivery
programmers can reduce the time gap. of the software.

This is because when new members

are introduced to the team, the
members already working on the
software will have to explain/train the
work done till now.

This will even reduce the time from

the time that has to spend on the
development of the software.
 Management Software Myths
Myth3 Reality 3

Outsourcing the software If the company has outsourced

project to a third party will let the software project to a third
the manager relax. party, it means the company is
not aware of the details of the
The third-party will be solely software project.
responsible for the development
of the software.
It doesn’t know how to manage
and control the software
project.
 Management Software Myths
Myth4 Reality 4

My people have state-of-the- It takes much more than the latest

art software development model mainframe, workstation, or
tools, after all, we buy them PC to do high-quality software
the newest computers. development.

Adopt Computer-aided software

engineering (CASE) tools such as
Diagramming Tools
• Analysis Tools
• Central Repository
• Documentation Generators
• Code Generators
 Customer Myths
Myth1 Reality 1

Customers believe that •Although it is not possible for a

giving a general statement customer to provide a comprehensive
would let the software and stable statement.
developer start writing the •An ambiguous statement will lead to
program. The rest of the disaster.
details can be filled in later. •By frequent meet with technical team
to avoid ambiguous statements.
 Customer Myths
Myth2 Reality 2
Customers can ask for the changes Well, the customer can ask for the changes in
in software as many times as the software. But the impact of the changes
desired as software is flexible. varies from the time it has been introduced.

If the customer asks for the changes early

during the development of the software the
cost impact is less.

However, over time impact of changes grows

gradually may it be in terms of cost or
duration, or the quality of the software.
 Practitioner’s Software Myth
Myth1 Reality 1
Once you write the code and Practically 60% – 80% of the efforts
develop the software your are expended on the software when
job is done. the software is delivered to the
customer for the first time.

When a customer starts using the

software they figure out the
improvements that can be made to
enhance the quality of the software.
 Practitioner’s Software Myth
Myth2 Reality 2
Practicing software engineering Practicing software engineering will never
while developing software will tend you to create huge documentation
tend you to create huge instead it focuses on the quality of the
documentation and this will developed software.
eventually slow down the process A better-quality software reduces the number
of software development. of iterations and thus faster the delivery time.
 Practitioner’s Software Myth
Myth3 Reality 3
Until I get the program “running” I One of the most effective software quality assurance
have no way of assessing its quality. mechanisms can be applied from the inception of a
project—the formal technical review., Assessments,
metrics etc.
 Generic Process Framework
• Communication
– Involves communication among the customer and other stake holders;
encompasses requirements gathering.
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule.
• Modeling (Analyze, Design)
– Encompasses the creation of models to better understand the requirements
and the design.
• Construction (Code, Test)
– Combines code generation and testing to uncover errors.
• Deployment
– Involves delivery of software to the customer for evaluation and feedback.
 Software Engineering as a Layered Technology
• The Institute of Electrical and Electronics Engineers (IEEE) defines software
engineering as “the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that
is, the application of engineering to software.”

• The most common systematic approach taken is described as “layered.”

 Software Engineering as a Layered Technology
• A quality Focus:
• Main principle of Software Engineering is Quality Focus.

• An engineering approach must have a focus on quality.

• Total Quality Management (TQM), Six Sigma, ISO 9001, ISO 9000-3,
CAPABILITY MATURITY MODEL (CMM), CMMI & similar approaches
encourages a continuous process improvement culture to assess the
quality.
• Process:
• It is a foundation of Software Engineering.
• It defines a framework with activities for effective delivery of software
engineering technology.
• It enables balanced and timely development.
• From the basis for management; provides the context for technical
methods, work products, milestones, quality measures, and change
management
 Software Engineering as a Layered Technology

• Methods:
• It provides technical “how-to” build a software.

• Rely on a set of basic principles.

• It encompasses many tasks including communication, requirement
analysis, design modeling, program construction, testing and
support.

• Tools:
• Provide automated or semi-automated support for the process and
methods (i.e.,CASE tools) i.e computer-aided software engineering
(CASE).

• Software Engineering Tools allows automation of activities which helps

to perform systematic activities.
 Benefits of Software Engineering as a Layered
Technology
• Better decision-making.
– The decisions outlined in each layer provide a structure for
the whole project, unifying collaboration and problem-
solving.
• Early error detection.
– The layered approach lends itself to identifying and solving
errors early in the project.
• Ease of configuration and maintenance.
– Helpful feedback, timely testing, and constant
communication help to make the end project easy to
configure and maintain.
 Software Engineering as a Process Framework
• The process of framework defines a small set of
activities that are applicable to all types of projects.

• The software process framework is a collection of task

sets.
• Each task sets consist of
• A collection of small work tasks,

• Project milestones,

• Work productivity, and

• Software quality assurance points.

Software Engineering as a Process Framework
 Software Engineering as a Process Framework
• Process Framework Activities:
– Communication: By communication, customer requirement gathering is done.
Communication with consumers and stakeholders to determine the system’s
objectives and the software’s requirements.
– Planning: Establish engineering work plan, describes technical risk, lists
resources requirements, work produced and defines work schedule.
– Modeling: Architectural models and design to better understand the problem
and for work towards the best solution. The software model is prepared by:
o Analysis of requirements
o Design
– Construction: Creating code, testing the system, fixing bugs, and confirming that
all criteria are met. The software design is mapped into a code by:
o Code generation
o Testing
– Deployment: In this activity, a complete or non-complete product or software is
represented to the customers to evaluate and give feedback. On the basis of
their feedback, we modify the product for the supply of better products.
 Software Engineering as a Process Framework
• Umbrella activities:
• Umbrella Activities are that take place during a software development process for
improved project management and tracking.
– Software project tracking and control: This is an activity in which the team can assess
progress and take corrective action to maintain the schedule. Take action to keep the
project on time by comparing the project’s progress against the plan.
– Risk management: The risks that may affect project outcomes or quality can be analyzed.
Analyze potential risks that may have an impact on the software product’s quality and
outcome.
– Software quality assurance: These are activities required to maintain software quality.
Perform actions to ensure the product’s quality.
– Formal technical reviews: It is required to assess engineering work products to uncover and
remove errors before they propagate to the next activity. At each level of the process, errors
are evaluated and fixed.
– Software configuration management: Managing of configuration process when any change
in the software occurs.
– Work product preparation and production: The activities to create models, documents,
logs, forms, and lists are carried out.
– Reusability management: It defines criteria for work product reuse. Reusable work items
should be backed up, and reusable software components should be achieved.
– Measurement: In this activity, the process can be defined and collected. Also, project and
product measures are used to assist the software team in delivering the required software.
 Capability Maturity Model Integration(CMMI)
• CMM was developed by the Software Engineering Institute (SEI) at
Carnegie Mellon University in 1987.

• It is not a software process model. It is a framework that is used to

analyze the approach and techniques followed by any organization
to develop software products.

• It also provides guidelines to further enhance the maturity of the

process used to develop those software products.

• It is based on profound feedback and development practices

adopted by the most successful organizations worldwide.

• Capability Maturity Model Integration (CMMI) is a successor of

CMM and is a more evolved model that incorporates best
components of individual disciplines of CMM like Software CMM,
Systems Engineering CMM, People CMM, etc.
 Capability Maturity Model Integration(CMMI)
• The Capability Maturity Model Integration (CMMI) is a model that helps
organizations to:
– Effectuate(put into force) process improvement.
– Develop behaviors that decrease risks in service, product, and software
development.
– The model enables organizations to measure, build, and improve
capabilities—to improve overall performance.
• A primary goal of CMMI is the creation of “reliable environments where
products, services and departments are proactive, efficient and
productive.”
• More specifically, CMMI’s objectives for businesses include enabling your
organization to:
– produce quality services or products
– Improve customer satisfaction
– Increase value for stakeholders
– Achieve industry-wide recognition for excellence
– Grow market share
 CMMI Maturity Levels
• Maturity level ratings range from 1 to 5, with level 5 being the highest level
and the goal towards which organizations are working.

• The five CMMI maturity levels are:

– Initial. Processes are seen as unpredictable, poorly controlled, and
reactive. Businesses in this stage have an unpredictable environment
that leads to increased risks and inefficiency.
– Managed. Processes are characterized by projects and are frequently
reactive.
– Defined. Processes are well-characterized and well-understood. The
organization is more proactive(before) than reactive, and there are
organization-wide standards that provide guidance.
– Quantitatively Managed. Processes are measured and controlled. The
organization is using quantitative data to implement predictable
processes that meet organizational goals.
– Optimizing. Processes are stable and flexible. The organizational focus
on continued improvement and responding to changes.
CMMI Maturity Levels
 CMMI Maturity Levels
• Level 0: Incomplete. The process area (e.g., requirements management) is
either not performed or does not achieve all goals and objectives defined
by the CMMI for level capability.

• Level 1: Performed. All of the specific goals of the process area (as defined
by the CMMI) have been satisfied. Work tasks required to produce defined
work products are being conducted.

• Level 2: Managed. All level I criteria have been satisfied. In addition, all
work associated with the process area conforms to an organizationally
defined policy; all people doing the work have access to adequate
resources to get the job done; stakeholders are actively involved in the
process area as required; all work tasks and work products are “monitored,
controlled, and reviewed; and are evaluated for adherence to the process
description”.
 CMMI Maturity Levels

• Level 3: Defined. All level 2 criteria have been achieved. In addition, the
process is “tailored from the organization’s set of standard processes
according to the organization’s tailoring guidelines, and contributes work
products, measures, and other process-improvement information to the
organizational process assets.”

• Level 4: Quantitatively managed. All level 3 criteria have been achieved. In

addition, the process area is controlled and improved using measurement
and quantitative assessment. “Quantitative objectives for quality and
process performance are established and used as criteria in managing the
process.”
 CMMI Maturity Levels

• Level 5: Optimized. All capability level 4 criteria have been achieved. In

addition the process area is adapted and optimized using quantitative
(statistical) means to meet changing customer needs and to continually
improve the efficacy of the process area under consideration.”
 PROCESS PATTERNS
• The software process can be defined as a collection of patterns that define
a set of activities, actions, work tasks, work products and/or related
behaviors required to develop computer software.

• Patterns can be defined at any level of abstraction(idea). In some cases, a

pattern might be used to describe a complete process (e.g., prototyping).

• Patterns can be used to describe an important framework activity (e.g.,

planning) or a task within framework activity (e.g., project- estimating).

• Ambler has proposed the following template for describing a process

pattern:
– Pattern Name. The pattern is given a meaningful name that describes its functions within
the software process (e.g., customer-communication).
– Intent. The objective of the pattern is described briefly.
• For example, the intent of customer-communication is “to establish a collaborative relationship with the
customer in an effort to define project scope, business requirements, and other projects constraints”.
– Type. The pattern type is specified i.e 3 types Task, Stage, and Phase patterns
 PROCESS PATTERNS-Types
• Ambler suggests three types:

– Task pattern define a software engineering action or work task that is part of the
process and relevant to successful software engineering practice
• (e.g., requirements gathering is a task pattern).

– Stage patterns represent a framework activity for the process. Since a

framework activity encompasses multiple work tasks, a stage pattern
incorporates multiple task patterns that are relevant to the stage.
• An example of a stage pattern might be communication with stakeholders.

– Phase patterns define the sequence of framework activities is iterative in nature.

• An example of a phase pattern might be a spiral model or prototyping.
 PROCESS PATTERNS
• Initial context. The conditions under which the pattern applies are described. Prior to the
initiation of the pattern, we ask (1) what organizational team created activities have already
occurred (2) what is the entry state for the process? And (3) what software engineering
information or project information already exists?

For example, the planning pattern (a stage pattern) requires that (1) customers and software
engineers have established a collaborative communication: (2) successful completion of a
number of task patterns (specified) for the customer-communication pattern has occurred:
and (3) project scope, basic business requirements, and project constraints are known.

An Example Process Pattern:

The following abbreviated process pattern describes an approach that may be applicable
when stakeholders have a general idea of what must be done, but are unsure of specific
software requirements.

Pattern name. Prototyping.

Intent: The objective of the pattern is to build a model (a prototype) that can be assessed
iteratively by stakeholders in an effort to identify or solidity software requirements.

Type: Phase pattern.

 PROCESS PATTERNS
• Initial context: The following conditions must be met prior to the initiation of this pattern:(
1) stakeholders have been identified; (2) a mode of communication between stakeholders
and the software team has been established; (3) the overriding problem to be solved has
been identified by stakeholders: (4) an initial understanding of project scope, basic business
requirements, and project constraints has been developed.

Problem: Requirements are hazy or nonexistent, yet there is clear recognition that there is a
problem, and the problem must be addressed with a software solution. Stakeholders are
unsure of what they want; that is, they cannot describe software requirements in any detail.

Solutions: A description of the prototype that identifies basic requirements (e.g., modes of
interaction, computational features, processing functions) is approved by stakeholders.
Following this, (1) the prototype may evolve through a series of increments to become the
production software or (2) the prototype may be discarded and the production software
built using some other process pattern.

Related Patterns: The following patterns are related to this pattern: customer-
communication; iterative design; iterative development, customer assessment;
requirement extraction.

Known uses/examples: Prototyping is recommended when requirements are uncertain.

 PROCESS ASSESSMENT
• The disciplined examination of the processes by an organisation against a set
of criteria to determine capability of those processes to perform within quality,
cost and schedule goals.

• The following diagram shows number of different approaches to software

process assessment
 PROCESS ASSESSMENT
• The following are the most successful process assessment organization

1. Standard CMMI Assessment Method for Process Improvement (SCAMPI)

provides a five—step process assessment model that incorporates initiating,
diagnosing, establishing, acting, and learning.
The SCAMPI methods use the SEI CMMI as the basis for assessment.

2. Speech Perception Instructional Curriculum & Evaluation (SPICE)

Standard defines a set of requirements for software process assessment.
The intent of the standard is to assist organization in developing an objective
evaluation of the efficacy of any defined software process.

3. ISO9001: 2000 for Software is a generic standard that applies to any organization
that wants to improve overall quality of the products, systems, or services that it
provides.
 Personal Software Process (PSP)
• The Personal Software Process (PSP) emphasizes personal measurement of
both the work product that is produced and the resultant quality of the
work product.

• The PSP model defines five framework activities:

– Planning. This activity isolates requirements and develops both size and
resource estimates.
• In addition, defects estimate (the number of defects projected for the work) is made.
• All metrics are recorded on worksheets or templates.
• Finally, development tasks are identified and a project schedule is created.

– High level design.

• External specifications for each component to be constructed are developed and a
component design is created.
• Prototypes are built when uncertainty exists.
• All issues are recorded and tracked.
 Personal Software Process (PSP)
– High level design review.
Formal verification methods are applied to uncover errors in the
design.
Metrics are maintained for all important tasks and work results.

– Development.
The component level design is refined and reviewed.
Code is generated, reviewed, compiled, and tested.
Metrics are maintained for all important tasks and work results.

– Postmortem.
Using the measures and metrics collected, the effectiveness of the
process is determined.
Measures and metrics should provide guidance for modifying the
process to improve its effectiveness.
 Team Software Process (TSP)
• TSP defines the following framework activities: Launch, high-level design,
implementation, integration and . test, and postmortem.
• TSP makes use of a wide variety of scripts, forms and standards that serve
to guide team members in their work.
• Responsibilities in launch
“Finding a good player is easy.
– Review project objectives Getting them to play as a team
– Establish team roles is another story”
– Define team’s development process
By Stengel
– Make quality plan and set quality targets
– Plan for the need support facilitates
– Make a development plan for the entire project
– Make detailed plan for each engineer for the next phase
– Merge individual plans into team plan
– Rebalance team workload to achieve minimum overall schedule
– Assess the project risks and assign tracking responsibility.
 Team Software Process (TSP)
• The goal of TSP is to build a “self directed” project team that
organizes itself to produce high quality software.

• Humphrey defines the following objectives for TSP:

– Build self directed teams that plan and track their work, establish goals,
and own their processes and plans. These can be pure software teams
or integrated product teams (IPTs) of 3 to about 20 engineers.

– Show managers how to coach and motivate their teams and how to
help them sustain peak(Max. out) performance

– Accelerate software process improvement by making CMMI Level 5

behavior normal and expected.

– Provide improvement guidance to high-maturity organizations.

– Facilitate university teaching of industrial-grade team skills.

 What is a Process?
• A system of operations in producing something.

• A series of actions, changes, or functions that achieve an end

result.

• (IEEE) A sequence of steps performed for a given purpose.

 What is a Software Process?
• A set of activities, methods, practices, and transformations that
people use to develop and maintain software and the
associated products (e.g., project plans, design documents,
code, test cases, and user manuals)

• As an organization matures, the software process becomes

better defined and more.

• consistently implemented throughout the organization

• Software process maturity is the extent to which a specific

process is explicitly defined, managed, measured and
controlled.

• An effective Prescriptive Process Models

 Software Process Models
• Waterfall Model
• Incremental Model
– RAD Model
• Iterative Model
• Evolutionary Model
– Prototyping Model
– Spiral Model
– The concurrent Development Model
• V Model
• Unified Model
• Agile Model
 Waterfall Model
• The waterfall model is a linear, sequential approach to the software
development life cycle (SDLC) that is popular in software
engineering and product development.

• The waterfall model emphasizes a logical progression of steps. Similar to

the direction water flows over the edge of a cliff, distinct endpoints or
goals are set for each phase of development and cannot be revisited after
completion.

• The term was first introduced in a paper published in 1970 by Dr. Winston
W. Royce and continues to be used in applications of industrial design.

• Waterfall Model is a sequential model that divides software development

into pre-defined phases. Each phase must be completed before the next
phase can begin with no overlap between the phases. Each phase is
designed for performing specific activity during the SDLC phase. It was
introduced in 1970 by Winston Royce.
Waterfall Model
 Waterfall Model
• The waterfall methodology is composed of seven non-overlapping stages:
1. Requirements: During this phase, detailed requirements of the software
system to be developed are gathered from client.
– This stage handles the defining and planning of the project without
mentioning specific processes.
– Potential requirements, deadlines and guidelines for the project are
analyzed and placed into a functional specification.
– Prepared a formal document called BRS-Business Requirement
Specifications that is an agreement(bid) between client and Company.

2. Analysis: The system specifications are analyzed to generate product

models and business logic that will guide production.

– This is also analyzed the financial, human and technical resources are
audited for feasibility.
– Prepared a technical document called Software Requirement
Specifications(SRS) that contains both functional and non-fuctional
requirements of software.
 Waterfall Model
3. Design:
A design specification document is created to outline technical design
requirements such as programming language, hardware, data sources,
architecture and services.
– Plan the programming language, for Example Java, PHP, .net
– or database like Oracle, MySQL, etc.
– Or other high-level technical details of the project
– Prepared the blueprint or prototype of the project with the help of algorithms,
pseudo code, f low charts, graphs, and UML Models

4. Coding/Implementation:
The source code is developed using the models, logic and requirements
designated in the prior stages. Typically, the system is designed in smaller
components, or units, before being implemented together.
 Waterfall Model
5. Testing:
– This is when quality assurance, unit, system and beta (uncover any bugs or issues
before a general release)tests take place to report issues that may need to be
resolved.

– This may cause a forced repeat of the coding stage for debugging. If the system
passes the tests, the waterfall continues forward.

– Use Manual/Automation testing tools- QTP, Win runner, Load Runner and Selenium

6. Operation/Deployment:
– The product or application is deemed(released) fully functional and is deployed to
a live client environment.
7. Maintenance:
– Once your system is ready to use, you may later require change the code as per
customer request.

– Corrective, adaptive and perfective maintenance is carried out indefinitely to

improve, update and enhance the final product. This could include
releasing patch updates or releasing new versions.
 Waterfall Model
• When to use SDLC Waterfall Model?
– When the requirements are constant and not changed regularly.

– A project is short.

– Where the tools and technology used is consistent(stable/static)

and is not changing.

– Requirements are not changing frequently.

– Application is not complicated and big.

 Waterfall Model
• Advantages of the waterfall model
– Simple to understand, follow and arrange tasks.
– Suited for smaller projects where requirements are well
defined.
– Reinforces good coding habits to define before design and
then code.
– Allows for early design or specification changes to be made
easily.
– Clearly defines milestones and deadlines.
– Facilitates departmentalization(integration) and managerial
control based on schedule or deadlines.
 Waterfall Model
• Disadvantages of the waterfall model
– No working software is produced until late during the life cycle.

– High amounts of risk and uncertainty.

– Not a good model for complex and object-oriented projects.

– Poor model for long and ongoing projects.

– Not suitable for the projects where requirements are at a moderate to

high risk of changing.

– It is difficult to measure progress within stages.

– Cannot accommodate changing requirements.

– Adjusting scope during the life cycle can end a project.

– Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
 Waterfall Model
• Disadvantages of the waterfall model
– Design is not adaptive; often when a flaw(error) is found, the entire
process needs to start over.

– Ignores the potential to receive mid-process user or client feedback and

make changes based on results.

– Delays testing until the end of the development life cycle.

– Does not consider error correction.

– Does not handle requests for changes, scope adjustments or updates

well.

– Reduces efficiency by not allowing processes to overlap.

– No working product is available until the later stages of the life cycle.

– Not ideal for complex, high risk, ongoing or object-oriented projects.

 Incremental Model
• The incremental model combines elements of the waterfall
model applied in an iterative fashion.

• Incremental model is a process of software development where

requirements divided into multiple standalone
modules(Increments) of the software development cycle.

• The first increment is often a core product, that is basic

requirements are addressed.

• In this model, each increment, goes through the requirements,

design, implementation and testing phases.

• Every subsequent release of the module adds function to the

previous release. The process continues until the complete
system achieved.
Incremental Model
Incremental Model
Incremental Model
 Incremental Model
• The various phases of incremental model are as follows:
1. Requirement analysis: In the first phase of the incremental model, the product
analysis expertise identifies the requirements. And the system functional
requirements are understood by the requirement analysis team. To develop the
software under the incremental model, this phase performs a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC, the design of
the system functionality and the development method are finished with success.
When software develops new practicality, the incremental model uses style and
development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various
methods are used to test the behavior of each task.

4. Implementation: Implementation phase enables the coding phase of the development

system. It involves the final coding that design in the designing and development
phase and tests the functionality in the testing phase. After completion of this phase,
the number of the product working is enhanced and upgraded up to the final system
product
 Incremental Model
• When we use the Incremental Model?
– When the requirements are superior(huge).
– A project has a lengthy development schedule.
– When Software team are not very well skilled or trained.
– When the customer demands a quick release of the product.
– You can develop prioritized requirements first.
• Advantage of Incremental Model
– Errors are easy to be recognized
– Easier to test and debug.
– More flexible.
– Simple to manage risk because it handled during its iteration.
– The Client gets important functionality(core) early.
• Disadvantage of Incremental Model
– Need for good planning.
– Total Cost is high.
– Well defined module interfaces are needed.
 RAD Model
• The Rapid Application Development(RAD) is an incremental software process
model that emphasizes a short development cycle.
• The RAD model is a “high speed” adaptation of the waterfall model, in which
rapid development is achieved by using component based construction
approach.
 RAD Model

• The Rapid Application Development Model was first proposed by IBM in

the 1980s.

• The critical feature of this model is the use of powerful development

tools and techniques.

• A software project can be implemented using this model if the project

can be broken down into small modules wherein each module can be
assigned independently to separate teams.

• These modules can finally be combined to form the final product.

• Development of each module involves the various basic steps as in the

waterfall model i.e analyzing, designing, coding, and then testing, etc. as
shown in the figure.

• Another striking feature of this model is a short time span i.e the time
frame for delivery(time-box) is generally 60-90 days.
 RAD Model
• When to use RAD Model?
– When the customer has well-known requirements, the user is involved
throughout the life cycle, the project can be time boxed, the functionality
delivered in increments, high performance is not required, low technical risks are
involved and the system can be modularized. In these cases, we can use the RAD
Model.
• Advantages:
– The use of reusable components helps to reduce the cycle time of the
project.
– Feedback from the customer is available at the initial stages.
– Reduced costs as fewer developers are required.
– The use of powerful development tools results in better quality products
in comparatively shorter time spans.
– The progress and development of the project can be measured through
the various stages.
– It is easier to accommodate changing requirements due to the short
iteration time spans.
 RAD Model
• Disadvantages:
– The use of powerful and efficient tools requires highly skilled professionals.

– The absence of reusable components can lead to the failure of the project.

– The team leader must work closely with the developers and customers to
close the project in time.

– The systems which cannot be modularized suitably cannot use this model.

– Customer involvement is required throughout the life cycle.

– It is not meant for small-scale projects as in such cases, the cost of using
automated tools and techniques may exceed the entire budget of the
project.
 RAD Model
• Applications:
– This model should be used for a system with known requirements and
requiring a short development time.

– It is also suitable for projects where requirements can be modularized and

reusable components are also available for development.

– The model can also be used when already existing system components can
be used in developing a new system with minimum changes.

– This model can only be used if the teams consist of domain experts. This is
because relevant knowledge and the ability to use powerful techniques are
a necessity.

– The model should be chosen when the budget permits the use of
automated tools and techniques required.
 Iterative Model
• In this Model, you can start with some of the software specifications and
develop the first version of the software.

• After the first version if there is a need to change the software, then a new
version of the software is created with a new iteration.

• Every release of the Iterative Model finishes in an exact and fixed period that
is called iteration.

• The Iterative Model allows the accessing earlier phases, in which the
variations made respectively.

• The final output of the project renewed at the end of the Software
Development Life Cycle (SDLC) process.
Iterative Model
 Iterative Model
• When to use the Iterative Model?
– When requirements are defined clearly and easy to understand.

– When the software application is large.

– When there is a requirement of changes in future.

• Advantage(Pros) of Iterative Model:

– Testing and debugging during smaller iteration is easy.
– A Parallel development can plan.
– It is easily acceptable to ever-changing needs of the project.
– Risks are identified and resolved during iteration.
– Limited time spent on documentation and extra time on designing.

• Disadvantage(Cons) of Iterative Model:

– It is not suitable for smaller projects.

– More Resources may be required.

– Design can be changed again and again because of imperfect requirements.

– Requirement changes can cause over budget.

– Project completion date not confirmed because of changing requirements.

 Evolutionary Model
• Evolutionary model is a combination of Iterative and
Incremental model of software development life cycle.

• In Evolutionary model, the software requirement is first broken

down into several modules (or functional units) that can be
incrementally constructed and delivered.

• The development first develops the core modules of the

system.

• The initial product skeleton is refined into increasing levels of

capability by adding new functionalities in successive versions
are developed using an iterative waterfall model of
development.
 Evolutionary Model
• Each phase product feature sets redefined because of user
feedback and other factors.

• Evolutional Models are

– The Prototype Model

– The Spiral Model

– The Concurrent Development Model

 Evolutionary Model
• When Evolutional Model is useful
– It is very useful in a large projects
– Mostly used in object-oriented software development because all
the development is divided into different units(modules)
• Advantages
– The client has checked every stage during the development and it is
helpful in achieving customer confidence.
– All the modules are well design/code.
– It helps to reduce the risk of software projects.
– It also reduces the cost of development.
• Disadvantages
– The delivery of full software can be late due to different changes by
customers during development.
– It is difficult to divide the problem into several parts, that would be
acceptable to the customer which can be incrementally implemented
and delivered.
 The Prototyping model
• The prototype model requires that before carrying out the development of
actual software, a working prototype of the system should be built.

• A prototype usually contains very basic version of the actual system, possible
exhibiting limited functional capabilities, low reliability, and inefficient
performance as compared to actual software.

• It is software working model of limited functionality.

• In this model, working programs are quickly produced.

The Prototyping model
 The Prototyping model
• The different phases of Prototyping model are:
1. Communication
In this phase, developer and customer meet and discuss the overall objectives of
the software.
2. Quick design Quick design is implemented when requirements are
known.
– It includes only the important aspects like input and output format of the software.
– It focuses on those aspects which are visible to the user rather than the detailed plan.
– It helps to construct a prototype.
3. Modeling quick design This phase gives the clear idea about the
development of software because the software is now built.
– It allows the developer to better understand the exact requirements.
4. Construction of prototype
The prototype is evaluated by the customer itself.
5. Deployment, delivery, feedback If the user is not satisfied with current
prototype then it refines according to the requirements of the user.
– The process of refining the prototype is repeated until all the requirements of users are
met.
– When the users are satisfied with the developed prototype then the system is developed
on the basis of final prototype.
 The Prototyping model
• Advantages of Prototyping Model

– In the development process of this model users are actively involved.

– The development process is the best platform to understand the

system by the user.

– Errors are detected much earlier.

– Gives quick user feedback for better solutions.

– It identifies the missing functionality easily. It also identifies the

confusing or difficult functions.
 The Prototyping model
• Disadvantages of Prototyping Model:

– The client involvement is more and it is not always considered by the

developer.

– It does not identify the requirements like detailed input, output.

– It is a slow process because it takes more time for development.

– Many changes can disturb the rhythm of the development team.

– It is a thrown away prototype when the users are confused with it.
 The Spiral model
• The spiral model is a risk-driven software development process model.

• Initially proposed by Boehm, is an evolutionary software process model that

couples the iterative feature of prototype and linear sequential model.

• It implements the potential for rapid development of new versions of the

software and developed a series of incremental releases.

• Spiral model follows 5 different Phases -

[Link],[Link],[Link],[Link],[Link]

• Each phase is begins with design goals and ends with client reviewing. Each
series of spiral contains
– Series1: Concept development
– Series2: System development
– Series 3: Enhancement development
– Series 4: System maintenance
The Spiral model
The Spiral model
 When to use Spiral model
Properties of Spiral Model

• Rick Handling

• Radius of Spiral=Cost

• Angular dimension of Spiral=Progress

• Meta Model(Combines Evolutionary, Prototype and waterfall models)

 The Spiral model
When to use Spiral Model
• Frequent deliveries
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
• When risk and costs evaluation is important

Advantages of Spiral Model

• It reduces high amount of risk.
• It is good for large and critical projects.
• It gives strong approval and documentation control.
• In spiral model, the software is produced early in the life cycle process.

Disadvantages of Spiral Model

• It can be costly to develop a software model.
• Skilled people required for Risk analysis
• It is not used for small projects.
 The Concurrent Development model
• The concurrent development model is also called as concurrent
model.

• The communication activity has completed in the first iteration and

exits in the awaiting changes state.

• The modeling activity completed its initial communication and then

go to the underdevelopment state.

• If the customer specifies the change in the requirement, then the

modeling activity moves from the under development state into the
awaiting change state.

• The concurrent process model activities moving from one state to

another state.
The Concurrent Development model
 The Concurrent Development model
Advantages
• This model is applicable to all types of software development
processes.

• It is easy for understanding and use.

• It gives immediate feedback from all phases e.g testing.

• It provides an accurate picture of the current state of a project.

Disadvantages

• It needs better communication between the team members. This

may not be achieved all the time.

• It requires to remember the status of the different activities.

 V model
• V-Model also referred to as the Verification and Validation
Model.

• In this, each phase of SDLC must complete before the next

phase starts.

• It follows a sequential design process same as the waterfall

model.

• Testing of the device is planned in parallel with a

corresponding stage of development.
 V model
• Verification: It involves a static analysis method (review) done
without executing code. It is the process of evaluation of the product
development process to find whether specified requirements meet.

• Validation: It involves dynamic analysis method (functional, non-

functional), testing is done by executing code. Validation is the
process to classify the software after the completion of the
development process to determine whether the software meets the
customer expectations and requirements.

• So V-Model contains Verification phases on one side of the Validation

phases on the other side.

• Verification and Validation process is joined by coding phase in V-

shape. Thus it is known as V-Model.
V model
 V model
• V-model strengths
– A highly opinionated(hide) and disciplined model where
phases are completed linearly.

– Works well for smaller projects where requirements are

clear and well documented.

– Simple and easy to understand and use.

– Easy to manage each phase having specific deliverables and

a clear review process.
 V model
• V-model weaknesses
– Not considered a good model for developing complex and
object-oriented software.

– Not suited to long and/or ongoing iterative software projects.

– Not suitable for software whose requirements are likely to

change.

– The model makes it difficult to make retrospective changes to

design and functionality once the verification testing phases
have started.

– No working software is produced until late in the linear life

cycle.
 Agile model
• The meaning of Agile is versatile."Agile process model"
refers to a software development approach based on
iterative development.

• Agile methods break tasks into smaller iterations, or

parts do not directly involve long term planning.

• The project scope and requirements are laid down at

the beginning of the development process. Plans
regarding the number of iterations, the duration and the
scope of each iteration are clearly defined in advance.
Agile model
 Agile model
• Phases of Agile Model:
– Requirements gathering
– Design the requirements
– Construction/ iteration
– Testing/ Quality assurance
– Deployment
– Feedback
 Agile model
• Agile Testing Methods:
– Scrum
– Crystal
– Dynamic Software Development Method(DSDM)
– Feature Driven Development(FDD)
– Lean Software Development
– eXtreme Programming(XP)
 Agile model
• When to use the Agile Model?
– When frequent changes are required.
– When a highly qualified and experienced team is available.
– When a customer is ready to have a meeting with a
software team all the time.
– When project size is small.
• Advantage(Pros) of Agile Method:
– Frequent Delivery
– Face-to-Face Communication with clients.
– Efficient design and fulfils the business requirement.
– Anytime changes are acceptable.
– It reduces total development time.
 Agile model
• Disadvantages(Cons) of Agile Model:
• Due to the shortage of formal documents, it creates
confusion and crucial decisions taken throughout
various phases can be misinterpreted at any time by
different team members.

• Due to the lack of proper documentation, once the

project completes and the developers allotted to
another project, maintenance of the finished project
can become a difficulty.
 Unified model
• Unified process (UP) is an architecture centric, use case driven, iterative
and incremental development process. UP is also referred to as the
unified software development process.
• Adopted the best principles from agile software development.
• The Unified Process recognizes the importance of customer
communication and streamlined methods for describing the customer’s
view of a system.
• 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”.
• Phases of the Unified Process
• This process divides the development process into five phases:
– Inception
– Elaboration
– Conception
– Transition
– Production
Unified model
 Unified model
• The inception phase of the UP encompasses both customer communication and
planning activities. By collaborating with stakeholders, 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 communication 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 requirements
model, the design model, the implementation model, and the deployment model.

• Elaboration creates an “executable architectural baseline” that represents a “first

cut” executable system.
 Unified 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.
• To accomplish this, requirements and design models that were started during the elaboration
phase are completed to reflect the final version of the software increment. All necessary and
required features and functions for the software increment (the release) are then
implemented in source code.

• The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback) 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.

• The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and requests for
changes are submitted and evaluated.