SOFTWARE

PROCESSES
-PART 1
Chapter-3 (Roger Pressman)
Chapter-2 (Ian Sommerville)
CONTENTS
 Software processes
 Process model
 Plan-driven and agile processes
 A generic process model
 Process flow
 Identifying a task set
 Process patterns
 Process improvement
 Standards for process assessment and improvement
SOFTWARE PROCESS
A structured set of activities required to develop a
software system.
 A framework for the activities, actions, and tasks that are required to build high-
quality software.
 Is not equal to software engineering, which also encompasses technologies that populate
the process– technical methods and automated tools
 Many different software processes but all involve:
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the system and
implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer needs.
SOFTWARE PROCESS
DESCRIPTIONS
 When we describe and discuss processes, we usually talk about the activities in
these processes such as specifying a data model, designing a user interface,
etc. and the ordering of these activities.
 Process descriptions may also include:
 Products, which are the outcomes of a process activity;
 Roles, which reflect the responsibilities of the people involved in the
process;
 Pre- and post-conditions, which are statements that are true before and after
a process activity has been enacted or a product produced.
SOFTWARE PROCESS MODEL
 A software process model is an abstract representation of a process.
 It presents a description of a process from some particular perspective.
 It describes the sequence of phases for the entire lifetime of a product.
 Therefore it is sometimes also called Product Life Cycle.

 This covers everything from the initial commercial idea until the final de-
installation or disassembling of the product after its use.
PLAN-DRIVEN AND AGILE
PROCESSES
 Plan-driven processes are processes where all of the process activities are
planned in advance and progress is measured against this plan.
 In agile processes, planning is incremental and it is easier to change the
process to reflect changing customer requirements.
 In practice, most practical processes include elements of both plan-driven and
agile approaches.
 There are no right or wrong software processes.
 WHAT/WHO/WHY IS PROCESS
MODELS?
 What: Go through a series of predictable steps--- a road map that helps you create a timely, high-quality
results.
 Who: Software engineers and their managers, clients also. People adapt the process to their needs and
follow it.
 Why: Provides stability, control, and organization to an activity that can if left uncontrolled, become
quite chaotic. However, modern software engineering approaches must be agile and demand ONLY
those activities, controls and work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the software that you are building. One process
might be good for aircraft avionic system, while an entirely different process would be used for website
creation.
 How to ensure right: A number of software process assessment mechanisms that enable us to determine
the maturity of the software process. However, the quality, timeliness and long-term viability of the
software are the best indicators of the efficacy of the process you use.
A GENERIC PROCESS MODEL
 As we discussed before, 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.
CONTD…
 Communication : This activity involves heavy communication with customers and
other stakeholders in order to gather requirements and other related activities.
 Planning : Here a plan to be followed will be created which will describe the
technical tasks to be conducted, risks, required resources, work schedule etc.
 Modeling : A model will be created to better understand the requirements and design
to achieve these requirements.
 Construction : Here the code will be generated and tested.
 Deployment : Here, a complete or partially complete version of the software is
represented to the customers to evaluate and they give feedbacks based on the
evaluation.
A GENERIC PROCESS
MODEL
 PROCESS FLOW
 A Linear process flow executes
each of the five activities in
sequence.
 An iterative process flow repeats
one or more of the activities before
proceeding to the next.
 CONTD…
 An evolutionary process flow executes the
activities in a circular manner.
 Each circuit leads to a more complete version
of the software.
 A parallel process flow executes one or more
