SCOPE AND NECESSITY OF SOFTWARE ENGINEERING

Software engineering is an engineering approach for software development. We can alternatively view
it as a systematic collection of past experience. The experience is arranged in the form of methodologies
and guidelines. A small program can be written without using software engineering principles. But if one
wants to develop a large software product, then software engineering principles are indispensable to
achieve a good quality software cost effectively.

Without using software engineering principles it would be difficult to develop large programs. In industry
it is usually needed to develop large programs to accommodate multiple functions. A problem with
developing such large commercial programs is that the complexity and difficulty levels of the programs
increase exponentially with their sizes as shown in the below figure.

Fig: Increase in development time and effort with problem size

For example, a program of size 1,000 lines of code has some complexity. But a program with 10,000
LOC is not just 10 times more difficult to develop, but May as well turn out to be 100 times more difficult
unless software engineering principles are used. In such situations software engineering techniques
come to rescue. Software engineering helps to reduce the programming complexity.

Page 1 of 27
Handling complexity through Abstraction and Decomposition:

Software engineering principles use two important techniques to reduce problem complexity:
Abstraction and Decomposition

The principle of abstraction (in fig.1.4) implies that a problem can be simplified by omitting
irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of
the problem that are relevant for certain purpose and suppress other aspects that are not relevant for
the given purpose. Once the simpler problem is solved, then the omitted details can be taken into
consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of
reducing the complexity of the problem.

The other approach to tackle problem complexity is decomposition. In this technique, a complex
problem is divided into several smaller problems and then the smaller problems are solved one by one.
However, in this technique any random decomposition of a problem into smaller parts will not help. The
problem has to be decomposed such that each component of the decomposed problem can be solved
independently and then the solution of the different components can be combined to get the full solution.
A good decomposition of a problem as shown in fig.1.5 should minimize interactions among various
components. If the different subcomponents are interrelated, then the different components cannot be
solved separately and the desired reduction in complexity will not be realized.

Page 2 of 27
Causes of and solutions for software crisis:

Software engineering appears to be among the few options available to tackle the present software
crisis. To explain the present software crisis in simple words, consider the following. The expenses that
organizations all around the world are incurring on software purchases compared to those on hardware
purchases have been showing a worrying trend over the years (as shown in fig. 1.6)

Organizations are spending larger and larger portions of their budget on software. Not only are
the software products turning out to be more expensive than hardware, but they also present a host of
other problems to the customers:

Software products are difficult to alter, debug, and enhance

Use resources non – optimally
Often fail to meet the user requirements
Are far from being reliable
Frequently crash
Often delivered late
Among these, the trend of increasing software costs is probably the most important symptom
of the present software crisis.
There are many factors that have contributed to the making of the present software crisis:

larger problem sizes

lack of adequate training in software engineering
increasing skill shortage
Low productivity improvements.

It is believed that the only satisfactory solution to the present software crisis can possibly come from a
spread of software engineering practices among the engineers, coupled with further advancements to
the software engineering discipline itself.

Page 3 of 27
Program vs. software product
Programs are developed by individuals for their personal use. They are therefore, small in size
and have limited functionality but software products are extremely large.

In case of a program, the programmer himself is the sole user but on the other hand, in case of
a software product, most users are not involved with the development.

In case of a program, a single developer is involved but in case of a software product, a large
number of developers are involved.

For a program, the user interface may not be very important, because the programmer is the
sole user. On the other hand, for a software product, user interface must be carefully designed
and implemented because developers of that product and users of that product are totally
different.

In case of a program, very little documentation is expected, but a software product must be well
documented.

A program can be developed according to the programmer’s individual style of development,

but a software product must be developed using the accepted software engineering principles.

Page 4 of 27
 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

A software development life cycle model (also called process model) is a descriptive and
diagrammatic representation of the software life cycle. A life cycle model represents all the activities
required to make a software product transit through its life cycle phases. It also captures the order in
which these activities are to be undertaken. In other words, a life cycle model maps the different
activities performed on a software product from its inception to retirement.

The Need for A Software Life Cycle Model: The development team must identify a suitable life cycle
model for the particular project and then adhere to it. Without using of a particular life cycle model the
development of a software product would not be in a systematic and disciplined manner. When a
software product is being developed by a team there must be a clear understanding among team
members about when and what to do. Otherwise it would lead to chaos and project failure.

