UNIT- I

Software Process Models

Introduction to software engineering, Classification of Software, Software Development
Life Cycle- Waterfall Model, Iterative Waterfall Model, Spiral Model, Incremental
process Model, Rapid Application Development Model (RAD), Agile Development
Model, SCRUM, Extreme Programming.

Introduction to Software and Software Engineering

Software engineering stands for 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 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.
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.

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.
1
Characteristics of software
Software has characteristics that are considerably different than those of hardware:
1) Software is developed or engineered, it is not manufactured in the Classical Sense.
Although some similarities exist between software development and hardware
manufacture, the two activities are fundamentally different. In both the activities, high quality is
achieved through good design, but the manufacturing phase for hardware can introduce quality
problems that are nonexistent or easily corrected for software. Both the activities are dependent
on people, but the relationship between people is totally varying. These two activities require the
construction of a "product" but the approaches are different. Software costs are concentrated in
engineering which means that software projects cannot be managed as if they were
manufacturing.
2) Software doesn’t “Wear Out”
The following figure shows the relationship between failure rate and time. Consider the
failure rate as a function of time for hardware. The relationship is called the bathtub curve,
indicates that hardware exhibits relatively high failure rates early in its life, defects are corrected
and the failure rate drops to a steady-state level for some period of time. As time passes,
however, the failure rate rises again as hardware components suffer from the cumulative effects
of dust, vibration, abuse, temperature extremes, and many other environmental maladies. So,
stated simply, the hardware begins to wear out. Software is not susceptible to the environmental
maladies that cause hardware to wear out

2
3) Although the industry is moving toward component-based construction, most software
continues to be custom built
A software component should be designed and implemented so that it can be reused in
many different programs. Modern reusable components encapsulate both data and the processing
that is applied to the data, enabling the software engineer to create new applications from
reusable parts.

Software Application Domains

Seven Broad Categories of software are challenges for software engineers
System software : A collection of programs written to service other programs. Some system
software (e.g., compilers, editors, and file management utilities)
Application software : Stand-alone programs that solve a specific business need. Application
software is used to control business functions in real time (e.g., point-of-sale transaction
processing, real-time manufacturing process control).
Engineering/scientific software : It has been characterized by “number crunching” algorithms.
Applications range from astronomy to volcanology, from automotive stress analysis to space
shuttle orbital dynamics, and from molecular biology to automated manufacturing.
Embedded software : It resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself. Embedded software can perform
limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant
function and control capability (e.g., digital functions in an automobile such as fuel control,
dashboard displays, and braking systems).

3
 Product-line software : Designed to provide a specific capability for use by many different
customers. Product-line software can focus on a limited and esoteric marketplace (e.g., inventory
control products) or address mass consumer markets (e.g., word processing, spreadsheets,
computer graphics, multimedia, entertainment, database management, and personal and business
financial applications).
Web applications : These Applications called “WebApps,” this network-centric software
category spans a wide array of applications. In their simplest form, WebApps can be little more
than a set of linked hypertext files that present information using text and limited graphics.
.Artificial intelligence software : These makes use of non numerical algorithms to solve
complex problems that are not amenable to computation or straightforward analysis.
Applications within this area include robotics, expert systems, pattern recognition (image and
voice), artificial neural networks, theorem proving, and game playing.

Software General Principles

The dictionary defines the word principle as “an important underlying law or assumption
required in a system of thought.”
David Hooker has Proposed seven principles that focus on software Engineering practice.

The First Principle: The Reason It All Exists

A software system exists for one reason: to provide value to its users.
The Second Principle: KISS (Keep It Simple, Stupid!)
Software design is not a haphazard process. There are many factors to consider in any
design effort. All design should be as simple as possible, but no simpler.
The Third Principle: Maintain the Vision
A clear vision is essential to the success of a software project. Without one, a project almost
unfailingly ends up being “of two [or more] minds” about itself.
The Fourth Principle: What You Produce, Others Will Consume
Always specify, design, and implement knowing someone else will have to understand what you
are doing.
The Fifth Principle: Be Open to the Future
A system with a long lifetime has more value. Never design yourself into a corner. Before
beginning a software project, be sure the software has a business purpose and that users
perceive value in it.
4
 The Sixth Principle: Plan Ahead for Reuse
