Back
Home
Contact Us
Meeting Cancellation Policy

Established September, 1992

Newsletter of the Boston SPIN

Issue 2, February 95

Return to Newsletter Index

Contents


CALENDAR

MAR 14 (second Tue), 7-9 pm -- Monthly BCS Software Quality interest group, BCS office, Waltham

MAR 21 (third Tue), 630-830 pm -- Monthly SPIN meeting: Bill Hefley [SEI] on the People Capability Maturity Model. Side attractions include refreshments and our copy of Bob Holeman's Software Process Improvement Game. GTE Building 5, 77 A St, Needham

MAR 23 (Thu) -- BOSCON 1995, Newton Marriott -- ASQC Boston Section annual quality conference -- (508) 746-3849

APR 14 (Fri) -- Deadline for early registration for SEPG workshop

MAY 22-25 (Mon-Thu) -- 1995 SEPG Workshop, Boston Sheraton -- SEI annual conference for software process improvement -- (412) 268-6467, 7388

Back to top

NOTICES

SEPG/95 volunteers wanted -- Door monitors needed for individual sessions to check in registrants, hand out materials. Be guaranteed a seat with plenty of legroom while quietly impressing people with your "insider" status. Please contact Ron Price, (508) 651-2663, price@sequoia.com .

SEPG/95 SPIN boothors wanted -- Spend a fun-filled hour hosting the Boston SPIN booth. A great way to network! Please contact Al Jost, (508) 443-7244, acjost@sud.ed.ray.com

Walter Chick -- A mailing to you last fall was returned due to insufficient address information. Please contact Sallie Hoffman, (508) 369-2365, otter@world.std.com with email address or phone number for dialogue (not just mailing address).

Bill Duncan , the author of last month's article on Software Methodology versus Project Management, can be reached at wrduncan@aol.com.

The Web Thickens -- Rachel Silber, the author of last month's book review, also happens to be the leader of a subteam that hopes to "SPIN" us a home page on the World Wide Web. If you had questions regarding the book review, or if you would like to be a resource or mentor for the Web subteam, please contact her. Other Web subteam members include Bob Lechner, David Rosenberg, and Michael Hyde. If other SPINs are also looking into this, you are invited to "net-work" with us. Rachel can be reached at rachel@ontos.com.

Program "R" You -- Your input is critical to our putting on good programs. Our Program Committee welcomes your suggestions and your offers to present. Please contact Ken Oasis at (617) 734-1017, oasis.k@adlittle.com .

Back to top

THANK YOU
to Richard Desjardins (Strategic Quality Alliance)

for being our February speaker on a week's notice when one of the scheduled speakers developed a calendar conflict. Richard described "Internal Auditing for ISO and SEI Compliance".

At this program our new Reporter of the Month muscle was flexed, and as a result we hope to include a capsule report on Richard's presentation in the next issue.

Back to top

LOGO HUNTING SEASON
Opens to End of March 21

The Boston SPIN logo -- a simple circular spiral -- is in need of at least a technical upgrade, and we would like to explore possibilities for redesign.

On the technical side, the new logo needs better crispness/resolution when enlarged. It should, like the current one, be simple enough to "come across" in smaller sizes (as in a letterhead).

On the redesign side, the ideal candidate also perfectly expresses the unwavering determination to expand the boundaries of software process improvement knowledge, the razor-sharp intellect, the shrewdness, the candor, the social grace, the fortunate location, the sense of adventure, and that indefinable je-ne-sais-quoi, that combine to characterize the Boston SPIN. (Be assured that we are reconciled to the likelihood of no ideal candidates.)

You need not be an artist to have a good idea. Please communicate suggestions, drawings on cocktail napkins, files, etc., to Al Jost. Please be sure to include your name, and how to reach you, with your input! Ways to communicate to Al:

(508) 443-7244
acjost@sud.ed.ray.com
Mail Stop 3-1-3293
Raytheon Electronic Systems Division
1001 Boston Post Road
Marlboro MA 01752

At its March 21 meeting (just before the public meeting), the Steering Committee will review all proposals and (hopefully) pick one. The new logo will greet the world at SEPG/95.

Back to top

CMM-BASED APPRAISALS:
What Can You Look Forward To?
by Ken Oasis

While the Software Engineering Institute (SEI) is moving forward with the upgraded Capability Maturity Model (CMM) Based Appraisal methodology, it has yet to lock into a specification or framework, not to mention a final set of supporting tools for performing these appraisals. The SEI's CMM Appraisal Framework (CAF) was designed to improve consistency and reliability within a specific appraisal method and across different appraisal methods. The framework provides requirements and guidelines for developing, defining, and using appraisal methods based on the CMM. For example, the Software Capability Evaluation (SCE) version 3.0 and Internal Process Improvement (IPI) appraisals are all based on similar rules for gathering data and applying judgement.