Phase Entry and Exit Criteria: A software life cycle model defines entry and exit criteria for every
phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life
cycle models the entry and exit criteria for a phase cannot be recognized. Without software life cycle
models (such as classical waterfall model, iterative waterfall model, prototyping model, evolutionary
model, spiral model etc.) it becomes difficult for software project managers to monitor the progress of
the project.

Different Process Models:

Many life cycle models have been proposed so far. Each of them has some advantages as well as
some disadvantages. A few important and commonly used life cycle models are as follows:

Classical Waterfall Model

Iterative Waterfall Model
Prototyping Model
Evolutionary Model
Spiral Model
RAD Model
Agile Models

Page 5 of 27
CLASSICAL WATERFALL MODEL:

The classical waterfall model is intuitively the most obvious way to develop software. Though the
classical waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it
cannot be used in actual software development projects. Thus, this model can be considered to
be a theoretical way of developing software. But all other life cycle models are essentially derived from
the classical waterfall model.

Classical waterfall model divides the life cycle into the following phases as shown in the below figure:

• Feasibility Study
• Requirements Analysis and Specification
• Design
• Coding and Unit Testing
• Integration and System Testing
• Maintenance

Page 6 of 27
ACTIVITIES UNDERTAKEN DURING FEASIBILITY STUDY: -

The main aim of feasibility study is to determine whether it would be financially and technically
feasible to develop the product.
At first project managers or team leaders try to have a rough understanding of what is
required to be done by visiting the client side. They study different input data to the system
and output data to be produced by the system. They study what kind of processing is needed
to be done on these data and they look at the various constraints on the behavior of the
system.

After they have an overall understanding of the problem they investigate the different
solutions that are possible. Then they examine each of the solutions in terms of what
kind of resources required, what would be the cost of development and what would be
the development time for each solution.

Based on this analysis they pick the best solution and determine whether the solution
is feasible financially and technically.

ACTIVITIES UNDERTAKEN DURING 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 & analysis
• Requirements specification

• Requirements gathering and analysis: The goal of the requirements gathering activity is to
collect all relevant information from the customer regarding the product to be developed. This
is done to clearly understand the customer requirements so that incompleteness and
inconsistencies are removed.
The requirements analysis activity is begun by collecting all relevant data
regarding the product to be developed from the users of the product and from the customer
through interviews and discussions. The data collected from such a group of users usually
contain several contradictions and ambiguities, since each user typically has only a
partial and incomplete view of the system. Therefore it is necessary to identify all
ambiguities and contradictions in the requirements and resolve them through further
discussions with the customer.

• Requirements Specification: After all ambiguities, inconsistencies, and incompleteness

have been resolved and all the requirements properly understood, the requirements
specification activity can start. During this activity, the user requirements are systematically
organized into a Software Requirements Specification (SRS) document. The important
components of SRS are functional requirements, the nonfunctional requirements, and
the goals of implementation.

Page 7 of 27
ACTIVITIES UNDERTAKEN DURING 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 approaches are available: the traditional design approach and the object-oriented
design approach.
Traditional design approach

Traditional design consists of two different activities; first a 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 activity. During structured design, the results of structured analysis are
transformed into the software design.
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.

ACTIVITIES UNDERTAKEN DURING CODING AND UNIT TESTING:-

The purpose of the coding and unit testing phase (sometimes called the implementation phase)
of software development is to translate the software design into source code. 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 tested.

During this phase, each module is unit tested to determine the correct working of all the
individual modules. It involves testing each module in isolation as this is the most efficient way
to debug the errors identified at this stage.

ACTIVITIES UNDERTAKEN DURING INTEGRATION AND SYSTEM TESTING: -

Integration of different modules is undertaken once they have been coded and unit tested. During the
integration and system testing phase, the modules are integrated in a planned manner. The
different modules making up a software product are almost never integrated in one shot.
Integration is normally carried out incrementally over a number of steps. During each integration
step, the partially integrated system is tested and a set of previously planned modules are added to it.
Finally, when all the modules have been successfully integrated and tested, system testing is
carried out.
The goal of system testing is to ensure that the developed system conforms to its requirements
laid out in the SRS document. System testing usually consists of three different kinds of testing
activities:
α – testing: It is the system testing performed by the development team.
β – testing: It is the system testing performed by a friendly set of customers.

