Software Process:

A software process (also known as software methodology) is a set of related activities that leads
to the production of the software. These activities may involve the development of the software
from the scratch, or, modifying an existing system.

Any software process must include the following four activities:

 Software specification (or requirements engineering): The main purpose of this part is to
know main functionalities of software and constraints.
 Software design and implementation: This part is for designing and programming
purpose.
 Software verification and validation: This part is to conform to its specs and fulfill
customer needs.
 Software evolution (software maintenance): This part is responsible for modification in
software to meet customer and markets requirement.

Software Process Models:

A software process model is a simplified representation of a software process. Each model
represents a process from a specific perspective. We’re going to take a quick glance about very
general process models. These generic models are abstractions of the process that can be used to
explain different approaches to the software development. They can be adapted and extended to
create more specific processes.

Stages Involve:
Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. Each phase produces deliverables required by the next phase in the life
cycle. Requirements are translated into design. Code is produced according to the design which
is called development phase. After coding and development, the testing verifies the deliverable
of the implementation phase against requirements. The testing team follows Software Testing
Life Cycle (STLC) which is similar to the development cycle followed by the development team.

There are following six phases in every Software development life cycle model:

 Requirement gathering and analysis

Business requirements are gathered in this phase. This phase is the main focus of the
project managers and stake holders. Meetings with managers, stake holders and users are
held in order to determine the requirements like; Who is going to use the system? How
will they use the system? What data should be input into the system? What data should be
output by the system? These are general questions that get answered during a requirement
gathering phase. After requirement gathering these requirements are analyzed for their
validity and the possibility of incorporating the requirements in the system to be
 development is also studied. Finally, a Requirement Specification document is created
which serves the purpose of guideline for the next phase of the model. The testing team
follows the Software Testing Life Cycle and starts the Test Planning phase after the
requirements analysis is completed.

 Design
In this phase the system and software design is prepared from the requirement
specifications which were studied in the first phase. System Design helps in specifying
hardware and system requirements and also helps in defining overall system architecture.
The system design specifications serve as input for the next phase of the model.
In this phase the testers come up with the Test strategy, where they mention what to test,
1
how to test.

 Implementation or coding
On receiving system design documents, the work is divided in modules/units and actual
coding is started. Since, in this phase the code is produced so it is the main focus for the
developer. This is the longest phase of the software development life cycle.
 Testing
 After the code is developed it is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements
phase. During this phase all types of functional testing like unit testing, integration
testing, system testing, acceptance testing are done as well as non-functional testing are
also done.
 Deployment

 After successful testing the product is delivered / deployed to the customer for their use.
As soon as the product is given to the customers, they will first do the beta testing. If any
changes are required or if any bugs are caught, then they will report it to the engineering
team. Once those changes are made or the bugs are fixed then the final deployment will
happen.

 Maintenance:
Once when the customers start using the developed system then the actual problems
come up and needs to be solved from time to time. This process where the care is taken
for the developed product is known as maintenance.
Agile Process Models:
Agile approaches to software development consider design and implementation to be the central
activities in the software process. They incorporate other activities, such as requirements
elicitation ‫توضيح‬/‫ استنباط‬and testing, into design and implementation
Plan Driven Model:
A plan-driven approach to software engineering identifies separate stages in the software process
with outputs associated with each stage. The outputs from one stage are used as a basis for
planning the following process activity

1
Different Software Process Models:

Waterfall Model
The waterfall model is a sequential approach, where each fundamental activity of a process
represented as a separate phase, arranged in linear order. In the waterfall model, you must plan
and schedule all of the activities before starting working on them (plan-driven process). The
phases of the waterfall model are: 

 Requirements
 Design
 Implementation
 Testing
 Maintenance.

Prototyping:
A prototype is a version of a system or part of the system that’s developed quickly to check the
customer’s requirements or feasibility of some design decisions.
So, a prototype is useful when a customer or developer is not sure of the requirements, or of
algorithms, efficiency, business rules, response time, etc.
In prototyping, the client is involved throughout the development process, which increases the
likelihood of client acceptance of the final implementation.
While some prototypes are developed with the expectation that they will be discarded, it is
possible in some cases to evolve from prototype to working system.
The phases of a prototype are:

1. Establish objectives: The objectives of the prototype should be made explicit from the
start of the process. Is it to validate system requirements, or demonstrate feasibility, etc.

