Chapter 1

Introduction to Software Engineering

Topics In curriculum
Nature of Software, Software Engineering, Software Process, Generic Process Model,
Prescriptive Process Models: The Waterfall Model, V-model, Incremental Process Models,
Evolutionary Process Models, Concurrent Models
Definition of Software and Characteristics of Software
Computer Software is the product that software professionals build and then support over
the long term. Software is a set of instructions to acquire inputs and manipulate them to
produce the desired output in terms of functions and performance as determined by the user
of the software.
Software Engineering is defined as a discipline that addresses the following aspects of the
software and its development. They are:
1. Economic : Cost, Benefits, and Returns on Investment (ROI).
2. Design : Ease of development and ensuring delivery of customer requirements.
3. Maintenance : Ease of effecting changes and modifications.
4. Implementation : Ease of installation, Demonstration, and implementation of software by
the
customer and users.
It is an engineering discipline which is systemic, scientific, methodical, uses standards,
models algorithms in design and development.
The IEEE (Institution of Electrical and Electronics Engineers) defines Software Engineering
as the application of a systematic, disciplined, quantifiable approach to the development,
operations and maintenance of software.
Today, software performs a dual role. It is both a product and a vehicle for delivering a
product. As a product, it delivers the computing potential embodied by computer hardware
or, more broadly, by a network of computers that are accessible by local hardware. Software
is an information transformer - producing, managing, acquiring, modifying, displaying,
transmitting information that can be as simple as a single bit or as complex as a multimedia
presentation.
As a vehicle, for delivering the product, software acts as the basis for the control of computer
(Operating System),the communication of information (networks), and the creation and
control of other programs (Software tools and environments).
Characteristics of Software:
Software is written to handle an Input – Process – Output system to achieve predetermined
goals. Software is logical rather than a physical system element. Therefore software has
characteristics that are different than that of hardware.
1. Software is developed or engineered; it is not manufactured in the classical sense.
2. Software doesn’t “wear out” like hardware and it is not degradable over a period.
3. Although the industry is moving toward component – based construction, most software
continues to be custom built.
4. A software component should be designed and implemented so that it can be reused in
many different programs.
5. The following figure depicts failure rate as a function of time for hardware. The
relationship often called as “bathtub curve”, indicates that, hardware exhibits relatively
high failure rates early in its life.
6. Software is not susceptible to the environmental maladies that cause hardware to wear
out. Hence, the failure rate curve for software should take the form of “idealized curve”
as shown in the figure. Undiscovered defects will cause high failure rates early in the life
of a program. However, these are corrected and the curve flattens as shown. Hence the
software doesn’t wear out, but it does deteriorate.

Time
Failure curve for Hardware

Failure curve for Software

The classical and conventional definition of software is that it is a set of instructions which
when executed through a computing device produces the desired result by the execution of
functions and processes. It also includes a set of documents, such as the software manual,
meant for users to understand the software system. Today’s software comprises the source
code, Executable, Design Documents, Operations Manual, System Manual, Installation
/Implementation Manuals.
Software is described by its capabilities. The capabilities relate to the functions it executes,
the features it provides and the facilities it offers.
Characteristics of Good software

Nature of Software/ Types of Software