Page 8 of 27
 Acceptance testing: It is the system testing performed by the customer himself after the
product delivery to determine whether to accept or reject the delivered product
.
ACTIVITIES UNDERTAKEN DURING MAINTENANCE: -

Maintenance of a typical software product requires much more than the effort necessary to develop the
product itself. Many studies carried out in the past confirm this and indicate that the relative effort of
development of a typical software product to its maintenance effort is roughly in the 40:60 ratio.

Maintenance involves performing any one or more of the following three kinds of activities:
Correcting errors that were not discovered during the product development phase. This is called
corrective maintenance.
Improving the implementation of the system and enhancing the functionalities of the system
according to the customer’s requirements. This is called perfective maintenance.
Porting the software to work in a new environment. For example, porting may be required to
get the software to work on a new computer platform or with a new operating system. This is
called adaptive maintenance.

Shortcomings of the classical waterfall model:

The classical waterfall model is an idealistic one since it assumes that no development
error is ever committed by the engineers during any of the life cycle phases. However,
in practical development environments, the engineers do commit a large number of errors
in almost every phase of the life cycle.
The source of the defects can be many: oversight, wrong assumptions, use of
inappropriate technology, communication gap among the project engineers, etc.
These defects usually get detected much later in the life cycle. For example, a design
defect might go unnoticed till we reach the coding or testing phase.
Once a defect is detected, the engineers need to go back to the phase where the defect had
occurred and redo some of the work done during that phase and the subsequent phases to
correct the defect and its effect on the later phases.
Therefore, in any practical software development work, it is not possible to strictly follow
the classical waterfall model.

Page 9 of 27
ITERATIVE WATERFALL MODEL:

In the Iterative model, iterative process starts with a simple implementation of a small set of the software
requirements and iteratively enhances the evolving versions until the complete system is implemented
and ready to be deployed.

An iterative life cycle model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software, which is then reviewed
to identify further requirements. This process is then repeated, producing a new version of the software
at the end of each iteration of the model.

Iterative Model - Design

Iterative process starts with a simple implementation of a subset of the software requirements and
iteratively enhances the evolving versions until the full system is implemented. At each iteration, design
modifications are made and new functional capabilities are added. The basic idea behind this method
is to develop a system through repeated cycles (iterative).

Iterative and Incremental development is a combination of both iterative design or iterative method and
incremental build model for development. "During software development, more than one iteration of the
software development cycle may be in progress at the same time." This process may be described as
an "evolutionary acquisition" or "incremental build" approach."

During each iteration, the development module goes through the requirements, design, implementation
and testing phases. Each subsequent release of the module adds function to the previous release. The
process continues till the complete system is ready as per the requirement.

The key to a successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those requirements
within each cycle of the model. As the software evolves through successive cycles, tests must be
repeated and extended to verify each version of the software.

Page 10 of 27
Iterative Model - Application

Like other SDLC models, Iterative and incremental development has some specific applications in the
software industry. This model is most often used in the following scenarios –

• Requirements of the complete system are clearly defined and understood.

• Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team while working on
the project.
• Resources with needed skill sets are not available and are planned to be used on contract basis
for specific iterations.
• There are some high-risk features and goals which may change in the future.

The advantages of the Iterative SDLC Model are as follows −

• Some working functionality can be developed quickly and early in the life cycle.
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
• Less costly to change the scope/requirements.
• Testing and debugging during smaller iteration is easy.
• Risks are identified and resolved during iteration; and each iteration is an easily managed
milestone.
• Easier to manage risk - High risk part is done first.
• With every increment, operational product is delivered.
• Issues, challenges and risks identified from each increment can be utilized/applied to the next
increment.
• Risk analysis is better.
• It supports changing requirements.
• Initial Operating time is less.
• Better suited for large and mission-critical projects.
• During the life cycle, software is produced early which facilitates customer evaluation and
feedback.

Page 11 of 27
The disadvantages of the Iterative SDLC Model are as follows −

