Directories |
Search U of M
|
|
|
|
|
||
|
|
TwinSPIN Newsletter: Volume 2, Issue 1January 1, 2000 Well, Y2K has happened. My expectation was similar to dental surgery; it has to happen, there's bound to be some pain involved, but it's not as bad as some believed and you'll survive. Looking at it from the perspective of software process improvement and software quality, what can we learn? One thing is shortsightedness. Like many quality problems, doing things the quickest and easiest way can cause expensive problems later. Another aspect is data quality; even if the code works, garbage data in means garbage data out. Lastly, it's great motivation for improving software quality; software problems usually gain much more recognition, albeit negative, than success. I could go on, but haven't we already heard / read / seen enough? To close, I believe there is a terrific upside to Y2K. We can get all the worry and work out of the way now so that next year, when it's really the start of the third millennium, we can fully enjoy it! May you, your families, and your business enjoy a Happy New Year! Thank you to Tom Gilb for again allowing us to use his excellent material. Thanks to Dave Kleist and Pat O'Toole, both local software professionals, for contributing their work to this issue. As always, a big thanks to Esther Derby for her editorial skills and her efforts to pull this newsletter together. Also, we received some suggestions on names for this newsletter from Chuck Davis - "NewsWeb" or "SPINaker". I thought of "SPINformation" and even "SPINews". What do you think? Send letters-to-the-editor, comments, questions, submissions, or anything else relevant to Pat Wegerson at weger002@tc.umn.edu or at 612-448-1335. Esther Derby can be reached at estherderby@worldnet.att.net .
Writers 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 612-448-1335.
TwinSPIN Meeting Topic: Software Test: Best Practices and Introduction to Testing
Maturity Model Meeting Directions: For maps:
12 Tough Questions by Tom Gilb [Editor's note: Process improvement champions or change agents must often ask - then answer - the tough questions about existing or proposed processes. Tom Gilb presents the dozen most relevant tough questions in the reference below.] In Tom Gilb's own words: Learn about Tom's 12 tough questions at: http://ourworld.compuserve.com/homepages/KaiGilb/12TOUGH.pdf Copyright (c) Tom Gilb. Used by permission of author. Tom Gilb is a freelance consultant, teacher, and author serving clients in Europe and the US. He has written "Principles of Software Engineering Management" and is the principal author of "Software Inspection". He specializes in software quality design and management. He lives in Norway, when he is not traveling. His newest book manuscript is "Competitive Engineering: A New Systems Engineering Approach for Controlling Complexity, Communicating Clearly, and Challenging Creativity." This and other of his artifacts are available on his web site at www.result-planning.com.
Study Groups and Process Improvement by Dave Kleist More, faster, better: most project managers have been encouraged to seek methods for improving the speed, accuracy, and quality of software development, but without altering the project deadline. Process improvement has never been easy, but trying to incorporate improvements while under stringent deadlines is a daunting challenge for any project manager. We'll look at one tool, study groups, that can be used to introduce new technical skills to a team with minimal impact to ongoing work efforts. In addition, we'll discuss some additional soft-skill benefits that result from the successful use of study groups. One of the problems with introducing process improvements to a team is the ability for each member of the team to understand the intent and purpose of the process improvement. Today's workforce is very mobile, with each member bringing different educational and occupational experiences to the team. Even something as straightforward as tool usage will have team members bringing a variety of experiences. When we look at software processes, we see a larger variance in experiences, even within the same company. Despite progressive practices from some companies, it is still very difficult to assemble a team that possesses shared experiences and a shared language. For almost any new project, we must allow for re-orienting each member to a new culture and new practices. This can be rough going for a freshly-assembled team that is still accountable for deliverables. Study groups can be an effective tool to quicken the acclimation of team members. Study groups are organized around the collective reading and discussion of a book. The group, usually 10 but never more than 15 people, meets weekly to review the latest assigned section of the book, discuss topics of the book, questions raised by the reading, and take notes on the discussions. The group has a moderator and a note-taker, but it is not required that each meeting have a specific agenda. The organizer of the group (usually the moderator) will section up the book into no more than 10 chunks to be read and discussed, and publishes the schedule in advance of the first meeting. The rules for running a study group are similar to those for doing a review: keep the language neutral, don't interrupt, have someone act as moderator, stay on topic (the book), take notes, and come prepared. Study groups often work well meeting over the lunch hour, with people bringing their lunch. (Some companies will sometimes support a group by purchasing lunch for the participants.) Run properly, the study group can achieve several goals. The most obvious one is the increased knowledge in the subject area of the book. This is often cited as the main reason for managerial support of a study group, especially when it focuses on new techniques or languages. The stresses of completing a project can sometimes overwhelm a team, precluding any efforts to introduce new processes or techniques. A study group offers the opportunity to learn the new technique or process in a non-threatening environment, allowing team members to become comfortable the new ideas. The group will develop a common understanding of how the technology or technique will work within their area, thereby improving the overall performance of the team. Another benefit is the improved communications for the team. Because the study group becomes a shared experience, the team members now have a common basis for communicating with each other. This will not improve all areas of communication, but it does allow normally separated team members to interact with each other. This can only benefit a project, as a time of crisis is usually not when we would want project members introducing themselves to each other. Lastly, a large but often unacknowledged benefit is supporting the team's education on functioning as a group. While some team members will benefit from the usual team-building efforts, others may not enjoy nor participate in what may seem non-essential soft skill activities. A study group can be a good method to pull in task-oriented team members, and allow all members to learn to function as a group. A study group can offer a controlled, non-threatening opportunity to learn how other team members think, communicate, and work. These are valuable skills for the team to acquire prior to those stressful, critical periods that exist in any project. Copyright (c) Dave Kleist 1999 Dave Kleist has been in the industry over 15 years.
He's held a variety of positions, including project manager, DBA, and training
manager. Currently Dave is working as a developer at Summit IT Consulting.
In addition, he
Do's and Don'ts of Software Process Improvement by Pat O'Toole [Editor's note: This is the first of several short articles on "Do's and Don'ts" from Pat O'Toole experience working in an SEPG. This is written for managers and SEPG members who are implementing CMM-based improvements in their organizations.] DO: Keep Your Eye on the Prize Imagine that six months ago, your senior management directed the SEPG to achieve CMM Level 2 within a year. As an SEPG member, you have invested extensive (some might say “excessive”) time and effort generating all the required policies, procedures, templates, measures, checklists, and training materials, but are having trouble getting the development projects to pilot and adopt any of these new process components. Being reasonable, proactive change agents, the SEPG solicits the sponsor's assistance. The sponsor eloquently reminds project personnel how important it is to reach Level 2 and urges them to be more open to helping the organization achieve this distinctive honor. The sponsor instructs SQA to be more aggressive in explaining the value of all the new process stuff and in identifying process deviants. But nothing really changes; the process assets continue to gather dust and the SEPG’s frustration continues to mount. Sound familiar? Why are the projects being so difficult and how can the SEPG achieve Level 2 if they don't get with the program? Why aren't they helping us achieve success? But wait a minute…why is the organization doing process improvement?
We're not REALLY doing it to “achieve Level 2," we're doing it to
improve. We shouldn't be forcing the projects to grunt through a pile of
administrivia to accommodate the CMM, we should be employing process aspirin to
relieve project pain. Perhaps we can exploit the CMM to help the projects
achieve greater success! Let's check this hypothesis by determining which
result is preferred: Unless there are compelling business reasons to get a particular CMM level (i.e., your customers will not allow you to bid on work unless you have been assessed at Level 2), answering “A” above means you've been in the Quality organization too long! On the other hand, if the SEPG continues to help the projects succeed, their value will be recognized and they will overcome much natural resistance to change. In addition, if the projects continue to demonstrate sustainable improvement, the CMM level will ultimately come. Remember that using the CMM is merely one tactic to achieve a higher-level (no pun intended) business strategy through the execution of successful projects. Focus the SEPG by changing the meaning of “SPI” to Software Project Improvement and creating an SEPG’s motto: “If we are not helping the projects achieve measurable improvement, we are failing!” Okay, so what is the higher-level business strategy? And how do we define project success? And what do we do with senior management's directive to “achieve Level 2”? These issues will be addressed by the next installment, “Do: Establish the Alignment Principle." Copyright (c) Pat O'Toole 1999 Mr. Patrick O’Toole, a Software Process Improvement Director and Lead Assessor with TeraQuest, manages major customer relationships, performs process maturity assessments, and helps establish process improvement programs at all levels of the organization. Pat works with executives of companies implementing process improvement, to foster speedy commitment and visible leadership. He also serves as an “executive coach,” providing objective feedback and advice to senior executives in formulating and accomplishing their strategic business objectives. A popular instructor, he also provides CMM-related training and coaching. Pat's professional experience includes more than 14 years managing design and implementation of MIS/IT development and support activities, as well as software engineering projects for commercially-available products at Unisys Corporation. While at Unisys, he served as chief negotiator and project manager for a strategically important, multi-million dollar imaging project with the Federal Reserve Bank and U.S. Treasury. Prior to joining TeraQuest, he provided independent consulting services for three years in the areas of project management, software risk management, quality assurance, system test, software metrics, and software process improvement. Pat O'Toole can be reached at:
Web Picks by Pat Wegerson In last month's Web Picks, Esther Derby offered a links page on software testing. This month, I'd like to continue that approach with my favorite link page on software configuration management (SCM). While researching for a presentation on SCM planning, I stumbled across a gold mine. To paraphrase Johnny Carson's famous line: Everything you ever wanted to know about SCM is linked to this web site: www.cs.colorado.edu/users/andre/configuration_management.html . This web site is an incredible resource on a wide variety of SCM-related topics. It is sponsored by the Software Engineering Research Laboratory of the University of Colorado and is maintained by André van der Hoek. Because of its source, the information is provided objectively without promotion or preference. Looking for general information on SCM? There are over 50 links to general and vendor papers on the subject. There are also links to Honeywell's CM FAQ page for introductory SCM information. Looking for an SCM tool, either commercial or public domain? There are links to over 100 tools to automate various SCM activities. Did you know there is a CM conference in Minneapolis this June? I didn't, until I re-visited this web site to write this review. In last month's Web Picks, the Internet was likened to a library with all the index cards scattered. I often view the Internet as a mine where the right tools, a keen eye, and a dash of luck will yield a valuable find. I consider the University of Colorado's SCM links page to be a big gold nugget. Copyright (c) Pat Wegerson 1999
Announcements & Calendar Recent and upcoming U.S. SPIN meetings:
About TwinSPIN For the Minneapolis/St. Paul Regional Area TwinSPIN Mission Statement Meetings are normally held on the 1st Thursday of each month from 6-8 PM. TwinSPIN web site: 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. |
|
|
||||
|
