University of Minnesota
Twin-SPIN
/

You are here

TwinSPIN Newsletter: Volume 2, Issue 4

Editor's Note

This TwinSPIN Newsletter did not arrive earlier in the month as had been
planned. Your newsletter editors have continued to be challenged by their day
jobs, including intense work situations and extended travel to far-off lands.
Unfortunately, these tasks and the resulting income tax filing extensions
and jet lag take precedence over volunteer efforts. This newsletter is the May -
June 2000 issue. In keeping with the tradition of many SPINs' meetings, and to
allow your harried newsletter staff sufficient time to rest and regroup, there
will not be a summer issue covering July and August. The next issue, covering
September - October 2000, is planned for distribution in early September. Thank
you for all the support and encouragement you give us as we work to bring you a
quality newsletter in a timely fashion.

As always, many thanks to our talented contributors: Duncan Stickings,
compliments of SPC E-ssentials!; Pat O'Toole of PACT; and Larry Boldt of TBI for
providing articles to the TwinSPIN newsletter. Also thank you to Esther Derby
for coming through with a book review and for pulling together once again to
publish this newsletter.

Send letters-to-the-editor, comments, questions, submissions, or anything
else relevant to Pat Wegerson at weger002@tc.umn.edu
or at 952-448-1335. Esther Derby can be reached at estherderby@worldnet.att.net
.

TwinSPIN Meetings

May Meeting:
Topic: Requirements Capture: Some simple steps towards quality
requirements
Speakers: Mats Heimdahl
When: Thursday, May 4, 2000
Where: University of MN, Electrical Eng/Computer Science Hall
Sponsor: StorageTek, Gordon Dosher
Program Director: Mats Heimdahl

June Meeting:
Topic: Checklist Sharing
Speaker: Burke Maxey, BF Goodrich
When: Thursday, June 1, 2000, from 6 - 8 P.M.
Where: University of MN, Electrical Eng/Computer Science Hall, Room EE/Csi
3-180 (Minneapolis, MN)
Sponsor: Keane, Lee Peterson
Program Director: Burke Maxey

Meeting Directions:
Please check out the maps (see below) or contact Jesse Freese (612-882-0800 or Jesse_Freese@Fissure.com)
if you need additional directions.

For maps:
1. Browse to http://www1.umn.edu/tc/maps/EECSci/
2. See more detail in the "Close up view" at http://www1.umn.edu/tc/maps/EECSci/EECSci-map.html.

About TwinSPIN


For the Minneapolis/St. Paul Regional Area

TwinSPIN Mission Statement
--------------------------------------------------------------------------------
The TwinSPIN software process improvement network (SPIN) is a regional
organization established in January of 1996 as a forum for the free and open
exchange of software process improvement experiences and ideas. Representatives
from industry, government, academia, other professional organizations, and
consultants are welcome to participate. Our mission is to help sustain
commitment and enhance skills in the area of software process improvement
through an active program of networking and mutual support. The organization
strives to serve as a source of educational and experiential information for its
members, other SPIN organizations, and the general community of software
professionals. (May 1996)
--------------------------------------------------------------------------------

Meetings are normally held on the 1st Thursday of each month from 6-8 PM.
TwinSPIN is a non-profit organization.
============================================================================

All articles, reviews and commentaries are copyright by the authors, unless
otherwise noted. All rights are reserved to the authors. We encourage sharing
the TwinSPIN Newsletter in whole or in part if copyright and attribution are
always included.

Writer's Guidelines

The goal of the TwinSPIN Newsletter is to provide articles and information
with a real world perspective that will be useful to you, the readers. And who
could know more about real world software process improvement than the members
of a SPIN? If you've ever had the urge to be an author and have an insight you'd
like to share, consider writing an article for the Newsletter!

In general, articles should be fairly short, not more than 1000 words (since
the Newsletter is distributed electronically, we can't accommodate graphs and
figures at this time). We're looking for articles with a "how-to"
bias, and we also like to put a lighter piece in each issue. Articles that are
academic or commercial are less likely to be of interest.

If you have an interest in writing an article or contributing one that has
been previously published, please contact Pat Wegerson at weger002@tc.umn.edu
or at 952-448-1335, or contact Esther Derby at estherderby@worldnet.att.net.

Mentoring: Building the
Stars

by Duncan Stickings
Alpine Training and Development

[Original Editor's note: The author refers to the person being mentored as
the mentee in keeping with current practice in the area of mentoring.]

As a project manager in a software company one of the biggest challenges is
to find and keep good people. In the high-tech industry, there is more than
enough work to go around for good people and we scramble to find enough people.
We (the industry) have plenty of projects with paying customers, and they always
want things done yesterday. The challenge is to ramp up a project team with
enough talented people to get the job done. The next challenge is to keep your
good people from leaving your company for another one.

