THE SOFTWARE PROCESS

A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created. An activity strives to achieve a broad objective (e.g.,
communication with stakeholders) and is applied regardless of the application domain,
size of the project, complexity of the effort, or degree of rigor with which software
engineering is to be applied. An action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an architectural design model). A task
focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces
a tangible outcome.

In the context of software engineering, a process is not a rigid prescription for how to
build computer software. Rather, it is an adaptable approach that enables the people
doing the work (the software team) to pick and choose the appropriate set of work
actions and tasks. The intent is always to deliver software in a timely manner and with
sufficient quality to satisfy those who have sponsored its creation and those who will
use it.

A process framework establishes the foundation for a complete software engineering

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. A generic process framework for software engineering encompasses
five activities:

Communication. Before any technical work can commence, it is critically important to

communicate and collaborate with the customer (and other stakeholders). The intent is
to understand stakeholders’ objectives for the project and to gather requirements that
help define software features and functions.

Planning. Any complicated journey can be simplified if a map exists. A software project
is a complicated journey, and the planning activity creates a “map” that helps guide the
team as it makes the journey. The map—called a

software project plan—defines the software engineering work by describing

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.

1
Modeling. A model is a simplification of the reality
We build models to:
 communicate the desired structure and behavior of a system
 visualize and control the system’s architecture
 better understand the system, to exposing opportunities for simplifications and
reuse
 manage risks

Construction. This activity combines code generation (either manual or automated) and
the testing that is required to uncover errors in the code.

Deployment. The software (as a complete entity or as a partially completed increment)

is delivered to the customer who evaluates the delivered product and provides
feedback based on the evaluation.

For many software projects, framework activities are applied iteratively as a project
progresses. That is, communication, planning, modeling, construction, and
deployment are applied repeatedly through a number of project iterations.

Each project iteration produces a software increment that provides stakeholders with a
subset of overall software features and functionality. As each increment is produced,
the software becomes more and more complete.

Software engineering process framework activities are complemented by a number of

umbrella activities. In general, umbrella activities are applied throughout a software
project and help a software team manage and control progress, quality, change, and
risk. Typical umbrella activities include:

Software project tracking and control—allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.

Risk management—assesses risks that may affect the outcome of the project or the
quality of the product.

Software quality assurance—defines and conducts the activities required to ensure

software quality.

2
Technical reviews—assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next activity.

Measurement—defines and collects process, project, and product measures that assist
the team in delivering software that meets stakeholders’ needs; can be used in
conjunction with all other framework and umbrella activities.

Software configuration management—manages the effects of change throughout the

software process.

Reusability management—defines criteria for work product reuse (including software

components) and establishes mechanisms to achieve reusable components.

Work product preparation and production—encompasses the activities required

tocreate work products such as models, documents, logs, forms, and lists.

SOFTWARE PROCESS
A software process defines the approach that is taken as software is engineered.
software engineering also encompasses technologies that populate the process technical
methods and automated tools.

Some of the activities of software product include:

SW Process Activity What is going on there?

What does the customer need?

Specification
What are the constraints?

Development Design & programming.

Validation Checking whether it meets requirements.

Evolution Modifications (e.g. customer/market).

3
Description of the software process that represents one view, such as the activities,
data or roles of people involved.

Examples of views Focus on…

Activities = human actions.

Workflow
What is input, output, and dependencies.

Activities = transformations of information.

Dataflow
How the input is transformed into output.

Role/Action What is the role of people involved in each step of the process?

A GENERIC PROCESS MODEL

A generic process framework for software engineering defines five framework
activities—communication, planning, modeling, construction, and deployment. In
addition, a set of umbrella activities—project tracking and control, risk management,
quality assurance, configuration management, technical reviews, and others—are
applied throughout the process.

Important aspect in software process is process flow—describes how the framework

activities and the actions and tasks that occur within each framework activity are
organized with respect to sequence and time

A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment.

An iterative process flow repeats one or more of the activities before proceeding to the
Next.

An evolutionary process flow executes the activities in a “circular” manner. Each circuit
through the five activities leads to a more complete version of the software.

A parallel process flow executes one or more activities in parallel with other activities
(e.g., modeling for one aspect of the software might be executed in parallel with
construction of another aspect of the software).

4
TYPES OF SOFTWARE PROCESS/MODELS

GENERIC/PRESCRIPTIVE PROCESS MODELS

Prescriptive process models are sometimes referred to as “traditional” process models.
Prescriptive process models were originally proposed to bring order to the chaos of
software development. History has indicated that these traditional models have
brought a certain amount of useful structure to software engineering work and
have provided a reasonably effective road map for software teams. However, software
engineering work and the product that it produces remain on “the edge of chaos.”

The Waterfall Model

The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification
of requirements and progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed software.

The waterfall model is the oldest paradigm for software engineering. However, over the
past three decades, criticism of this process model has caused even ardent supporters to
question its efficacy. 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 indirectly. 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(s) will not
be available until late in the project time span. A major blunder, if undetected
until the working program is reviewed, can be disastrous.

Incremental Process Models

The incremental model combines elements of linear and parallel process flows, the
incremental model applies linear sequences in a staggered fashion as calendar time
progresses. Each linear sequence produces deliverable “increments” of the software in a

5
manner that is similar to the increments produced by an evolutionary process flow.