Reuse saves time and effort. Planning ahead for reuse reduces the cost and increases the value
of both the reusable components and the systems into which they are incorporated.
The Seventh principle: Think!
Placing clear, complete thought before action almost always produces better results. When you
think about something, you are more likely to do it right.

Software Development Life Cycle Models :

Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the
project. In "The Waterfall" approach, the whole process of software development is divided into separate
phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase
sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.

The sequential phases in Waterfall model are −

Requirement Gathering and analysis − All possible requirements of the system to be developed are
captured in this phase and documented in a requirement specification document.

5
 System Design − The requirement specifications from first phase are studied in this phase and the
system design is prepared. This system design helps in specifying hardware and system requirements
and helps in defining the overall system architecture.

Implementation − With inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and tested for its
functionality, which is referred to as Unit Testing.

Integration and Testing − All the units developed in the implementation phase are integrated into a
system after testing of each unit. Post integration the entire system is tested for any faults and failures.

Deployment of system − Once the functional and non-functional testing is done; the product is
deployed in the customer environment or released into the market.

Maintenance − There are some issues which come up in the client environment. To fix those issues,
patches are released. Also to enhance the product some better versions are released. Maintenance is
done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a
waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for
previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.
Waterfall Model - Application
Every software developed is different and requires a suitable SDLC approach to be followed based on the
internal and external factors. Some situations where the use of Waterfall model is most appropriate are −
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
Waterfall Model - Advantages
The advantages of waterfall development are that it allows for departmentalization and control. A schedule
can be set with deadlines for each stage of development and a product can proceed through the development
process model phases one by one.
Development moves from concept, through design, implementation, testing, installation, troubleshooting, and
ends up at operation and maintenance. Each phase of development proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows −
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific deliverable and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
6
 Easy to arrange tasks.
 Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow much reflection or revision. Once an
application is in the testing stage, it is very difficult to go back and change something that was not well-
documented or thought upon in the concept stage.
The major disadvantages of the Waterfall Model are as follows −
 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. So, risk and
uncertainty is high with this process model.
 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.

Iterative Waterfall Model in SDLC :

The iterative waterfall model allows for flexibility and adaptability, as the project team can review and revise
the plan for each iteration based on the results of the previous iteration. This can help to mitigate risk and
improve the overall quality of the final product.
Phases of Iterative Waterfall Model:

The iterative waterfall model is a software development approach that combines elements of both the
waterfall model and iterative development. In this model, the software development process is divided into a
series of iterations, or cycles, each of which involves the following phases:

Planning:
7
In this phase, the project team determines the goals and objectives for the current iteration, and develops a
plan for achieving them.
Analysis:
In this phase, the project team gathers and analyses requirements for the current iteration.
Design:
In this phase, the project team designs the solution for the current iteration.
Implementation:
In this phase, the project team builds and tests the solution for the current iteration.
Testing:
In this phase, the project team tests the solution to ensure that it meets the requirements and functions as
intended.
Deployment:
In this phase, the solution is deployed to the production environment.
Maintenance:
In this phase, the project team provides ongoing support and maintenance for the solution.

Advantages of Iterative Waterfall Model

There are several advantages to using the Iterative Waterfall Model in software development:
 It is easy to understand and implement, making it a good choice for small projects or teams that are new
to software development.
 The iterative nature of the model allows for changes and adjustments to be made as the project progresses,
which can be beneficial in addressing unexpected issues or requirements.
 The clear separation of phases allows for better planning and management of the project, as each phase
has specific goals and deliverable.
 The Waterfall Model can be a good choice for projects with well-defined and unchanging requirements,
as it allows for a more structured and predictable development process.
 It can be easier to get stakeholder buy-in and approval at each phase of the project, as the deliverables are
clearly defined and progress can be easily tracked.