The Software Process Assessment (SPA), which has been in use since 1990 and is still an acknowledged option for baselining and rating an organization's software process, is not a fully CAF-compliant appraisal method. For comparison purposes, the following distinguishes the features of the SPA with the new CAF-compliant IPI Appraisal.

  • Duration
    SPA  
      1 week on-site
    IPI  
      1-2 weeks on-site
  • Cost
    SPA  
      n
    IPI  
      n x 1.5
  • Staff Effort
    SPA  
      100 hours/team member
    IPI  
      160 hours/team member
  • Training
    SPA  
      Required. Most vendors train organizations for 2 1/2 days
    IPI  
      SEI CMM course no longer required. Team preparation on CMM required.
  • Certified Assessors
    SPA  
      SEI licensed vendors.
    IPI  
      SEI certified individuals, listed in the SEI Appraisal Directory.
  • Reference Model
    SPA  
      TR-23 (Most vendors have improved the original SPA to use the CMM for guidance).
    IPI  
      CMM
  • Document Review SPA: When needed to support findings IPI: Required as supporting evidence for each KPA goal
  • Interviews and Discussions SPA: Non-directed and free-flowing IPI: Less free-flowing and more directed
  • Data Collection and Consolidation SPA: Data remains in form of individual notes until generation of findings. IPI: Notes/Data continuously aggregated and consolidated as observations onto Master KPA worksheets until coverage is complete.
  • Findings SPA: Data accepted when team collectively agrees that the data shows strength or weakness IPI: Observations are accepted as findings when team rules that the strength or weakness is validated by the rules for corroborating observations against the CMM.
  • Judgement/Rating SPA: Assesses satisfaction of KPA goals to rate the organization based on the findings. IPI: Assesses satisfaction of KPA goals to rate the organization based on observations related to the common features.

The SEI has been beta-testing the IPI appraisal method and tools for about ten months and should have a product out this calendar year. The SCE equivalent is due to begin beta-testing in the spring of this year. While it is too early to assess the SEI's process and ability to achieve their goals, it is worth noting that the framework has undergone a significant metamorphosis since field testing began. Major changes to the IPI method as a result of beta-testing include relaxed training requirements and closer alignment to the SPA rating approach.

Organizations who are still undecided on the choice of appraisal method to drive their process improvement initiative should understand why they need to be assessed. Are they being assessed in order to compete for a government contract, or are they being assessed in order to support their own process improvement program?

To successfully compete for government contracts, an organization should undergo an IPI appraisal. SCE teams are using a method that is closely based on the same CMM Appraisal Framework to identify the risk of selecting among different contractors for awarding business. While each appraisal/evaluation may differ in scope, the intent of the common framework is for each of the appraisals to yield comparable results.

To initiate improvement, the SPA remains an effective tool for evaluating software development capabilities, benchmarking, and building organization-wide consensus for action. SPA hybrids have gained popularity with organizations involved with continuing process improvement because of the lower cost, fewer resource requirements, and ability to benchmark against other models of best software practices.

Ken Oasis is a member of the professional staff of Arthur D. Little, Inc., Cambridge, MA, where he provides consulting services in software management and process improvement. As a lead assessor in the SPA and IPI appraisal methods, he has conducted over six CMM based assessments and has participated in other process diagnostic assessments. He is the tutorial co-chair for the 1995 SEPG international conference to be held in Boston in May. He can be reached at oasis.k@adlittle.com.

Back to top

SPIN DOCTOR
conducted by Judi Brodman

Greetings -- SPINners:

By the time you read this column, we will have passed the ninth anniversary of the Challenger Space Shuttle disaster. I recently received an update from the Challenger Center, in remembrance of that day nine years ago, describing the Mission Centers that have been established in memory of the crew. These centers are networked together as a means of teaching young men and women the wonders of space exploration. As I read through this information, I kept returning to a quote from James Michener:

There are moments when challenges occur of such a compelling nature that to miss them is to miss the whole challenge of an epoch.

I wonder if one such challenge isn't Software Process Improvement. Could it be that those of us who miss this challenge will also "miss the whole challenge of an epoch" ?! Food for thought, isn't it?

In some of your letters to the SPIN Doctor, you voiced your frustrations stemming from your efforts to meet this challenge within your organizations -- efforts to establish management commitment, obtain peer buy-in, change corporate cultures. The following letter describes numerous attempts to establish an organizational process improvement culture.

Dear SPIN Doctor,

I have a very real example of a "problem" I have encountered at several companies. The problem I have run into is getting peer buy-in (i.e., fostering a "culture change") to software process improvement activities.

I have three different experiences at three different companies that have ended up in the same conclusion: Software Engineering Process Improvement will never work unless it is backed throughout the organization and in particular the software engineering practitioners.

From these experiences, I have realized that the software engineering practitioners need to experience software process improvement themselves before they believe (after all that is how I got involved) in the benefits. Here are some ideas I have tried (with minimal success) to help install software process improvement:

  • Get management buy-in, use industry statistics and metric data to show how process improvement can help save money. The key here is to relate all technical activities [to] money savings.
  • Realize that the software engineering staff will need to be trained in professional software engineering techniques. This is not a cheap undertaking.
  • Try to win confidence from peers by personally participating in an example of process improvement on your own project.
  • Get involved in professional societies and activities to validate [that] your ideas are also used elsewhere (SPIN, IEEE, NCOSE, ACM, etc.).