When an incremental model is used, the first increment is often a core product. That is,
basic requirements are addressed but many supplementary features (some known,
others unknown) remain undelivered. The core product is used by the customer (or
undergoes detailed evaluation). As a result of use and/or evaluation, plan is developed
for the next increment. The plan addresses the modification of the
core product to better meet the needs of the customer and the delivery of additional
features and functionality. This process is repeated following the delivery of each
increment, until the complete product is produced.

The incremental process model focuses on the delivery of an operational product with
each increment. Early increments are stripped-down versions of the final product, but
they do provide capability that serves the user and also provide a platform for
evaluation by the user.

Evolutionary Process Models

Evolutionary process models produce an increasingly more complete version of the
software with each iteration. Evolutionary models are iterative. They are characterized
in a manner that enables you to develop increasingly more complete versions of the
software.

 Resembles iterative enhancement model

 Does not require a useable product at the end of each cycle
 Requirements are implemented by category rather than by priority
 Used when it is not necessary to provide a minimal version of the system quickly
 Useful for projects using new technology or complex projects

In the paragraphs that follow, two common evolutionary process models.

Prototping
Often, a customer defines a set of general objectives for software but does not identify
detailed input, processing, or output requirements.

In other cases, the developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, or the form that human –machine interaction
should take . In this case prototyping paradigm may offer the best approach

6
Prototype: an initial version of a software system that is used to demonstrate concepts,
try out design options and find out more about the problem and its possible solutions.

Rapid, iterative development of the prototype is essential (to control costs; system
stakeholders can experiment with the prototype early in the software process)
How software prototyping can help:
 Requirements engineering process: elicitation and validation of system
requirements
 System design process: explore particular software solutions; support user
interface design
 Get new ideas for requirements
 Find areas of strength and weakness in the software (to propose new system
requirements)
 May reveal errors and omissions in the requirements
 Carry out design experiments to check the feasibility of a proposed design
 Essential part of the user interface design process (dynamic nature of user
interfaces)

The Spiral Model

Originally proposed by Barry Boehm. The spiral model is an evolutionary software
process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model. It provides the potential for rapid
development of increasingly more complete versions of the software.
 Is a risk-driven software process framework
 Software process is represented as a spiral
 Each loop in the spiral represents a phase of the software process
 It combines change avoidance with change tolerance
 It assumes that changes are a result of project risks and includes explicit risk
management activities to reduce these risks.

Spiral Model

Consist of loops. Each loop is split into four sectors:

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). The following
activities are carried out during each phase of a spiral model.
7
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.
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.
Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the
identified risks.
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.

Spiral Model Advantages

 Focuses attention on reuse options.
 Focuses attention on early error elimination.
 Puts quality objectives up front.
 Integrates development and maintenance.
 Provides a framework for hardware/software Development

8
Weaknesses
 Lack of explicit process guidance in determining objectives, constraints, alternatives
 The risk-driven model is dependent on the developers' ability to identify project risk
 Provides more flexibility than required for many applications

Rapid Application Development (RAD)

Topical in 1990’s after Book Rapid Application Development by Martin, J (1991)
 can utilize a wide range of techniques and tools
 Incremental, plus reliance on many standard modules
 usually very small team.
 emphasis on user involvement and responsibility throughout whole
development

Quality definition in a RAD environment put by James Martin

“meeting the true business (or user) requirements as effectively as possible at the time
the system comes into operation

Radically changes way systems are developed with goals of.

 High quality systems
 fast development and delivery
 low costs High
should go hand in hand when the right tools and techniques are used

RAD Properties
• Must be delivered in 2 - 6 months
• split into increments if too large to enable this
• each increment is implemented separately with frequent delivery of working parts
of system.

RAD - Essentials
Tools
 Code generators, CASE tools, prototyping tools and 4GLs
Methodology
 to use tools as effectively as possible
People
 right skills and talents. Well selected and motivated. End users
Management
 not place obstacles, facilitate fast development
Infrastructure
 In which fast development can take place

9
Advantages
 Quick initial view is possible
 Less development time
 User involvement increases the acceptability

Disadvantages
 User involvement is difficult through out the life cycle
 Difficult to reduce the development time significantly
 Reusable components may not be available
 Availability of highly skilled personnel is difficult
 Not effective if system is not modularized properly

Selection of a Life Cycle Model

 Requirement
 Development Team
 Users
 Project type & Associated Risk

AGILE SOFTWARE DEVELOPMENT

Agile software development is a group of software development methodologies based

on iterative and incremental development, where requirements and solutions evolve
through collaboration between self-organizing, cross-functional teams. It promotes
adaptive planning, evolutionary development and delivery; time boxed iterative
approach and encourages rapid and flexible response to change.

Principles of agile methods:

Customer involvement
 Provide and prioritize new system requirements
 Evaluate the iterations of the system

Incremental delivery
 Customer specifies the requirements to be included in each increment

People not process

 Recognize and exploit the skills of the development team
 Team members should develop their own ways of working without prescriptive
processes

Embrace change

10
  Perspective: system requirements will change overtime
 System design should accommodate these changes

Maintain simplicity
 Simplicity for the software and for the development process
 Actively work to eliminate complexity from the system

Some Agile Methodologies

1. Extreme Programming (XP)
2. Scrum
3. Adaptive Sofotware Process
4. Feature Driven Development
5. Lean Development

11