8
Disadvantages of Iterative Waterfall Model
The Iterative Waterfall model, like the traditional Waterfall model, has a number of disadvantages that can
make it less suitable for some projects. Some of the main disadvantages of the Iterative Waterfall model are:
Various Disadvantages
1- Inflexibility
2- Lack of Customer involvement
3- Risk of Failure
4- Poor Communication
5- High Costs

Spiral Model - Design

The spiral model has four phases. A software project repeatedly passes through these phases in iterations
called Spirals.
Identification
This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as
the product matures, identification of system requirements, subsystem requirements and unit requirements are
all done in this phase.
This phase also includes understanding the system requirements by continuous communication between the
customer and the system analyst. At the end of the spiral, the product is deployed in the identified market.
Design
The Design phase starts with the conceptual design in the baseline spiral and involves architectural design,
logical design of modules, physical product design and the final design in the subsequent spirals.
Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In the baseline spiral,
when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed
in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working model of the
software called build is produced with a version number. These builds are sent to the customer for feedback.
Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks,
such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.
The following illustration is a representation of the Spiral Model, listing the activities in each phase.

9
Based on the customer evaluation, the software development process enters the next iteration and
subsequently follows the linear approach to implement the feedback suggested by the customer. The process
of iterations along the spiral continues throughout the life of the software.
Spiral Model Application
The Spiral Model is widely used in the software industry as it is in sync with the natural development process
of any product, i.e. learning with maturity which involves minimum risk for the customer as well as the
development firms.
The following pointers explain the typical uses of a Spiral Model −

 When there is a budget constraint and risk evaluation is important.

 For medium to high-risk projects.
 Long-term project commitment because of potential changes to economic priorities as the requirements
change with time.
 Customer is not sure of their requirements which is usually the case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough customer feedback.
 Significant changes are expected in the product during the development cycle.

Spiral Model - Pros and Cons

The advantage of spiral lifecycle model is that it allows elements of the product to be added in, when they
become available or known. This assures that there is no conflict with previous requirements and design.

10
This method is consistent with approaches that have multiple software builds and releases which allows
making an orderly transition to a maintenance activity. Another positive aspect of this method is that the
spiral model forces an early user involvement in the system development effort.
On the other side, it takes a very strict management to complete such products and there is a risk of running
the spiral in an indefinite loop. So, the discipline of change and the extent of taking change requests is very
important to develop and deploy the product successfully.
The advantages of the Spiral SDLC Model are as follows −

 Changing requirements can be accommodated.

 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky parts can be developed earlier which helps
in better risk management.

The disadvantages of the Spiral SDLC Model are as follows −

 Management is more complex.

 End of the project may not be known early.
 Not suitable for small or low risk projects and could be expensive for small projects.
 Process is complex
 Spiral may go on indefinitely.
 Large number of intermediate stages requires excessive documentation.

Incremental Model :
Incremental Model is a process of software development where requirements divided into multiple standalone
modules of the software development cycle. In this model, each module 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.

The various phases of incremental model are as follows:

11
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.

When we use the Incremental Model?

 When the requirements are superior.
 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 early.
Disadvantage of Incremental Model
 Need for good planning
 Total Cost is high.
 Well defined module interfaces are needed.

RAD Model Design

RAD model distributes the analysis, design, build and test phases into a series of short, iterative development
cycles.
Following are the various phases of the RAD Model −
Business Modelling
The business model for the product under development is designed in terms of flow of information and the
distribution of information between various business channels. A complete business analysis is performed to
find the vital information for business, how it can be obtained, how and when is the information processed
and what are the factors driving successful flow of information.
Data Modelling
The information gathered in the Business Modelling phase is reviewed and analyzed to form sets of data
objects vital for the business. The attributes of all data sets is identified and defined. The relation between
these data objects are established and defined in detail in relevance to the business model.
Process Modelling
The data object sets defined in the Data Modelling phase are converted to establish the business information
12
flow needed to achieve specific business objectives as per the business model. The process model for any
changes or enhancements to the data object sets is defined in this phase. Process descriptions for adding,
deleting, retrieving or modifying a data object are given.
Application Generation
The actual system is built and coding is done by using automation tools to convert process and data models
into actual prototypes.
Testing and Turnover
The overall testing time is reduced in the RAD model as the prototypes are independently tested during every
iteration. However, the data flow and the interfaces between all the components need to be thoroughly tested
with complete test coverage. Since most of the programming components have already been tested, it reduces
the risk of any major issues.
The following illustration describes the RAD Model in detail.

