Software Engineering

UNIT-1

Chapter-1(Introduction)

Definition of software and Software engineering, Need of Software engineering,

Difference between Program and Product, Software development life cycle,
Different life cycle models (waterfall, Iterative waterfall, Prototype,
Evolutionary and Spiral model), Agile software development and Their
characteristics, V-Model.

Chapter-2 (Software requirements)

Requirement Analysis, Analysis principle, Software prototyping Specification,

Characteristics and components of SRS, Data modeling, Functional modeling
and information flow, behavioral modeling, Mechanics of structural modeling,
Data dictionary.

Chapter-3 (Function and Object oriented design)

Structured analysis, Data flow diagrams, Basic object orientation concepts, Unified
modeling language, Use case model, Class diagrams, Interaction diagrams, Activity
diagrams, State chart diagrams

Prepared By: Er. Inderjeet Singh(e8822) Page 1

 Software Engineering

Chapter-1(Introduction)

Evolving Role of Software

The role of software has undergone drastic change in the last few decades. These
improvements range through hardware, computing architecture, memory, storage
capacity and a wide range of unusual input and output conditions. All these
significant improvements have lead to the development of more complex and
sophisticated computer-based systems. Sophistication leads to better results but
can cause problems for those who build these systems.

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.

Software

Software is a program or set of programs containing instructions which provide

desired functionality. The software is collection of integrated programs. Software
consists of carefully-organized instructions and code written by programmers in
any of various special computer languages.

The software differs from hardware as it is more logical in nature and hence, the
difference in characteristics.

Classification of Software:

Real-time software: It refers to the software that controls the events and when
they occur. The data gatherer component of the software gathers the data and

Prepared By: Er. Inderjeet Singh(e8822) Page 2

 Software Engineering

formats it into an acceptable form. The analyzer component that transforms

information as required by the application. The output component that interacts
with the external environment and the monitoring component that coordinates
with all the components to generate timely results. Example: Google maps,
Whatsapp, Instagram etc.

Business software: For example, library management, data inventory, HR

management, etc.

System Software: It is the software program that interacts with the hardware
components so that other application software can run on it. Operating systems
like Windows, Unix, DOS, etc., are examples of the system software.

Personal computer software: These software programs have grown rapidly over
the past few decades. These include the like of database management,
entertainment, computer graphics, multimedia, etc.

Artificial intelligence software: AI software uses algorithms to solve problems that

are not open to simple computing and analysis. For example, Pattern matching
(voice or image), game playing, robotics, expert systems, etc.

Engineering software: The software is characterized by number-crunching

algorithms ranging from molecular biology, automated manufacturing to space
shuttle orbit management, etc.

Characteristics of Software:

1. Software is developed or engineered and not manufactured

2. Dual Role of Software
As a product –
It delivers the computing potential across network of Hardware.
It enables the Hardware to deliver the expected functionality.
It acts as information transformer because it produces, manages, acquires,
modifies, displays, or transmits information.
Prepared By: Er. Inderjeet Singh(e8822) Page 3
 Software Engineering

As a vehicle for delivering a product –

It provides system functionality (e.g., payroll system).

It controls other software (e.g., an operating system).
It helps build other software (e.g., software tools).

3. Software is Custom Built and Not Designed Component Wise

Software is designed and built so that it can be reused in different programs.

Today this view has been extended to ensure re-usability of not only algorithms
but data structures as well. Thus, the data and the processes that operate on this
data were combined together to be able to use later on.

4. Software does not wear out

The software does not undergo environmental degradation, its failure curve
ideally should flatten out after the initial stage of its life. The initial failure

Prepared By: Er. Inderjeet Singh(e8822) Page 4

 Software Engineering

rate is high because of undiscovered defects. Once these defects are fixed,
the curve flattens at a later stage. Thus, the software does not wear out but
deteriorates.

Program vs. Software

Software is more than programs. Any program is a subset of software, and it

becomes software only if documentation & operating procedures manuals are
prepared. There are three components of the software as shown in fig:

Prepared By: Er. Inderjeet Singh(e8822) Page 5

 Software Engineering

1. Program: Program is a combination of source code & object code.

2. Documentation: Documentation consists of different types of manuals.

Examples of documentation manuals are: Data Flow Diagram, Flow Charts, ER
diagrams, etc.

3. Operating Procedures: Operating Procedures consist of instructions to set up

and use the software system and instructions on how react to the system
failure. Example of operating system procedures manuals is: installation guide,
Beginner's guide, reference guide, system administration guide, etc.
Prepared By: Er. Inderjeet Singh(e8822) Page 6
 Software Engineering

Sno Programs Software

1 Program is a set of instruction Software Product is a collection of
related each other program designed for specific task.

2 Programs are usually small in size Software Products are usually large
in size.

3 Programs are developed by Software Product are developed by

individuals that means single user large no of users.

4 In program, there is no In Software Product, Proper

documentation or lack in proper documentation and well
documentation documented and user manual
prepared.
5 Development of program is Development of Software Product
Unplanned, usually not Systematic is well Systematic, organized,
etc. planned approach.
6 Programs provide Limited Software Products provides more
functionality and less features functionality as they are big in size
more options and features.

Prepared By: Er. Inderjeet Singh(e8822) Page 7

 Software Engineering

Software Engineering-

A popular definition of software engineering is: “A systematic collection of good

program development practices and techniques”.

Or

Software engineering discusses systematic and cost-effective techniques for

software development. These techniques help develop software using an
engineering approach(Example of Petty Contractors).

Or

The term software engineering is the product of two words, software, and
engineering. The software is a collection of integrated programs.

Software subsists of carefully-organized instructions and code written by

developers on any of various particular computer languages.

The result of software engineering is an effective and reliable software product.

• Different methods and techniques of software engineering are appropriate

for different types of systems.

• For example, games should be developed using series of prototypes, while

critical control systems require a complete analyzable specification to be
developed.

Objectives of Software Engineering

• Correctness – the extent to which software meets its specified requirements

• Reusability – the extent to which a module can be used in multiple

applications.

Prepared By: Er. Inderjeet Singh(e8822) Page 8

 Software Engineering

• Reliability – an attribute of software quality. The extent to which a program

can be expected to perform its intended function, over an arbitrary time
period.

• Portability – the ease with which software can be transferred from one
computer system or environment to another.

• Testability – the extent to which software facilitates both the establishment

of test criteria and the evaluation of the software with respect to those
criteria.

• Adaptability – the ease with which software allows differing system

constraints and user needs to be satisfied by making changes to the
software.

Need of Software Engineering

Software Engineering is required due to the following reasons:

• To manage Large software

• For more Scalability

• Cost Management

• To manage the dynamic nature of software

