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
|Conservation of information: Reverse engineering dark social systems||William Lawless, Stan Rifkin et al.||Structure and Dynamics: eJournal of Anthropological and Related Sciences, 2010, vol. 4, no. 2||On-line||No copyright.
|Abstract. Collecting information from well-defined organizations for social network analysis (SNA) is relatively straightforward. For "Dark" social networks, for example, illicit drug gangs or terrorists, uncovering information to compute an SNA is orders of magnitude more difficult. However, even when the information is readily available, the signals collected from social networks have not led to valid predictions about their actions or stability. This failure has led to a wide request for new social theory to better understand the effects of interdependence in social networks and in social organizations. For example, Barabási concluded that room needs to be made for a new theory "to understand the behavior of the systems ... [and] the dynamics of the processes ... [to] form the foundation of a theory of complexity."|
|Systems of systems: Answering the organizational implications||Stan Rifkin||2010 Annual Defense Systems Engineering Conference, National Defense Industrial Association, San Diego, California, October 25-29.||PDF (2.15Mb) ||No copyright.
|Abstract. Last year you heard the problems and this year you can hear the solutions, and working together in this session tailor the answer to your particular organizations, customers, and what you are trying to optimize. Less of death by PowerPoint and more interactive problem-solving using a library of long-standing tools and methods. Most of the organizational-related problems of SoShave been solved in other settings, so this tutorial seeks to marry the well-known solutions to your specific issues. The format will be question and (long) answer; participants should be prepared to describe their environments and concerns, and then the guide will expose the whole group to what successful organizations have done to address those very subjects. Most of the material will be new to the participants because it comes from sources outside of our usual engineering, science, and technology backgrounds. One objective of the tutorial will be to equip participants with a lens with which to best see organizational dynamics and leverage points. Remember: some problems that look technical, such as requirements allocation, are usually results of how engineers are organized. Participants will leave not only with the answers to their own questions and the others' in the room, but also a deeper understanding of approaches that are off of our usual radars, outside of our normal experience-base -- along with advice about where to look in the future as new organizational challenges arise.|
|The counter-case: How to interfere with terrorist learning||Stan Rifkin||New Horizons Research Conference, the George Washington University, Ashburn, Virginia, October 8-9, 2010.||PDF (264Kb) ||No copyright.
|Abstract. Can we use theory of social systems interaction -- for example, Parsons' theory of action and GWU's extension to learning -- to intefere with, deny, and otherwise disrupt learning by terrorist organizations? Presented are a few prospects as a thought-piece, the beginning of a conversation.|
|Explaining success AND failure of engineering improvements||Stan Rifkin||Washington DC area Software Process Improvement Network, October 6, 2010.||PDF (817Kb) ||No copyright.
|Abstract. We usually take for granted the goodness of an enterprise's choice of overall direction and strategy; we sometimes observe that performance is not in line with strategy and prescribe some lining-up exercise. I have found that many engineering quality and process improvement initiatives fail because they go against the strategy and therefore one or the other of them is "bad" and should be changed. In other words, in trying to explain why it is that some enterprises embrace and succeed in the improvements yet others do not, the fit with strategy may be central and powerful. In particular, when strategy and improvement are aligned, the improvements go very quickly and painlessly, belying the myth that there is always resistance to change. Therefore, as agents of change we need to add tools to be able to quickly assess strategy, improvement, and the mutual fit, and then know what to do about a possible misfit. They are the topics of the presentation.|
|What is the best way to develop systems? Continuing the conversation about agile and plan-driven methods||Stan Rifkin||Washington DC area Software Process Improvement Network, August 4, 2010.||PDF (1Mb) ||No copyright.
|Abstract. There is a tension between disciplined, plan-driven methods of systems development and more ad hoc, agile ones. Some participants and observers take an all-or-nothing stance, while there has been an emerging practice trying to blend the best of each approach. This poses the question of what IS, after all, the best of each method? How could we tell what one life cycle approach offers that another does not? In the end the answer depends upon what we are trying to optimize: rapid delivery of value or high assurance. Besides presenting a framework containing the factors to take into account when deciding on a life cycle model, there will also be perhaps the first local presentation of the Incremental Commitment Model, successor of the spiral model and created by the same author, Barry Boehm.|
|Organizational assessment models for enterprise transformation||Nathan Perkins, Ricardo Valerdi, Deborah Nightingale( all MIT) & Stan Rifkin||2010 International Council on Systems Engineering (INCOSE) Annual Conference, Chicago, Illinois.||PDF (263Kb) ||No copyright.
|Abstract. Organizational assessment is becoming increasingly important, both as a cross-time
and cross-industry measurement and as a guiding force in enterprise transformation. Assessments
provide crucial information about strengths, areas for improvement and potential investment
strategies for achieving performance benefits. As performance is being recognized as a complex
and multifaceted construct, assessment tools seek to incorporate and reflect a holistic
measurement of performance across multiple dimensions such as stakeholder value, leadership,
culture and quality.|
|An ab initio solution of interdependence: Social organization with first principles||W. Lawless, Stan Rifkin and D. Sofge||Advances in Quantum Theory conference, International Centre for Mathematical Modelling and Linnæus University, Växjö, Sweden, June 2010.||PDF (112Kb) ||No copyright.
|Abstract. A special issue of Science, the National Academy of Sciences, the military, and economists have called for a new theory of interdependence, call it iota. Constructed around the notion of bistable social reality (i.e., complementarity between conjugate or Fourier pairs), we have developed a social physics of iota for organizations and systems of humans, machines and robots that has shown some validity. But because of the loss of meaning associated with understanding iota states or interactions between social Fourier pairs, we consider it high-risk research.|
|I am a change agent: What do I do and how do I learn how?||Stan Rifkin||2010 North America Software Engineering Process Group Conference, March, Savannah, Georgia||PDF (349Kb) ||No copyright.
|Abstract. Engineering process improvement can be a significant organizational change: new ways to work; new ways to measure and new rewards; new jobs, titles, and ways to organize; and new skills, both technical and people-related. Bottom line: Successful implementation will require us to make significant changes in how we think and behave. |
Sponsors, targets, champions, and particularly change agents ... ME!
It is rare for change agent skills to be included in software/engineering curricula or even training. How can we find out which are the most important skills and the best way to attain them?
There is literature in other fields (agriculture, nursing, mergers & acquisitions, down-sizing, etc.)
Rather we wanted to be practical and focused on engineering improvement, so we have gone directly to practitioners in the field to ask them what skills made them successful and how they gained those skills.
- Normal skills that made me successful as a developer, quality professional, etc. might be insufficient.
- Success requires me to master the skills and framework of a change agent, in addition to all of the other skills I have to have.
|(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 presenter 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 commercial 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
|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.
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
|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)|
CMM an impediment to innovation?||Stan Rifkin||EDS annual CMM Conference, July
2002||PDF (189K)||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.|
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.|
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||PDF (167K)||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.|
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.|
"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?|
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
|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
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
|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
|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.|
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||PDF (109K)||Insitute of Electrical and Electronics
|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.|
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||PDF (99K)||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
|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.|
of Market Leaders and other impediments to measurement||Stan Rifkin||IT Metrics
Strategies, March 2000, vol. VI, no. 3||PDF (68K)||Cutter
|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.|
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||PDF (102K)||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.|
practice||Stan Rifkin & Charles Cox||SEI Tech Report 91-TR-16, July
1991(For some reason this is not on the SEI web site)||PDF (178K)||Software
|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.|
engineering process group (SEPG) guide||Priscilla Fowler & Stan Rifkin||SEI Tech Report 90-TR-24, September 1990||PDF (797K)||Software
|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