Seven broad categories of computer software present continuing challenges for software
engineers.
1. System Software:
System Software is a collection of programs written to serve other programs. Some system
software (e.g.- compliers, editors, and file management utilities) processes complex, but
determinate information structures. Other system applications (e.g.- operating system
components, drivers, networking software, telecommunications processors) process largely
indeterminate data. In either case, the systems software area is characterized by heavy
interaction with computer hardware; heavy usage by multiple users; concurrent operation that
requires scheduling, resource sharing, and sophisticated process management; complex data
structures and multiple external interfaces.
2. Application Software:
Application Software consists of standalone programs that solve a specific business need.
Applications in this area process business or technical data in a way that facilitates business
operations, management, and technical decision-making. In addition to conventional data
processing applications, application software is used to control business functions in real time
(e.g., point-of-sale transaction processing, real-time manufacturing process control).
3. Engineering / Scientific Software:
Formerly characterized by “number crunching” algorithms, engineering and scientific
software applications range from astronomy to volcanology, from automotive stress analysis
to space shuttle orbital dynamics, and from molecular biology to automated manufacturing.
Computer-aided design, system simulation, and other interactive applications have begun to
take on real–time and even system software characteristics.
4. Embedded Software:
Embedded Software resides within a product or system and is used to implement and control
features and functions for the end-user and for the system itself. Embedded software can
perform limited and esoteric functions (e.g. keypad control for a microwave oven) or provide
significant function and control capability (e.g. digital functions in an automobile such as fuel
control, dashboard displays, braking systems, etc.)
5. Product–line Software:
Designed to provide a specific capability for use by many different customers, product–line
software can focus on a limited & esoteric market place (e.g. – inventory control products) or
address mass consumer markets (e.g. – word processing, spreadsheets, computer graphics,
multimedia, entertainment, database management, personal and business financial
applications.)
6. Web – applications:
“WebApps”, span a wide array of applications. WebApps are evolving into sophisticated
computing environments that not only provide standalone features, computing functions and
content to the end user, but also are integrated with corporate databases and business
applications.
7. Artificial Intelligence(AI) Software:
AI Software makes use of non–numerical algorithms to solve complex problems that are not
amenable to computation or straight forward analysis. Applications within this area include
robotics, expert systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing.
Due to changing nature of software and rapid growth of technology, the challenge for
software engineers will be –
a) To develop systems and application software that will allow small devices, personal
computers, and enterprise system to communicate across vast networks to meet rapid
growth of wireless networking.
b) To architect simple (e.g.- personal financial planning) and sophisticated applications that
provide benefit to targeted end-user markets worldwide to meet rapid growth of net
sourcing (World Wide Web)
c) To build source code that is self-descriptive, but, more importantly, to develop techniques
that will enable both customers and developers to know what changes have been made
and how those changes manifest themselves within the software.
d) To build applications that will facilitate mass communication and mass product
distribution using concepts that is only now forming.
e) The computer itself will make a historic transition from something that is used for
analytic tasks to something that can elicit emotion. - David Vaskevitch
 Software Engineering: Definition and its Need
According to Fritz Bauer, software engineering is establishment and use of sound engineering
principles in order to obtain economical software that is reliable and works efficiently on real
machines.
“More than a discipline or a body of knowledge, engineering is a verb, an action word, a way
of approaching a problem”. - Scott Whit mire
Relationship between Systems Engineering and Software Engineering
Software Engineering
Software engineering deals with designing and developing software of the highest quality. A
software engineer does analyzing, designing, developing and testing software. Software
engineers carry out software engineering projects, which usually have a standard software life
cycle. For example, the Water Fall Software Life cycle will include an analysis phase, design
phase, development phase, testing and verification phase and finally the implementation
phase. Analysis phase looks at the problem to be solved or the opportunities to be seized by
developing the software. Sometimes, a separate business analyst carries out this phase.
However, in small companies, software engineers may do this task. Design phase involves
producing the design documents such as UML diagrams and ER diagrams depicting the
overall structure of the software to be developed and its components. Development phase
involves programming or coding using a certain programming environment. Testing phase
deals with verifying that software is bug free and also satisfies all the customer requirements.
Finally, the completed software is implemented at the customer site (sometimes by a separate
implementation engineer). In recent years, there has been a rapid growth of other software
development methodologies in order to further improve the efficiency of the software
engineering process. For example, Agile methods focus on incremental development with
very short development cycles. Software Engineering profession is a highly rated job because
of its very high salary range.
System Engineering
System Engineering is the sub discipline of engineering which deals with the overall
management of engineering projects during their life cycle focusing more on physical
aspects. It deals with logistics, team coordination, automatic machinery control, work
processes and similar tools. Most of the times, System Engineering overlaps with the
concepts of Industrial Engineering, Control Engineering, Organizational and Project
Management and even Software Engineering. System Engineering is identified as an
interdisciplinary engineering field due to this reason. System Engineer may carry out system
designing, developing requirements, verifying requirements, system testing and other
engineering studies.
Software engineering layers: A Layered Technology Approach
Software engineering is a layered technology. The layers of software engineering as shown
in the above diagram are:-
1. A Quality Focus:
Any engineering approach including software engineering must rest on an organizational
commitment to quality. Total quality management, six sigma and similar philosophies foster
a continuous process improvement culture, and it is this culture that ultimately leads to the
development of increasingly more effective approaches to software engineering. The
bedrock that supports software engineering is a quality focus.
2. Process Layer:
The foundation for software engineering is the process layer. Software Engineering process
is the glue that holds the technology layers together and enables rational and timely
development of computer software. Process defines a framework that must be established for
effective delivery of software engineering technology. The software process forms the basis
for management control of software projects and establishes the context in which technical
methods are applied, works products (models, documents, data, reports, forms etc.) are
produced, milestones are established, quality is ensured and change is properly managed.
3. Methods:
Software Engineering methods provide the technical know-how’s for building software.
Methods encompass a broad array of tasks that include communication, requirements
analysis, design modeling, program construction, testing and support.
4. Tools:
Software Engineering tools provide automated or semi-automated support for the process and
the methods. When tools are integrated so that information created by one tool can be used
by another, a system for the support of software development, called computer–aided
software engineering is established.
Software Development Generic Process Framework
A process framework establishes the foundation for a complete software process by
identifying a small number of framework activities that are applicable to all software projects,
regardless of their size or complexity. In addition, the process framework encompasses a set
of umbrella activities that are applicable across the entire software process.
Software Process

