Skip to Main Content
Home
Contact Us
Meeting Cancellation Policy

Established September, 1992

Newsletter of the Boston SPIN

Issue 17, November 1997

Return to Newsletter Index

Contents


READER SURVEY

  1. Do you read In the SPIN?

    ____ YES

    ____ NO

  2. If yes, about how much of each issue do you read?

    ____ Less than 25%

    ____ Less than 25-50%

    ____ Less than 50-75%

    ____ Over 75%

  3. What articles do you find most useful? Please check all that apply.

    _____ Calendar

    _____ Notices

    _____ Meeting Reports

    _____ The SPIN Doctor

    _____ Job Bank

    Other (please specify)___________________________________________________________

  4. Is there any kind of news you would like to read but do not find in the newsletter ?

    If so, what is it?___________________________________________________________

  5. What is your preference for In the SPIN distribution?

    _____ SPIN Web site

    _____ E-mail

  6. Would you be willing to write articles for In the SPIN?

    _____ Yes

  7. Any other comments?___________________________________________________________

Send your survey response via E-mail to: glaserp@hanscom.af.mil

Back to top

CALENDAR

November Meeting

6:30-7:00 Networking, Networking Round Tables, and Refreshments

7:00-7:15 Introduction: Barbara Purchia

7:15-8:30 Program:

"Metrics for the Intrapreneurial Software Organization"

Guest Speaker: Maxine Crowther - Senior Quality Consultant at Cadence

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

Back to top

December Meeting

Topic: "QFD and Software Development: So, what's the problem?"

Guest Speaker: Lou Cohen - Consultant

Date: Tuesday, December 16, 1997 at 6:30 pm (networking & refreshments), 7:00-8:30pm (meeting)

January Meeting

Topic: "Deep Dark Secrets from the Software Process Improvement World"

Audience Participation Facilitated by Donna Johnson, President of LOGOS International, Inc.

Date: Tuesday, January 20, 1998 at 6:30pm (networking & refreshments), 7:00-8:30pm (meeting)

Back to top

NOTICES

Networking Round Tables

From 6:30 to 7:00, we are offering a number of Networking Roundtables in addition to the usual ad hoc networking and refreshments. To help you understand this part of the program, here are a few things you might want to think about:

  • Do you ever feel alone?
  • Do you think you are the only person who is facing challenges related to implementing process improvements?

The networking round tables might help you! The goal is to:

  • Share experiences on particular topics
  • Hear what others have done to solve problems
  • Ask questions
  • Answer questions
  • Learn what, why, and how people in similar situations have done
  • Learn what has worked and what has not worked
  • Network more effectively

The round table topics for November include:

  • Metrics
  • Risk Management
  • Problem Tracking Systems
  • Peer Reviews

If there are any other topics you would like to discuss with fellow SPIN members, please contact Barb Purchia (bpurchia@kronos.com).

Job Postings

Job postings can now be found at our WEB PAGE, http://www.cs.uml.edu/Boston-SPIN/

Back to top

Heard ‘Round the Round Tables
by Maxine Crowther

The Boston SPIN hosted its first ever round table discussions at the October 21st SPIN meeting. The popular topics were Metrics, Risk Management, Problem Tracking Systems, and Peer Reviews.

About half of the audience took part during the Networking portion of the meeting from 6:30 to 7. Thumbs up was the general consensus of the participants.

Heard around the Metrics table -
  • We always seem to measure what is easiest to collec, not what matters
  • There is no cause and effect analysis done
  • We need to start measuring based on what we want to achieve. If we can measure our progress, that's a good start
  • Really "nuts and bolts" metrics aren't easy to translate for management
  • We measure lines of code because everybody measures that - don't they?
Heard around the Risk Management table -
  • In theory every project manager is constantly doing risk management
  • We use templates to provide a framework for risk management
  • The critical elements are assess and prioritize
  • Do it and you will find your own best practices naturally
  • Risk assessment has commonality over like projects
Heard around the Problem Tracking table -
  • Tools, tools, tools
  • Once automation occurs, you can see the effect of this system on project management
  • We use a priority to define which defects go in which release
  • We identify a target release for planning and an actual release to track completion
Heard around the Peer Reviews table -
  • Does anyone have a good way to deal with teams that are distributed and multi-cultural?

Back to top

MEETING REPORTS

