WASE SQM

( Class 2005)

Lecture-5
Course No. : SEWP ZG661
Title : Defining the
software process Management
DATE :3th Aug,2008

Prof.N.Prasanna Balaji
B.E(CSC),M.Tech(IT),MBA(OM),Ph.D(ERP)
LMCSI, LMISTE, MIEEE, MAIMA

email:gneccsebalaji@gmail.com
 Human factors in Software
Process Automation
• Attitudes to change
• Specific human oriented issues
• General non-technical and technical
issues

• The Personal Software Process - a Self-

Help programme for individuals
 Phases of technology adoption

institutionalization

adaptation Commitment Phase

installation Acceptance Phase
understanding Preparation Phase

awareness
Initial
contact
time
 People need time to adjust
[Przybylinski (cited by Christie)]

productivity

unfreezing time
“ice breaking”
Refreezing
“new practices
become standard”
When new practices are introduced, productivity may actually
fall initially
 Human reactions to change
Reactions to Change
satisfaction

Emotional State

optimism
hope

time

pessimism

Important not to abandon new technology too soon!

Good gauge is to suggest replacing automated system with old manual
system and see reaction.
 Human Oriented Issues
• Success of Automating Processes depends on
– Personnel
– Organisational element
– Cultural elements
• There is a high initial cost to Process Centred Environment
development and so if it does not meet developers’ requirements,
it is likely to become ‘shelf-ware’.
• Some developers resent the controlling nature of Process
Automation technology.
• Management must create an environment of trust and closely
involve developers in the development and transition to the
Process Centred Environment
Process issues for managers and
developers
• Management need information and may view Process
Automation in terms of better control of software
process
• Developers use Process Automation for guidance and
relief from menial chores so see it in a supporting role
• Process Automation can also assist developers in
cooperative product development providing both
support for and control of products e.g. automated
Configuration Management, concurrent debugging
 Fear of Process Automation
• Why developers fear • Why managers fear
Process Automation Process Automation
– reduction of privacy – loss of control due to
automated decision making
– loss of control over
– loss of control due to
how one performs introduction of self-directed
work work groups
– de-skilling – loss of control over
information
– fear of redundancy
– ignorance (fear) of new
technology
– loss of status
 Guidelines from Computer-
supported Cooperative Work
• Do not try to get too elaborate with sophisticated functionality
– aim for basic functions
– ease of access
– performance from the end user view point
• Use suitable analogies and metaphors
• If possible try to achieve seamless data and control integration
between applications in Process Centred Environment
• Ensure system does not favour one group over others
• Design for adaptability as system must be adaptable to
account for user experience
 Selecting tasks for automation
• tasks that are well understood and stable
• tasks that have clear interfaces to and from other tasks
• tedious tasks
• tasks where manual involvement is error prone
• tasks with high amounts of routine communications
• high integrity tasks where conformance to process must be
assured
• If individual in charge of process is hostile to PA then better to chose
an alternative process. Once islands of PA have been built up,
these can be bridged.
 Other Issues
• Resistance to chance - Issues
such as fear of job loss, being
controlled by a machine,
concerns over intrusive metrics
should be discussed; and
everyone should ‘buy in’ to an
agreed solution e.g. metrics
data should be used for
process improvement and not
for performance evaluations
• Process Ownership and
Involvement - Philosophy
should be to push
responsibility down in the
organisation - enpowerment
• Training - Both technical and
non-technical issues must be
addressed by training
• Organisational Context- Start
at project level then
standardise through out
organisation
• Broad higher-level process
models may be used to guide
the organisation of lower-level
processes and information
flows but detailed low level
process automation should be
bottom up
The Personal Software Process
(PSP)
• A self-improvement process designed to help you
– to control,
– to manage and
– to improve
the way you work as a software engineer
• The PSP is a structural framework of forms, guidelines
and procedures for developing software.
• Properly used, it provides historical data needed to make
and meet development commitments and it makes routine
elements of your work more predictable and more
efficient.
 Key points
• The Personal Software Process can be adapted to
individual circumstances.
• Through Personal Software Process principles, it is
possibleto define, measure and analyse your own
process.
• With experience it is possible to improve (i.e. enhance)
your processes to take advantage of new technology,
tools and methods.
• Overall goal of Personal Software Process Understanding
your own performance as a software engineer and
determining how to improve your performance
 Do-It-Yourself Professional