• For better quality Management

Prepared By: Er. Inderjeet Singh(e8822) Page 9

 Software Engineering

Main Attributes of Software Engineering

Software Engineering is a systematic, disciplined, quantifiable study and approach

to the design, development, operation, and maintenance of a software system.
There are four main Attributes of Software Engineering.

 Efficiency: It provides a measure of the resource requirement of a software

product efficiently.
 Reliability: It assures that the product will deliver the same results when
used in similar working environment.
 Reusability: This attribute makes sure that the module can be used in
multiple applications.
 Maintainability: It is the ability of the software to be modified, repaired, or
enhanced easily with changing requirements.

Advantages of Software Engineering

There are several advantages to using a systematic and disciplined approach to

software development, such as:

1. Improved Quality: By following established software engineering principles

and techniques, the software can be developed with fewer bugs and higher
reliability.

2. Increased Productivity: Using modern tools and methodologies can

streamline the development process, allowing developers to be more
productive and complete projects faster.

3. Better Maintainability: Software that is designed and developed using sound

software engineering practices is easier to maintain and update over time.

4. Reduced Costs: By identifying and addressing potential problems early in the

development process, software engineering can help to reduce the cost of
fixing bugs and adding new features later on.

Prepared By: Er. Inderjeet Singh(e8822) Page 10

 Software Engineering

5. Increased Customer Satisfaction: By involving customers in the development

process and developing software that meets their needs, software
engineering can help to increase customer satisfaction.

6. Better Team Collaboration: By using Agile methodologies and continuous

integration, software engineering allows for better collaboration among
development teams.

7. Better Scalability: By designing software with scalability in mind, software

engineering can help to ensure that software can handle an increasing
number of users and transactions.

8. Better Security: By following the Software Development Life Cycle (SDLC)

and performing security testing, software engineering can help to prevent
security breaches and protect sensitive data.

In summary, software engineering offers a structured and efficient approach to

software development, which can lead to higher-quality software that is easier
to maintain and adapt to changing requirements. This can help to improve
customer satisfaction and reduce costs, while also promoting better collaboration
among development teams.

Disadvantages of Software Engineering

While Software Engineering offers many advantages, there are also some potential
disadvantages to consider:

1. High upfront costs: Implementing a systematic and disciplined approach to

software development can be resource-intensive and require a significant
investment in tools and training.
2. Bureaucratic: Software Engineering can create an environment that is
bureaucratic, with a lot of processes and paperwork, which may slow down
the development process.
3. Complexity: With the increase in the number of tools and methodologies,
software engineering can be complex and difficult to navigate.

Prepared By: Er. Inderjeet Singh(e8822) Page 11

 Software Engineering

4. Limited creativity: The focus on structure and process can stifle creativity
and innovation among developers.
5. High learning curve: The development process can be complex, and it
requires a lot of learning and training, which can be challenging for new
developers.
6. High dependence on tools: Software engineering heavily depends on the
tools, and if the tools are not properly configured or are not compatible with
the software, it can cause issues.
7. High maintenance: The software engineering process requires regular
maintenance to ensure that the software is running efficiently, which can be
costly and time-consuming.

In summary, software engineering can be expensive and time-consuming, and it

may limit flexibility and creativity. However, the benefits of improved quality,
increased productivity, and better maintainability can outweigh the costs and
complexity. It’s important to weigh the pros and cons of using software
engineering and determine if it is the right approach for a particular software
project.

Software Development Life Cycle

Software development life cycle (SDLC) is a structured process that is used to

design, develop, and test good-quality software. SDLC, or software development
life cycle, is a methodology that defines the entire procedure of software
development step-by-step.

Or

A software development life cycle (SDLC) model (also called software life cycle
model and software development process model ) describes the different
activities that need to be carried out for the software to evolve in its life cycle.

Prepared By: Er. Inderjeet Singh(e8822) Page 12

 Software Engineering

The goal of the SDLC life cycle model is to deliver high-quality, maintainable
software that meets the user’s requirements. SDLC in software engineering
models outlines the plan for each stage so that each stage of the software
development model can perform its task efficiently to deliver the software at a
low cost within a given time frame that meets users’ requirements.

Prepared By: Er. Inderjeet Singh(e8822) Page 13

 Software Engineering

Stage-1: Planning and Requirement Analysis

Planning is a crucial step in everything, just as in software development. In this

same stage, requirement analysis is also performed by the developers of the
organization. This is attained from customer inputs, and sales
department/market surveys.

The information from this analysis forms the building blocks of a basic project. The
quality of the project is a result of planning. Thus, in this stage, the basic project is
designed with all the available information.

Stage-2: Defining Requirements

In this stage, all the requirements for the target software are specified. These
requirements get approval from customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This is a
sort of document that specifies all those things that need to be defined and
created during the entire project cycle.

Prepared By: Er. Inderjeet Singh(e8822) Page 14

 Software Engineering

Stage-3: Designing Architecture

SRS is a reference for software designers to come up with the best architecture for
the software. Hence, with the requirements defined in SRS, multiple designs for
the product architecture are present in the Design Document Specification
(DDS).

This DDS is assessed by market analysts and stakeholders. After evaluating all the
possible factors, the most practical and logical design is chosen for development.

Prepared By: Er. Inderjeet Singh(e8822) Page 15

 Software Engineering

Stage-4: Developing Product

At this stage, the fundamental development of the product starts. For this,
developers use a specific programming code as per the design in the DDS. Hence, it
is important for the coders to follow the protocols set by the association.
Conventional programming tools like compilers, interpreters, debuggers, etc. are
also put into use at this stage. Some popular languages like C/C++, Python, Java,
etc. are put into use as per the software regulations.

Stage-5: Product Testing and Integration

After the development of the product, testing of the software is necessary to

ensure its smooth execution. Although, minimal testing is conducted at every
stage of SDLC. Therefore, at this stage, all the probable flaws are tracked, fixed,
and retested. This ensures that the product confronts the quality requirements
of SRS.

Prepared By: Er. Inderjeet Singh(e8822) Page 16

 Software Engineering

Stage-6: Deployment and Maintenance of Products

After detailed testing, the conclusive product is released in phases as per the
organization’s strategy. Then it is tested in a real industrial environment. It is
important to ensure its smooth performance. If it performs well, the organization
sends out the product as a whole. After retrieving beneficial feedback, the
company releases it as it is or with auxiliary improvements to make it further
helpful for the customers. However, this alone is not enough. Therefore, along
with the deployment, the product’s supervision.

Prepared By: Er. Inderjeet Singh(e8822) Page 17

 Software Engineering

Software Development life Cycle models

1. Waterfall model
2. Iterative Waterfall model
3. Prototype model
4. Evolutionary model
5. Spiral model

