Software Processes

The term software specifies to the set of computer programs, procedures and associated
documents (Flowcharts, manuals, etc.) that describe the program and how they are to be
used.
A software process is the set of activities and associated outcome that produce a software
product. Software engineers mostly carry out these activities. These are four key process
activities, which are common to all software processes. These activities are:
1. Software specifications: The functionality of the software and constraints on its
operation must be defined.
2. Software development: The software to meet the requirement must be produced.
3. Software validation: The software must be validated to ensure that it does what
the customer wants.
4. Software evolution: The software must evolve to meet changing client needs.

The Software Process Model

A software process model is a specified definition of a software process, which is
presented from a particular perspective. Models, by their nature, are a simplification, so
a software process model is an abstraction of the actual process, which is being
described. Process models may contain activities, which are part of the software process,
software product, and the roles of people involved in software engineering. Some
examples of the types of software process models that may be produced are:
1. A workflow model: This shows the series of activities in the process along with
their inputs, outputs and dependencies. The activities in this model perform human
actions.
2. A dataflow or activity model: This represents the process as a set of activities,
each of which carries out some data transformations. It shows how the input to the
process, such as a specification is converted to an output such as a design. The
activities here may be at a lower level than activities in a workflow model. They
may perform transformations carried out by people or by computers.
3. A role/action model: This means the roles of the people involved in the software
process and the activities for which they are responsible.
There are several various general models or paradigms of software development:
1. The waterfall approach: This takes the above activities and produces them as
separate process phases such as requirements specification, software design,
implementation, testing, and so on. After each stage is defined, it is "signed off"
and development goes onto the following stage.
2. Evolutionary development: This method interleaves the activities of
specification, development, and validation. An initial system is rapidly developed
from a very abstract specification.
3. Formal transformation: This method is based on producing a formal
mathematical system specification and transforming this specification, using
mathematical methods to a program. These transformations are 'correctness
preserving.' This means that you can be sure that the developed programs meet
its specification.
4. System assembly from reusable components: This method assumes the parts
of the system already exist. The system development process target on integrating
these parts rather than developing them from scratch.

Software Crisis
1. Size: Software is becoming more expensive and more complex with the growing
complexity and expectation out of software. For example, the code in the consumer
product is doubling every couple of years.
2. Quality: Many software products have poor quality, i.e., the software products
defects after putting into use due to ineffective testing technique. For example,
Software testing typically finds 25 errors per 1000 lines of code.
3. Cost: Software development is costly i.e. in terms of time taken to develop and the
money involved. For example, Development of the FAA's Advanced Automation
System cost over $700 per lines of code.
4. Delayed Delivery: Serious schedule overruns are common. Very often the
software takes longer than the estimated time to develop, which in turn leads to
cost shooting up. For example, one in four large-scale development projects is
never completed.
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:

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.
Software Development Life Cycle (SDLC)
A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods
required to make a software product transit through its life cycle stages. It also captures
the structure in which these methods are to be undertaken.
In other words, a life cycle model maps the various activities performed on a software
product from its inception to retirement. Different life cycle models may plan the necessary
development activities to phases in different ways. Thus, no element which life cycle
model is followed, the essential activities are contained in all life cycle models though the
action may be carried out in distinct orders in different life cycle models. During any life
cycle stage, more than one activity may also be carried out.

Need of SDLC
The development team must determine a suitable life cycle model for a particular plan
and then observe to it.
Without using an exact life cycle model, the development of a software product would not
be in a systematic and disciplined manner. When a team is developing a software product,
there must be a clear understanding among team representative about when and what to
do. Otherwise, it would point to chaos and project failure. This problem can be defined by
using an example. Suppose a software development issue is divided into various parts
and the parts are assigned to the team members. From then on, suppose the team
representative is allowed the freedom to develop the roles assigned to them in whatever
way they like. It is possible that one representative might start writing the code for his
part, another might choose to prepare the test documents first, and some other engineer
might begin with the design phase of the roles assigned to him. This would be one of the
perfect methods for project failure.
A software life cycle model describes entry and exit criteria for each phase. A phase can
begin only if its stage-entry criteria have been fulfilled. So without a software life cycle
model, the entry and exit criteria for a stage cannot be recognized. Without software life
cycle models, it becomes tough for software project managers to monitor the progress of
the project.
SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes
the following steps:

The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.
The senior members of the team perform it with inputs from all the stakeholders and
domain experts or SMEs in the industry.
Planning for the quality assurance requirements and identifications of the risks associated
with the projects is also done at this stage.
Business analyst and Project organizer set up a meeting with the client to gather all the
data like what the customer wants to build, who will be the end user, what is the objective
of the product. Before creating a product, a core understanding or knowledge of the
product is very necessary.
For Example, A client wants to have an application which concerns money transactions.
In this method, the requirement has to be precise like what kind of operations will be done,
how it will be done, in which currency it will be done, etc.
Once the required function is done, an analysis is complete with auditing the feasibility of
the growth of a product. In case of any ambiguity, a signal is set up for further discussion.
Once the requirement is understood, the SRS (Software Requirement Specification)
document is created. The developers should thoroughly follow this document and also
should be reviewed by the customer for future reference.
Stage2: Defining Requirements
Once the requirement analysis is done, the next stage is to certainly represent and
document the software requirements and get them accepted from the project
stakeholders.
This is accomplished through "SRS"- Software Requirement Specification document
which contains all the product requirements to be constructed and developed during the
project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and
design of the software project. This phase is the product of the last two, like inputs from
the customer and requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow the
coding guidelines described by their management and programming tools like compilers,
interpreters, debuggers, etc. are used to develop and implement the code.

Stage5: Testing
After the code is generated, it is tested against the requirements to make sure that the
products are solving the needs addressed and gathered during the requirements stage.
During this stage, unit testing, integration testing, system testing, acceptance testing are
done.

Stage6: Deployment
Once the software is certified, and no bugs or errors are stated, then it is deployed.
Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.
After the software is deployed, then its maintenance begins.

Stage7: Maintenance
Once when the client starts using the developed systems, then the real issues come up
and requirements to be solved from time to time.
This procedure where the care is taken for the developed product is known as
maintenance.
SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project management
that defines the stages include in an information system development project, from an
initial feasibility study to the maintenance of the completed application.

There are different software development life cycle models specify and design, which are
followed during the software development phase. These models are also called
"Software Development Process Models." Each process model follows a series of
phase unique to its type to ensure success in the step of software development.

Here, are some important phases of SDLC life cycle:

Waterfall Model
The waterfall is a universally accepted SDLC model. In this method, the whole process
of software development is divided into various phases.
The waterfall model is a continuous software development model in which development
is seen as flowing steadily downwards (like a waterfall) through the steps of requirements
analysis, design, implementation, testing (validation), integration, and maintenance.
Linear ordering of activities has some significant consequences. First, to identify the end
of a phase and the beginning of the next, some certification techniques have to be
employed at the end of each step. Some verification and validation usually do this mean
that will ensure that the output of the stage is consistent with its input (which is the output
of the previous step), and that the output of the stage is consistent with the overall
requirements of the system.
RAD Model
RAD or Rapid Application Development process is an adoption of the waterfall model; it
targets developing software in a short period. The RAD model is based on the concept
that a better system can be developed in lesser time by using focus groups to gather
system requirements.
o Business Modeling
o Data Modeling
o Process Modeling
o Application Generation
o Testing and Turnover

Spiral Model
The spiral model is a risk-driven process model. This SDLC model helps the group to
adopt elements of one or more process models like a waterfall, incremental, waterfall,
etc. The spiral technique is a combination of rapid prototyping and concurrency in design
and development activities.
Each cycle in the spiral begins with the identification of objectives for that cycle, the
different alternatives that are possible for achieving the goals, and the constraints that
exist. This is the first quadrant of the cycle (upper-left quadrant).
The next step in the cycle is to evaluate these different alternatives based on the
objectives and constraints. The focus of evaluation in this step is based on the risk
perception for the project.
The next step is to develop strategies that solve uncertainties and risks. This step may
involve activities such as benchmarking, simulation, and prototyping.

V-Model
In this type of SDLC model testing and the development, the step is planned in parallel.
So, there are verification phases on the side and the validation phase on the other side.
V-Model joins by Coding phase.