Process Framework
Umbrella activities
Framework activity #1

Software engineering action #1.1

Work tasks

Work products

Quality assurance points

Task sets

. Work tasks
. Work products
. Quality assurance points
Software engineering action #1.k

Framework activity #n

Software engineering action #n.1

Work tasks

Work products

Task sets Quality assurance points

. Work tasks
.
. Work products
.
. Quality assurance points
Software engineering action #n.m

From the above figure, each framework activity is populated by a set of software engineering
actions- a collection of related tasks that produces a major software engineering work product
(e.g. design is a SE action). Each action is populated with individual work tasks that
accomplish some part of the work implied by the action.
A process defines who is doing what, when and how to reach a certain goal. The following
generic process framework is applicable to the vast majority of software projects.
1. Communication :
This framework activity involves heavy communication & collaboration with the customer
(and the stakeholders) and encompasses requirements gathering and other related activities.
Planning :
This activity establishes a plan for the software engineering work that follows. It describes
the technical tasks to be conducted, the risks that are likely, the resources that will be
required, the work products to be produced and a work schedule.
2. Modeling :
This activity encompasses the creation of models that allow the developer & the customer to
better understand software requirements & the design that will achieve those requirements.
3. Construction :
This activity combines code generation and the testing that is required to uncover errors in
the code.
4. Deployment :
The software is delivered to the customer who evaluates the delivered product and provides
feedback based on the evaluation.
Umbrella Activities:Generic views of SE has a set of unbrella activities. They are
Software Project tracking and control:
The framework described in the generic view of SE is complemented by a number of
umbrella activities, one of which is software project tracking and control. It allows the
software team to access progress against the project plan and takes necessary action to
maintain schedule. Umbrella activities occur throughout the software process and focus
primarily on project management, tracking and control.
Risk Management:
Assess risks that are likely to affect performance and quality of project.
Software quality assurance:
Define and conduct activities to ensure software quality.
Formal Technical Review:
Work products to uncover and remove errors before they are shifted to next level of activity.
Measurement:
Defines and collects process, project and product measures to assist the team in delivering the
software that meets customer needs can be used in conjunction with all framework and
umbrella activities.
Software Configuration Management (SCM):
Manages and effects the changes throughout the software process.
Reusability management:
Defines criteria for work product reuse (including software components) and establishes the
mechanism to achieve reusable components.
Work product preparation and production:
Includes activities for creating work product such as models, documents, data, reports etc.
Process Technology:
The generic process models must be adapted for use by a software project team. To
accomplish this, process technology tools have been developed to help software organizations
analyze their current process, organize work tasks, control, monitor progress and manage
technical quality.
Process technology tools allow a software organization to build an automated model of the
common process framework, task sets and umbrella activities. The model, normally
represented as a network can then be analyzed to determine typical workflow and examine
alternative process structures that might lead to reduced development time and cost.
Once, an acceptable process is created, other process technology tools can be used to allocate,
monitor and even control all software engineering tasks defined as part of the process model,
to develop a checklist of work tasks to be performed, work products to be produced and
quality assurance activities to be conducted, to coordinate the use of other computer-aided
software engineering tools that are appropriate for a particular work task.
In some cases, the process technology tools incorporate standard project management tasks
such as estimating, scheduling, tracking and control.
Prescriptive Process Models:
Irrespective of which level of CMM the organization has, the software engineer has five
choices for selection of software process models.
They are –
1. Waterfall Model
2. Incremental Model
3. RAD Model
4. Prototype Model
5. Spiral Model
1. The Waterfall Model:
There are times when the requirements of a problem are reasonably well understood – when
work flows from communication through deployment in a reasonably linear fashion.
The waterfall model is a traditional method, sometimes called the classic life cycle. This is
one of the initial models. As the figure implies stages are cascaded and shall be developed
one after the other. In other words one stage should be completed before the other begins.
Hence, when all the requirements are elicited by the customer, analyzed for completeness and
consistency, documented as per requirements, the development and design activities
commence.
One of the main needs of this model is the user’s explicit prescription of complete
requirements at the start of development. For developers it is useful to layout what they need
to do at the initial stages. Its simplicity makes it easy to explain to customers who may not be
aware of software development process. It makes explicit with intermediate products to begin
at every stage of development.
One of the biggest limitation is it does not reflect the way code is really developed.
Problem is well understood but software is developed with great deal of iteration.
Often this is a solution to a problem which was not solved earlier and hence software
developers shall have extensive experience to develop such application; as neither the user
nor the developers are aware of the key factors affecting the desired outcome and the time
needed. Hence at times the software development process may remain uncontrolled.
Today software work is fast paced and subject to a never-ending stream of changes in
features, functions and information content. Waterfall model is inappropriate for such work.
This model is useful in situation where the requirements are fixed and work proceeds to
completion in a linear manner.
Among the problems that are sometimes encountered when the waterfall model is applied are
1. Real projects rarely follow the sequential flow that the model proposes. Although the
linear model can accommodate iteration, it does so directly. As a result, changes can
cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The Waterfall
Model requires this and has difficulty accommodating the natural uncertainty that exists
at the beginning of many projects.
3. The customer must have patience. A working version of the program will not be
available until late in the project time-span. A major blunder, if undetected until the
working program is received, can be disastrous.
The waterfall model is often inappropriate for such work. However, it can serve as a useful
process model in situations where requirements are fixed and work is to proceed to
completion in a linear manner.
2. The Incremental Model:
The incremental model combines elements of the waterfall model applied in an iterative
fashion. The incremental model delivers a series of releases, called increments, that provides
progressively more functionality for the customer at each increment is delivered. In each
increment, additional functions and features are added after confirming the utility of earlier
increments.
In the early years of development users were willing to wait for software projects to be ready.
Today’s business does not tolerate long delays. Software helps to distinguish products in the
market place and customers are always looking for new quality and functions. One of the
ways to reduce time is the phased development. The system is developed such that it can be
delivered in parts enabling the users to have few functions while the rest are being developed.
Thus development and usage will happen in parallel.
In incremental development the system is partitioned into subsystems or increments. The
releases are defined in the beginning with initial function and them adding functionalities
with subsequent releases. Incremented development slowly builds up to full functionality
with subsequent releases.
This model combines the elements of waterfall model in an iterative fashion. The model
applies linear sequences in a staggered manner as the calendar time progresses. In this model
first increment is the core product or primary function. The core product implemented
undergoes detailed evaluation by the user which becomes advantages for future increments.
The feedback also addresses future modifications which are included in the next increments
for additional features and functionality. He process is repeated till delivery of each
increment till the final product is delivered.
This is useful when the software team is smaller in size. Additional increments can be
planned and managed to address technical risks. This has the advantage of prompt system
delivery to users without hassle.
In case of availability of new hardware are delayed and early increments which could be
executed on existing systems for partial functionality to prevent inordinate delays.
From this diagram, the incremental model applies linear sequences in a staggered fashion as
calendar time progresses. Each linear sequence produces deliverable “Increments” of the
software.
For example, word-processing software developed using the incremental paradigm might
deliver basic file management, editing and document production functions in the first
increment; more sophisticated editing and document production capabilities in the second
increment; spelling and grammar checking in the third increment; and advanced page layout
capability in the fourth increment.
The RAD Model:

Rapid Application Development (RAD) is a modern software process model that emphasizes
a short development cycle. The RAD Model is a “high-speed” adaptation of the waterfall
model, in which rapid development is achieved by using a component based construction
approach. If requirements are well understood and project scope is considered, the RAD
process enables a development team to create a “Fully Functional System” within a very
short period of time (e.g. 60 to 90 days).
One of the distinct features of RAD model is the possibility of cross life cycle activities
which will be assigned to teams, teams #1 to team #n leading to each module getting
developed almost simultaneously.
This approach is very useful if the business application requirements are modularized as
function to be completed by individual teams and finally to integrate into a complete system.
As such compared to waterfall model the team will be of larger size to function with proper
coordination.
RAD model distributes the analysis and construction phases into a series of short iterative
development cycles. The activities of each phase per team are Business modeling, Data
modeling and process modeling.
This model is useful for projects with possibility of modularization. RAD may fail if
modularization is difficult. This model should be used if domain experts are available with
relevant business knowledge.
Advantages:
1. Changing requirements can be accommodated and progress can be measured.
2. Powerful RAD tools can reduce development time.
3. Productivity with small team in short development time and quick reviews, risk control
increases reusability of components, better quality.
4. Due to risks in new approach only modularized systems are recommended through RAD.
5. Suitable for scalable component based systems.
Limitations:
1. Success of RAD model depends on strong technical team expertise and skills.
2. Highly skilled developers needed with modeling skills.
3. User involvement throughout life cycle. If developers & customers are not committed to
the rapid fire activities necessary to complete the System in a much-abbreviated time
frame, RAD projects will fail.
4. May not be appropriate for very large scale systems where the technical risks are high.
3. The Prototype Model:
The prototyping paradigm begins with communication as shown in the diagram below.

