Intro to Software Processes

Engineering versus Programming

 Engineers follow procedures, methods, standards to
"assure" more predictable results.
 No guarantee of quality.
 Performance and cost are more predictable.
 Measurable.
 Verifiable.
 Repeatable.
How many Programmers
does it take to change a light bulb?
 ?
How many Programmers
does it take to change a light bulb?
 None.
A defective light bulb is a hardware problem.
How many Software Engineers
does it take to change a light bulb?
How many Software Engineers
does it take to change a light bulb?
 Six.
Analyst to write the specification.
Architect to design a light-bulb changing procedure.
Developer to change the light bulb.
Tester to test it.
Documenter to write RUP project reports.
Auditor to verify that the process was followed.
What is a Software Process?

A process is a method for doing or producing something.

A software process is a method for producing software.

"Producing software" includes Managing the project involves

 specification  obtaining resources
 design  measuring
 construction  tracking
 documentation  reviews
 transition  analyzing results and acting

on them
maintenance
 improvement
Do You Have a Process?
Everyone who develops software uses a process.
 Process may not be formal.
 You may even be aware of it (not "defined").
 It changes every time you develop a new application.
Exercise 1
 Identify a process you use repeatedly in your daily life.
 Why do you follow this process?
 Are there any advantages to using a process?
 Have you improved your process?
Exercise 2
 What process "procedures" or "activities" did you use in
your POS project?
Process Disadvantages
• overhead
• diminish sense of spontaneity or creativity
• may be the wrong process for the job

Beginner's mind
初 the beginner's mind sees many
possibilities;
心 the expert's mind sees few or one.
What is the Most Common Software
Process?
What is the Most Common Software
Process?

1. "Code and fix"

2. ad hoc (chaos)

My Software Process
• used since high school (FORTRAN programming)
1. think about the problem
2. start coding
3. as code grows, I realize that I need to restructure parts
of it.
• modify previous code to support new, improved
structure.
• goto step 2.
Do We Need a Formal Process?
Teams can be effective without a formal software
process!
 Teams can have “jack-of-all-trades” programmers
who understand the business of the organization.
 Excellent, motivated developers take initiative and
build the software without consensus or planning.
 A highly capable development manager may be
willing to put in an enormous effort.
 Motivated developers put in extra time to get the
project done.
Problems with an Implicit Process
 What are problems of this approach (implicit process)?
Problems with an Implicit Process
1. Depends a lot on motivated, talented individuals.
 what happens if your best programmer/architect
quits?
2. Not repeatable or predictable.
 if you can't predict how long the next project will take,
then how can you bid (estimate cost)?
3. Stress / burn-out.
 Too much pressure on team.
 Uncertainty and O.T. lead to frustration, burn-out.
 No slack time for HR development.
Another Problem...
1. We learn programming on small projects.
2. We develop an implicit process that works well...
we get "A"s in our courses!
Obviously, we are great "software engineers"!

Problem:
our implicit process doesn't scale to large problems.
Why a Defined Process?
 More Effective
 less time spent on planning, estimates, decisions
 Predictable
 Repeatable (related to predictability)
 Trackable (measuring predictability)
 Maintainability
 Quality
 Capability Improvement
 use what you learn from past experience
Ref: http://www.acm.org/crossroads/xrds6-4/software.html (2000)
Creating a Defined Process
 Meta-thinking
 thinking about what you know / do

 Humans are the only animal that consciously changes

his behavior
 "learn from experience"
 improvement - creative thinking & insight
4 key factors in software development
speed

Key factors that determine how well or quickly you can

design, develop, configure, implement, ... a software
project:
1.
2.
3.
4.
4 key factors in development speed
1. People
– ability, knowledge, skills, motivation
2. Process
– Customer focus
– QA, risk management, lifecycle planning, revision control, ...
3. Product
– Size and characteristics, phasing
4. Technology
– Product or software development environment
– Tools
The Role of Process

People Technology

Methods

The Desired Product

 The Role of Process

People Technology

"the glue that binds

Methods
[guides] people, Process
methods, and
technology to create
a product."

The Desired Product

 The Role of Process (2)

People Technology

Roles: Methods
Task Task

Activities: Analysis Design Implement Test

Use Case
Artifacts: Description ...
Prerequisite...
Main Scenaria
1.....
..... Desired
2.....
3.....
Extensions: ...
Product

Communicate: Measurements, Milestones, Documents

 Object Model of the
Software Life Cycle
Software life cycle

*
Process group

*
Process

*
Phase
*
Work Product

* produces
consumes
Activity Task
*
Resource

Participant

