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.

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.

3
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).

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.

4
 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
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.

5
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

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.

6
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.

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.

7
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

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

8
  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

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

9
  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
 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

Extreme Programming (XP) is a software development methodology which is intended

to improve software quality, productivity and responsiveness to changing customer
requirements. As a type of agile software development, it advocates frequent "releases"
in short development cycles (time boxing).

Other elements of extreme programming include:

 programming in pairs,
 doing extensive code review,
 unit testing of all code,
 avoiding programming of features until they are actually needed, a flat
management structure ,
 simplicity and clarity in code,
 expecting changes in the customer's requirements as time passes and
 frequent communication with the customer and among programmers

10
In XP, user requirements are expressed as scenarios or user stories.
These are written on cards and the development team break them down into
implementation tasks.
The customer chooses the stories for inclusion in the next release based on their
priorities and the schedule estimates.
In XP, programmers work in pairs, sitting together to develop code.
 This helps develop common ownership of code and spreads knowledge across
the team.
 It serves as an informal review process as each line of code is looked at by more
than 1 person.
 It encourages refactoring as the whole team can benefit from this.

Scrum
This is an iterative, incremental framework for project management often seen in agile
software development It defines a set of activities that can help your team deliver more
value to your customers faster. These activities provide your customers with the
opportunity to review, guide and influence your team's work as it progresses. This
approach does not attempt to define everything at the start of a project. Instead, your
team works in short iterations (also called sprints) and refines the plan as the team
makes progress.

Adaptive Software Development (ASD)

ASD is a software development process that grew out of rapid application development
work by Jim Highsmith and Sam Bayer
ASD replaces the traditional waterfall cycle with a repeating series of speculate,
collaborate, and learn cycles.
The characteristics of an ASD life cycle are that it is
 mission focused,
 feature based,

11
  iterative,
 time boxed,
 risk driven, and
 change tolerant.

Adaptive Software Development Cycle

Speculation- During this phase coders attempt to understand the exact nature of the
software and the requirements of the users. This phase relies on bug and user reports to
guide the project.
Collaboration phase is when the individual developers solidify what they are each
doing and how to combine their portions. This phase is generally completely in-house.
Learning cycles results in releasing the newest version of the software to users. Either
they can accept it without any modifications or wants some change.

Feature-driven development (FDD)

FDD is an iterative and incremental software development process.
A feature is a small, client-valued function. For example, “Calculate the total of a sale”,
“Validate the password of a user”.
Features are to FDD as user stories are to XP – they‟re a primary source of requirements
and the primary input into your planning efforts.
The Activities of FDD are
 Develop Overall Model
 Build Feature List
 Plan By Feature
 Design By Feature
 Build By Feature

Develop Overall Model

The project starts with a high-level walkthrough of the scope of the system and its
context. Next, detailed domain walkthroughs are held for each modeling area.

Build Feature List

The knowledge that is gathered during the initial modeling is used to identify a list of
features. This is done by functionally decomposing the domain into subject areas.
Subject areas each contain business activities, the steps within each business activity
form the categorized feature list.
Features should not take more than two weeks to complete, else they should be broken
down into smaller pieces.

Plan By Feature
Now that the feature list is complete, the next step is to produce the development plan.
Class ownership is done by ordering and assigning features as classes to programmers.

12
Design By Feature
A design package is produced for each feature. A chief programmer selects a small
group of features that are to be developed within two weeks. Together with the
corresponding class owners, the chief programmer works out detailed sequence
diagrams for each feature and refines the overall model followed by design inspection.

Build By Feature
After a successful design inspection, a client-valued function (feature) is being
produced. The class owners develop the actual code for their classes. After a unit test
and a successful code inspection, the completed feature is promoted to the main build.

Practices in FDD
 Domain Object Modeling
 Developing by Feature
 Individual Class Ownership
 Feature Teams
 Inspection
 Configuration Management
 Regular Builds
 Visibility of Progress and Results

Lean software development

Lean software development is a translation of Lean manufacturing and Lean IT
principles and practices to the software development domain. Adapted from the Toyota
Production System.
Lean is an Agile methodology which can also be seen as a philosophy

13
The core idea is to maximize customer value while minimizing waste. Simply, lean
means creating more value for customers with fewer resources.

Lean principles
 Eliminating Waste
 Amplify Learning
 Decide as late as possible
 Deliver as fast as possible
 Empower the Team
 Build Integrity in
 See the Whole

14