Date: Wed, 3 Jun 1998 19:56:39 -0400 From: Daniel Forrest Allen Subject: IN THE SPIN, Issue 18 | IN THE SPIN, Issue 18, May 1998 | | Newsletter of the Boston Software Process Improvement Network | -------------------------------------------------------------------------- CONTENTS Notices Meeting Reports Masthead -------------------------------------------------------------------------- NOTICES June 16 (Tuesday) -- Next Boston SPIN meeting, 6:30-8:30pm 6:30-7:00 Networking, Networking Round Tables, and Refreshments 7:00-7:15 Introduction: Barbara Purchia 7:15-8:30 "Ten Things Every Project Manager Should Know About the Project Management Institute's Project Management Body of Knowledge Guide" Guest Speaker: William R. Duncan, Project Management Partners The Project Management Institute's "A Guide to the Project Management Body of Knowledge" documents generally accepted practices of project management. It is the only project management standard recognized by the international project management community. Over 100,000 copies are currently in print. Nearly 4,00 people download some or all of the document from PMI's web page each month. An ISO technical committee used it as the basis for "Software Project Management Guidelines" in support of ISO 12207. Yet despite the acclaim, some of the most valuable insights into the process of project management have remained buried in the understated style of the document. In this presentation, Bill Duncan, the primary author of the document, will both identify and explain ten of these nuggets. Good project management is fundamental to a repeatable process. Every SPIN member should be familiar with this project management standard. William R. Duncan is a principal of Project Management Partners, a project management consulting and training firm head quartered in Lexington, MA USA. He is the Director of Standards for the Project Management Institute (PMI), a member of the Editorial Review Board of the Project Management Journal, and a certified Project Management Professional (PMP), and was the primary author of PMI's, "A Guide to the Project Management Body of Knowledge". He has worked with numerous clients in the US, Canada, Australia, and Europe to improve the performance of software development project teams. Location: GTE, Building #5, 77 A Street, Needham, MA (Wheelchair accessible) INFO: Maureen Harris (617) 455-3393, maureen.harris@GSC.GTE.com or Ken Oasis (617) 563-4197, ken.oasis@fmr.com ********************** DECEMBER 16 MEETING REPORT by Carol Pilch "QFD and Software Development: So, what's the problem?" By Lou Cohen - Consultant The presentation began with an overview of QFD, followed by a discussion of where software engineers have trouble with QFD, and concluded with "where to go from here" or how to go about using QFD. QFD or Quality Function Deployment was first used by the speaker at Digital in the context of hardware development. Interestingly, the speaker pointed out, individuals who build hardware take more readily to using QFD than individuals who develop software. Overview of Quality Function Deployment This part of the presentation described the basics of QFD. QFD can be characterized as "The House of Quality", a house consisting of eight sections or rooms. In effect, each room represents a snap shot of strategic and detailed project planning. The speaker noted that, since he has been a consultant, he has learned that all of the "rooms" have great value. Room 1 - the voice of the customer. Concepts important here are expressing the customer's needs in the customer's language, focusing on needs and benefits, not solutions, and grouping needs into a hierarchical structure. Room 2 - required characteristics. These are best expressed as measurable performance characteristics of the product. Focus should be on identifying performance measures that drive customer satisfaction. Room 3 - relationships. This "room" provides a model for assessing the impact or "degree" of customer need. Focus is on identifying strong drivers of customer satisfaction in pairing technical requirements with customer needs. Room 4 - customer perceptions and goals. This is used to develop a product strategy and understand the market. It includes rank-ordering customer needs. Room 5 - technical benchmarks. The prioritization of customer requirements drives this. Bench marking is performed only on the most important required characteristics. This can be used to measure the competition's products as well as ones own products. Room 6 - correlation of required characteristics. This "room", although the least used part of the House of Quality, allows one to see the relationships between technical characteristics. Each requirement is compared with every other requirement. Room 7 - importance ratings. This provides the rated importance of requirements. Room 8 - targets (for performance). Set aggressive goals where the impact will make the product competitive as determined by the House of Quality information. At this point in the presentation, the House of Quality concept applied to software implementation was described. QFD is used as the method to analyze system requirements and prioritize the requirements. System requirements as prioritized are then flowed down to data requirements and functional requirements for the software. Sub-system and/or object requirements can be derived from an analysis of the functional requirements and the data requirements. This is accomplished by grouping functions together that share the same data. A side benefit of this analysis is that customer priorities can be used to determine the testing that really matters to the customer. Testing can then be prioritized which may, in fact, be necessary when there are limited test resources. The basic benefits of QFD are that QFD 1) provides of common understanding of, consensus about, and commitment to the product; 2) builds teams and a common vision; and 3) ensures that all aspects of product development are responsive to the customer needs. Where Software Engineers have trouble Two areas of difficulty were identified. The first, difficulties with customer needs, includes failure to distinguish between customer needs and solutions and poor interview technique. The second, difficulties with product requirements, includes jumping too quickly from high-level to detailed implementation (need to insert an intermediate level between requirements and code) and using an inappropriate language for requirements. With regard to interview techniques, the presenter recommended: 1) decide on the customer, 2) select a good customer cross-section, 3) interview at least some on-site, where they work and as they work, 4) ask open-ended questions, and 5) record interviews and study transcripts. The speaker addressed the disadvantages of using functions as requirements. The basic pitfalls are that the analysis becomes skewed to binary decisions (i.e., the function is there or it is not) and that function names may appear to be clear and unambiguous but they are not. Requirements are best stated as measurable performance characteristics. Advantages to this approach are that 1) measurement data is on a continuous scale (i.e., avoids binary decisions and facilitates prioritization), clear system objectives are identified without locking in a design, competitive bench marking becomes feasible, and requirements can be re-used in future implementations. Where to go from here Use QFD to create a structure for the product planning process. The structure will provide a systematic approach and promote both teamwork and communication. The results using QFD will be better products developed faster and with less cost. Q&A: Question: What are your (speaker's) comments regarding bringing a customer in house to do QFD? Answer: It's a good idea. However, it would depend on the product. Use market research to make sure that you bring in the "right" customer. JANUARY 20 MEETING REPORT by Carol Pilch "Deep Dark Secrets from the Software Process Improvement World" Guest Speakers and Audience Participation facilitated by Donna Johnson "Range Estimating" Wm. Duncan, Project Management Partners Problems with a single point estimate include the assumption that the target is a mean of a normal distribution and that over time the possible outcomes fall into a normal distribution. A single point estimate leads to communication problems because the single point converts to a price. This does not represent the real world. Estimates should be provided as ranges: optimistic, most likely, pessimistic. Range estimates promote better manager-doer communication. Boundaries of acceptable performance are defined as opposed to a single target value. The team is reminded of uncertainty inherent in estimates. In addition, range estimates improve team morale, the quality of planning decisions, and the accuracy of reporting. "A Massachusetts Software Benchmark Study" Carl Foote & Anne Lowenthal, QSM Associates, Inc. QSM is conducting a software benchmark study, and Massachusetts software companies are invited to participate. The objectives for the study are to establish a Massachusetts Software Reference Database, determine the competitive position of Massachusetts in the software industry, and provide a private report for each participant. The database will initially be established as a minimum data set: size, time, effort, and defects. Resulting productivity indicies will be calculated based on application type. QSMs already established database spans over 18 years. It is a large heterogeneous database and contains over 4,800 projects. It is a representation of over 290 million SLOC, 3 million function points and over 200 languages. QSM adds 200-400 projects each year. Data may be submitted through February 28th. Data will be presented in the May-June time frame. "A Metrics Template" H.S. Lahman, Teradyne/ATB The template was developed as a standard for defining and reporting metrics. In addition, the template proved to provide a checklist for the metrics activity. The template was used by hardware and software from the onset of the definition and use of metrics. The template includes: name of the metric, purpose, technical description, example, interpretation, limitations, revision history, and responsible or owning group. By using the template approach, the metrics program was successfully implemented. This activity started over ten years ago and has been ongoing since then. This demonstrates the achievement of the original goal to institutionalize metrics. The metrics themselves have evolved over time but the template is still used. "Managing Product Development Process, Product & Continuous Improvement" Ken Martin, Independent Consultant The process described by the speaker begins by specifying the organization's core development processes. The process specifications include: the process for process specification, the process for project planning, the process for project management, and the process for process improvement. Specifications are then reviewed, approved and archived. The next step is to automate as much of project planning and project management as possible. Automated processes for project management include: flow of work and updates to schedules, detection of bottlenecks and problems, schedule improvements, and measurement and reporting. This automation is achieved through the use of hyper-linked multi-media messages and e-mail. Work management tools manage the flow of work, record starting and stopping of tasks, pass this information to an automated process that keeps metrics, project plans, process history, and management visibility continuously up-to-date. Work specified by each project task is organized into a step-by-step set of instructions, packaged into a hyper-linked multi-media message and e-mailed to the resource assigned to produce the task. The document management system provides the user with step-by-step guidelines for using the tools to produce the desired work. "Scheduling Forwards using the Yellow Sticky Method" Steven R. Rakitin, Software Quality Consulting Projects are typically given an end date and scheduling backwards occurs. The result demonstrates that a lot can go wrong. This talk is about scheduling forward. The process for scheduling forwards begins with a complete SRS. The SRS is critical. Marketing identifies those requirements that are must haves and those requirements that are wants. The company commits only to the must haves not the wants. Project teams then work the schedule using yellow stickies to identify on a schedule the specific tasks they need to perform. Many rules apply to decomposing the schedule. Tasks should be from 1-5 days in duration. If longer then 5 days, they must be decomposed into subtasks. The 80% rule for time utilization applies (account for time on the phone, etc.). Days off must be included in the schedule. The team then works the schedule on a large wall chart and works together to optimize the schedule. Constructive criticism is welcomed, and the approach is iterative. The result is a realistic schedule that everyone has bought into and the project is then managed to the schedule. "Easy Project Intranet Site using Visual Source Safe" Johnathan S. Watson, Software Innovation Consultant The speaker described a project intranet site that was built on Windows NT. The resulting system is used for project documentation and communicating status such as build status and change history. Links were established from the home page to the build directories and the documentation. The project required 5-10 person days to setup and maintenance is minimal. "SEI CMM Maturity Success" Nicole Bianco, Cable Data Products The organization's goal was to achieve level 3 in 30 months. A team approach was used so that improvements would be driven by people in the departments doing the work. SEI Coordinator provided the guidance. 100% staff and management participation was required. The staff was assigned to teams by interest and expertise. The managers were assigned as coaches to the teams. New processes were implemented using peer review and training. Processes were implemented in phases, not all at once. New methods were to be used as soon as they were made available. The cost of improvement was 13 man years of effort. 4% of the experienced staff left the organization. The customer was frustrated. The Return on the investment was attainment of level 3 in 28 months. The organization developed a better way of working (teaming). The quality of life of the employees improved. New employees became productive quickly. Customer comfort level and satisfaction improved. Productivity improved 2.9X and quality improved 3X. "What is a Reasonable Structure for a Data Object?" Ed Lowry, Advance Information Microstructures Six constraints on data object structure were presented by the speaker 1. Objects connect to each other, not storage space - eliminates insertion and deletion complications. 2. Connective only, no internal state - eliminates encoding of internal state. 3. Asymmetric connection - needed for deterministic interpretation. 4. Interconnected in hierarchies with ordered children - hierarchy eliminates redundancy; uniform iteration allows "functional expressiveness". 5. Connection ONLY to neighbors in hierarchy, class identifiers, realtees of relationships - empirically based; the main open issue. (speaker cannot prove that no other connections are needed). 6. Connection ONLY to -neighbors in hierarchy, at most one other object - there is a small advantage in decomposing more complex objects. Complexity reductions become possible when optimum data objects are used. This results in more practical reuse and contextual adaptation. Technological stability results from near optimum design. In addition, learning burdens are reduced using complete, readable, integrated descriptions of technical subject matter. Working carefully with anything requires control of fine structures. APRIL 21 MEETING REPORT by Maxine Crowther "Reuse and Standards" by Dr. Carma McClure Dr. Carma McClure, Chairperson of the IEEE Reuse Processes Working Group, gave a very compelling case for the practice of reuse and for the standards that her IEEE working group are compiling. Companies like AT&T, GTE, HP, IBM, NEC, and Toshiba are getting results from component reuse that tell an exciting story. They are finding that quality has risen 5-10%, that maintenance costs are less by 2-10%, that development cost are less by 10-15%, and that 60-70% of their functions are common. Components are defined as supporting common functions or features, having well-defined interfaces, having interoperability, fitting into an architecture, and being used in multiple systems. Architecture-driven construction of products using component-based development is quicker, simpler, more adaptable, and is the only technology that addresses cost, time, flexibility, and quality at the same time. But components are totally dependent on standards such as for interfaces. Process standards are also required such as the types of components and what activities are required for identification and construction. In an industry which is growing very quickly in both sales and service, component engineering needs to have standards in order to survive. Dr. McClure then discussed reuse in terms of process quality. The CMM standard, she says, looks at reuse at level 4 (only 2.3% of companies are at this level). She, however, says that elements of reuse should be located between level 2 and 3 where almost 40% of companies could benefit. The standards that her working group are proposing will change the way the software process life cycle is used. It will provide a framework, a minimum set of processes, activities, and tasks that need to be considered, it will promote and control the practice of reuse, define common terminology, and can be used by those who acquire, supply, develop, and maintain reusable components. The life cycle must now consider components for reuse during the planning phases of projects over time. It will be especially useful in large domains like wireless communications where components may be developed for use as well as sale to others. The characteristics of reuse thinking include themes such as taking advantage of existing components and looking for opportunities to create them; requirements which are imposed on the life cycle over time; and views such as whether you are a producer or a consumer of components. In a life cycle where strategic planning is done at the top level, the addition of a reuse plan and its associated infrastructure is advocated. A second level focuses on domain engineering, (such as wireless communication mentioned above) a new concept, which would focus on design for components, searching for candidates, integration, and evaluation of cost/benefit. The third level, the project would have a standard plan, analyze, design, implement, and maintain cycle with a mini-cycle focused on reuse that would include find, select, modify, integrate, recommend improvements. To read the new standard, called IEEE Reuse Software Standard 1517 - Standard for Information Technology - Software Life Cycle Processes - Reuse Processes, check out the WEB site http://rsc.asset.com/ ********************** MASTHEAD The Boston SPIN is a forum for the free and open exchange of software process improvement experiences and ideas. Meetings are usually held on third Tuesdays, September-June. We thank our sponsors: GTE and U/Mass at Lowell (our Web page host). For information about SPINs in general, including ***HOW TO START A SPIN***, contact: DAWNA BAIRD of SEI, (412) 268-5539, dbaird@sei.cmm.edu. Boston SPIN welcomes volunteers and sponsors. For more information about our programs and events contact: CHARLIE RYAN, The Software Engineering Institute (SEI) ESC/ENS (Bldg 1704), 5 Eglin St, Hanscom AFB MA 01731-2116; (617) 377-8324; Fax (617) 377-8325; ryan@sei.cmu.edu. IN THE SPIN is published quarterly September-June. Letters, notices, and contributed articles are welcomed. Articles do not necessarily represent the opinions of anyone besides their authors. IN THE SPIN is available by email and on our Web page. TO SUBSCRIBE send email addressed to danallen@ma.ultranet.com. We have 2 separate email lists: one for this newsletter and one containing announcements that we receive from other process organizations and forward out. TO ADD YOURSELF TO THE ANNOUNCEMENTS LIST send email to ryan@sei.cmu.edu. SEND letters-to-editor, notices, calendar entries, quips, quotes, anecdotes, articles, offers to write, and general correspondence to Carol Pilch, carol.pilch@gsc.gte.com or Phil Glaser, glaserp@hanscom.af.mil. Send job postings to dheimann@mitre.com. Back issues and other information about Boston SPIN can be found at our WEB HOME PAGE, http://www.cs.uml.edu/Boston-SPIN/