• More resources may be required.

• Although cost of change is lesser, but it is not very suitable for changing requirements.
• More management attention is required.
• System architecture or design issues may arise because not all requirements are gathered in
the beginning of the entire life cycle.
• Defining increments may require definition of the complete system.
• Not suitable for smaller projects.
• Management complexity is more.
• End of project may not be known which a risk is.
• Highly skilled resources are required for risk analysis.
• Projects progress is highly dependent upon the risk analysis phase.

PROTOTYPING MODEL

Prototype: A prototype is a toy implementation of the system. A prototype usually exhibits limited
functional capabilities, low reliability, and inefficient performance compared to the actual software.
A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient,
inaccurate, or dummy functions. The shortcut implementation of a function, for example, may
produce the desired results by using a table look-up instead of performing the actual
computations. A prototype usually turns out to be a very crude version of the actual system.

Need for a prototype in software development:

There are several uses of a prototype. An important purpose is to illustrate the input data formats,
messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism
for gaining better understanding of the customer’s needs:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs

This is something similar to what the architectural designers of a building do; they show a prototype of
the building to their customer. The customer can evaluate whether he likes it or not and the
changes that he would need in the actual product. A similar thing happens in the case of a
software product and its prototyping model.

Another reason for developing a prototype is that it is impossible to get the perfect product in
the first attempt. Many researchers and engineers advocate that if you want to develop a good product
you must plan to throw away the first version. The experience gained in developing the prototype
can be used to develop the final product.

Page 12 of 27
A prototyping model can be used when technical solutions are unclear to the development team.
A developed prototype can help engineers to critically examine the technical issues associated
with the product development. Often, major design decisions depend on issues like the response
time of a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances,
a prototype may be the best or the only way to resolve the technical issues.

Examples for prototype model:

A prototype of the actual product is preferred in situations such as:
• User requirements are not complete
• Technical issues are not clear

Let’s see an example for each of the above category.

Example 1: User requirements are not complete

In any application software like billing in a retail shop, accounting in a firm, etc. the users of the software
are not clear about the different functionalities required. Once they are provided with the prototype
implementation, they can try to use it and find out the missing functionalities.

Page 13 of 27
Example 2: Technical issues are not clear
Suppose a project involves writing a compiler and the development team has never written a compiler.
In such a case, the team can consider a simple language, try to build a compiler in order to check the
issues that arise in the process and resolve them. After successfully building a small compiler
(prototype), they would extend it to one that supports a complete language.

Advantages of Prototype model:

• Users are actively involved in the development
• Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified: Requirements validation, Quick
implementation of incomplete but functional application.
Disadvantages of Prototype model:
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.
• Incomplete application may cause application not to be used as the full system was designed
Incomplete or inadequate problem analysis.

THE EVOLUTIONARY MODEL

This approach is based on the idea of rapidly developing an initial software implementation from very
abstract specifications and modifying this according to your appraisal. Each program version inherits
the best features from earlier versions. Each version is refined based upon feedback from yourself to
produce a system which satisfies your needs. At this point the system may be delivered or it may be re-
implemented using a more structured approach to enhance robustness and maintainability.
Specification, development and validation activities are concurrent with strong feedback between each.

Page 14 of 27
There are two types of evolutionary development:

1. Exploratory programming: Here the objective of the process is to work with you to explore
their requirements and deliver a final system. The development starts with the better
understood components of the system. The software evolves by adding new features as they
are proposed.

2. Throwaway prototyping: here the purpose of the evolutionary development process is to

understand your requirements and thus develop a better requirements definition for the system.
The prototype concentrates on experimenting with those components of the requirements
which are poorly understood.

Advantages:

This is the only method appropriate for situations where a detailed system specification is unavailable.
Effective in rapidly producing small systems, software with short life spans, and developing sub-
components of larger systems.

Disadvantages

It is difficult to measure progress and produce documentation reflecting every version of the system as
it evolves. This paradigm usually results in badly structured programs due to continual code
modification. Production of good quality software using this method requires highly skilled and motivated
programmers.