Development Plan
• It relates problems to industrial software
development to issues of professional discipline
and describes how an individual can use
disciplined methods to improve their
performance as a software engineer.
• Basically the Personal Software Process is a
self-improvement programme
The Rationale behind Personal
Software Process Improvement
• Software professionals
will better understand • Based on this knowledge and
what they do if they experience, they can select
those methods and practices
define, measure and
that best suit their particular
track their work
tasks and abilities
• They will then have a • By using a customised set of
defined process structure orderly, consistently practical
and measurable criteria and high quality personal
for evaluating and practices they will be more
learning from their own effective members of
and others’ experiences development teams and
projects
 4 Main Steps lead to the
personal software process
• Identify those large-scale s/w methods and
practices that can be used by individuals
• Define the subset of these that can be applied
while working on small projects ie developing
small programs
• Structure the methods and practices so they can
be gradually introduced
• Provide exercise suitable for practicing these
methods in an educational/professional
development setting
Evolution of
Personal PSP 0 Current
Baseline
Process - Basic
Software Process record keeping
Improvement PSP 0.1 Coding standard,
process improvement
proposal, basic measures

PSP 1 estimating,
test report Planning
PSP 1.0 task and
schedule planning
Quality
PSP 2 code &
design reviews management
PSP 2.1 design
templates

PSP 3 Cyclic development Repeat

iterative incremental development
Anyone who is well versed in the Personal Software Process has the
basis for carrying out Process Improvement in a software
development team and in an organisational context.
5 Principles behind the Personal
Software Process
• A defined and structure process can improve working
efficiency
• Defined personal process should fit the individual’s
skills and preferences
• For professionals to be comfortable with a defined
process, they should be involved in its definitions
• As professional’s skills and abilities evolve, so should
their processes
• Continuous process improvement is enhanced by
rapid and explicit feedback
Personal Software Process
Overview
 Process Improvement
1. Define the quality goal
2. Measure product quality
3. Understand the process
4. Adjust the process
5. Use the adjusted process
6. Measure the results
7. Compare results to goal
8.Go to step 4 and continue improvements
 Logic of Time Management
• You will likely spend your time this week the same way
you did last week
• You have to track the way you spend time to allow for
planning
• You must compare your time estimates and plans to
what you actually did
• You need to determine where your previous plans were
in error and correct future planning
• To mange your time, you need to make a plan and follow
your plan
 Understanding How You
Spend Time
• Categorize your major activities
• Record time spent in each major activity
• Record time in a standard way
• Keep the time data in a convenient place
– engineering notebook
– include a table of contents
– used for planning and recording time
 Tabular Time Recording Log
Pages
• Date
• Start Time
• Stop Time
• Interruption Time
• Delta Time (interruption time removed)
• Activity Name
• Comments
• Completed Task (check box)
• Units of Work Completed
 Hints on Logging Time
• Keep the engineering notebook with you at
all times
• When you forget to record a time, make an
estimate and write it down as soon as
possible
• Use a stop watch to time interruptions
• Summarize your time promptly
 Period and Product Planning
• Period Planning
– based on period of time (e.g. week)
– details how time is spent during this period
• Product Planning
– based on an activity (e.g. writing a program)
– products may be things like programs,
documents, knowledge, or service provided
• Both are important
 Period Planning Using the
Weekly Activity Summary

• Table with task names as column headings

and days/dates as the row labels
• Table cells contain total time on that task for a
given date
• Totals are computed for each row and column
• Summary table is computed for current week
and compared to summary table for previous
week
Weekly Summary Table

Task1 Task2 Task3 Task4 Total

Total
Time
Average
Time
Maximum
Time
Minimum
Time
 Product Plan Components
• Estimated size of the product
• Important features of product
• Time estimates for the required work
• Projected schedule

Note: Small jobs do not require plans that

are as sophisticated as large jobs
 Job Number Log
• Rows are organized for each project task (not by
date)
• Columns
– Date
– Process
– Estimated: Time and Units (based on past
experience)
– Actual: Time, Units, and Production Rate
– To Date: Time, Units, Production Rate, Minimum
Production Rate, and Maximum Production Rate
Elements of Time Management
• Decide how you want to spend your time
• Make a time budget
• Track the way you spend your time
• Decide what changes to make in your time
budget
• Make your actions agree with your time
budget
 Managing Variable Time
• Determine your highest priority items
• Determine the deadlines for specific tasks
• Identify activities that you want to do as
soon as you have time to do them
 Managing Commitments