RAD Model Vs Traditional SDLC

The traditional SDLC follows a rigid process models with high emphasis on requirement analysis and
gathering before the coding starts. It puts pressure on the customer to sign off the requirements before the
project starts and the customer doesn’t get the feel of the product as there is no working build available for a
long time.
The customer may need some changes after he gets to see the software. However, the change process is quite
rigid and it may not be feasible to incorporate major changes in the product in the traditional SDLC.
The RAD model focuses on iterative and incremental delivery of working models to the customer. This
results in rapid delivery to the customer and customer involvement during the complete development cycle of
product reducing the risk of non-conformance with the actual user requirements.
RAD Model - Application
RAD model can be applied successfully to the projects in which clear modularization is possible. If the
project cannot be broken into modules, RAD may fail.
The following pointers describe the typical scenarios where RAD can be used −

 RAD should be used only when a system can be modularized to be delivered in an incremental manner.
 It should be used if there is a high availability of designers for Modelling.
13
 It should be used only if the budget permits use of automated code generating tools.
 RAD SDLC model should be chosen only if domain experts are available with relevant business
knowledge.
 Should be used where the requirements change during the project and working prototypes are to be
presented to customer in small iterations of 2-3 months.

RAD Model - Pros and Cons

RAD model enables rapid delivery as it reduces the overall development time due to the reusability of the
components and parallel development. RAD works well only if high skilled engineers are available and the
customer is also committed to achieve the targeted prototype in the given time frame. If there is commitment
lacking on either side the model may fail.
The advantages of the RAD Model are as follows −

 Changing requirements can be accommodated.

 Progress can be measured.
 Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in a short time.
 Reduced development time.
 Increases re usability of components.
 Quick initial reviews occur.
 Encourages customer feedback.
 Integration from very beginning solves a lot of integration issues.

The disadvantages of the RAD Model are as follows −

 Dependency on technically strong team members for identifying business requirements.

 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 High dependency on Modelling skills.
 Inapplicable to cheaper projects as cost of Modelling and automated code generation is very high.
 Management complexity is more.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.

AGILE Method of Software development:

Agile model believes that every project needs to be handled differently and the existing methods need to be
tailored to best suit the project requirements. In Agile, the tasks are divided to time boxes (small time frames)
to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the customer.
Here is a graphical illustration of the Agile Model −

14
The Agile thought process had started early in the software development and started becoming popular with
time due to its flexibility and adaptability.
The most popular Agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear,
Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic
Systems Development Method (DSDM) (1995). These are now collectively referred to as Agile
Methodologies, after the Agile Manifesto was published in 2001.
Following are the Agile Manifesto principles −

 Individuals and interactions − In Agile development, self-organization and motivation are important, as
are interactions like co-location and pair programming.
 Working software − Demo working software is considered the best means of communication with the
customers to understand their requirements, instead of just depending on documentation.

 Customer collaboration − As the requirements cannot be gathered completely in the beginning of the
project due to various factors, continuous customer interaction is very important to get proper product
requirements.
 Responding to change − Agile Development is focused on quick responses to change and continuous
development.

Agile Vs Traditional SDLC Models