Classical Waterfall model:

Classical waterfall model divides life cycle into phases:

• feasibility study,

• requirements analysis and specification,

• design,

• coding and unit testing,

• integration and system testing,

Prepared By: Er. Inderjeet Singh(e8822) Page 18
 Software Engineering

• Maintenance.

In the waterfall model, different life cycle phases typically require relatively
different amounts of efforts to be put in by the development team. The relative
amounts of effort spent on different phases for a typical software has been shown
in Figure 2.2. Observe from Figure 2.2 that among all the life cycle phases, the
maintenance phase normally requires the maximum effort. On the average,
about 60 per cent of the total effort put in by the development team in the
entire life cycle is spent on the maintenance activities alone.

1. Feasibility study

The main focus of the feasibility study stage is to determine whether it would be
financially and technically feasible to develop the software. The feasibility study
involves carrying out several activities such as collection of basic information
relating to the software such as the different data items that would be input to
the system, the processing required to be carried out on these data, the output
data required to be produced by the system, as well as various constraints

Prepared By: Er. Inderjeet Singh(e8822) Page 19

 Software Engineering

on the development. These collected data are analysed to perform at the

following:

1. Development of an overall understanding of the problem: It is

necessary to first develop an overall understanding of what the customer
requires to be developed. For this, only the the important requirements of
the customer need to be understood and the details of various requirements
such as the screen layouts required in the graphical user interface (GUI),
specific formulas or algorithms required for producing the required results,
and the databases schema to be used are ignored.
2. Formulation of the various possible strategies for solving the problem:
In this activity, various possible high-level solution schemes to the problem
are determined. For example, solution in a client-server framework and a
standalone application framework may be explored.
3. Evaluation of the different solution strategies: The different identified
solution schemes are analysed to evaluate their benefits and shortcomings.
Such evaluation often requires making approximate estimates of the
resources required, cost of development, and development time required.
The different solutions are compared based on the estimations that have
been worked out. Once the best solution is identified, all activities in the
later phases are carried out as per this solution. At this stage, it may also be
determined that none of the solutions is feasible due to high cost, resource
constraints, or some technical reasons. This scenario would, of course,
require the project to be abandoned.
Prepared By: Er. Inderjeet Singh(e8822) Page 20
 Software Engineering

2. Requirements analysis and specification

The aim of the requirements analysis and specification phase is to understand the
exact requirements of the customer and to document them properly. This phase
consists of two distinct activities, namely requirements gathering and analysis,
and requirements specification. In the following subsections, we give an overview
of these two activities:

 Requirements gathering and analysis: The goal of the requirements

gathering activity is to collect all relevant information regarding the software
to be developed from the customer with a view to clearly understand the
requirements. For this, first requirements are gathered from the customer and
then the gathered requirements are analysed. The goal of the requirements
analysis activity is to weed out the incompleteness and inconsistencies
in these gathered requirements. Note that an inconsistent requirement is one
in which some part of the requirement contradicts with some other part. On
the other hand, an incomplete requirement is one in which some parts of the
actual requirements have been omitted.
 Requirements specification: After the requirement gathering and analysis
activities are complete, the identified requirements are documented.
This is called a software requirements specification (SRS) document. The
SRS document is written using end-user terminology. This makes the
SRS document understandable to the customer. Therefore,
understandability of the SRS document is an important issue. The SRS
Prepared By: Er. Inderjeet Singh(e8822) Page 21
 Software Engineering

document normally serves as a contract between the development team and

the customer. Any future dispute between the customer and the developers can
be settled by examining the SRS document. The SRS document is therefore an
important document which must be thoroughly understood by the
development team, and reviewed jointly with the customer.

3. Design
The goal of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some
programming language. In technical terms, during the design phase the software
architecture is derived from the SRS document. Two distinctly different design
approaches are popularly being used at present—the procedural and object-
oriented design approaches.

Procedural design approach: The traditional design approach is in use in many

software development projects at the present time. This traditional design
technique is based on the data flow-oriented design approach. It consists of two
important activities; first structured analysis of the requirements specification is
carried out where the detailed structure of the problem is examined. This is
followed by a structured design step where the results of structured analysis are
transformed into the software design.

Prepared By: Er. Inderjeet Singh(e8822) Page 22

 Software Engineering

During structured analysis, the functional requirements specified in the SRS

document are decomposed into subfunctions and the data-flow among these
subfunctions is analysed and represented diagrammatically in the form of DFDs.

Structured design is undertaken once the structured analysis activity is complete.

Structured design consists of two main activities—architectural design (also called

high-level design) and detailed design (also called Low-level design ). High-level
design involves decomposing the system into modules, and representing the
interfaces and the invocation relationships among the modules. A high-level
software design is sometimes referred to as the software architecture. During the
detailed design activity, internals of the individual modules such as the data
structures and algorithms of the modules are designed and documented.

Object-oriented design approach: In this technique, various objects that occur in

the problem domain and the solution domain are first identified and the different
relationships that exist among these objects are identified. The object structure is
further refined to obtain the detailed design. The OOD approach is credited to
have several benefits such as lower development time and effort, and better
maintainability of the software.

4. Coding and unit testing

The purpose of the coding and unit testing phase is to translate a software design
into source code and to ensure that individually each function is working
correctly. The coding phase is also sometimes called the implementation phase,
Prepared By: Er. Inderjeet Singh(e8822) Page 23
 Software Engineering

since the design is implemented into a workable solution in this phase. Each
component of the design is implemented as a program module. The end-
product of this phase is a set of program modules that have been individually unit
tested. The main objective of unit testing is to determine the correct working of
the individual modules.

5. Integration and system testing

Integration of different modules is undertaken soon after they have been coded
and unit tested. During the integration and system testing phase, the different
modules are integrated in a planned manner. Various modules making up a
software are almost never integrated in one shot (can you guess the reason for
this?). Integration of various modules are normally carried out incrementally over
a number of steps. During each integration step, previously planned modules
are added to the partially integrated system and the resultant system is tested.
Finally, after all the modules have been successfully integrated and tested, the
full working system is obtained. System testing is carried out on this fully
working system.

Integration testing is carried out to verify that the interfaces among different
units are working satisfactorily. On the other hand, the goal of system testing is
to ensure that the developed system conforms to the requirements that have
been laid out in the SRS document.

System testing usually consists of three different kinds of testing activities:

Prepared By: Er. Inderjeet Singh(e8822) Page 24

 Software Engineering

-testing: testing is the system testing performed by the development team.

-testing: This is the system testing performed by a friendly set of customers.

Acceptance testing: After the software has been delivered, the customer
performs system testing to determine whether to accept the delivered software or
to reject it.