• Personal commitments are viewed as
being voluntary
• Contractual commitments involve two
parties agreeing on an action and a time
frame
• True commitments involve explicit and
voluntary agreement between two or more
parties
 Agreements Required
• What will be done
• Who will do it
• When it will be done
• Compensation or other consideration to be
given upon completion
• Who is to provide the compensation
 Managing Commitments

• Analyze the job before agreeing to the

commitment
• Support the commitment with a plan
• Document the agreement
• If you are unable to complete your
commitment, notify all affected parties
promptly and try to minimize the impact
of your failure to complete your obligation
Handling Missed Commitments

• Don’t just give up trying

• Check with an independent expert for
alternative strategies to meet the
commitment
• Consider adding resources to project
• Look for smarter ways to do the design
• Waiting until the last minute to recognize
the problem always leads to disaster
 Consequences of Failing to
Manage Commitments
• Work required exceeds time available
• Failure to meet commitments
• Misplaced priorities
• Poor quality work
• Loss of trust
• Loss of respect for your judgement
 Project Management
• If you are falling behind, your schedule will continue to
slip unless you do something different
• Simply trying harder will not help
• You are in trouble if you do not know how much of a
project is completed and how much remains
• When you need luck to meet a commitment you will not
get it
• When your estimates are wrong, they are most likely to
be too low
• Almost all changes involve more work
 Managing Personal Schedules
• Gantt charts based on project check points
or milestones (e.g. completed activities)
• Tracking earned value (e.g. line graphs
showing estimated, projected, and actual
completion times)
• MS Project type tools
 Why are we doing all this?
• The quality of a software system is determined by the
quality of its worst components.
• The quality of a software components is determined by
the quality of its developer’s knowledge, discipline, and
commitment.
• As software professionals you should now how to
measure, track, and analyze your own performance.
• You should be able to learn from your past failures and
improve your personal practices.
 What is Personal Software
Process?
• PSP0
– You establish a measured performance
baseline
• PSP1
– You make size, resource, and schedule plans
• PSP2
– You practice defect management and yield
management
• PSP3
– You scale up PSP methods to larger projects
 PSP Overview - 2
PSP3
Cyclic development

PSP2 PSP2.1
Code reviews Design templates
Design reviews

PSP1 PSP1.1
Task planning
Size estimating
Schedule planning
Test report

PSP0.1
PSP0 Coding standard
Current process Size measurement
Time recording Process improvement
Defect recording proposal (PIP)
Defect type standard
The CMM and the PSP - 2
5 Level 5:
Process change management*
Technology innovation*
Defect prevention*

4 Level 4
Quality management*
Process measurement and analysis*

3 Level 3
Peer reviews*
Intergroup coordination
Software product engineering*
Integrated software management*
Training program
Organization process definition*
Organization process focus*

2 Level 2
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight*
Software project planning*
Requirements management

1 Level 1
*PSP key process areas
 PSP0 Process
• A simple defined personal process
• Uses your current design and
development methods
• You need to gather data on:
– time spent by phase
– defects found in by compile and test
• Prepare a summary report
 PSP0 Process Elements
• Process script
• Project plan summary form
• Time recording log
• Defect reporting log
• Defect type standard
 Defect Recording Log
• Defect type
• Phase in which defect was injected (best guess)
• Phase in which defect was found and repaired
• Time to fix defect
• If defect was injected during repair of another defect
(e.g. fix defect) what fix was it (best guess)

Note: A defect is any thing that must be changed for the

program to be properly developed, enhanced, or used
 PSP Standard Defect Types
• Documentation • Checking
• Syntax • Data
• Build or package • Function
• Assignment • System
• Interface • Environment
 PSP Higher Level Processes
• You must be operating at PSP0 to begin to
move up
• We discussed the most project planning
issues for PSP1 in CIS 375
• PSP2 is concerned with defect and yield
management (our focus for the next 3
weeks from Sommerville)
Software Process Improvement
• Current Problems
• Promising Approaches/Solutions
• Nature of Software Engineering
• Software Engineering Research
• Recent Developments and the Future
 Large and growing systems...
• In general, software systems have seen
an order of magnitude growth in size
every decade (for some industries this
has occurred every half decade). [SEI
finding]
• Software disasters are inevitable unless
software development becomes an
engineering discipline with roots in
science and mathematics.
 Some Solutions