Agile is based on the adaptive software development methods, whereas the traditional SDLC models like the
waterfall model is based on a predictive approach. Predictive teams in the traditional SDLC models usually
work with detailed planning and have a complete forecast of the exact tasks and features to be delivered in the
next few months or during the product life cycle.
15
Predictive methods entirely depend on the requirement analysis and planning done in the beginning of cycle.
Any changes to be incorporated go through a strict change control management and prioritization.
Agile uses an adaptive approach where there is no detailed planning and there is clarity on future tasks only in
respect of what features need to be developed. There is feature driven development and the team adapts to the
changing product requirements dynamically. The product is tested very frequently, through the release
iterations, minimizing the risk of any major failures in future.
Customer Interaction is the backbone of this Agile methodology, and open communication with minimum
documentation are the typical features of Agile development environment. The agile teams work in close
collaboration with each other and are most often located in the same geographical location.
Agile Model - Pros and Cons
Agile methods are being widely accepted in the software world recently. However, this method may not
always be suitable for all products. Here are some pros and cons of the Agile model.
The advantages of the Agile Model are as follows −

 Is a very realistic approach to software development.

 Promotes teamwork and cross training.
 Functionality can be developed rapidly and demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
 Delivers early partial working solutions.
 Good model for environments that change steadily.
 Minimal rules, documentation easily employed.
 Enables concurrent development and delivery within an overall planned context.
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers.
The disadvantages of the Agile Model are as follows −

 Not suitable for handling complex dependencies.

 More risk of sustainability, maintainability and extensibility.
 An overall plan, an agile leader and agile PM practice is a must without which it will not work.

 Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the
deadlines.
 Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong
direction.
 There is a very high individual dependency, since there is minimum documentation generated.
 Transfer of technology to new team members may be quite challenging due to lack of documentation.

Scrum and XP
There are two main models of Agile framework namely: Scrum, and Extreme Programming (XP). Scrum
Framework: Scrum is the type of Agile framework. It is a framework within which people can address
complex adaptive problem while productivity and creativity of delivering product is at highest possible values.
Scrum uses Iterative process. Life Cycle of Scrum:

16
Extreme Programming (XP): Extreme Programming is one of the most important models of Agile framework.
This model emphasizes team-work and customer satisfaction as well. The five basic component of Extreme
Programming are:
Communication
Simplicity
Feedback
Respect
Courage
Life Cycle of Extreme Programming (XP):

S. Scrum Extreme Programming (XP)

No.

In the Scrum framework, teamwork in

In Extreme Programming(XP), teamwork for 1-2
1. iterations is called Sprint which is 2 weeks to 1
weeks only.
month long.

Scrum models do not allow changes in their Extreme Programming allows changes in their set
2.
timeline or their guidelines. timelines.

17
S. Scrum Extreme Programming (XP)
No.

Extreme Programming emphasizes strong

3. Scrum emphasizes self-organization.
engineering practices

In the Scrum framework, the team determines In Extreme Programming, the team has to follow a
4. the sequence in which the product will be strict priority order or pre-determined priority
developed. order.

The Scrum framework is not fully described. If

Extreme Programming(XP) can be directly applied
you want to adopt it then you need to fill the
5. to a team. Extreme Programming is also known for
framework with your frameworks methods like
its Ready-to-apply features.
XP, DSDM, or Kanban.

Scrum does not put emphasis on software Extreme Programming (XP) emphasizes
6. engineering practices that developers should programming techniques that developers should use
use. to ensure a better outcome.

It requires developers to be conscious of It is very strict in adopting engineering methods

7. adopting engineering methods to ensure better such as pair programming, simple design,
progress or quality. restructuring to ensure better progress or quality.

In the preference of features, demand and

In the preference of features, the demand
8. priority do not have to be in line with one
corresponds to the priority.
another.

In scrum, the scrum master asks the owner of

In XP, customer decides the job priorities being the
9. the product to prioritize the tasks according to
owner of the product and then analyses the releases.
their requirements.

18
S. Scrum Extreme Programming (XP)
No.

The tasks are prioritized by the owner of the

The tasks are prioritized by the customer and the
product but with the flexibility that the
10. task priorities cannot be changed by the
priorities can be changed later on by the
development team.
development team if required.

Values- Values-
Openness Communication
11.
Focus Simplicity
Commitment Feedback

12. Customer involvement is less in the project. Customer involvement is more in the project.

19
20