October Meeting Report
by Carol Pilch

"You CAN test to achieve quality?!"
by Michael Taylor, Associate Director of Quality Management at PARAEXEL

October 21, 1997

The test methodology presented places emphasis on "control of overall requirements through the testing process." This is not the classic waterfall approach where all requirements are defined during an early development phase. The approach is to have a living requirements document by embodying the requirements in the test plan and test descriptions. Test planning and test case development start early in the development phases and are done concurrently with the product design.

Overview of the product

The product is an internet electronic message transfer agent. Messages inbound from the internet are stored using Lotus Notes.

Product Requirements

There are literally thousands of requirements. The basic product requirements document defined 40 requirements. However, requirements are "RFCs" or request for comments. In effect, the RFCs are message format and transmission standards with which the system must be compliant. In addition, the system must have the capability to run on eight specified platforms and other platforms are expected to be identified in the future.

Many individuals in various roles contributed to requirements both before and during development: Architects (3), Product Manager, Project Manager, Managers (2), "interested" VP, Customers, those incompatible with the specifications, and developers (added bells and whistles).

Quality Considerations

Developers create the quality, Quality Assurance quantifies the quality (the percentage of functionality that works), and Management ships quality.

Quality is quantified from a base level of 1. That is, everything is bug-free until a bug is found. Quality becomes visible from day 1 of testing.

Process

The testers (QA) start their tasks at the same time as the design team. Therefore, QA is involved early and by developing test cases as the design is developed, requirements problems are found early. QA reviews specifications at the same time as test cases are prepared. QA is involved in design reviews which are informal. At the start of first generation product test, the test plan is ready and sufficiently developed in terms of test cases to exercise the product against test cases.

A test database of test cases is developed. Traceability from the test cases back to the requirements is maintained. As test are executed, software problem reports are written or the test database (test plan and test cases) are updated. Software problem reports are tracked back to the test database.

Strategy/Implementation

All tests are black box tests and are formally documented. Tests are prioritized by functional group and automated. In addition, tests are platform and user interface independent. The test plans/suite are maintained in the Lotus Notes database (i.e., the test bed). There are more than 700 test cases and more than 1500 messages in the data base. In addition, the tests are classified into more than 40 functional groups and 5 categories. Category 1-4 tests represent varying gradation of regression tests. While category 5 is build specific and includes nstallation features. Category 5 tests and the most rigorous regression tests are run on any release prior to shipping.

There is a capability to run any test from any server in the test bed and to send messages both to and from any servers. Automation of address conversion provides flexibility in creating tests. It is possible to substitute any address.

Problem reports are streamlined. Only 5 items are required in the actual problem report documentation and pointers are maintained to the test case that was run when the problem was identified. This makes it easy for the maintainer to reproduce the bug in the actual test environment.

Summary

The approach to testing to achieve quality presented here has many benefits that are not provided by traditional methods and life cycles. First, the test suite is a "living document which changes as requirements change. Second, consistency and reliability result from the method. In effect, every test is conducted in the same way with the same test data. Third, traceability is inherent in the structure of the documentation. Fourth, since testing is started earlier as compared to traditional life cycle methods, there is an opportunity to prioritize fixes over a longer period of time. Fifth, there is high confidence in the level of quality of the product being shipped because tests are repeatable and results are consistent.

Qs & As

Presented here is a subset of questions and the answers:

Q: What metrics are collected and used?

A: Metrics consist of the number of tests successfully run.

Q: How are design reviews conducted?

A: Design reviews are informal and there is not tracking of action items.

Q: Do you measure and track code (i.e., test) coverage?

A: There is no measure of test coverage.

Q: Do the developers write code to pass the tests?

A: Yes and no. The test plan serves as the detailed requirements documentation. On the other hand, requirements are elicited in parallel with product development.

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 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/DIB (Bldg 1704), 5 Eglin St, Hanscom AFB MA 01731-2116; (781) 377-8324; Fax (781) 377-8325; ryan@sei.cmu.edu.

IN THE SPIN is published monthly or bimonthly 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 ryan@sei.cmu.edu. 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. Please indicate which email list to which you wish to be added.

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 heimann@world.std.com.

Back issues and other information about Boston SPIN can be found at our WEB HOME PAGE, http://www.cs.uml.edu/Boston-SPIN/

Return to Newsletter Index

Back to top