• Progress on Software Process, e.g. the
SEI’s Capability Maturity Model (CMM)
• 5 Level Model - 1 is Chaotic, 2 is
Repeatable, 3 is Defined, 4 is Managed and
5 is Optimising
• But 75% of companies are at Level 1 and
24% are at Levels 2 and 3.
• USA Space Shuttle software maintenance
is at Level 5.
 Mathematical Foundations and
Formal Methods
• Progress on error-free software is slow.
• Plan in mid90s to beta-test new version of Windows
by 20,000 volunteers. [Microsoft Chief Architect C Simonyi]
• This is expensive, inefficient and usually impractical.
• View of Martyn Thomas founder of Praxis is that we
should rely on mathematical analysis of formal
specifications to predict how software will behave.
• Applicable to either the most critical parts or whole
systems.
 Clean Room Approach and
Improved Testing
• Clean Room = Application of rigorous
engineering techniques from electronic
engineering

• Coupled with new approaches to testing

emphasizing probabilities of execution
paths. Putting testing on a more scientific
basis.
 Progress on Software Reuse
• There is some work on component
based development, reusable parts and
standardisation to support reuse
• But more research is needed before
this becomes widespread industrial
practice.
 No Single Solution
• A combination of approaches is needed - there
is no silver bullet!
• In addition, Software Engineering needs a better
empirical basis - we need more experiments!
• E.g. Software productivity measurement
problems
– No reliable data
– No uniform measures
– No quality considerations (1000 lines of spaghetti or lasagna.
 Sample Exam Question
• Question 1
(a) In the context of software process improvement, outline the main characteristics of the
software process found in companies assessed to be at the various levels of the
Capability Maturity Model.
[6 marks]
(b) discuss the process of capability determination within a software company and illustrate
how process modeling may be used.
[6 marks]
(c) A software company has been assessed as having a Level 2 Capability. Outline two
potential process improvements that the company may wish to consider and indicate how
they should go about evaluating whether or not the improvements once implemented
have been successful.
[8 marks]
(d) Outline the case for a Standard for Software Process Assessment, such as SPICE, to be
used throughout the software industry.
[5 marks]
 Model Answer
(a) Level 1 - Initial - ad hoc processes, chaotic development and
management activities
Level 2- Repeatable - basic software processes in place in individual
projects
Level 3 - Defined - organisation process defined across projects,
training programmes, software management, peer reviews take
place
Level 4 - Managed - quantitative process management, software
quality management
Level 5 - Optimising - process change management, technology
change management
(b) A company may either carry out self determination of their software
capability or engage outside experts to carry out this task. The latter
have the advantage of not being involving in the company and potentially
can give a more objective assessment. In both cases, the determination
should be done with reference to an established standard, such as the
SEI’s CMM or ISO SPICE. Experts in software process improvement will
be required to interpret the relevant standards especially associated
guidelines and to carry out the necessary questioning of managers and
engineers within the company. Depending of the level of the company
being assessed, the assessors will need to study the process models
used within projects and defined for the whole company if available.
Identifying deficiencies in these models and how practice within the
company deviates from the models will provide the basis for modeling
improved processes to guide in the future improvement of the company.
(c) At Level 3, the focus is on defined engineering processes across
the organisation. Various improvements can be considered: peer
reviews, intergroup coordination, organisation process definition
and associated training programme, integration of software
management into the process, ensure that the software products
produced at each phase are well defined. The answer should
address two of these and give a corresponding indication of how
the company should evaluate their successful implementation in
terms of monitoring impacts on software production and staff.
(d) It provides a common basis for education and training.
It provides a common basis for implementation of software process
assessment as well as a means of identifying software process
improvements.
It allows industry-wide comparisons of the state of practice to be made, e.g. it
has been estimated that the majority of software companies are at the
lower rather than the higher levels of process maturity.
It can be used be used to qualify potential partners or subcontractors in
international consortia/projects.
An international standard such as SPICE reflects the expertise of
international experts and is not biased towards any one national viewpoint.
The standard itself will be subjected to regular review and up-dating if
necessary following the procedures of the International Standards
Organisation. (any 5 of the above or similar)
 Advice on mini-essay answers
• Give a balanced argument, with a clear
introduction and conclusions.
• Do not just write a list of points; structure your
answer.
• If pressed for time, just give an outline. In any
case, outlining your answer may be a good way
to get started.
• Where citing papers/books/specific experts, just
give the minimum details for identification.
 These notes are based on:
Introduction to the
Personal Software Process
Watts S. Humphrey
Addison-Wesley Longman (1997)