Time

source: Bruegge, OOSE Money

Process Models
 Models to study software processes
 think, analyze
 adapt
 improve
Name some software process models
1.
2.
3.
4.
5.
6.
Classical Process Models
 Waterfall
 Rapid Prototype
 V-Model
 going down V: waterfall
 going up the V: unit test, integration test, V&V,
acceptance test
 See Schach slides for examples
 Spiral Process

Activities are performed

repeatedly.
Each time, new features
are added
Iterative and Incremental
 Unified Software Development Process is the most common
 Rational UP
 OpenUP
 Characteristics
 plan based
 architecture centric
 address risks early
 implement requirements based on priority
 accommodate change
Other "Disciplined" Processes
 Well documented, prescriptive
 Team software process (TSP)
 Personal Software Process (PSP)
 objective is to improve personal productivity through
staged sequence of activities
 measure and analyze: time, defects
 improvement through reflection and planning
 Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.
Agile Process Characteristics
 provide customer "value" at each iteration
 welcome evolving requirements
 working software as primary measure of progress
 lack of up-front architecture design (YAGNI)
 simplicity of design (XP: "do the simplest thing that ...")
 small, self-organizing teams at one site (preferred)
 frequent customer feedback
 shared understanding instead of comprehensive
documents (but they do write docs)
Agile Process Core Practices
 CRACK customer representative onsite
 Collaborate
 Representative
 Authorative
 Committed
 Knowledgeable
 Test-driven development
 write test cases first
 constant verification using automatic testing
Agile Process Core Practices (2)
 running software at each iteration
 frequent face-to-face communications
 competant teams
 reflection on how to be more effective
 well documented, readable code
 (XP) pair programming
 (XP, Scrum) limit or forbid overtime work
12 Principles of Agile Development
 http://agilemanifesto.org/principles.html
Some Agile Processes
 eXtreme Programming
 Kent Beck: Chrysler
 Scrum (called "more a management technique")
 processes as black boxes
 daily stand-up meeting
 Crystal
 a family of methods to address different types of
projects
 Synchronize and Stabilize (Microsoft process)
Scrum
 www.controlchaos.com
 graphic: www.controlchaos.com/about
 audio and video presentation
 interesting "White Papers"
 Ken Schwaber, "Scrum Development Process",
OOPSLA'95.
 the original Scrum article
Scrum articles:
http://www.controlchaos.com/old-site/articles.htm
Scrum
 Easy to add to existing software development process
 Often used as "first step" to test benefits of agile dev't
 Easy to combine with:
 UP, OpenUP
 XP
Software Process Models

General Models for Software Processes

and Process Improvement
Frameworks for Software Processes
There are frameworks for analyzing, evaluating, and
(maybe) improving a software process. Best known:
ISO 12207, Software Life Cycle Processes
IEEE 1074, Standard for Software Life Cycle Processes
IEEE Std 1074: Standard for
Software Lifecycle
Process Group
IEEE
IEEEStd
Std1074
1074

Pre- Develop- Post- Cross-

Cross-
Project
Project Pre- Develop- Post-
Development ment Development Development
Development
Management
Management Development ment Development (Integral
(IntegralProcesses)
Processes)
> Project Initiation > Concept > Requirements > Installation >V&V
>Project Monitoring Exploration Analysis > Operation & > Configuration
&Control > System > Design Support Management
> Software Quality Allocation > Implemen- > Maintenance > Documen-
Management tation > Retirement tation
> Training

source: Bruegge, OOSE

Processes
IEEE 1074
 IEEE Standard for Developing a Software Project Life
Cycle Process

Software Project Life Cycle Model

Software Process
Architect Select SPLCM

Select activities OPAs

uses
incorporates

Software Project Life Cycle

IEEE 1074 Activity Groups (1)
1. Management Activities
 Project Initiation
 Project Planning
 Project Monitoring and Control
2. Pre-Development
 Concept Exploration
 System Allocation (Architecture Design)
 Software Importation
IEEE 1074 Activity Groups (2)
3. Development
 Software Requirements
 Design
 Implementation
4. Post-Development
 Installation
 Operation and Support
 Maintenance
 Retirement
IEEE 1074 Activity Groups (3)
5. Support
 Evaluation
 Software Configuration Management
 Documentation Development
 Training
 Milestone
A scheduled event used to measure progress.
A milestone should be an event with "success" criteria that can be
objectively evaluated.

Milestone
Elicit Analyze Write
Review &
Activities: Requireme Requirem Specificatio
Approval
nts ents n