activities in parallel with other activities
( modeling for one aspect of the software in
parallel with construction of another aspect
of the software.
IDENTIFYING A TASK SET
 A task set defines the actual work to be done to accomplish the
objectives of a software engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied
CONTD…
For example, a small software project requested by one person with simple
requirements, the communication activity might encompass little more than a
phone call with the stakeholder. Therefore, the only necessary action is phone
conversation, the work tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval
CONTD…
 The task sets for Requirements gathering action for a simple project may
include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
CONTD…
 The task sets for Requirements gathering action for a big project may include:

1. Make a list of stakeholders for the project.

2. Interview each stakeholders separately to determine overall wants and needs.
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the system.
12. Discuss methods for validating the system.
PROCESS PATTERNS
 A process pattern
 describes a process-related problem that is encountered during
software engineering work,
 identifies the environment in which the problem has been
encountered, and
 suggests one or more proven solutions to the problem.
 Stated in more general terms, a process pattern provides you with a
template [Amb98]—a consistent method for describing problem
solutions within the context of the software process.
CONTD…
 Stage patterns—defines a problem associated with a framework activity
for the process. An example of a stage pattern might be
EstablishingCommunication. This pattern would incorporate the task
pattern RequirementsGathering and others
 Task patterns—defines a problem associated with a software engineering
action or work task and relevant to successful software engineering
practice (e.g., RequirementsGathering is a task pattern).
 Phase patterns—define the sequence of framework activities that occur
with the process, even when the overall flow of activities is iterative in
nature. An example of a phase pattern might be SpiralModel or
Prototyping.
CONTD…
 Template for describing a process pattern:
 Pattern Name:
 The pattern name is given a meaningful name that describe its function within software process.
 Example: Customer-Communication

 Intent:
 The objective of this pattern is describe briefly.
 Example: Intent of the communication customer to connection establish with customer.

 Type:
 The pattern type is specified.
 Three types:
 Task Pattern - action or work task;
 Stage Pattern – frame activity; and
 Phase Pattern – sequence of frame.
CONTD…
 Initial Context:
 Describe which pattern are applies prior to the initialization of the pattern.
1. What organizational or team-related activities have already occurred?
2. What is the entry state for the process?
3. What software engineering information or project information already exists?
For example, the Planning pattern (a stage pattern) requires that
4. customers and software engineers have established a collaborative
communication;
5. successful completion of a number of task patterns [specified] for the
Communication pattern has occurred; and
6. the project scope, basic business requirements, and project constraints are known
CONTD…
 Problem.
 The specific problem to be solved by the pattern.

 Solution.
 Describes how to implement the pattern successfully. This section describes how the initial state of the
process (that exists before the pattern is implemented) is modified as a consequence of the initiation of
the pattern.
 It also describes how software engineering information or project information that is available before
the initiation of the pattern is transformed as a consequence of the successful execution of the pattern.
CONTD…
 Resulting Context:
 The condition that will result once the pattern has been successfully
implementers are describe.
 Upon completion of the pattern:
1. What organizational or team-related activities must have occurred?
2. What is the exit state for the process?
3. What software engineering information or project information has been
developed?
CONTD…
 Related Pattern:
 A list of process pattern that are directly related to this one are provided as a
hierarchy on in some other diagrammatic form.
 For example, the stage pattern Communication encompasses the task patterns: ProjectTeam,
CollaborativeGuidelines, ScopeIsolation, RequirementsGathering, ConstraintDescription, and
ScenarioCreation.

 Known Uses and Examples:

 Indicate the specific instances in which the pattern is applicable.
 For example, Communication is mandatory at the beginning of every software project, is
recommended throughout the software project, and is mandatory once the deployment activity is
under way.
PROCESS IMPROVEMENT
 Many software companies have turned to software process improvement as a way of
enhancing the quality of their software, reducing costs or accelerating their development
processes.
 Process improvement means understanding existing processes and changing these processes to
increase product quality and/or reduce costs and development time.

Chapter 2 Software Processes 30/10/2014 25

APPROACHES TO
IMPROVEMENT
The process maturity approach, which focuses on improving process and
project management and introducing good software engineering practice.
 The level of process maturity reflects the extent to which good technical and
management practice has been adopted in organizational software
development processes.
 The agile approach, which focuses on iterative development and the reduction
of overheads in the software process.
 The primary characteristics of agile methods are rapid delivery of
functionality and responsiveness to changing customer requirements.

Chapter 2 Software Processes 30/10/2014 26

THE PROCESS IMPROVEMENT
CYCLE

Chapter 2 Software Processes 30/10/2014 27

PROCESS IMPROVEMENT
ACTIVITIES
 Process measurement
 You measure one or more attributes of the software process or product. These measurements forms a
baseline that helps you decide if process improvements have been effective.
 Process analysis
 The current process is assessed, and process weaknesses and bottlenecks are identified. Process
models (sometimes called process maps) that describe the process may be developed.
 Process change
 Process changes are proposed to address some of the identified process weaknesses. These are
introduced and the cycle resumes to collect data about the effectiveness of the changes.

Chapter 2 Software Processes 30/10/2014 28

PROCESS MEASUREMENT
 Wherever possible, quantitative process data should be collected
 However, where organisations do not have clearly defined process standards this is very
difficult as you don’t know what to measure.
 A process may have to be defined before any measurement is possible.

 Process measurements should be used to assess process improvements

 But this does not mean that measurements should drive the improvements.
 The improvement driver should be the organizational objectives.

Chapter 2 Software Processes 30/10/2014 29

PROCESS METRICS
 Time taken for process activities to be completed
 E.g. Calendar time or effort to complete an activity or process.
 Resources required for processes or activities
 E.g. Total effort in person-days.
 Number of occurrences of a particular event
 E.g. Number of defects discovered.

Chapter 2 Software Processes 30/10/2014 30

CAPABILITY MATURITY
LEVELS

Chapter 2 Software Processes 30/10/2014 31

THE SEI CAPABILITY
MATURITY MODEL
 Initial
 Essentially uncontrolled
 Repeatable
 Product management procedures defined and used
 Defined
 Process management procedures and strategies defined and used
 Managed
 Quality management strategies defined and used
 Optimising
 Process improvement strategies defined and used

Chapter 2 Software Processes 30/10/2014 32

PROCESS ASSESSMENT AND
IMPROVEMENT
 Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five
step process assessment model that incorporates five phases: initiating, diagnosing, establishing,
acting and learning.
 CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a
diagnostic technique for assessing the relative maturity of a software organization; uses
the SEI CMM as the basis for the assessment [Dun01]
 SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process. [ISO08]

 ISO 9001:2000 for Software—a generic standard that applies to any organization that
wants to improve the overall quality of the products, systems, or services that it provides.
Therefore, the standard is directly applicable to software organizations and companies.
[Ant06]
PRESCRIPTIVE PROCESS
MODELS
 Prescriptive process models advocate an orderly approach to software
engineering
That leads to a few questions …
 If prescriptive process models strive for structure and order, are they
inappropriate for a software world that thrives on change?
 Yet, if we reject traditional process models (and the order they imply) and
replace them with something less structured, do we make it impossible to
achieve coordination and coherence in software work?
WATERFALL MODEL
CONTD…
 The first published model of the software development process was derived
from more general system engineering processes (Royce, 1970).
 This model is known as the ‘waterfall model’ or software life cycle
 The waterfall model This takes the fundamental process activities of
specification, development, validation, and evolution and represents them as
separate process phases such as requirements specification, software design,
implementation, testing, and so on.
CONTD…
 Problems:
 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.
 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.
 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
CONTD…
 Problems:
 Rarely linear, iteration needed.
 Hard to state all requirements explicitly. Blocking state.
 Code will not be released until very late.

 Waterfall Model Application

 Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.