Maintenance

The total effort spent on maintenance of a typical software during its operation
phase is much more than that required for developing the software itself. Many
studies carried out in the past confirm this and indicate that the ratio of relative
effort of developing a typical software product and the total effort spent on its
maintenance is roughly 40:60. Maintenance is required in the following three
types of situations:

Corrective maintenance: This type of maintenance is carried out to correct errors

that were not discovered during the product development phase.

Perfective maintenance: This type of maintenance is carried out to improve the

performance of the system, or to enhance the functionalities of the system
based on customer’s requests.

Adaptive maintenance: Adaptive maintenance is usually required for porting the

software to work in a new environment. For example, porting may be required

Prepared By: Er. Inderjeet Singh(e8822) Page 25

 Software Engineering

to get the software to work on a new computer platform or with a new

operating system.

Advantages of Classical Waterfall Model:

• Simple and easy to understand and use

• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.

• Phases are processed and completed one at a time.

• Works well for smaller projects where requirements are very well
understood.

• Clearly defined stages.

• Well understood milestones.

• Easy to arrange tasks.

• Process and results are well documented.

Shortcomings of the classical waterfall model

 No feedback paths: In classical waterfall model, the evolution of a software

from one phase to the next is analogous to a waterfall. Just as water in a
waterfall after having flowed down cannot flow back, once a phase is
complete, the activities carried out in it and any artifacts produced in this

Prepared By: Er. Inderjeet Singh(e8822) Page 26

 Software Engineering

phase are considered to be final and are closed for any rework. This
requires that all activities during a phase are flawlessly carried out.
 Difficult to accommodate change requests: This model assumes that all
customer requirements can be completely and correctly defined at the
beginning of the project. There is much emphasis on creating an
unambiguous and complete set of requirements. But, it is hard to achieve
this even in ideal project scenarios. The customers’ requirements usually
keep on changing with time. But, in this model it becomes difficult to
accommodate any requirement change requests made by the customer
after the requirements specification phase is complete, and this often
becomes a source of customer discontent.
 No overlapping of phases: This model recommends that the phases be
carried out sequentially—new phase can start only after the previous one
completes. However, it is rarely possible to adhere to this recommendation
and it leads to a large number of team members to idle for extended periods.
For example, for efficient utilisation of manpower, the testing team might
need to design the system test cases immediately after requirements
specification is complete. The activities of the design and testing phases
overlap.
Iterative Waterfall Model:

The main change brought about by the iterative waterfall model to the
classical waterfall model is in the form of providing feedback paths from every

Prepared By: Er. Inderjeet Singh(e8822) Page 27

 Software Engineering

phase to its preceding phases. The feedback paths introduced by the iterative
waterfall model are shown in Figure 2.3. The feedback paths allow for correcting
errors committed by a programmer during some phase, as and when these are
detected in a later phase. For example, if during the testing phase a design error is
identified, then the feedback path allows the design to be reworked and the
changes to be reflected in the design documents and all other subsequent
documents.

There is no feedback path to the feasibility stage. This is because once a team
having accepted to take up a project, does not give up the project easily due to
legal and moral reasons.

Prepared By: Er. Inderjeet Singh(e8822) Page 28

 Software Engineering

Phase containment of errors : No matter how careful a programmer may be, he

might end up committing some mistake or other while carrying out a life cycle
activity. These mistakes result in errors (also called faults or bugs) in the
work product. It is advantageous to detect these errors in the same phase in
which they take place, since early detection of bugs reduces the effort and time
required for correcting those. For example, if a design problem is detected in the
design phase itself, then the problem can be taken care of much more easily than
if the error is identified, say, at the end of the testing phase. In the later case, it
would be necessary not only to rework the design, but also to appropriately redo
the relevant coding as well as the testing activities, thereby incurring higher cost. It
may not always be possible to detect all the errors in the same phase in which they
are made. Nevertheless, the errors should be detected as early as possible.

The principle of detecting errors as close to their points of commitment as

possible is known as phase containment of errors.

Phase overlap

Even though the strict waterfall model envisages sharp transitions to occur from
one phase to the next, in practice the activities of different phases overlap due to
two main reasons:

 In spite of the best effort to detect errors in the same phase in which they
are committed, some errors escape detection and are detected in a later
phase. These subsequently detected errors cause the activities of some

Prepared By: Er. Inderjeet Singh(e8822) Page 29

 Software Engineering

already completed phases to be reworked. If we consider such rework after a

phase is complete, we can say that the activities pertaining to a phase do
not end at the completion of the phase, but overlap with other phases as
shown in Fig 2.4.
 An important reason for phase overlap is that usually the work required to
be carried out in a phase is divided among the team members. Some
members may complete their part of the work earlier than other members.
If strict phase transitions are maintained, then the team members who
complete their work early would idle waiting for the phase to be complete,
and are said to be in a blocking state. Thus the developers who complete
early would idle while waiting for their team mates to complete their
assigned work. Clearly this is a cause for wastage of resources and a source
of cost escalation and inefficiency. As a result, in real projects, the phases
are allowed to overlap.

Prepared By: Er. Inderjeet Singh(e8822) Page 30

 Software Engineering

Shortcomings of the iterative waterfall model

The iterative waterfall model is a simple and intuitive software development

model. The projects are now shorter, and involve Customised software
development. Further, software was earlier developed from scratch. Now the
emphasis is on as much reuse of code and other project artifacts as possible.
Waterfall-based models have worked satisfactorily over last many years in the
past. The situation has changed substantially now.

In the present software development projects, use of waterfall model

causes several problems. In this context, the agile models have been proposed
about a decade back that attempt to overcome the important shortcomings of
the waterfall model by suggesting certain radical modification to the waterfall
style of software development.

Some of the glaring shortcomings of the waterfall model when used in the
present-day software development projects are as following:

1. Difficult to accommodate change requests: A major problem with the

waterfall model is that the requirements need to be frozen before the
development starts. Based on the frozen requirements, detailed plans are
made for the activities to be carried out during the design, coding, and
testing phases. Since activities are planned for the entire duration,
substantial effort and resources are invested in the activities as developing
the complete requirements specification, design for the complete

Prepared By: Er. Inderjeet Singh(e8822) Page 31

 Software Engineering

functionality and so on. Therefore, accommodating even small change