The software development process can help to control by including activities and sub
processes to enhance understanding. Prototyping is a sub process or a partially developed
product that enable customers and developers to examine aspects of a proposed system and
decide if it is suitable or appropriate for the finished product.
Developers may build a system to implement a small portion of some of the key requirements
to ensure that the requirements are consistent, feasible and practical. In case of changes,
revisions are made at the requirements stage by prototyping parts of the design.
Design prototyping helps the developers assess alternative strategies and decide which best
suits for the project. There may be radically different designs to get best performances. Often
user interface is built and tested as a prototype for users to understand the new system and
developers to get the idea of user’s reaction/response to the system.
In Business needs, requirements change very often making earlier methods unrealistic and
redundant. Short market deadlines make it difficult to complete comprehensive software
products. The evolutionary models are iterative and help the developers to complete short
version within the given deadlines.
Ideally prototype serves as a mechanism to identify software requirements for working
prototypes. The developer attempts to make use of existing program fragments and applies
tools such as report generators which enable working programs to be generated quickly.
The software engineer & customer meet and define the overall objectives for the software,
identify whatever requirements are known and outline areas where further definition is
mandatory. Prototyping iteration is planned quickly and modeling (in the form of quick
design) occurs. The quick design focuses on a representation of those aspects of the software
that will be visible to the customer/end-user (e.g. human interface layout or output display
formats). The quick design leads to the construction of a prototype. The prototype is
deployed & then evaluated by the customer/user. Feedback is used to refine requirements for
the software.
4. The Spiral Model:

Boehm (1988) viewed the software development process in light of risks involved, Spiral
model could combine development activities with risk management to minimize and control
the risk impact.
It is an evolutionary model which couples iterative nature of prototyping with controlled and
systematic aspects of the waterfall model. It also provides scope for RAD for increasingly
complete software.
The spiral development model is a risk-driven process model generator that is used to guide
multi-stakeholder concurrent engineering of software intensive systems. It has two main
distinguishing features. One is a cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its degree of risk. The other is a
set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually
satisfactory system solutions.
From the figure given above, a spiral model is divided into a set of framework activities
defined by the software engineering team. As this evolutionary process begins, the software
team performs activities that are implied by a circuit around the spiral in a clockwise
direction, beginning at the center. Risk is considered as each revolution is made. Anchor
point milestones – a combination of work products and conditions that are attained along the
path of the spiral – are noted for each evolutionary pass.
Each pass through the planning region results in adjustments to the project plan. Cost &
schedule are adjusted based on feedback derived from the customer after delivery. In
addition, the project manager adjusts the planned number of iterations required to complete
the software.
The initial circuit around the spiral can be for the concept development and with multiple
iterations. The spiral traverses outward for new product development spiral development
remains operative for the life span of software. This may be a realistic approach for large
scale software development. As the process progresses both users and developers better
understand the system. However the system, demands risks, identification and monitoring to
prevent hurdles.
Advantages:
1. One is a cyclic approach for incrementally growing a system‘s degree of definition and
implementation while decreasing its degree of risk.
2. The set of anchor point milestones for ensuring stakeholder commitment to obtain feasible
and mutually satisfactory system solutions.
Limitations:
1. The system demands risks identification and monitoring to prevent hurdles.
2. System can get into infinite iterations.
SDLC V-Model
The SDLC V-Model is a type of Software Development Life Cycle (SDLC). It is a method
that includes testing and validation alongside each development phase. It creates a structure
like the letter 'V,' which includes various phases
The V-Model, which includes the Verification and Validation it is a structural approach to
software development. The following are the different Phases of the V-Model of the SDLC.
1. V-Model Verification Phases
This is where the process begins. The first step is to gather and understand the customer’s
needs for the software. The goal is to define the scope of the project clearly to make sure
everyone is on the same page.
It involves a static analysis technique (review) done without executing code. It is the process
of evaluation of the product development phase to find whether specified requirements are
met.
There are several Verification phases in the V-Model:
1. Business Requirement Analysis
This is the first step of the designation of the development cycle where product requirement
needs to be cured from the customer's perspective. These phases include proper
communication with the customer to understand their requirements.
These are the very important activities that need to be handled properly, as most of the time
customers do not know exactly what they want, and they are not sure about it at that time
then we use an acceptance test design planning which is done at the time of business
requirement it will be used as an input for acceptance testing.
2. System Design
In this phase, the overall structure of the software is planned out. The team develops both the
high-level design (how the system will be structured) and detailed design (how the individual
components will work).
Design of the system will start when the overall we are clear with the product requirements,
and then need to design the system completely. This understanding will be at the beginning of
complete under the product development process. these will be beneficial for the future
execution of test cases.
3. Architectural Design
In this stage, architectural specifications are comprehended and designed. Usually, several
technical approaches are put out, and the ultimate choice is made after considering both the
technical and financial viability. The system architecture is further divided into modules that
each handle a distinct function. Another name for this is High-Level Design (HLD).
At this point, the exchange of data and communication between the internal modules and
external systems are well understood and defined. During this phase, integration tests can be
created and documented using the information provided.
4. Module Design
This phase, known as Low-Level Design (LLD), specifies the comprehensive internal design
for every system module. Compatibility between the design and other external systems as
well as other modules in the system architecture is crucial. Unit tests are a crucial component
of any development process since they assist in identifying and eradicating the majority of
mistakes and flaws at an early stage. Based on the internal module designs, these unit tests
may now be created.
5. Coding Phase
This is where the software is actually built. Developers write the code based on the design
created in the previous phase.
The Coding step involves writing the code for the system modules that were created during
the Design phase. The system and architectural requirements are used to determine which
programming language is most appropriate.
The coding standards and principles are followed when performing the coding. Before the
final build is checked into the repository, the code undergoes many code reviews and is
optimized for optimal performance.
2. V-Model Validation Phases
It involves dynamic analysis techniques (functional, and non-functional), and testing done by
executing code. Validation is the process of evaluating the software after the completion of
the development phase to determine whether the software meets the customer's expectations
and requirements.
1. Unit Testing
In Unit Testing, unit Test Plans are developed during the module design phase. These Unit
Test Plans are executed to eliminate bugs in code or unit level.
2. Integration testing
After completion of unit testing, Integration testing is performed. In integration testing, the
modules are integrated and the system is tested. Integration testing is performed in the
Architecture design phase. This test verifies the communication of modules among
themselves.
3. System Testing
System Testing tests the complete application with its functionality, inter-dependency, and
communication. It tests the functional and non-functional requirements of the developed
application.
4. User Acceptance Test
This is performed in a user environment that resembles the production environment. UAT
verifies that the delivered system meets the user's requirement and the system is ready for use
in the real world.
Industrial Challenge of V-Model
As the industry has evolved, the technologies have become more complex, increasingly
faster, and forever changing, however, there remains a set of basic principles and concepts
that are as applicable today as when IT was in its infancy.
 Accurately define and refine user requirements.
 Design and build an application according to the authorized user requirements.
 Validate that the application they had built adhered to the authorized business