Resources vs. stars

In a typical company, people are called resources. You staff a project with
these resources, assign them tasks, and track their progress via a series of
status reports and status meetings. If you are lucky you find resources who have
appropriate skill sets that match your project needs. If not, you send them on
training courses, or expect them to pick it up on the job.

That sounds pretty impersonal.

A large company I know talks about putting "stars" on their
projects. A star is a kind of person who will make magic happen and brings the
project through to a successful completion. Without a star, a project was
doomed. With mentoring, you are in the business of developing stars. If you
think of great people, there is likely a mentor behind them that helped them
rise to greatness. King Arthur had Merlin, Luke Skywalker had Obi Wan Kenobi and
later Yoda.

In our industry, there seems to be no end of potential stars. What we need
more of are mentors who can develop those people into stars. I believe the role
of project manager includes being a mentor.

What is mentoring?

To mentor another person takes time and effort. It is much more personal than
just scheduling and tracking to a project plan. It requires "soft
skills" that are sometimes undervalued (wrongly!) in a predominantly
technical environment.

In their book, Mentoring, authors Huang and Lynch talk about mentoring
as a kind of dance like in Tai Chi. Both the mentor and the mentee enter into a
unique relationship, where both give and receive wisdom.

Mentoring is more than a weekly status meeting. I would say it involves
creating a mutual learning environment. On an ongoing basis, you are seeking to
develop the mentee, to help guide the mentee on a journey of learning and
adventure.

There is a shift in your focus when you become a mentor to another person. As
a mentor, your focus is on the development of the person, as opposed to the
successful completion of projects. This can be a difficult shift to make, since
it is hard for a project manager to see beyond their schedules and delivery
dates. The truth is projects will come and go, but people should be around a lot
longer. You have to really care about their personal and professional
development. You have to be their supporter and believe in them.

The benefits of mentoring

Studies show that one of the biggest motivators is not money, but recognition
and respect. Being a good mentor to a person shows you care and respect them.

Ken Blanchard in his book The One Minute Manager said that people who
feel good about themselves perform better. Mentoring when done right, is a major
contributor to helping people feel good about themselves. If you want to
increase software development productivity, be a mentor to your people.

Another factor is retention of key people. It is always an interesting
indicator to see a project with high turnover. It tells me that people are not
getting their needs met on that project or in that company. As a mentor, it is
important to find out the needs of your mentee and help them to achieve those
needs. As I said, it is often recognition and respect.

If you create a mentoring culture, you will actually create a place where
people will want to work. Good people will hear about it and will be applying to
join your project/company.

So bottom line, mentoring helps to find and keep good people, to develop
stars, and to increase productivity.

Starting to mentor

If you want to get started in mentoring, here is a simple plan:

1. Read some of the books on mentoring to develop an understanding. (See
Mentoring page on SPC's online Resource Center for a list.)
2. Assign a mentor to each person in the company, including yourself.
3. Mentor and mentee should meet for up to an hour at least once a month or as
needed.
4. Start by going over the mentee's goals, help develop a plan of action.
5. Leave it up to the mentee to work on the goals, but hold them accountable.
Expect them to make progress since the last session.
6. Don't expect to have all the answers, be prepared to learn something
yourself.

This article came from Software Productivity Center Inc.'s E-ssentials!,
a free, biweekly e-newsletter with how-to's for successful project
management and practical software development.


Do's and Don'ts of Software
Process Improvement #4

By: Pat O'Toole (PACT.otoole@worldnet.att.net)
Process Assessment, Consulting & Training (PACT)

[Editor's note: This is the fourth of several short articles on "Do's
and Don'ts" from Pat O'Toole's experience working in an SEPG. This is
written for managers and SEPG members who are implementing CMM-based
improvements in their organizations.]

DO: Align the Reward System

As the annual meeting is called to order, the entire software development
staff settles into their auditorium seats. The Vice President of Software
Engineering covers both the quarterly and annual results, and the need for
continued process improvement becomes evident - although project results are
more positive than those attained last quarter, they are still below
competitors' levels and well below "world class". The VP stresses the
need for continued reduction of field-reported defects as the next quarter's
stretch goals are presented.

A hush falls over the crowd as the VP prepares to announce the winner of the
quarterly achievement award. The prestige associated with winning this award is
legendary, and the $5000 check that accompanies the plaque doesn't hurt either.
Although many of the projects met their committed dates, two project teams
worked incredibly long hours to accomplish their respective missions. The only
remaining question was upon which project team would management bestow the
award.

As the honored recipient is named, the crowd utters a collective gasp. Their
minds emerge from the fog of stunned disbelief to hear the VP saying, "...
having analyzed the project's historical peer review data to determine an
expected range of defect density, she then piloted an approach to re-inspect
work products when an insufficient number of defects had been detected. By
identifying and resolving more of the defects in the same phase in which they
were inserted, the project was able to meet the committed ship date without
incurring significant overtime. Let's all show our appreciation for a job well
done!"

It could happen! Senior management could actually change the reward
system to be more closely aligned with the behavior they would like people to
exhibit. After all, anything is possible!

Unfortunately for many organizations, it hasn't happened yet. Think back on
the last few achievement awards presented in your organization. Who received
them and why? More importantly, why do people perceive they were bestowed
on the recipients? Forget what senior management says about the
importance of process improvement, what subliminal messages to they send through
the recognition and reward system?

There are two critically important lessons buried in here somewhere. An
archeological dig would uncover:

  1. Perception IS reality to the perceiver; and
  2. The behavior you reward is the behavior you're gonna get!

The reward system provides the most tangible evidence of what senior management
wants the organization to be when it grows up. If senior management truly wants
to transform the organization, they have to take a hard look at the existing
reward system and ensure that it is rewarding the desired behavior, and
discouraging the behavior they are trying to eliminate.

Copyright (c) PACT 2000

Pat O'Toole is a Principal
Consultant at Process Assessment, Consulting & Training (
PACT)
where he provides a variety of services to his process improvement clients. Pat
is on the SEI's list of most active lead assessors, and has led assessments
spanning all maturity levels, including the largest Level 5 assessment conducted
to date.

With over 20 years of software
development, project management, and consulting experience, Pat works with all
levels of management, SEPGs, and Process Action Teams in establishing,
evaluating, and sustaining their process improvement initiatives. He is a
popular instructor who supplements standard training material with his vast
array of case studies and humorous examples.

For more information contact:

PACT
1316 Summit Oaks Dr.
Burnsville, MN 55337
Toll free: (877) 432-PACT (7228)
PACT.otoole@worldnet.att.com

Potential Ambiguities in
Specifications

By Larry Boldt
Technology Builders, Inc.

[Editor's Note: This "List of Potential Ambiguities in
Specifications" was provided by Larry Boldt of TBI following his April 2000
TwinSPIN presentation entitled "Requirements Management: An Object-Oriented
Approach". This list is Larry's compilation of potentially ambiguous terms
that nevertheless appear frequently in software (and other) requirements
specifications. Try searching for these in the next specification you review -
or the next specification you write!]

Dangling Else
can be, could be, is one of, must be, shall, should be, will be

Ambiguity of Reference
it, such, the above, the previous, them, these, they, this, those,

Ambiguous Adjectives
all, any, every, few, many, same, several, similar, some, the complete, the
entire

Ambiguous Adverbs
accordingly, almost, approximately, by and large, commonly, customarily,
frequently, generally, hardly ever, infrequently, just about, more often
than not, more or less, mostly, nearly, not quite, often, on the odd occasion,
ordinarily, rarely, roughly, seldom, sometime, somewhat, typically, virtually

Ambiguous Variables (project specific)
data, rule, status, value

Ambiguous Verbs
adjust, alter, amend, calculate, change, compare, compute, create, derive,
determine, enable, indicate, manipulate, match, modify, perform, process,
produce, support, update, verify

e.g. versus i.e.
e.g., i.e.

Implicit Cases
also, although, as well, besides, but, even though, for all other, furthermore,
however, in addition to, likewise, moreover, notwithstanding, on the other hand,
otherwise, still, though, whereas, yet

Logical Operators
and, neither, nor, not, or

Temporal Ambiguity
after, at a given time, at the appropriate time, daily, fast, in a while, later,
monthly, quickly, soon, weekly, yearly

Totally Ambiguous
etc., sentences that end with ?

Copyright ©
Larry Boldt 2000

Larry Boldt is a co-founder of TBI and is an accomplished
information engineering manager and engineer with over 26 years of experience in
managing and providing business process reengineering (BPR) services to
corporate and government clients. TBI's clients rely on his ability to
synthesize TBI's requirements management process with their system development
process as an integral component of every software development project.

Larry's primary areas of functional expertise at TBI
include: requirements management, requirements-based testing, business process
reengineering (BPR), software quality management, system implementation and
training development. Managing a team of 25 consultants and engineers, Larry
provides process management engineering expertise to improve clients' short-
and long-term business performance and meet the standards of the Capability
Maturity Model (CMM) set by the Software Engineering Institute.

Prior to forming TBI, Larry was an Army officer where he
designed and deployed information systems for 17 years. He then moved on to
consultant work focusing on BPR and system development. Prior to TBI, Larry was
a senior consultant at KnowledgeWare, where he guided customers in successfully
implementing state-of-the-art computer software technology for client/server
application development.

Given his scope of expertise, Larry is a prolific public
speaker, having lectured at engagements such as Intersolv's International User
Conference, Mercury Interactive's International User Conference, Software
Quality Week, Software Process Improvement Network and the Atlanta Quality
Assurance Association. Larry's discussion topics focus on quality-driven
requirements management, component-based development, test management and test
automation.

Larry holds a BA degree in Business Management from St. Leo
College, and an MS degree in Management from Maryville University. Larry can be
reached at:

Technology Builders, Inc.
400 Interstate North Parkway
Suite 1090
Atlanta, GA 30339
770-937-7900
www.tbi.com

Software
Requirements
by Karl E. Wiegers

Reviewed by Esther Derby
© 2000

Requirements are the cornerstone of software development. Without good, solid
requirements, elegant design and state of the art technology don't add up to
much. Karl Wiegers' book, Software Requirements (Microsoft Press, 1999)
is an ambitious undertaking. He promises useful information for analysts,
developers, testers, customers, users and project managers -- "anyone
involved with defining or understanding the requirements."

With a promise like that, I want to know if a book delivers: is there
something in this book that I can use in the here-and-now to help my clients
"do requirements" better and improve on quality, costs or schedule
performance? The answer for Wiegers' book is "yes." I have adapted
material from this book to use with clients, and I'll wager it's already saved
them more than the $34.99 purchase price of the book. That said, for
skill-related areas (gathering and analyzing requirements) this book isn't
enough.

Wiegers covers the entire life cycle of requirements and gives an overview of
key requirements topics: how requirements fit into the development cycle, how
different types of requirements relate to each other, techniques for gathering,
documenting, analyzing and managing requirements.

Wiegers starts from the position that most organizations can improve the way
they gather, document and manage requirements, and provides guidance on just how
to do that. Chapter 4, "Improving Your Requirements Processes" gives
advice on approaching an improvement process. Consciousness of the improvement
process carries thought the book: there's a "Current Requirements Practice
Self-Assessment" in the appendix and each chapter ends with a short section
on "Next Steps."

The book is structured with many entry points for the improvement process. I
like this because it encourages making whatever improvement is reasonable and
possible at the time. If a project is in the build phase, in most cases it
doesn't make sense to go back and improve the way requirements documentation is
written (unless the requirements documentation is so poor it can't be used).
There are other improvements that can be implemented even in projects already
underway. Impact analysis, for example, will help to quantify the effect of
changing requirements and may help point out the costs of missed or ambiguous
requirements.

Here are some highlights:

Chapter 17 describes the roles and responsibilities of the Change Control
Board and Change Control process. I find Wiegers' description more robust and
useful than similar descriptions I've come across in project management
literature. In Chapter 18, Wiegers' provides checklists for analyzing the impact
and effort that have been immediately useful: I've adapted the checklists for a
client who is now using them to overcome the notion that "it's just one
line of code, it will only take 5 minutes to make the change."

Chapter 13 covers requirements prioritization. In general, the prioritization
methods Wiegers presents make common sense: prioritize early in the project
using an agreed-upon scale. Definitions for several three-point scales are
listed. Wiegers also describes a weighting scheme based on TQM that computes a
numeric ranking for each requirement. In my experience, the trade-offs are
seldom so cut-and-dried, and the discussion that goes into the ranking more
valuable than the resulting spreadsheet.

Software Requirements talks about processes: step-by-step activities
that produce an output. There are two arenas covered in the book where process
is necessary, but not sufficient. In my experience, requirements
gathering (Wiegers uses the term "elicitation") and analysis require
skills that go well beyond a defined process.

Gathering good, unambiguous requirements is a skill that is developed through
practice and experience. It's not something you can learn out of a book. Software
Requirements
acknowledges that elicitation is "the most difficult, most
critical, most error-prone, and most communication-intensive aspect of software
development. Elicitation can only succeed through an effective
customer-developer partnership." Yet only a small portion of the section
speaks to those challenges. The bulk of the chapter describes documenting
requirements with Use Cases.

The sections on requirements analysis models gives examples and descriptions
of various types of models (data flow diagrams, entity-relationship diagrams,
dialog maps). I wouldn't expect someone to be able to use one of these notations
after reading the book. However, the point of doing analysis models is to better
understand requirements and make the translation between needs and design. So
perhaps the activity of drawing a view of the system will be helpful, if the
model is understandable to both the developer and user, whether or not it
follows a particular notation.

In spite its shortcomings in covering elicitation and analysis, Software
Requirements
provides solid information on requirements practices and making
process improvements. You can expect to get more than your money's worth in cost
savings by adopting and applying the checklists, document templates and other
practices described in this book.

Esther Derby works with software development
managers and project managers to get projects on track. She focuses on helping
her clients become more effective in managing complex systems -- like software
development organizations and software development projects. Esther can be
reached at derby@estherderby.com or
612-724-8114.

Date: 
2000-05-01T00:00:00