requests after the development activities are underway not only requires
overhauling the plan, but also the artifacts that have already been
developed.
Once requirements have been frozen, the waterfall model provides no
scope for any modifications to the requirements.
2. Incremental delivery not supported: In the iterative waterfall model, the full
software is completely developed and tested before it is delivered to the
customer. There is no provision for any intermediate deliveries to occur.
This is problematic because the complete application may take several
months or years to be completed and delivered to the customer. By the time
the software is delivered, installed, and becomes ready for use, the
customer’s business process might have changed substantially.
3. Phase overlap not supported: For most real life projects, it becomes
difficult to follow the rigid phase sequence prescribed by the waterfall
model. By the term a rigid phase sequence, we mean that a phase can start
only after the previous phase is complete in all respects.
4. Error correction unduly expensive: In waterfall model, validation is
delayed till the complete development of the software. As a result, the
defects that are noticed at the time of validation incur expensive rework and
result in cost escalation and delayed delivery.

Prepared By: Er. Inderjeet Singh(e8822) Page 32

 Software Engineering

5. Limited customer interactions: This model supports very limited customer

interactions. It is generally accepted that software developed in isolation
from the customer is the cause of many problems. In fact, interactions occur
only at the start of the project and at project completion. As a result, the
developed software usually turns out to be a misfit to the customer’s actual
requirements.
6. Heavy weight: The waterfall model overemphasises documentation. A
significant portion of the time of the developers is spent in preparing
documents, and revising them as changes occur over the life cycle. Heavy
documentation though useful during maintenance and for carrying out
review, is a source of team inefficiency.
7. No support for risk handling and code reuse: It becomes difficult to use the
waterfall model in projects that are susceptible to various types of risks, or
those involving significant reuse of existing development artifacts. Please
recollect that software services types of projects usually involve significant
reuse.

V-Model
A popular development process model, V-model is a variant of the waterfall
model. As is the case with the waterfall model, this model gets its name from its
visual appearance (see Figure 2.5). In this model verification and validation
activities are carried out throughout the development life cycle, and therefore

Prepared By: Er. Inderjeet Singh(e8822) Page 33

 Software Engineering

the chances bugs in the work products considerably reduce. This model is
therefore generally considered to be suitable for use in projects concerned with
development of safety-critical software that are required to have high reliability.

As shown in Figure 2.5, there are two main phases—development and validation
phases. The left half of the model comprises the development phases and the
right half comprises the validation phases.

 In each development phase, along with the development of a work product,

test case design and the plan for testing the work product are carried out,
whereas the actual testing is carried out in the validation phase. This
validation plan created during the development phases is carried out in the

Prepared By: Er. Inderjeet Singh(e8822) Page 34

 Software Engineering

corresponding validation phase which have been shown by dotted arcs in

Figure 2.5.
 In the validation phase, testing is carried out in three steps—unit,
integration, and system testing. The purpose of these three different steps of
testing during the validation phase is to detect defects that arise in the
corresponding phases of software development— requirements analysis
and specification, design, and coding respectively.

Advantages of V-model

The important advantages of the V-model over the iterative waterfall model are as
following:

 In the V-model, much of the testing activities (test case design, test
planning, etc.) are carried out in parallel with the development
activities. Therefore, before testing phase starts significant part of the testing
activities, including test case design and test planning, is already
complete. Therefore, this model usually leads to a shorter testing phase and an
overall faster product development as compared to the iterative model.
 Since test cases are designed when the schedule pressure has not built up, the
quality of the test cases are usually better.
 The test team is reasonably kept occupied throughout the development
cycle in contrast to the waterfall model where the testers are active only
during the testing phase. This leads to more efficient manpower utilisation.

Prepared By: Er. Inderjeet Singh(e8822) Page 35

 Software Engineering

 In the V-model, the test team is associated with the project from the
beginning. Therefore they build up a good understanding of the
development artifacts, and this in turn, helps them to carry out effective
testing of the software. In contrast, in the waterfall model often the test team
comes on board late in the development cycle, since no testing activities are
carried out before the start of the implementation and testing phase.

Disadvantages of V-model

 Being a derivative of the classical waterfall model, this model inherits most of
the weaknesses of the waterfall model.

Prototyping Model

The prototype model is also a popular life cycle model. The prototyping model can
be considered to be an extension of the waterfall model. This model suggests
building a working prototype of the system, before development of the actual
software. A prototype is a toy and crude implementation of a system. It has limited
functional capabilities, low reliability, or inefficient performance as compared to
the actual software. A prototype can be built very quickly by using several
shortcuts. The shortcuts usually involve developing inefficient, inaccurate, or
dummy functions.

Prepared By: Er. Inderjeet Singh(e8822) Page 36

 Software Engineering

Necessity of the prototyping model

The prototyping model is advantageous to use for specific types of projects. In the
following, we identify three types of projects for which the prototyping model can
be followed to advantage:

 It is advantageous to use the prototyping model for development of the

graphical user interface (GUI) part of an application. Through the use of a
prototype, it becomes easier to illustrate the input data formats,
messages, reports, and the interactive dialogs to the customer. This
is a valuable mechanism for gaining better understanding of the
customers’ needs.
 The prototyping model is especially useful when the exact technical
solutions are unclear to the development team. A prototype can help them
to critically examine the technical issues associated with product
development. For example, consider a situation where the development
team has to write a command language interpreter as part of a graphical user
interface development. Suppose none of the team members has ever written a
compiler before. Then, this lack of familiarity with a required development
technology is a technical risk. This risk can be resolved by developing a
prototype compiler for a very small language to understand the issues
associated with writing a compiler for a command language. Once they feel
confident in writing compiler for the small language, they can use this
knowledge to develop the compiler for the command language.

Prepared By: Er. Inderjeet Singh(e8822) Page 37

 Software Engineering

The prototyping model is considered to be useful for the development of not

only the GUI parts of a software, but also for a software project for which certain
technical issues are not clear to the development team.

Prepared By: Er. Inderjeet Singh(e8822) Page 38

 Software Engineering

Life cycle activities of prototyping model

The prototyping model of software development is graphically shown in Figure 2.6.

As shown in Figure 2.6, software is developed through two major activities—
prototype construction and iterative waterfall-based software development.

Prototype development: Prototype development starts with an initial

requirements gathering phase. A quick design is carried out and a prototype is
built. The developed prototype is submitted to the customer for evaluation. Based
on the customer feedback, the requirements are refined and the prototype is
suitably modified. This cycle of obtaining customer feedback and modifying the
prototype continues till the customer approves the prototype.

Iterative development: Once the customer approves the prototype, the actual
software is developed using the iterative waterfall approach. In spite of the
availability of a working prototype, the SRS document is usually needed to be
developed since the SRS document is invaluable for carrying out traceability
analysis, verification, and test case design during later phases. However, for GUI
parts, the requirements analysis and specification phase becomes redundant since
the working prototype that has been approved by the customer serves as an
animated requirements specification.

Prepared By: Er. Inderjeet Singh(e8822) Page 39

 Software Engineering

Strengths of the prototyping model