requirements.
Importance of V-Model
The V-Model is an important part of the SDLC, and the process is structured and sequential
throughout all the testing. Here is why the V-Model is important:
1. Early Defect Identification
By incorporating verification and validation tasks into every stage of the development
process, the V-Model encourages early testing. This lowers the cost and effort needed to
remedy problems later in the development lifecycle by assisting in the early detection and
resolution of faults.
2. Determining the Phases of Development and Testing
The V-Model contains a testing phase that corresponds to each stage of the development
process. By ensuring that testing and development processes are clearly mapped out, this
clear mapping promotes a methodical and orderly approach to software engineering.
3. Prevents "Big Bang" Testing
Testing is frequently done at the very end of the development lifecycle in traditional
development models, which results in a "Big Bang" approach where all testing operations are
focused at once. By integrating testing activities into the development process and
encouraging a more progressive and regulated testing approach, the V-Model prevents this.
4. Improves Cooperation
At every level, the V-Model promotes cooperation between the testing and development
teams. Through this collaboration, project requirements, design choices, and testing
methodologies are better understood, which improves the effectiveness and efficiency of the
development process.
5. Improved Quality Assurance
Overall quality assurance is enhanced by the V-Model, which incorporates testing operations
at every level. Before the program reaches the final deployment stage, it makes sure that it
satisfies the requirements and goes through a strict validation and verification process.
Principles of V-Model
 Large to Small: In V-Model, testing is done in a hierarchical perspective, for
example, requirements identified by the project team, creating High-Level Design,
and Detailed Design phases of the project. As each of these phases is completed the
requirements, they are defining become more and more refined and detailed.
 Data/Process Integrity: This principle states that the successful design of any project
requires the incorporation and cohesion of both data and processes. Process elements
must be identified at every requirement.
 Scalability: This principle states that the V-Model concept has the flexibility to
accommodate any IT project irrespective of its size, complexity, or duration.
 Cross Referencing: A direct correlation between requirements and corresponding
testing activity is known as cross-referencing.
Tangible Documentation:
This principle states that every project needs to create a document. This documentation is
required and applied by both the project development team and the support team.
Documentation is used to maintain the application once it is available in a production
environment.
Why preferred?
 It is easy to manage due to the rigidity of the model. Each phase of V-Model has
specific deliverables and a review process.
 Proactive defect tracking – that is defects are found at an early stage.
When to Use of V-Model?
 Traceability of Requirements: The V-Model proves beneficial in situations when
it's imperative to create precise traceability between the requirements and their related
test cases.
  Complex Projects: The V-Model offers a methodical way to manage testing
activities and reduce risks related to integration and interface problems for projects
with a high level of complexity and interdependencies among system components.
 Waterfall-Like Projects: Since the V-Model offers an approachable structure for
