Chapter 2: Process and Methodology

Key Takeaway Points

• A software process defines the phases of
activities or what need to be performed to
construct a software system.
• A software methodology details the steps or
how to perform the activities of a software
process. A methodology is an implementation
of a process.
• Software development needs a software
process and a methodology.

2-2
 Challenges of System Development
Project Reality 1. Many systems require many years to develop.
Project Challenge 1. How do we schedule, and manage the work
without knowing exactly what the customer wants, and what
may happen in the future?
Project Reality 2. Many software projects require collaboration
of multiple departments and teams.
Project Challenge 2. How do we divide the work among the
departments and teams, and integrate the components
produced by them?
Project Reality 3. Different departments or teams may use
different processes, methods, and tools. They may reside at
different locations.
Project Challenge 3. How do we ensure proper communication
and coordination among the departments and teams?
2-3
 Challenges of Systems Development
System Reality 1. Many systems need to satisfy numerous
requirements and constraints.
System Challenge 1. How do we develop systems to ensure that
the requirements and constraints are met?
System Reality 2. Requirements and constraints may change
from time to time.
System Challenge 2. How do we design the processes and the
products to cope with change?
System Reality 3. A system may consist of hardware, software
and third party components using different programming
languages and run on multiple platforms and machines located
at different places.
System Challenge 3. How do we design the system to hide these
differences?
2-4
 Software Process
System development challenges call for an engineering
approach for software development. A software
process is required.

Definition 2.1 A software process defines a

series of activities performed to construct a
software system. Each activity produces some
artifacts, which are the input to other phases.
Each phase has a set of entrance criteria and a
set of exit criteria.
2-5
The Waterfall Process
System Engineering

Software Requirements Analysis

Software Design

Coding & Unit Testing

Integration & Integration Testing

Acceptance Testing

Maintenance
2-6
 Merits of the Waterfall Model
• The simple, straight sequence of phases of the
waterfall simplifies project management.
• It supports function-oriented project
organization:
– Each project is carried out by a pipeline of
functional teams.
– Each functional team is specialized in one function
such as requirements analysis, design,
implementation, integration and testing, and so
forth.

2-7
 Problems of the Waterfall Model
• It is inflexible to requirements change.
• The long development duration means the
system is outdated when it is delivered.
• Users cannot experiment with the system to
provide early feedback.
• The customer has to wait until the entire
system is implemented and deployed to reap
the benefits.
• The customer may lose the entire investment if
the project fails.

2-8
 Properties of a Tame Problem
1) A tame problem can be completely specified.
2) For a tame problem, the specification and the solution can be
separated.
3) For tame problems, there are stopping rules.
4) A solution to a tame problem can be evaluated in terms of
correct or wrong.
5) Each step of the problem-solving process has a finite number
of possible moves.
6) These is a definite chain of cause-effect reasoning.
7) The solution can be tested immediately; once tested, it remains
correct forever.
8) The solution can be adapted for solving similar problems.
9) The solution process is a scientific process.
10) If the problem is not solved, simply try again.
2-9
 Examples of Tame Problem

Operations
Chess playing Math problems research

Many computer science problems

Query
optimization
AI problems
Operating
Compiler systems Why are these tame
construction problems?

2-10
 Software Development Is a Wicked Problem
1) A wicked problem does not have a definite formulation.
2) The specification and solution cannot be separated.
3) There is no stopping rule – you can always do it better.
4) The solutions can only be evaluated in terms of good or bad,
and the judgment is usually subjective.
5) Each step of the problem-solving process has an infinite
number of choices – everything goes as a matter of principle.
6) Cause-effect reasoning is premise-based, leading to varying
actions, but hard to tell which one is the best.
7) The solution is subject to life-long testing.
8) Every wicked problem is unique.
9) The solution process is a political process.
10) The problem-solver has no right to be wrong because the
consequence is disastrous.
2-11
 Examples of Wicked Problem

Urban planning
National policy making

Why are these

wicked problems?

Economic reforms Application software

development

2-12
 Software Process Models
• Prototyping Process Model
• Evolutionary Process Model
• Spiral Process Model
• Unified Process Model
• Personal Software Process Model
• Team Software Process Model
• Agile Process Models

2-13
 Prototyping Process Model
• Prototypes of the software system are
constructed to:
– acquire and validate requirements
– assess the feasibility of the project and/or the
feasibility of the requirements and constraints
• Simple prototypes as well as sophisticated
prototypes are used, depending on the needs of
the project.
• Prototypes are classified into throwaway
prototypes and evolutionary prototypes.
2-14
 Evolutionary Prototyping Model