This model is the most appropriate for projects that suffer from technical and
requirements risks. A constructed prototype helps overcome these risks.

Weaknesses of the prototyping model

The prototype model can increase the cost of development for projects that are
routine development work and do not suffer from any significant risks. Even
when a project is susceptible to risks, the prototyping model is effective only
for those projects for which the risks can be identified upfront before the
development starts. Since the prototype is constructed only at the start of the
project, the prototyping model is ineffective for risks identified later during the
development cycle. The prototyping model would not be appropriate for projects
for which the risks can only be identified after the development is underway.

Incremental Development Model

This life cycle model is sometimes referred to as the successive versions model and
sometimes as the incremental model. In this life cycle model, first a simple
working system implementing only a few basic features is built and delivered to
the customer. Over many successive iterations successive versions are
implemented and delivered to the customer until the desired system is realised.

Prepared By: Er. Inderjeet Singh(e8822) Page 40

 Software Engineering

Life cycle activities of incremental development model

In the incremental life cycle model, the requirements of the software are first
broken down into several modules or features that can be incrementally
constructed and delivered. This has been pictorially depicted i n Figure 2.7. At
any time, plan is made only for the next increment and no long-term plans are
made. Therefore, it becomes easier to accommodate change requests from the
customers.

The development team first undertakes to develop the core features of the
system. The core or basic features are those that do not need to invoke any
services from the other features. On the other hand, non-core features need
services from the core features. Once the initial core features are developed, these
are refined into increasing levels of capability by adding new functionalities in
successive versions. Each incremental version is usually developed using an

Prepared By: Er. Inderjeet Singh(e8822) Page 41

 Software Engineering

iterative waterfall model of development. The incremental model is

schematically shown in Figure 2.8.

As each successive version of the software is constructed and delivered to the

customer, the customer feedback is obtained on the delivered version and these
feedbacks are incorporated in the next version. Each delivered version of the
software incorporates additional features over the previous version and also
refines the features that were already delivered to the customer.

Prepared By: Er. Inderjeet Singh(e8822) Page 42

 Software Engineering

Advantages

The incremental development model offers several advantages. Two important

ones are the following:

 Error reduction: The core modules are used by the customer from the
beginning and therefore these get tested thoroughly. This reduces chances of
errors in the core modules of the final product, leading to greater reliability of
the software.
 Incremental resource deployment: This model obviates the need for the
customer to commit large resources at one go for development of the system.
It also saves the developing organisation from deploying large resources and
manpower for a project in one go.

Evolutionary Model

This model has many of the features of the incremental model. As in case of the
incremental model, the software is developed over a number of increments.
At each increment, a concept (feature) is implemented and is deployed at
the client site. The software is successively refined and feature-enriched until
the full software is realised. The principal idea behind the evolutionary life cycle
model is conveyed by its name. In the incremental development model,
complete requirements are first developed and the SRS document prepared.
In contrast, in the evolutionary model, the requirements, plan, estimates, and

Prepared By: Er. Inderjeet Singh(e8822) Page 43

 Software Engineering

solution evolve over the iterations, rather than fully defined and frozen in a major
up-front specification effort before the development iterations begin. Such
evolution is consistent with the pattern of unpredictable feature discovery and
feature changes that take place in new product development.

The evolutionary software development process is sometimes referred to as

design a little, build a little, test a little, deploy a little model.

Prepared By: Er. Inderjeet Singh(e8822) Page 44

 Software Engineering

Advantages

The evolutionary model of development has several advantages. Two important

advantages of using this model are the following:

 Effective elicitation of actual customer requirements: In this model, the

user gets a chance to experiment with a partially developed software much
before the complete requirements are developed. Therefore, the
evolutionary model helps to accurately elicit user requirements with the
help of feedback obtained on the delivery of different versions of the software.
As a result, the change requests after delivery of the complete software gets
substantially reduced.
 Easy handling change requests: In this model, handling change requests is
easier as no long term plans are made. Consequently, reworks required due to
change requests are normally much smaller compared to the sequential
models.
Disadvantages:

 Feature division into incremental parts can be non-trivial: For many

development projects, especially for small-sized projects, it is difficult to
divide the required features into several parts that can be incrementally
implemented and delivered. Further, even for larger problems, often the
features are so interwined and dependent on each other that even an expert
would need considerable effort to plan the incremental deliveries.

Prepared By: Er. Inderjeet Singh(e8822) Page 45

 Software Engineering

 Ad hoc design: Since at a time design for only the current increment is done,
the design can become ad hoc without specific attention being paid to
maintainability and optimality. Obviously, for moderate sized problems and
for those for which the customer requirements are clear, the iterative waterfall
model can yield a better solution.

SPIRAL MODEL

This model gets its name from the appearance of its diagrammatic representation
that looks like a spiral with many loops (see Figure 2.10). The exact number of
loops of the spiral is not fixed and can vary from project to project. The number of
loops shown in Figure 2.10 is just an example. Each loop of the spiral is called a
phase of the software process. The exact number of phases through which the
product is developed can be varied by the project manager depending upon the
project risks. A prominent feature of the spiral model is handling unforeseen
risks that can show up much after the project has started.

This model achieves this by incorporating much more flexibility compared to SDLC
other models.

Prepared By: Er. Inderjeet Singh(e8822) Page 46

 Software Engineering

While the prototyping model does provide explicit support for risk handling, the
risks are assumed to have been identified completely before the project start. This
is required since the prototype is constructed only at the start of the project. In
contrast, in the spiral model prototypes are built at the start of every phase. Each
phase of the model is represented as a loop in its diagrammatic
representation. Over each loop, one or more features of the product are
elaborated and analysed and the risks at that point of time are identified and are
resolved through prototyping. Based on this, the identified features are
implemented.

Prepared By: Er. Inderjeet Singh(e8822) Page 47

 Software Engineering

Risk handling in spiral model

A risk is essentially any adverse circumstance that might hamper the successful
completion of a software project. As an example, consider a project for which a
risk can be that data access from a remote database might be too slow to be
acceptable by the customer. This risk can be resolved by building a prototype of
the data access subsystem and experimenting with the exact access rate. If the
data access rate is too slow, possibly a caching scheme can be implemented or
a faster communication scheme can be deployed to overcome the slow data
access rate. Such risk resolutions are easier done by using a prototype as the pros
and cons of an alternate solution scheme can evaluated faster and inexpensively,
as compared to experimenting using the actual software application being
developed. The spiral model supports coping up with risks by providing the scope
to build a prototype at every phase of software development.

Phases of the Spiral Model : Each phase in this model is split into four sectors (or
quadrants) as shown in Figure 2.10. In the first quadrant, a few features of the
software are identified to be taken up for immediate development based on how
crucial it is to the overall software development.