organizing, carrying out, and monitoring testing activities at every level of
development, it is appropriate for projects that use a sequential approach to
development, much like the waterfall model.
 Safety-Critical Systems: These systems are used in the aerospace, automotive, and
healthcare industries. They place a strong emphasis on rigid verification and
validation procedures, which help to guarantee that essential system requirements are
fulfilled and that possible risks are found and eliminated early in the development
process.
Advantages of V-Model
 This is a highly disciplined model and Phases are completed one at a time.
 V-Model is used for small projects where project requirements are clear.
 Simple and easy to understand and use.
 This model focuses on verification and validation activities early in the life cycle
thereby enhancing the probability of building an error-free and good quality product.
 It enables project management to track progress accurately.
 The V-Model provides a clear and structured process for software development,
making it easier to understand and follow.
 The V-Model places a strong emphasis on testing, which helps to ensure the quality
and reliability of the software.
 The V-Model provides a clear link between the requirements and the final product,
making it easier to trace and manage changes to the software.
 The clear structure of the V-Model helps to improve communication between the
customer and the development team.
Disadvantages of the V-Model
 The V-Model is a linear and sequential model, which can make it challenging to adapt
to changing requirements or unforeseen events.
 The V-Model can be time-consuming, as it requires a lot of documentation and
testing.
 High risk and uncertainty.
 It is not good for complex and object-oriented projects.
 It is not suitable for projects where requirements are not clear and contain a high risk
of changing.
 This model does not support iteration of phases.
 The V-Model places a strong emphasis on documentation, which can lead to an
overreliance on documentation at the expense of actual development work.
Concurrent Development Model
 The Concurrent Development Model is a software development approach where
multiple phases (e.g., design, coding, testing) occur simultaneously. This model
emphasizes the overlapping of various project stages, which allows teams to work on
different parts of the project at the same time.. This model supports the concept of
concurrency in that design, code, test and another related phase occur simultaneously.
 They include minimizing development time, encouraging effective interaction
between development teams, and increasing the versatility of the resulting product
due to the possibility of feedback at any step of the cycle. In their operation, each
team is in harmony with the other, reporting details in real-time thus making the
processes much more coherent and active.
Features of the Concurrent Development Model
 Parallel Workflow: Several phases start and run concurrently like the design phase,
development phase, and the testing phase allowing completion of a project more
expediently.
 Real-time Communication: Everyone gets repeated feedback hence the team works
and solutions together to ensure the common goal is achieved.
 Flexibility: Stakeholders can incorporate new changes and improvements easily since
one phase operates in tangent to another.
 Iterative Development: The model is also suitable for iterative activities in which
input and testing are received continually, and prototypes are revised.
 Reduced Time-to-Market: The work is divided between the tasks and stages,
making the project faster since many tasks are done concurrently.
Advantages
 Reduced Development Time: By running multiple phases in parallel, tasks are
completed faster, leading to shorter time-to-market.
 Improved Collaboration: Teams working across different phases simultaneously
create constant feedback loops, allowing real-time problem-solving, faster issue
resolution, and better collaboration across all stages.
 Early Detection of Issues: Continuous testing and feedback integration allow for
issues to be detected early in the development process.
 Flexibility and Adaptability: Changes can be incorporated at any stage of the
development, allowing for a more adaptable approach to evolving project needs.
 Enhanced Product Quality: With real-time feedback and iterative testing, the final
product benefits from higher quality due to continuous improvements throughout
the development cycle.

Challenges of the Concurrent Development Model

• Complex Project Management : Managing concurrent tasks across multiple teams
requires effective coordination and real-time communication to ensure that the teams’
efforts align properly.
• Communication Overload: Since multiple teams work in parallel, maintaining
constant communication and synchronizing updates across teams becomes crucial.
• Higher Resource Demand: Concurrent development increases resource allocation,
as teams must manage overlapping tasks. This can lead to resource conflict, higher
costs, and logistical challenges.
• Difficulty in Managing Dependencies: Teams often depend on each other’s work,
and if one team lags behind, it can affect the entire project’s progress.
• Increased Complexity in Integration: Integrating modules developed by different
teams concurrently can lead to compatibility issues, requiring additional testing and
debugging.