• Throwaway prototypes waste time and effort.
• Evolutionary prototyping model lets the
prototype evolve into the production system.
• It is most suited for the development of
exploratory types of systems such as intelligent
systems, research software, and systems that
actively interact with and control the
environment.
• It is not suitable for projects that require a
predictable schedule of progress.

2-15
 Spiral Process Model
If risks remains {
plan next phase (SW)
conduct prototyping }
It begins here.
else if risks resolved {
proceed as waterfall
(SE) }
else if prototype works
& robust {
proceed as
evolutionary model
(NE corner) }

2-16
Rational Unified Process (RUP)

2-17
 Rational Unified Process (RUP)
• Inception consists of the first 1-2 iterations. It
produces a simplified use case model, a tentative
architecture, and a project plan.
• Elaboration consists of the next N iterations. It
produces the architectural design and implements the
most critical use cases.
• Construction, during which remaining use cases are
iteratively implemented and integrated into the
system.
• Transition, during which the system is deployed,
users are trained, and defects are corrected.
2-18
 Personal Software Process Model
• PSP is a comprehensive framework for
training software engineers.
• It consists of scripts, forms, standards and
guidelines used in the training.
• It helps the software engineer identify areas for
improvement.
• It prepares the software engineer to work in a
team project.

2-19
 Personal Software Process Model
• PSP framework consists of a series of
predefined processes:
– PSP0 & PSP0.1. These introduce process
discipline and measurement including baseline,
time recording, defect recording, defect type,
coding standards, and process improvement.
– PSP1 & PSP1.1. These introduce size estimation,
planning and scheduling.
– PSP2 & PSP2.1. These introduce quality
management and design including code review and
design review.
– PSP3.0. It guides component level development.
2-20
Team Software Process

2-21
 Agile Process Models

phases in an iteration

Iterations 2-22
 Process and Methodology
• Methodology is often confused with process.
• A process is a set of inter-related activities to
be carried out to construct something (usually
a system).
• The activities are carried out in phases.
• Each phase produces some products which are
the input of the next phase.
• The completion of each phase establishes a
milestone.
• A methodology implements a process or a
phase of a process.
2-23
 Methodology
• A methodology is a cook-book for performing
a task. It describes
– steps to accomplish a series of subtasks
– input and output of each step
– representations of input and output
– entrance and exit conditions for each step
– procedures for carrying out each step
– methods and techniques used by each step
– relationships, or control flow and data flow
between the steps
2-24
 Process and Methodology
Process Methodology
• Defines a framework of phased • Defines steps to carry out phases
activities of a process
• Specifies phases of WHAT • Describes steps of HOW
• Does not dictate representations • Defines representations of
of artifacts artifacts (e.g., UML)
• It is paradigm-independent • It is paradigm-dependent
• A phase can be realized by • Steps describe procedures,
different methodologies. techniques & guidelines
Examples Examples
Waterfall, spiral, prototyping, Structured analysis/structured
unified, and agile processes design (SA/SD), Object Modeling
Technique (OMT), Scrum,
DSDM, FDD, XP, and Crystal
Orange
2-25
 Software Paradigm
• A software paradigm is a style of software
development that constitutes a way of viewing
the reality.
• Examples:
– procedural paradigm
– OO paradigm, and
– data-oriented paradigm

2-26
 Three Paradigms in History
• Procedural paradigm views the world and system as:
– a network of processes
– a process is refined by lower level processes
– basic building blocks and starting point are processes
• OO paradigm views the world and system as:
– interrelated and interacting objects
– basic building blocks are objects
• Data-oriented paradigm views the world and system
as:
– interrelated data entities, processed by transactions
– basic building blocks are data entities and relationships

2-27
 Paradigm and Methodology
Class - 1 sn
attrib 1 Student
Books attrib 2 sname

orders
Customer Process enroll
invoices Orders Class - 2 Class - 3
(w/books) credit status attrib 1 attrib x
attrib 2
cn
Student
Customers cname

Domain model
Structured Analysis Object-Oriented Analysis Data-Oriented Analysis
Top Manager Obj: class b :Bclass
m1 ( ) m2 ( ) m3 ( )
A Top Decider

BE CF DG info m5 ( ) m4 ( )

B E C F D G m6 ( ) m7 ( ) m8 ( )