With each iteration around the spiral (beginning at the center and moving
outwards), progressively more complete versions of the software get built. In
other words, implementation of the identified features forms a phase.

Prepared By: Er. Inderjeet Singh(e8822) Page 48

 Software Engineering

Quadrant 1: The objectives are investigated, elaborated, and analysed. Based

on this, the risks involved in meeting the phase objectives are identified. In
this quadrant, alternative solutions possible for the phase under consideration are
proposed.

Quadrant 2: During the second quadrant, the alternative solutions are

evaluated to select the best possible solution. To be able to do this, the solutions
are evaluated by developing an appropriate prototype.

Quadrant 3: Activities during the third quadrant consist of developing and

verifying the next level of the software. At the end of the third quadrant, the
identified features have been implemented and the next version of the
software is available.

Quadrant 4: Activities during the fourth quadrant concern reviewing the results
of the stages traversed so far (i.e. the developed version of the software) with the
customer and planning the next iteration of the spiral.

The radius of the spiral at any point represents the cost incurred in the project so
far, and the angular dimension represents the progress made so far in the current
phase.

Advantages/pros and disadvantages/cons of the spiral model

There are a few disadvantages of the spiral model that restrict its use to a only a
few types of projects. To the developers of a project, the spiral model usually

Prepared By: Er. Inderjeet Singh(e8822) Page 49

 Software Engineering

appears as a complex model to follow, since it is risk-driven and is more

complicated phase structure than the other models we discussed. It would
therefore be counterproductive to use, unless there are knowledgeable and
experienced staff in the project. Also, it is not very suitable for use in the
development of outsourced projects, since the software risks need to be
continually assessed as it is developed.

Other Advantages:

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

Other Disadvantages:

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

Prepared By: Er. Inderjeet Singh(e8822) Page 50

 Software Engineering

 Large number of intermediate stages requires excessive documentation.

Applications:

 Managing clients requirements in industry.

 Generating software for noticing health activities with novel smart
technologies.
 Content Management and to analyzing Fraud detection and Prevention
 Advertisements Targeting Platforms Managing content, posts, images and
videos on social media platforms
 Analyzing customer data in real-time for improving business performance
 Public sector fields such as intelligence, defense, cyber security and scientific
research

Summary: For projects having many unknown risks that might show up as the
development proceeds, the spiral model would be the most appropriate
development model to follow.

Prepared By: Er. Inderjeet Singh(e8822) Page 51

 Software Engineering

AGILE DEVELOPMENT MODELS

Capers Jones carried out research involving 800 real-life software development
projects, and concluded that on the average 40 per cent of the requirements is
arrived after the development has already begun. In this context, over the last two
decade or so, several life cycle models have been proposed to overcome the
important shortcomings of the waterfall-based models that become conspicuous
when used in modern software development projects.

Over the last two decades or so, projects using iterative waterfall-based life cycle
models are becoming rare due to the rapid shift in the characteristics of the
software development projects over time. Two changes that are becoming
noticeable are rapid shift from development of software products to development
of customised software and the increased emphasis and scope for reuse.

In the following, a few reasons why the waterfall-based development was

becoming difficult to use in project in recent times:

 In the traditional iterative waterfall-based software development models,

the requirements for the system are determined at the start of a development
project and are assumed to be fixed from that point on. Later changes to the
requirements after the SRS document has been completed are discouraged. If
at all any later requirement changes becomes unavoidable, then the cost of
accommodating it becomes prohibitively high.

Prepared By: Er. Inderjeet Singh(e8822) Page 52

 Software Engineering

 Customised applications (services) has become common place and the sales
revenue generated world wide from services already exceeds that of the
software products. Clearly, iterative waterfall model is not suitable for
development of such software. Since customization essentially involves
reusing most of the parts of an existing application and consists of only
carrying out minor modifications by writing minimal amounts of code. For
such development projects, the need for more appropriate development
models was deeply felt, and many researchers started to investigate in this
direction.
 Waterfall model is called a heavy weight model, since there is too much
emphasis on producing documentation and usage of tools.

The agile software development model was proposed in the mid-1990s to

overcome the serious shortcomings of the waterfall model of development
identified above. The agile model was primarily designed to help a project to adapt
to change requests quickly. Thus, a major aim of the agile models is to facilitate
quick project completion.

But, how is agility achieved in these models? Agility is achieved by fitting the
process to the project, i.e. removing activities that may not be necessary for a
specific project. Also, anything that that wastes time and effort is avoided.

In the agile model, the requirements are decomposed into many small parts that
can be incrementally developed. The agile model adopts an iterative approach.

Prepared By: Er. Inderjeet Singh(e8822) Page 53

 Software Engineering

Each incremental part is developed over an iteration. Each iteration is intended to

be small and easily manageable and lasting for a couple of weeks only. At a time,
only one increment is planned, developed, and then deployed at the customer
site. No long-term plans are made. The time to complete an iteration is called a
time box. The implication of the term time box is that the end date for an iteration
does not change. That is, the delivery date is considered sacrosanct. The
development team can, however, decide to reduce the delivered functionality
during a time box if necessary.

Essential Idea behind Agile Models

For establishing close contact with the customer during development and to gain a
clear understanding of the domain-specific issues, each agile project usually
includes a customer representative in the team. At the end of each iteration,
stakeholders and the customer representative review the progress made and
re-evaluate the requirements. A distinguishing characteristics of the agile models
is frequent delivery of software increments to the customer.

Agile model emphasise face-to-face communication over written documents. It

is recommended that the development team size be deliberately kept small
(5–9 people) to help the team members meaningfully engage in face-to-face
communication and have collaborative work environment. It is implicit then
that the agile model is suited to the development of small projects. However, if
a large project is required to be developed using the agile model, it is likely that

Prepared By: Er. Inderjeet Singh(e8822) Page 54

 Software Engineering

the collaborating teams might work at different locations. In this case, the
different teams are needed to maintain as much daily contact as possible through
video conferencing, telephone email etc.

The following important principles behind the agile model were publicised in the
agile manifesto in 2001:

 Working software over comprehensive documentation.

 Frequent delivery of incremental versions of the software to the
customer in intervals of few weeks. Requirement change requests from the
customer are encouraged and are efficiently incorporated.
 Having competent team members and enhancing interactions among them is
considered much more important than issues such as usage of sophisticated
tools or strict adherence to a documented process. It is advocated that
enhanced communication among the development team members can be
realised through face-to-face communication rather than through exchange of
formal documents.
 Continuous interaction with the customer is considered much more important
rather than effective contract negotiation. A customer representatives is
required to be a part of the development team, thus facilitating close, daily
co-operation between customers and developers.
Or