2. Define prototype functionality: Decide what are the inputs and the expected output from
a prototype. To reduce the prototyping costs and accelerate the delivery schedule, you may
ignore some functionality, such as response time and memory utilization unless they are
relevant to the objective of the prototype.
 3. Develop the prototype: The initial prototype is developed that includes only user
interfaces.

4. Evaluate the prototype: Once the users are trained to use the prototype, they then
discover requirements errors. Using the feedback both the specifications and the prototype
can be improved. If changes are introduced, then a repeat of steps 3 and 4 may be needed.

Incremental Development:
Incremental development is based on the idea of developing an initial implementation, exposing
this to user feedback, and evolving it through several versions until an acceptable system has been
developed. The activities of a process are not separated but interleaved with feedback involved
across those activities. Each system increment reflects a piece of the functionality that is needed
by the customer. Generally, the early increments of the system should include the most important
or most urgently required functionality. This means that the customer can evaluate the system at
early stage in the development to see if it delivers what’s required. If not, then only the current
increment has to be changed and, possibly, new functionality defined for later increments.

Incremental Phases Activities performed in incremental phases

Requirement Analysis Requirement and specification of the software are

collected

Design Some high-end function are designed during this stage

Code Coding of software is done during this stage

Test Once the system is deployed, it goes through the testing

phase
Spiral Model:
The spiral model is a risk-driven where the process is represented as spiral rather than a sequence
of activities. It was designed to include the best features from the waterfall and prototyping
models, and introduces a new component; risk-assessment.

Each loop (from review till service —  see figure below) in the spiral represents a phase. Thus the
first loop might be concerned with system feasibility, the next loop might be concerned with the
requirements definition, the next loop with system design, and so on.
Each loop in the spiral is split into four sectors:

 Objective setting: The objectives and risks for that phase of the project are defined.
 Risk assessment and reduction: For each of the identified project risks, a detailed
analysis is conducted, and steps are taken to reduce the risk. For example, if there’s a risk
that the requirements are inappropriate, a prototype may be developed.
 Development and validation: After risk evaluation, a process model for the system is
chosen. So if the risk is expected in the user interface then we must prototype the user
interface. If the risk is in the development process itself then use the waterfall model.
 Planning: The project is reviewed and a decision is made whether to continue with a
further loop or not.
Reuse-oriented Software Engineering:
It’s attempting to reuse an existing design or code (probably also tested) that’s similar to what’s
required. It’s then modified, and incorporated to the new system.
Although the initial “requirements specification” phase and the “validation” phase are comparable
with other software processes, the intermediate phases in a reuse-oriented process are different.
These phases are:

1. Component analysis: A search is made for the components to implement the given
requirements specification. Usually, there’s no exact match, and components may be only
providing some of the functionality required.
2. Requirements modification: During this phase, the requirements are analyzed using
information about the components that have been discovered. They are then modified to
reflect the available components. If the modifications are impossible, the component
analysis activity may be re-entered to search for alternative solutions.
3. System design with reuse: During this phase, the framework of the system is designed or
an existing framework is reused. The designers take into account the components that are
reused and they will organize the framework accordingly. Some new software has to be
designed if some reusable components are not available.
4. Development and integration: The components are integrated to create the new system.
System integration, in this model, may be part of the development process rather than a
separate activity.
 Extreme Programming Model:
Extreme Programming is a software development methodology designed to improve the quality
of software and its ability to properly adapt to the changing needs of the customer or client.
Extreme Programming aims to provide iterative and frequent small releases throughout the
project, allowing both team members and customers to examine and review the project’s
progress throughout the entire SDLC. Following are the Stages of Extreme Programming Model:

Planning Managing Designing

 User stories are written.  Give the team a dedicated open  Simplicity.
 Release planning creates work space.  Choose a system metaphor.
the release schedule.  Set a sustainable pace.  Use CRC cards for design
 Make frequent small  A stand-up meeting starts each sessions.
releases. day.  Create spike solutions to reduce
 The project is divided into  The Project Velocity is risk.
iterations. measured.  No functionality is added early.
 Iteration planning starts  Move people around.  Refactor whenever and
each iteration.  Fix Extreme Programming wherever possible.
2
when it breaks.

Coding Testing
 The customer is always available.  All code must have unit tests.
 Code must be written to agreed standards.  All code must pass all unit tests before it can be
 Code the unit test first. released.
 All production code is pair programmed.  When a bug is found tests are created.
 Only one pair integrates code at a time.  Acceptance tests are run often and the score is
 Integrate often. published.