|
Papers and
Presentations:
|
Please feel free to download these papers, being careful to respect the
copyright holder and copyright notice. If you would like a paper or presentation
you do not see, or you would like another format, please contact the webmaster.
Two good reasons
why new software processes are not adopted (and what to do about them!)
Author: Stan Rifkin
Proceedings of the 2003 Workshop on Adoption-Centric Software Engineering,
held in conjunction with the International Conference on Software Engineering,
Portland, Oregon, May 9, 2003. The entire proceedings are available from
the Software Engineering Institute. Click
here to find out more.
PDF (276.19Kb)
Copyright holder: Insitute
of Electrical and Electronics Engineers
Abstract. There are many reasons we do not adopt software engineering
processes, including those associated with tools. This paper presents
two of the most persuasive reasons, based on a literature review of 175
references. And suggests what, as change agents, to do about them.
Why new
software processes are not adopted
Author: Stan Rifkin
Advances in Computers, vol. 59, 2003, pp. 83-126
PDF (815K)
Permission requested from Academic
Press division of Elsevier
Abstract. Why do we often appear not to do what is best for us, or at
least what someone else thinks is best? To what extent do the reasons
have to do with what is being suggested vs. to how the implementation
is planned and executed? Is there a way to accelerate the rate at which
the implementation of process adoption can be achieved? These questions
are addressed by reviewing the considerable literature on implementations
of software engineering, information systems, and quality improvement.(ver.
1.2)
Is the CMM an
impediment to innovation?
Author: Stan Rifkin
EDS annual CMM Conference, July 2002
ZIP Word .doc (10K)
Copyright holder: Master Systems Inc.
Abstract. The CMM is tuned to organizations that seek operational excellence,
one of three strategies or value propositions. Organizations that have
innovation as their value proposition will find little guidance in the
CMM.
Is process improvement
irrelevant to produce new era software?
Author: Stan Rifkin
European Conference on Software Quality 2002, Helsinki, Finland, June
2002
PDF (285K)
Copyright holder: The Springer-Verlag, reprinted here with permission
Abstract. Narrow focus is the key to success for organizations of all
kinds and sizes. Focus can be diluted by emphasizing the "wrong kind"
of software process improvement. That's right: traditional software process
improvement may impede the successful development and deliver software,
particularly innovative and total solutions. In fact, adherence to traditional
software process improvement can cause an organization to become blind
to competitive forces. This presentation gives a preview of a new set
of improvements that are tailored to the new styles of software development
and to the new market realities about time to market, our tolerance of
quality concerns, and relentless focus on convenience.
What I would
do differently if I wrote the SEPG Guide today (draft 0.2A)
Author: Stan Rifkin
Software Engineering Process Group (SEPG) Conference, Phoenix, Arizona,
February 2002
ZIP Word .doc (116K)
Copyright holder: Master Systems Inc.
Abstract. The Software Engineering Process Group Guide (SEPG Guide) was
researched and written by Priscilla Fowler and Stan Rifkin in 1988-1990,
and published by the Software Engineering Institute in 1990. It is about
how to improve processes every day. Many of the observations reported
in it have proved useful over the years of application. Some additional
information would have added significantly to its applicability, particularly
(not in any order): one size does not fit all, the importance of process
improvement by stealth, how we are misled by psychology and should pay
attention to sociology, what patterns of adoption look like, a fresh look
at "resistance," and how engineers might approach the subject
of deployment.
The CMMs are relevant
to modern software development environments
Authors: Stan Rifkin & Jerry Lankford
Software Engineering Process Group (SEPG) Conference, Phoenix, Arizona,
February 2002
ZIP PowerPoint (264K)
Abstract. We cannot afford "People's uniqueness is used to mold
a process to their individual and collective strengths and diversity."
We need long-running, robust engineering methods to develop the life-critical
systems that will last decades, the initial development of which is only
a small fraction of the investment. We have to focus on quality, trustworthiness
and maintainability for those systems, and the CMM is the best roadmap
for that.
Son of "Behavioral
clues to organizational process maturity": A framework for understanding
organizations
Authors: Judah Mogilensky & Stan Rifkin
Software Engineering Process Group (SEPG) Conference, Phoenix, Arizona,
February 2002
ZIP PowerPoint (33K)
Copyright holders: Process Enhancement
Partners Inc. & Master Systems Inc.
Abstract. Is there a framework-a theory-that can help us organize our
informal, unofficial observations about organizations and use them to
make better predictions? Do certain observations imply others? Are there
any connections-perhaps cause & effect-that can sharpen our observations
and our conclusions? Is it possible to understand, and predict, a broad
range of organizational behavior (including, but not limited to, behaviors
observed as processes mature)? Where might we look for such answers?
Why software process innovations
are not adopted
Author: Stan Rifkin
IEEE Software, vol. 10, no. 4, pp. 110-112, July/August 2001
PDF (308K)
Copyright holder: Insitute
of Electrical and Electronics Engineers
Abstract. What do these modern, buzzword software methods have in common:
eXtreme Programming, Crystal, lean programming, scrum, feature-driven
development, adaptive software development, "good enough" software,
personal software process/team software process, Rational Unified Process,
rapid development, code complete, ...? They all offer something in exchange
for a change in work habits, and sometimes in exchange for a "culture"
change, too. An important reason organizations do not adopt such methods
-that is, do not use them in daily software development-is that what the
methods offer is not as important (read "cost-effective") as
staying with the status quo. This has nothing to do with inertia or resistance
to change. Put more strongly, what these methods offer is irrelevant.
Put more diplomatically, what they offer is not strategic for the enterprise.
What makes measuring
software so hard?
Author: Stan Rifkin
IEEE Software, vol. 10, no. 3, pp. 41-45, May/June 2001
PDF (212K)
Copyright holder: Insitute
of Electrical and Electronics Engineers
Abstract. We often hear that it is difficult to get software measurement
into practice. Traditional measurement addresses the decisions that support
increased quality, increased programmer productivity, and reduced costs—key
elements for organizations strategically focused on operational excellence.
But what if the organization's highest priority isn't operational excellence?
This article shows that such organizations have different measurement
needs and presents ideas on how to address those needs, thereby making
measurement more appealing. The potential mis-fit is universal, so the
term "measurement" can be replaced by any of the areas ripe
for process improvement.
How to
select software project macro-estimation tools
Author: Stan Rifkin
IT Metrics Strategies, vol. VI, no. 9, September 2000, pages 13-16
PDF (228K)
Copyright holder: Cutter
Consortium
Abstract. Over the years I have developed a checklist for selecting automated
tools to perform macro software estimates. Here is a description and justification
of the list.
When the project
absolutely must get done: Marrying the organization chart with the precedence
diagram
Author: Stan Rifkin
22nd International Conf on Software Engineering, June 2000, Limerick,
Ireland, pp. 588-596
ZIP Word .doc (204K)
Copyright holder: Insitute
of Electrical and Electronics Engineers
Abstract. Very little is new in project planning, but this is! We present
a technique to marry the organization chart with a project's task precedence
diagram. This permits us to simulate the project at a micro, project-specific
level never before achieved. We can perform "what-if" scenarios
related to organization structures, the deployment of specific individuals
and skills, and the structure of information flow and exception-handling
in a project. The tool used, ViteProject, was developed over the last
ten years in a Stanford University laboratory, where substantial results
have been achieved when applied to design activities other than software.
We present our real-world experience with several software projects, where
it has improved project visibility and allowed us to rationally optimize
projects in a way hitherto impossible.
Program comprehension techniques
improve software inspections: A case study
Authors: Stan Rifkin & Lionel Deimel
8th International Conf on Program Comprehension, Limerick, Ireland, June
2000, pp. 131-138
ZIP Word .doc (360K)
Copyright holder: Insitute
of Electrical and Electronics Engineers
Abstract. Software inspections are widely regarded as a cost-effective
mechanism for removing defects in software, though performing them does
not always reduce the number of customer-discovered defects. We present
a case study in which an attempt was made to reduce such defects through
inspection training that introduced program comprehension ideas. The training
was designed to address the problem of understanding the artifact being
reviewed, as well as other perceived deficiencies of the inspection process
itself. Measures, both formal and informal, suggest that explicit training
in program understanding may improve inspection effectiveness.
When the
project absolutely must get done: Marrying the organization chart with
the precedence diagram
Author: Stan Rifkin
IT Metrics Strategies, May 2000, vol. VI, no. 5
PDF (1M)
Copyright holder: Cutter
Consortium
Abstract. A new tool integrates the project organization chart with the
PERT diagram in order to very closely predict the actual completion time
of a knowledge- and labor-intensive project, such as software development.
Its results are compared with those of traditional software project tools,
such as Microsoft Project, that don't take into account communication
overhead, delays, waiting, and rework.
Discipline
of Market Leaders and other impediments to measurement
Author: Stan Rifkin
IT Metrics Strategies, March 2000, vol. VI, no. 3
PDF (68K)
Copyright holder: Cutter
Consortium
Abstract. We often hear that it is difficult to get software measurement
into practice. At least one important reason for this is that traditional
software measurement is not aligned with the strategic objectives of the
organization. When software measurement is aligned with an organization’s
market discipline, the implementation is accelerated.
Climbing the SEI maturity
model makes a difference on software projects
Author: Stan Rifkin
Eleventh International Conference of the Israel Society for Quality,
Jerusalem, Israel, November 19-21, 1996
ZIP Word .doc (58K)
Copyright holder: Master Systems Inc.
Abstract. Using data from 2,500 completed software projects we illustrate
the effects of Software Engineering Institute-style software process maturity
on duration, effort (cost), and quality. For example, using the median
case, in going from SEI software process maturity level 1 to level 2,
a typical business application could save 10 months of development time,
75% of development expense, and 75% of development errors. We illustrate
additional SEI levels and give some details of the derivation of the mapping
of SEI levels to completed software projects.
Measurement in practice
Authors: Stan Rifkin & Charles Cox
SEI Tech Report 91-TR-16, July 1991(For some reason this is not on the
SEI web site)
ZIP Word .doc (80K)
Copyright holder: Software
Engineering Institute
Abstract. A few organizations have reputations for implementing excellent
software measurement practices. A sample of these organizations was surveyed
in site visits. Clear patterns of practices emerged and they are reported
at a consolidated, "lessons learned" level and in more detailed
case studies.
Software engineering process
group (SEPG) guide
Authors: Priscilla Fowler & Stan Rifkin
SEI Tech Report 90-TR-24, September 1990
ZIP PDF (616K)
Copyright holder: Software
Engineering Institute
Abstract. Improving the process of software systems development and maintenance
is the most reliable way to improve product quality. This document offers
guidance on how to establish a software engineering process group (SEPG)
and related software engineering process improvement functions. The process
group works with line organizations to improve process quality by helping
to assess current status, plan and implement improvements, and transfer
technology to facilitate improvement in practice. It has been one of the
SEI's most requested technical reports.