Prepared By: Er. Inderjeet Singh(e8822) Page 55

 Software Engineering

Core Values of Agile Software Development

 Individuals and Interactions over Processes and Tools

 Working Software over Comprehensive Documentation
 Customer Collaboration over Contract Negotiation
 Responding to Change over Following a Plan

Agile Software Development Life Cycle

Prepared By: Er. Inderjeet Singh(e8822) Page 56

 Software Engineering

 Step 1: In the first step, concept, and business opportunities in each possible
project are identified and the amount of time and work needed to complete the
project is estimated. Based on their technical and financial viability, projects
can then be prioritized and determined which ones are worthwhile pursuing.

 Step 2: In the second phase, known as inception, the customer is consulted

regarding the initial requirements, team members are selected, and funding is
secured. Additionally, a schedule outlining each team’s responsibilities and
the precise time at which each sprint’s work is expected to be finished should
be developed.

 Step 3: Teams begin building functional software in the third step,

iteration/construction, based on requirements and ongoing feedback.
Iterations, also known as single development cycles, are the foundation of the
Agile software development cycle.

Prepared By: Er. Inderjeet Singh(e8822) Page 57

 Software Engineering

Advantages Agile Software Development

 Deployment of software is quicker and thus helps in increasing the trust of

the customer.

 Can better adapt to rapidly changing requirements and respond faster.

 Helps in getting immediate feedback which can be used to improve the

software in the next increment.

 People – Not Process. People and interactions are given a higher priority than
processes and tools.

 Continuous attention to technical excellence and good design.

Prepared By: Er. Inderjeet Singh(e8822) Page 58

 Software Engineering

 Increased collaboration and communication: Agile Software Development

Methodology emphasize collaboration and communication among team
members, stakeholders, and customers. This leads to improved
understanding, better alignment, and increased buy-in from everyone
involved.

 Flexibility and adaptability: Agile methodologies are designed to be flexible

and adaptable, making it easier to respond to changes in requirements,
priorities, or market conditions. This allows teams to quickly adjust their
approach and stay focused on delivering value.

 Improved quality and reliability: Agile methodologies place a strong

emphasis on testing, quality assurance, and continuous improvement. This
helps to ensure that software is delivered with high quality and reliability,
reducing the risk of defects or issues that can impact the user experience.

 Enhanced customer satisfaction: Agile methodologies prioritize customer

satisfaction and focus on delivering value to the customer. By involving
customers throughout the development process, teams can ensure that the
software meets their needs and expectations.

 Increased team morale and motivation: Agile methodologies promote a

collaborative, supportive, and positive work environment. This can lead to
increased team morale, motivation, and engagement, which can in turn lead
to better productivity, higher quality work, and improved outcomes.
Prepared By: Er. Inderjeet Singh(e8822) Page 59
 Software Engineering

Disadvantages Agile Software Development

 In the case of large software projects, it is difficult to assess the effort

required at the initial stages of the software development life cycle.

 Agile Development is more code-focused and produces less documentation.

 Agile development is heavily dependent on the inputs of the customer. If the

customer has ambiguity in his vision of the outcome, it is highly likely that
the project to get off track.

 Face-to-face communication is harder in large-scale organizations.

 Only senior programmers are capable of making the kind of decisions

required during the development process. Hence, it’s a difficult situation for
new programmers to adapt to the environment.

 Lack of predictability: Agile Development relies heavily on customer

feedback and continuous iteration, which can make it difficult to predict
project outcomes, timelines, and budgets.

 Limited scope control: Agile Development is designed to be flexible and

adaptable, which means that scope changes can be easily accommodated.
However, this can also lead to scope creep and a lack of control over the
project scope.

Prepared By: Er. Inderjeet Singh(e8822) Page 60

 Software Engineering

 Lack of emphasis on testing: Agile Development places a greater emphasis

on delivering working code quickly, which can lead to a lack of focus on
testing and quality assurance. This can result in bugs and other issues that
may go undetected until later stages of the project.

 Risk of team burnout: Agile Development can be intense and fast-paced,

with frequent sprints and deadlines. This can put a lot of pressure on team
members and lead to burnout, especially if the team is not given adequate
time for rest and recovery.

 Lack of structure and governance: Agile Development is often less formal

and structured than other development methodologies, which can lead to a
lack of governance and oversight. This can result in inconsistent processes
and practices, which can impact project quality and outcomes.

Agile is a framework that defines how software development needs to be carried on.
Agile is not a single method, it represents the various collection of methods and
practices that follow the value statements provided in the manifesto. Agile methods
and practices do not promise to solve every problem present in the software
industry (No Software model ever can). But they sure help to establish a culture and
environment where solutions emerge.

Agile software development is an iterative and incremental approach to software

development. It emphasizes collaboration between the development team and the

Prepared By: Er. Inderjeet Singh(e8822) Page 61

 Software Engineering

customer, flexibility, and adaptability in the face of changing requirements, and the
delivery of working software in short iterations.

The Agile Manifesto, which outlines the principles of agile development, values
individuals and interactions, working software, customer collaboration, and
response to change.

Advantages of Agile Software Development over traditional software

development approaches

1. Increased customer satisfaction: Agile development involves close

collaboration with the customer, which helps to ensure that the software meets
their needs and expectations.

2. Faster time-to-market: Agile development emphasizes the delivery of

working software in short iterations, which helps to get the software to market
faster.

3. Reduced risk: Agile development involves frequent testing and feedback,

which helps to identify and resolve issues early in the development process.

4. Improved team collaboration: Agile development emphasizes collaboration

and communication between team members, which helps to improve
productivity and morale.

5. Adaptability to change: Agile Development is designed to be flexible and

adaptable, which means that changes to the project scope, requirements, and
timeline can be accommodated easily. This can help the team to respond
quickly to changing business needs and market demands.

Prepared By: Er. Inderjeet Singh(e8822) Page 62

 Software Engineering

6. Better quality software: Agile Development emphasizes continuous testing

and feedback, which helps to identify and resolve issues early in the
development process. This can lead to higher-quality software that is more
reliable and less prone to errors.

7. Increased transparency: Agile Development involves frequent

communication and collaboration between the team and the customer, which
helps to improve transparency and visibility into the project status and
progress. This can help to build trust and confidence with the customer and
other stakeholders.

8. Higher productivity: Agile Development emphasizes teamwork and

collaboration, which helps to improve productivity and reduce waste. This can
lead to faster delivery of working software with fewer defects and rework.

9. Improved project control: Agile Development emphasizes continuous

monitoring and measurement of project metrics, which helps to improve
project control and decision-making. This can help the team to stay on track
and make data-driven decisions throughout the development process.

Prepared By: Er. Inderjeet Singh(e8822) Page 63