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
| Title | Author(s) | Occasion | Format & Size | Copyright
holder |
| (Secrets of a) Process Whisperer | Stan Rifkin | 2007 Software Engineering Process Group Conference, March 26-29, Austin, Texas | PDF (274Kb) | Master Systems Inc. |
| Abstract. From afar, horse and dog whisperers appear to get recalcitrant animals to obey them without saying anything aloud, seeming to whisper “secret” commands into an animal’s ear. When we see this we attribute such gifts to magical powers, hocus pocus, hypnosis, and imbue supernatural powers to the “whisperer.” We have also seen these same things happen when certain strong personalities speak to executives: even though we have told those executives virtually those very same words a thousand times, when a Process Whisperer says it there appears to be some secret communication and the executive becomes interested for the first time! What “whisperers” do is to get their targets into the natural states, back to where their instincts take over, where they react in an inborn, almost physical way. The written presentation is brief because, after all, whispering is inherently oral! |
| "I'm the Lead!!?? Now what do I do?" - Continuing the conversation | Stan Rifkin | February 19, 2007 meeting of the San Diego Software Improvement Network | PDF (1.27Mb) | Master Systems Inc. |
| Abstract. The January 2007 SD SPIN meeting pesenter did a wonderful job introducing the challenges of being a new technical manager and offering some heuristics about how to be effective. This presentation uses that one as a basis and offers more depth and some of the reasons why the rules of thumb might work. The previous speaker correctly answered a number of questions from the participants with "It depends." This presentation will give more details on what exactly the answer does depend. And it will also supply a "buyer's guide" to information on leadership, management, and teamwork. In addition, the presentation will address such questions as: what is the difference between a leader and a manager and what difference does the answer make; does the size of a team make a difference in how a leader should behave; should a leader care about what the team does (technical vs. sales, for example) - isn't leadership a professional onto itself; seems like leaders have to be able to do everything (mentor, strategize, inspire, critique, make decisions, etc.), but who can really do that and aren't we setting up leaders for failure by having such high expectations; are leaders made or born (trainers need to believe they are made, but what is the data); what is the best way for teams to make decisions (consensus?); how does psychology mislead us when dealing with groups; and what resources are available to those of us who do not have natural people skills (like the speaker!) |
| Best commercial practices for acquiring systems of systems | Stan Rifkin | University of Southern California's Center for Systems and Software Engineering Executive Workshop, February, 13, 2007 | PDF (818Kb) | Master Systems Inc. |
| Abstract. Probably the biggest problem in creating systems of systems is acquiring them. Are there any commercial best practices that the rest of us can use as a template? This presentation suggests one: European Organization for Nuclear Research (CERN), where distrust of partners is the rule. The biggest difference between government acquisition and commerical is the knowledge of capability, even if vague vs. "Can do" attitude. Government: "We must have something this big!" Commercial: "We don’t think we can built something that big." |
| Why do I have to learn about organizations? I am a software engineer/computer scientist! | Stan Rifkin | Keynote address at the 2006 International Conference on Computer Science and its Applications, at National University, San Diego, California, June 27-29, 2006 | PDF (283Kb) | Master Systems Inc. |
| Abstract. Most systems fail for organizational
reasons, not for technical ones.
Many of our solutions are technically
adequate, but they cause organizational
problems or do not take into account
organizational issues, and that is why so
much technology is not implemented,
adopted, or deployed. Knowing how
organizations work greatly improves
the chances that our technical solutions
are appropriate and will actually be
used. Besides, big work, significant
work, is done by organizations for
organizations. |
| How much should we spend on quality assurance? | Stan Rifkin | March 28, 2006 San Diego chapter meeting of the Society for Software Quality | PDF (359Kb) | Master Systems Inc. |
| Abstract. You would think by now that we would be able to answer that question definitively! You would think that we would be articulate about how much testing we have to conduct, when to stop, what exactly to test, and what product quality is required by the marketplace. This presentation is based on the pioneering work of Barry Boehm and LiGuo Huang at the USC Center for Software Engineering and is a contribution to answering the questions above, by taking a context-sensitive approach, one that looks carefully at the value of what is being developed, since not all parts have equal value to stakeholders. Practical application of the method is illustrated, along with the theoretical underpinnings. |
| Explaining success & failure: Value-based software engineering | Stan Rifkin | March 20, 2006 joint meeting of the San Diego Software Process Improvement Network and the San Diego chapter of the Association for Computing Machinery | PDF (258Kb) | Master Systems Inc. |
| Abstract. There is very little new in the overall framework of how to engineer software, but this is! Barry Boehm and Apurva Jain at the USC Center for Software Engineering have been doing some serious thinking about how to best manage and develop software. This presentation describes the fruits of that powerful thinking by illustrating the five components of the framework: negotiating a win-win solution, characterizing and attending to dependencies, the relative worth of each of the important variables (cost, schedule, features, etc.), the relationship between what we do and what happens, and how we make decisions. The framework will be animated by showing how the components interact and are traversed. And then the framework will be applied to the question of "how much quality assurance is enough?" |
| Combining systems & software engineering: Who's in charge of organizational aspects? | Stan Rifkin | Executive workshop, Center for Systems & Software Engineering, University of Southern California, March 14-16, 2006 | PDF (252Kb) | Master Systems Inc. |
| Abstract. The systems we develop impact those who consume and use them, but who in systems engineering is in charge of making sure to attend to the human and organizational impacts? We need to shift our world view in order to understand how our systems are seen by those impacted and then take responsibility for that impact, hopefully by prospectively designing the impact to be what we all intended. The presentation gives examples of the new world view and how we might be successful at adopting it. |
How do I know if I can learn from your experience? (Paper v1.2)
How do I know if I can learn from your experience? (Slides v2.0)
Comparing patterns: elevation, scatter, and shape
| Stan Rifkin | Software Engineering Process Group Conference (SEPG), Nashville, Tennessee, March
2006 | PDF (859K, 1.3M, 503K respectively) | Master Systems Inc. |
Abstract. The SEPG Conference is, at its core, a sharing of practical software process improvement experience. When we hear the experience of others how do we know if it will apply to our situation? How do we know what variables control the applicability of another organization's experience to our particular situation? Comparing organizations, it turns out, is a settled question in organizational studies.
This presentation introduces SEPG members to a free, well-documented tool that helps to address what we need to know about another organization to recognize if its lessons may be applicable to mine. You may be surprised by how few variables there are that really make a difference, that we do not need to know "everything" in order to make reasonable inferences.
The principal tool operationally defines "misfit" as a serious difference in the values of the variables that have to match in order for one organization to learn from another. Therefore, as we listen to SEPG Conference presentations this tool is so easy to use that we can answer for ourselves whether the lessons we are hearing are a misfit for us.
|
| Appropriate life cycles depend upon enterprise strategy | Stan Rifkin | Development and Deployment of Product Software 2005, the first ever workshop on product software, held in conjunction with the 3rd International Conference on Computer Science and its Application, National University, San Diego, California, on June 27-28 | PDF (93Kb) | Master Systems Inc. |
| Abstract. Suggested that selecting the best life cycle depends upon a number of factors. One of them is the market discipline or strategy of the organization. Certain strategies are aligned -- that is fit -- with corresponding strategies. |
| What is the best way to develop software? Continuing the conversation about agility and plan-driven methods | Stan Rifkin | June 20, 2005, meeting of the San Diego Software Process Improvement Network, which began the fifth year of SD SPIN | PDF (652Kb) | Master Systems Inc. |
| Abstract. Reviewed and updated Boehm & Turner's Balancing agility and discipline: A guide for the perplexed since its publication, noting in particular that we are still perplexed about how to develop software intensive systems of systems, free and open source software, geographically distributed development, and how to obtain CMMI compliance for agile methods. |
| Is there a misfit between the Capability Maturity Model/Capability Maturity Model Integration (CMM/CMMI) and corporate strategy? | Stan Rifkin | Intel Software Process Improvement Network meeting on April 13, 2005. | PDF (600Kb) | Master Systems Inc. |
| Abstract. While the part of Intel that fabricates integrated circuits is clearly a quality leader, in the software area innovation may be dominant and therefore the CMM/CMMI may offer little guidance. In that respect the software part of Intel might be "allergic" to the CMM/CMMI.
|
| Learning from a great many sources: Summary of SEPG Conferences since 1988 | Stan Rifkin | Software Engineering Process Group (SEPG) Conference 2005 in Seattle, Washington, on March 9th. | PDF (548Kb) | Master Systems Inc. |
Abstract. There are patterns, repetitions in the SEPG Conferences over this many years. Patterns include: one size does not fit all, executive sponsorship is essential but there are exceptions, the human side of technology change is important, assessment is different than improvement, software process improvement (SPI) is part salesmanship, strict quality and measurement do not work for every organization, there are only a few ways to execute the key practices, it is difficult to get SPI to stick, changes in management can derail improvement, one model or the other does not make implementation easier, resistance to change is common and natural, and teamwork is essential.
Along with these patterns are anti-patterns and also evidence over the years that many of the patterns are not accurate. This session may greatly accelerate those new to SPI, and the veterans will be able to compare their list of learnings with the presenter's. This presentation is a lively point-counterpoint, challenging the wisdom repeated without question at every SEPG Conference.
The presenter has attended every SEPG Conference, except one (2003). The presentation is the heart of what the Conference offers: condensed, practical advice from many sources who have actually performed the work.
|
| Combining operational excellence and product innovativeness | Stan Rifkin | Robert Bosch software engineering conference 2004 near Stuttgart, October 26-27. | ZIP of Power Point (913Kb) | Master Systems Inc. |
| Abstract. Keynote address to an audience of this provider of the electrical and electronic components in automobiles, esp. those of German manufacture. How to combine two of The Disciplines of Market Leaders: operational excellence and product innovativeness. This is considered very difficult, usually impossible, so the presentation carefully shows how quality and innovation can be achieved together.
|
| Reviewing 25 years of testing technique experiments | Stan Rifkin | San Diego Chapter of the Society for Software Quality, August 24, 2004 | ZIP of Power Point (81.65Kb) | Master Systems Inc. |
Abstract. An article of this same title recently appeared in Empirical Software Engineering. This presentation is a summary of the results reported there, translated for quality professionals. The article examined virtually every paper written on unit testing (that is, white box or state testing) and collected the results so that inferences could be made about the best way to test a computer program where one has the source code.
Testing is a difficult subject because, even for a small program, it would take approximately an infinite amount of time to cycle through all of the states. Therefore, only a (tiny) subset of the states can be exercised. Which ones? That is the subject of this presentation.
|
| Two good reasons why new
software processes are not adopted (and what to do about them!) | 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) | 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 | 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? | Stan Rifkin | EDS annual CMM Conference, July
2002 | ZIP Word .doc (10K) | 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? | Stan Rifkin | European
Conference on Software Quality 2002, Helsinki, Finland, June 2002 | PDF (285K) | 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) | Stan
Rifkin | Software Engineering Process Group (SEPG) Conference, Phoenix, Arizona, February
2002 | ZIP Word .doc (116K) | 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 | 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 | Judah Mogilensky & Stan Rifkin | Software Engineering
Process Group (SEPG) Conference, Phoenix, Arizona, February 2002 | ZIP PowerPoint
(33K) | 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 | Stan Rifkin | IEEE Software, vol.
10, no. 4, pp. 110-112, July/August 2001 | PDF (308K) | 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? | Stan Rifkin | IEEE Software, vol. 10, no.
3, pp. 41-45, May/June 2001 | PDF (212K) | 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 | Stan Rifkin | IT Metrics Strategies, vol. VI, no.
9, September 2000, pages 13-16 | PDF (228K) | 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 | Stan Rifkin | 22nd International Conf on Software Engineering, June
2000, Limerick, Ireland, pp. 588-596 | ZIP Word .doc (204K) | 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 | Stan Rifkin
& Lionel Deimel | 8th International Conf on Program Comprehension, Limerick, Ireland, June 2000, pp.
131-138 | ZIP Word .doc (360K) | 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 | Stan
Rifkin | IT Metrics Strategies, May 2000, vol. VI, no. 5 | PDF (1M) | 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 | Stan Rifkin | IT Metrics
Strategies, March 2000, vol. VI, no. 3 | PDF (68K) | 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 | Stan
Rifkin | Eleventh International Conference of the Israel Society for Quality, Jerusalem,
Israel, November 19-21, 1996 | ZIP Word .doc (58K) | 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 | 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) | 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 | Priscilla Fowler & Stan Rifkin | SEI Tech Report
90-TR-24, September 1990 | ZIP PDF (616K) | 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. |