H m10 ( ) m9 ( )
Sequence diagram
Structured Design Object-Oriented Design Data-Oriented Design
Structured Object-Oriented Programming in
Programming Programming 4GL (e.g., SQL)
Procedural Paradigm OO Paradigm Data-Oriented Paradigm
2-28
 Some Well-Known Agile Methods
• Dynamic Systems Development Method
(DSDM)
• Feature Driven Development (FDD)
• Scrum
• Extreme Programming (XP)
• Crystal Clear
• Lean Development

2-29
 DSDM Unique Key Features
• It is a framework that works with Rational
Unified Process and XP.
• It is based on the 80-20 principle.
• It is suitable for agile as well as plan-driven
projects.

2-30
 DSDM Lifecycle Activities

Feasibility
Study

Business Study

Agree schedule User approval &

user guidelines
Create Identify Assess
functional Functional functional business Train
Implemen-
prototype model iteration prototype impact users
tation

Review prototype Deploy system

Review prototype
Identify Create
design Design & build design
prototype iteration prototype

Agree schedule

2-31
 Feature Driven Development (FDD)
• Unique key features:
– feature driven and model driven
– configuration management, review and inspection,
and regular builds
– suitable for agile or plan-driven projects

2-32
 FDD Lifecycle Activities
• system walkthrough
1.Develop • develop group models
an Overall class diagram
• derive overall model from group models
Model
• produce model description

• identify business activities to be automated

2.Build a • identify features of business activities
Feature List
feature list
• schedule development of activities
• assign activities to chief schedule &
3.Plan By
programmers assignments
Feature
• assign classes to team members

• produce sequence diagrams to show structureal

object interaction using features 4.Design & behavioral
• encapsulate features to form classes By Feature diagrams

• implement the classes 5.Build By

Feature
Deployment
2-33
 Scrum
• Unique key features:
– include Scrum Master, Product Owner, and Team
roles
– 15 minute daily status meeting to improve
communication
– team retrospect to improve process

2-34
 Scrum Lifecycle Activities
• Release planning meeting
– identify and prioritize requirements, called product backlog
– identify top priority requirements to be delivered within an
increment, called a sprint
– identify sprint development activities
• Sprint iteration
– sprint planning meeting to determine what and how to build
next
– daily Scrum meeting to exchange status
• Sprint review meeting
– increment demo
– team retrospection
• Deployment

2-35
 Scrum Process

Daily
Scrum
Meeting

Release Planning Sprint Planning

2-4 Weeks Sprint Retrospection

Potentially
Shippable
Product
Increment
Product Sprint
Backlog Backlog

2-36
 Extreme Programming (XP)
• Unique Key Features:
– Anyone can change any code anywhere at any time
– Integration and build many times a day whenever a
task is completed
– Work ≤ 40 hours a week

2-37
 XP Lifecycle Activities
1. Collect information about the application
Exploration
2. Conduct feasibility study

1. Determine the stories for the next release

Planning
2. Plan for the next release

1. Define/modify architecture
Iteration to 1st Release 2. Select and implement stories for each iteration
3. Perform functional tests by customer

1. Evaluate and improve system performance

Productionizing
2. Certify and test system for production use

1. Improve the current release

Maintenance
2. Repeat process with each new release

1. Produce system documentation if project

Death
is done, or
2. Replace system if maintenance is too costly
2-38
 The Methodology Presented in This Book
• It is designed for beginners as well as seasoned
developers.
• It is aimed at educating software architects and
systems analysts.
• It can be applied to agile as well as plan-driven
projects. It has been applied to sponsored as well as
industrial projects.
• Team members should work together from project
start to completion.
• Many students continue practicing the methodology
after graduation.
2-39
Methodology Overview – Planning Phase
Business goals & needs
Current situation
Acquiring Requirements &
Domain Modeling
Requirements
Deriving Use Cases
from Requirements
Abstract & high level use cases,
use case diagrams

Allocating Use Cases &

to Iterations
Use case-iteration allocation matrix
Producing an
Architecture Design
Software architecture
2-40
Methodology Overview – Iterative Phase
Software architecture Use case-iteration allocation matrix
Accommodating
Requirements Change
Iteration use cases
Domain Modeling
Domain model
Actor-System Interaction Domain model
Modeling & UI Design
Expanded use cases & UI design

Behavioral Design
Behavior diagrams
Deriving Design Class Diagram
Design class diagram
TDD, Integration, & Deployment
2-41