The problem I have run into several times is getting people to become software-engineering literate and to understand the benefits of professional software engineering and software process improvements. It seems to be viewed as "busy" work and not value added to the uninformed software engineer/manager. Sound familiar? Please give me you[r] insights about creating a software engineering culture and getting "peer buy-in". Thank you very much.

Kevin from Tucson

Dear Kevin from Tucson:

I'm going to attempt to answer your letter from my own personal experience.

First, I think that you attempted to address the areas that most influence the establishment of software process improvement within organizations:

  • management buy-in,
  • training program,
  • peer buy-in, and
  • organizational support.

All of these areas are ingredients in establishing a process improvement culture within an organization. But when I think of organizations that have been successful with process improvement, one of those areas becomes much more important than the others: management buy-in or commitment. Let me give you an example of what I am talking about.

I am thinking of a particular organization where management made the decision AND commitment to improve their software process. They established an SEPG and initiated a training program. The software practitioners complained bitterly when they had to endure certain of the courses, grousing that they would never have an opportunity to use any of the course material in the particular organization within which they were working; in other words, it was not very forward thinking. Management remained committed. They then required all projects to collect metrics consistently. The practitioners continued to complain.... Management remained steadfast and required more changes to be made. The organization, in spite of itself, continued to mature.

Around the time the organization was transitioning between Level 2 and Level 3, something happened -- a cultural change occurred within the organization. The practitioners started recommending courses to be added to the training program because they needed these courses to perform their work, projects started looking at and using the measurement information they were collecting, and on and on.... Now that's not to say that everyone lived happily ever after!! In cases such as this one, some practitioners will become believers and some will not. Those who do not become believers will either leave the organization for one more in keeping with their attitudes or find a place to remain hidden within the organization.

What I am saying is that peer buy-in will never be 100% even in the best of cases. The most you can do is hope to remove the negative influence of the non-believers.

I truly believe that in the above case, if management did not have a deep commitment to accomplish software process improvement that the organization, as a whole, would not have experienced the cultural change that occurred. Therefore, I think that the real key to successful process improvement is deep management commitment! It has to endure much. Practitioners cannot accomplish software process improvement without that commitment from "on high". What does that management commitment stem from? Sounds like the subject for another column to me.

Let's not "miss the whole challenge of an epoch". And let us all help each other meet this challenge head on! Let me hear your comments on this column or your questions on any other areas of process improvement. Send your comments or questions to "The SPIN Doctor": brodmanj@v3.hanscom.af.mil

The SPIN Doctor

Back to top

QUIPS, QUOTES, & ANECDOTES

Research is what I'm doing when I don't know what I'm doing.
Wernher von Braun

My biggest adrenaline rush as an inspections program leader was when I walked in to an inspection for which I was the document author, and the Moderator handed me a hard hat to wear. HE thought it was cute (it was his "trademark" as a moderator), I was dumbfounded and ticked off (it flew in the face of all our training about not making authors feel "cut out from the pack"). But I couldn't say a word. That would have undercut the moderator, it would have certainly disrupted the inspection meeting, and it might be interpreted as arising from personal defensiveness rather than the concern of a process steward, thus giving a black eye to the process group, of which I was a member. But I shudder to think of other authors, who might be less pro-inspections, being put through what amounts to hazing. Comments, anyone?

--My Hair Is Still Flat, Not Thirty Miles from Boston

[Share! Anonymity freely granted.]

Back to top

MASTHEAD

The Boston SPIN is a forum for the free and open exchange of software process improvement experiences and ideas. Meetings are held on third Tuesdays, September to June.

We thank our sponsors: GTE and Bull Information Systems.

Volunteers and new sponsors are always welcome. For more information about Boston SPIN contact Maureen Harris, GTE Building 5, Dept 0440, 77 A St, Needham Heights MA 02194; (617) 455-3393; Fax (617) 455-3377; Internet harris.maureen@mail.ndhm.gtegsc.com.

For information about SPINs in general, including how to start one, contact Dawna Baird of SEI, (412) 268-5539, dbaird@sei.cmm.edu.

IN THE SPIN is published monthly September to June. Letters, notices (including job postings), and contributed articles are welcomed. Articles do not necessarily represent the opinions of anyone besides their authors.

TO SUBSCRIBE send email address to price@sequoia.com (Ron Price). IN THE SPIN is available only by email.

SEND SPIN DOCTOR QUESTIONS to brodmanj@v3.hanscom.af.mil (Judi Brodman).

SEND letters-to-editor, notices (including job postings but not advertisements), calendar entries, quotes, quips, anecdotes, articles, offers, and general correspondence to Sallie Hoffman, (508) 369-2365, otter@world.std.com.

Return to Newsletter Index

Back to top