Incremental Model
The incremental model is not a separate model. It is necessarily a series of waterfall
cycles. The requirements are divided into groups at the start of the project. For each
group, the SDLC model is followed to develop software. The SDLC process is repeated,
with each release adding more functionality until all requirements are met. In this method,
each cycle act as the maintenance phase for the previous software release. Modification
to the incremental model allows development cycles to overlap. After that subsequent
cycle may begin before the previous cycle is complete.
Agile Model
Agile methodology is a practice which promotes continues interaction of development and
testing during the SDLC process of any project. In the Agile method, the entire project is
divided into small incremental builds. All of these builds are provided in iterations, and
each iteration lasts from one to three weeks.
Any agile software phase is characterized in a manner that addresses several key
assumptions about the bulk of software projects:
1. It is difficult to think in advance which software requirements will persist and which
will change. It is equally difficult to predict how user priorities will change as the
project proceeds.
2. For many types of software, design and development are interleaved. That is, both
activities should be performed in tandem so that design models are proven as they
are created. It is difficult to think about how much design is necessary before
construction is used to test the configuration.
3. Analysis, design, development, and testing are not as predictable (from a planning
point of view) as we might like.

Iterative Model
It is a particular implementation of a software development life cycle that focuses on an
initial, simplified implementation, which then progressively gains more complexity and a
broader feature set until the final system is complete. In short, iterative development is a
way of breaking down the software development of a large application into smaller pieces.

Big bang model

Big bang model is focusing on all types of resources in software development and coding,
with no or very little planning. The requirements are understood and implemented when
they come.
This model works best for small projects with smaller size development team which are
working together. It is also useful for academic software development projects. It is an
ideal model where requirements are either unknown or final release date is not given.
Prototype Model
The prototyping model starts with the requirements gathering. The developer and the user
meet and define the purpose of the software, identify the needs, etc.
A 'quick design' is then created. This design focuses on those aspects of the software
that will be visible to the user. It then leads to the development of a prototype. The
customer then checks the prototype, and any modifications or changes that are needed
are made to the prototype.
Looping takes place in this step, and better versions of the prototype are created. These
are continuously shown to the user so that any new changes can be updated in the
prototype. This process continue until the customer is satisfied with the system. Once a
user is satisfied, the prototype is converted to the actual system with all considerations
for quality and security.

Requirement Engineering

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analyzing
the need, and assessing feasibility, negotiating a reasonable solution, specifying the
solution clearly, validating the specifications and managing the requirements as they are
transformed into a working system. Thus, requirement engineering is the disciplined
application of proven principles, methods, tools, and notation to describe a proposed
system's intended behavior and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the
software that is acceptable to users, flexible to change and conformable to established
standards.

Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the current technologies,
which are needed to accomplish customer requirements within the time and
budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and
customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified
with the help of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are
analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in
terms of relationships and also resolve conflicts if any.
Problems of Elicitation and Analysis
o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources - the requirement
received by the customer written in ordinary language. It is the job of the analyst to write
the requirement in technical language so that they can be understood and beneficial by
the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.
o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling
the requirements. DFD shows the flow of data through a system. The system may
be a company, an organization, a set of procedures, a computer hardware system,
a software system, or any combination of the preceding. The DFD is also known
as a data flow graph or bubble chart.
 o Data Dictionaries: Data Dictionaries are simply repositories to store information
about all data items defined in DFDs. At the requirements stage, the data dictionary
should at least define customer data items, to ensure that the customer and
developers use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the
entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e.
data entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document
are validated. The user might demand illegal, impossible solution or experts may
misinterpret the needs. Requirements can be the check against the following conditions;
o If they can practically implement
o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the
requirements.
o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the
requirements engineering process and system development.
New requirements emerge during the process as business needs a change, and a better
understanding of the system is developed.
The priority of requirements from different viewpoints changes during development
process.
The business and technical environment of the system changes during the development.
Prerequisite of Software requirements
Collection of software requirements is the basis of the entire software development
project. Hence they should be clear, correct, and well-defined.
A complete Software Requirement Specifications should be:
o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized into two

categories:
1. Functional Requirements: Functional requirements define a function that a
system or system element must be qualified to perform and must be documented
in different forms. The functional requirements are describing the behavior of the
system as it correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the
criteria that can be used to decide the operation instead of specific behaviors of
the system.
3. Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run
time.
o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.