SPIRAL MODEL
The Spiral model of software development is shown in the below figure. The diagrammatic
representation of this model appears like a spiral with many loops. The exact number of loops in
the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For
example, the innermost loop might be concerned with feasibility study. The next loop with
requirements specification, the next one with design, and so on. Each phase in this model is split
into four sectors (or quadrants) as shown in the below figure. The following activities are carried out
during each phase of a spiral model.

Page 15 of 27
 A. First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.

B. Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements
are inappropriate, a prototype system may be developed.

C. Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified risks.

D. Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration around the
spiral.
• Progressively more complete version of the software gets built with each iteration around
the spiral.

The spiral model is called a Meta model since it encompasses all other life cycle models. Risk handling
is inherently built into this model. The radius from the center of the loop shows the cost and the angular
displacement of the loops shows progress of the software development. The spiral model is suitable
for development of technically challenging software products that are prone to several kinds of
risks. However, this model is much more complex than the other models – this is probably a factor
deterring its use in ordinary projects.

Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.

• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

Disadvantages of Spiral model:

• Can be a costly model to use.

• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

Page 16 of 27
RAD MODEL
The RAD (Rapid Application Development) model is based on prototyping and iterative development
with no specific planning involved. The process of writing the software itself involves the planning
required for developing the product.

Rapid Application Development focuses on gathering customer requirements through workshops or

focus groups, early testing of the prototypes by the customer using iterative concept, reuse of the
existing prototypes (components), continuous integration and rapid delivery.

What is RAD?

Rapid application development is a software development methodology that uses minimal planning in
favour of rapid prototyping. A prototype is a working model that is functionally equivalent to a component
of the product.

In the RAD model, the functional modules are developed in parallel as prototypes and are integrated to
make the complete product for faster product delivery. Since there is no detailed preplanning, it makes
it easier to incorporate the changes within the development process.

RAD projects follow iterative and incremental model and have small teams comprising of developers,
domain experts, customer representatives and other IT resources working progressively on their
component or prototype.

The most important aspect for this model to be successful is to make sure that the prototypes developed
are reusable.

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 Modeling: 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 Modeling: The information gathered in the Business Modeling phase is reviewed and
analysed 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.

Page 17 of 27
 Process Modeling: The data object sets defined in the Data Modeling phase are converted to
establish the business information 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.
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 Modeling.
• 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.

The following illustration describes the RAD Model in detail.

Page 18 of 27
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 reusability 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 modeling skills.
• Inapplicable to cheaper projects as cost of Modeling 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.

Page 19 of 27
AGILE MODELS
Agile SDLC model is a combination of iterative and incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods
break the product into small incremental builds. These builds are provided in iterations. Each iteration
typically lasts from about one to three weeks. Every iteration involves cross functional teams working
simultaneously on various areas like −
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and important stakeholders.

What is Agile?

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 −

Page 20 of 27
The Agile thought process had started early in the software development and started becoming popular
with time due to its flexibility and adaptability.
The agile software development emphasizes on four core values.

1. Individual and team interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

1. Individuals and interactions − In Agile development, self-organization and motivation are

important, as are interactions like co-location and pair programming.
2. 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.
3. 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.
4. Responding to change − Agile Development is focused on quick responses to change and
continuous development.

Agile Testing Methodology:

Scrum
Agile Testing
Methodology:
Extreme
Programming
Scrum Methodology:
SCRUM is an agile development method which concentrates specifically on how to manage
tasks within a team-based development environment. Basically, Scrum is derived from activity
that occurs during a rugby match. Scrum believes in empowering the development team and
advocates working in small teams (say- 7 to 9 members). It consists of three roles, and their
responsibilities are explained as follows:

Page 21 of 27
 • Scrum Master
o Master is responsible for setting up the team, sprint meeting and removes obstacles to
progress
• Product owner
o The Product Owner creates product backlog, prioritizes the backlog and is responsible
for the delivery of the functionality at each iteration
• Scrum Team
o Team manages its own work and organizes the work to complete the sprint or cycle

Product Backlog

This is a repository where requirements are tracked with details on the no of requirements to be
completed for each release. It should be maintained and prioritized by Product Owner, and it should be
distributed to the scrum team. Team can also request for a new requirement addition or modification or
deletion

Page 22 of 27
Scrum Practices

Practices are described in detailed:

Process flow of Scrum Methodologies:

Process flow of scrum testing is as follows:

• Each iteration of a scrum is known as Sprint

• Product backlog is a list where all details are entered to get end product
• During each Sprint, top items of Product backlog are selected and turned into Sprint backlog
• Team works on the defined sprint backlog
• Team checks for the daily work
• At the end of the sprint, team delivers product functionality

eXtreme Programming (XP):

Extreme Programming technique is very helpful when there is constantly changing demands or
requirements from the customers or when they are not sure about the functionality of the
system. It advocates frequent "releases" of the product in short development cycles, which
inherently improves the productivity of the system and also introduces a checkpoint where any
customer requirements can be easily implemented. The XP develops software keeping
customer in the target.

Page 23 of 27
Business requirements are gathered in terms of stories. All those stories are stored in a place called
the parking lot. In this type of methodology, releases are based on the shorter cycles called Iterations
with span of 14 days’ time period. Each iteration includes phases like coding, unit testing and system
testing where at each phase some minor or major functionality will be built in the application.

Phases of eXtreme programming:

There are 6 phases available in Agile XP method, and those are explained as follows:

1. Planning
2. Analysis
3. Design
4. Execution
5. Wrapping
6. Closure

Page 24 of 27
 1. Identification of stakeholders and sponsors
2. Infrastructure Requirements 3.
Planning 3. Security related information and gathering
4. Service Level Agreements and its conditions

1. Capturing of Stories in Parking lot

2. Prioritize stories in Parking lot
Analysis 3. Scrubbing of stories for estimation
4. Define Iteration SPAN(Time)
5. Resource planning for both Development and QA teams

1. Break down of tasks

Design 2. Test Scenario preparation for each task
3. Regression Automation Framework

1. Coding
2. Unit Testing
3. Execution of Manual test scenarios
Execution 4. Defect Report generation
5. Conversion of Manual to Automation regression test cases
6. Mid Iteration review
7. End of Iteration review

1. Small Releases
2. Regression Testing
3. Demos and reviews
Wrapping 4. Develop new stories based on the need
5. Process Improvements based on end of iteration review
comments

1. Pilot Launch
2. Training
3. Production Launch
Closure 4. SLA Guarantee assurance
5. Review SOA strategy
6. Production Support

Page 25 of 27
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.

Page 26 of 27
Agile Versus Waterfall Method
Agile and Waterfall model are two different methods for software development process. Though they
are different in their approach, both methods are useful at times, depending on the requirement and the
type of the project.

Agile Model Waterfall Model

• Agile method proposes incremental and iterative approach • Development of the software flows sequentially
to software design from start point to end point.

• The agile process is broken into individual models that • The design process is not broken into an
designers work on individual models

• The customer has early and frequent opportunities to look • The customer can only see the product at the
at the product and make decision and changes to the end of the project
project

• Agile model is considered unstructured compared to the • Waterfall model are more secure because they
waterfall model are so plan oriented

• Small projects can be implemented very quickly. For large • All sorts of project can be estimated and
projects, it is difficult to estimate the development time. completed.

• Error can be fixed in the middle of the project. • Only at the end, the whole product is tested. If
the requirement error is found or any changes
have to be made, the project has to start from
the beginning

• Development process is iterative, and the project is • The development process is phased, and the
executed in short (2-4) weeks iterations. Planning is very phase is much bigger than iteration. Every
less. phase ends with the detailed description of the
next phase.

• Documentation attends less priority than software • Documentation is a top priority and can even
development use for training staff and upgrade the software
with another team

• Every iteration has its own testing phase. It allows • Only after the development phase, the testing
implementing regression testing every time new functions phase is executed because separate parts are
or logic are released. not fully functional.

• In agile testing when an iteration end, shippable features • All features developed are delivered at once
of the product is delivered to the customer. New features after the long implementation phase.
are usable right after shipment. It is useful when you have
good contact with customers.

• Testers and developers work together • Testers work separately from developers

• At the end of every sprint, user acceptance is performed • User acceptance is performed at the end of the
project.

• It requires close communication with developers and • Developer does not involve in requirement and
together analyze requirements and planning planning process. Usually, time delays
between tests and coding

Page 27 of 27