Baseline
Specifica
tion
Artifacts
 Final Deliverables
 What should we have when we’re finished? (not
“what code should we write”)
 Interim Deliverables
 What do we need to get the job done?
 Internal vs. External Artifacts
 Key Artifacts

Interim Final
 Requirements  Code Libraries
 Analysis & Design Models  API Documents
 Plan Documents  Executables
 Test Plans, Procedures,  User Documents
Results
 Meeting Minutes
 Release Notes
 Demo Builds
 Delivery Bundle
 Install Documents
 Process Essentials

The following slides are from

CMU 11-791 Software Engineering and IT
 Key Process Concepts

 Test Infrastructure Early  Incremental Approach

 Reduce Technical Risk  Synchronize & Stabilize
 Reduce Schedule Risk  Code Reviews
 Team for Success  Use Bug Tracking
 Effective Meetings  Use Version Control
 Keep Models Updated
Test Infrastructure Early
 Example: “Which web app framework should I use?”
 Different costs & tradeoffs
 Training, documentation
 Ease of use, stability
 Platform issues, bugs, performance

If there is more than one technology choice for your

infrastructure, a skilled subteam should test or
prototype to enable a clear decision
Reduce Technical Risk
 Examples:
 Adopting very new technology
 Novel first use of technology
 No “safer” alternative

Perform a feasibility study (or “proof of concept”)

which demonstrates that the new technology will
work for the function you intend to implement,
on the platform you wish use
Reduce Schedule Risk
 Examples:
 Low confidence in estimates
 No data for approach / technology
 Large-scale tasks
 content creation, test data creation, knowledge / rule
development, etc.
Gather data on a sample task, extrapolate
Consider automation, tools
Create contingency plan
Team for Success
 Leverage skills of team members
 Training / examples for others
 Mentoring, subgroups
 Infrastructure development / support
 “Inviting commitment” vs. “Unilateral task assignment”
 Frequent post-mortems, process adjustments
whenever necessary
Run Effective Meetings
 Agenda
 Review action items from last meeting
 Discuss new issues (elicit in meeting, too)
 Assign new action items
 Schedule next meeting
 Minutes
 Document attendance (note latecomers)
Send an email update if you can’t attend!
 Document progress on old action items
 Document decisions and pending issues
 Document new action items
 Email to all members
Effective Meetings [2]
 Meeting Roles
 Moderator
 Run the agenda, keep discussion focused and concise
 Make sure all voices are heard
 Tangents noted for later, or saved for a sub-meeting
 Scribe
 Responsible for meeting minutes
 Timekeeper
 Meeting roles should rotate among team members
(week to week, phase to phase)
Effective Meetings [3]
 Keep meetings brief
 One hour should suffice, except for a working
meeting
 The more people, the shorter the meeting (e.g.
whole-project meetings should be kept short)
 Spawn sub-group meetings to discuss substantive
issues in more detail
 Subgroups report back in main project meeting
Effective Meetings [4]
 Participation is essential
 Arrive on time, don’t leave early
 Everyone has a voice
 If absence is unavoidable:
 Send an update to the meeting leader via email
 Read meeting minutes asap and clarify if necessary
 Don’t allow your absence to disrupt the project
Issue-Based Development
 Organize teamwork around issues to be resolved as
well as code to be written
 Document discussion, assumptions, alternative
solutions, and resolution for each issue
 If assumptions change later, an alternative can be
explored
 (More in Bruegge & Dutoit)
Keep Models Up To Date
 Models are only useful if they describe what you are
doing
 Models get out of date easily
 Details become visible during development
 Design changes
 Link issue resolution to action items: update
appropriate models
Consider an
Incremental Approach
 When working with a hard deadline
 A means of mitigating technical and schedule risks
 Guarantee you have something to deliver
 Development is a series of stable, tested increments
 PRO: Always have working system
 CON: Extra overhead?
Synchronize & Stabilize
 “Test early, test often”
 At level of individual class, module, or entire system
 Synergy with incremental approach
 Mitigates estimation risk in system integration
 Microsoft’s approach (Cusamano, 1997)
(from Cusamano, 1997)
Use Bug Tracking
 Manage enhancements, fixes to
 Code
 Test Suites
 On-line resources (web)
 Written documentation
 (See Bugzilla slides from last lecture)
Code Reviews
 At each milestone
 One module per review
 Code examined in advance
 Developer leads the meeting
 Issues put into bug tracking system
 Source code issues (style, doc)
 Design/implementation mismatches
 Defects
 Side-effect: other developers learn how the module works
(useful)
CVS: Concurrent Versions System
 CVS Home Page:
http://www.cvshome.org/
 CVS for new users:
http://www.cvshome.org/new_users.html
 Jim Blandy’s tutorial:
http://www.cvshome.org/docs/blandy.html
 The Cederqvist manual:
http://www.cvshome.org/docs/manual/cvs.html
Subversion: A Better CVS
 http://subversion.tigris.org
Process Improvement
Frameworks for Process
Improvement
There are frameworks for analyzing, evaluating, and
(maybe) improving a software process. Best known:
Capability Maturity Model Integrated (CMMI), and its
earlier version CMM-SW (CMM for Software).
Software Process Improvement Capability Determination
(SPICE), ISO 15504, a framework for assessing and
comparing software processes.
ISO 9000 - a family of standards for "quality managed
systems". Requires a map of all key processes;
documented procedures and assessment.
Overview of CMMI - Maturity Levels

Fall 2007/2008 Uwe Gühl, Software Engineering 71

01 v0.5
Overview of CMMI - Maturity Levels

5 Focus on process improvement; "Optimizing"

"Optimizing"

Process measurements; adapt to “Quantitatively

“Quantitatively
4 Managed"
problems to reduce variance; Managed"
predictable performance

3 Process and procedures are “Defined"

“Defined"
standard, managed, improved
over time
has process model "Managed"
2 but varies project to "Managed"
project; repeatable
ad hoc "Performed"
1 not repeatable "Performed"

0 Outcome “Incomplete"
“Incomplete"
depends
on “heroes”
Overview of CMMI - KPA
The CMMI definition of "process"

A “process” [as used in the CMMI Product Suite] consists

of activities that can be recognized as implementations of
practices in a CMMI model.

These activities can be mapped to one or more practices

in CMMI process areas to allow a model to be useful for
process improvement and process appraisal. (In Chapter
2, see the definition of “process area” and a description
of how this term is used in the CMMI Product Suite.)
SPICE (ISO 15504)
 Software Process Improvement and Capability
Evaluation
 Bloated ISO standard ... not popular outside the EU
5 Types of Processes
1. Engineering
2. Supporting
3. Management
4. Organizational
5. Customer-supplied
Open UP definition of process
An organization of method content into partially ordered
sequences for [completing] a software project

What is "method content"?

• Roles
• Tasks
• Artifacts (inputs and outputs)
• Guidance
• checklists
• concept documents
• knowledge resources
RUP Process Model
What are Roles? Name some...
What are Tasks? Name some...
What are Artifacts?

Some ancient
artifacts

http://www.crystalinks.com/emeraldtablet.html
Software Development Plan
 Includes the "Project Management Plan"
 What areas does it address?
Software Development Plan
Configuration Management
 In your project there are...
280 source code files
12 files for user documentation
8 project documents (deliverable) such as
SRS
Software Architecture Document
...
Configuration Management (2)
 How do you know...
which ones have been tested?
where is the "release 1.0" final version?
have they been reviewed?
what bugs or issues remain (in each file)?
Configuration Management (3)
 Configuration Mgmt is part of Development Plan
 What artifacts do you want to manage?

1. Source code
2. Built code (which one is version 1.0?)
3. Change requests
4. Change notification
5. Bug & Issue tracking
CM: Process
 Artifacts
what do you want to manage?
 Tasks / Activities
 xx
 xx
 xx
 Guidance / Standards:
naming convention
version numbering convention
repository organization
what documents go where?
directory structure
Activities and processes (again)

Roles

Input Activity Output

IEEE xxxx
1. blah blah
2. blah blah
3. blah blah
Tools, technology

Guidance, standards, procedures

Review of Important Concepts
What is a Process?
How many Programmers does it take
to write a "Hello World" program?
 ?
How many Programmers does it take
to write a "Hello World" program?
 One.
How many eXtreme Programmers does it
take
to write a "Hello World" program?
 ?
How many eXtreme Programmers does it
take
to write a "Hello World" program?
 Two
XP requires that you always do "pair
programming".
But they can write "Hello World" much faster.
How many Software Engineers
to write a "Hello World" program?
How many Software Engineers
to write a "Hello World" program?
 Six.
Analyst to write the specification.
Architect to design the program.
Developer to write it.
Tester to test it.
Documenter to write the user guide.
Auditor to verify that the process was followed.
How many people to write a IEEE1074
compliant "Hello World" program?
How many people to write a IEEE1074
compliant "Hello World" program?
 Seven.
Software Process Architect to design the process.
Analyst to write the specification.
Architect to design the program.
Developer to write it.
Tester to test it.
Documenter to write the user guide.
Auditor to verify that the process was followed.