Newsletter of the Boston SPIN

Issue 13, February 1997

Return to Newsletter Index

Contents

• Calendar
• January 1997 SPIN Meeting Report (Ed Maher): Michael Mah on Controlling Software Development
• Job Bank
• Masthead

CALENDAR

MAR 4: New England Software Quality Assurance Forum (NESQAF)

Wil Spencer (Fidelity Investments):

"Using the SEI CMM to Improve Quality"

6-9 pm, Lotus Development Corporation, Cambridge

Info: Jill (617) 272-7393

Directions: (617) 693-4732

MAR 25 (**FOURTH** Tuesday): Boston SPIN meeting

Guest speaker Watts Humphrey:

"What If Your Life Depended on Software?"

5:30 - Social, 6:15 - Dinner, 7:30 - Panel

GTE, Building #5, 77 A Street, Needham, MA

Info: Ken Oasis, (617) 563-4197, ken.oasis@fmr.com

THE UNIVERSITY OF MASSACHUSETTS TECHNICAL FORUM Software Quality Roundtables

A series of presentations and discussions regarding software quality

FEB 28 (Friday): Morven Gentleman (National Research Council, Canada)

MAR 28 (Friday): Stu Feldman (IBM)

APR 25 (Friday): Ed Miller (Software Research, Inc.)

The Westin Hotel, Waltham, MA, 9:00 AM - noon

Sponsor: LASER (Laboratory for Advanced Software Engineering

Research), U/Mass Amherst, Department of Computer Science

Info: Wendy Cooper, 413-545-2475, cooper@cs.umass.edu

MAR 17-20 -- SEPG Conference

"People - Process - Technology: Stuff That Works"

San Jose Convention Center, San Jose, California

Contact: 412-268-5800

customer-relations@sei.cmu.edu

http://www.sei.cmu.edu

APR 1 -- First Annual Software Quality Institute (SQI) Symposium

"Software Reliability Engineering"

The University of Texas at Austin, Austin, Texas

Contact: (800) 687-8012 or (512) 471-4922

leti@sqi.utexas.edu

http://www.utexas.edu/coe/sqi/

Back to top

MEETING REPORTS

November 1996 Meeting Report
by Ed Maher (Digital Equipment Corporation)

Summary

November's speaker was Michael Mah, Director and Principal of QSM Associates; the topic was "Controlling Software Development".

I found the material in this talk to be interesting. He presented techniques for planning software projects, tracking progress against plans, managing risks, and projecting a completion date based on progress to date.

Details

Michael started out by stating his belief that you can not effectively deal with risks without addressing measurement. Quoting Tom DiMarco: "Risk Management is project management for adults". He pointed out that most people have no problem using measures to gain understanding of things in their personal life; citing the APGAR score assigned to newborns, the Dow-Jones Index, and Cholesterol readings as examples.

On the other hand, people still are uncomfortable using numbers to describe the status of their own work activities, or the status of a project on which they are working. In the software world, people often will measure schedule or effort; but not cost, product size or defects.

He said that many companies do not know how likely they are to complete a given project on schedule. What is more important is that they don't know if the committed schedule is even possible.

He showed us a concept called "The impossible zone". This is based on the QSM database of historical projects. It shows graphically theduration that all of the projects in that database took to complete. The graph had product size (in lines of code) on the X-axis and duration on the Y-axis. It was fairly obvious that (for a given product size) there is a minimum project duration under which it is practically impossible to achieve. Unfortunately, many project managers are pressured into committing to schedules that fall into "the impossible zone", and they either don't recognize it or they are unable to clearly demonstrate it.

He illustrated the concept using some real data from their clients. He showed us graphical representations of the planned size, effort, duration, and Productivity Index (PI) for a couple of project plans {More about PI later on}. One project was planned to complete two standard deviations faster than the industry average for their project type; this looks to be a plan that is highly likely to fail. Another project had a plan that was clearly right in line with industry averages, and in line with with their own historical data; this plan is demonstrably likely to succeed.

Being able to plan in this way requires that you can estimate with some amount of accuracy; and better estimation requires the effective use of metrics. He quoted Ed Yourdon;:

"If you underestimate the size of your next project, common sense says that it doesn't matter which methodology you use, what tools you buy, or even what programmers you assign to the job."

Managers need to use the SEI Minimum Data Set (size, effort, cost, duration, & defects), and "get out of the two dimensional flatlands of only looking at cost and schedule." They need to monitor size metrics and defect metrics.

Back to top

On the other hand, organizations need to be very careful about attaching judgments to metrics, or politicizing them -- stressing that you should never use these measures to evaluate people. Michael described how trying to capture them can be made more difficult than it needs to be because of people's fear of how the data may be used.

When used correctly, these measurements can allow everyone to see that any blame usually doesn't lie with those doing the engineering or planning. It is almost always a management problem; with people being asked to execute a plan that can't possibly succeed.

The CMM Level 2 and 3 key process areas have associated practices and guidelines that can help to improve an organization's estimatingcapabilities. [Note: The practices in the CMM are more focused on the "what" of estimating and not the "how". The guidelines he is referring to are contained within an SEI document titled: "Software Cost and Schedule Estimating: A Process Improvement Initiative". I did not find this document very helpful. It was more focused on describing how to roll-out a new estimating process -- not on what a good estimating process is.]

He spent some time explaining the concept of the Productivity Index (PI). Simply put, it can't be simply explained. It is a number derived based on size, effort, and duration. A project plan has anassociated planned PI, and a completed project has an associated actualPI. A higher PI indicates an ability to produce product with less effort or time. One easy rule-of-thumb: one PI higher translates to roughly 10% less schedule and about 25% less effort. The PI is explained in detail in "Measures for Excellence, Reliable Software On Time, Within Budget"; by Lawrence H. Putnam and Ware Myers; Yourdon Press. He called this his only shameless plug -- since this was co-authored by QSM's founder.

An organization's knowledge of their PI allows them to better plan and to assess the likelihood of success of the plans with which they commit. In the first example above, they had a plan that called for a PI of 21.2, when the industry average is 9.9. They really need to understand the extreme levels of risk that this implies. He believes that many project failures are due to plans that have an unrealistic implied PI.

He presented some PI data from the QSM database:

Back to top

Back to top

Someone asked why "Business" software projects are so different from "Avionics"? He pointed out that the PI shouldn't be looked at as a measure of goodness. It can be affected by things like complexity, constraints, and reliability. Shuttle software has to be of significantly higher quality than your average business application.

What about a company that knows if they bid for a project showing a certain schedule, then they won't get the contract? (but their data shows that's what it would take). The solution to this common dilemma is to show the data to the customer to make them more confident that delivery will occur when planned.

He cited Tim Lister as saying that two identical projects can complete at the same time; the team that comes in ahead of plan are heroes, the team that comes in behind plan are goats. The only difference between the two were the deadlines that they were aiming for. Negotiation needn't be just about who comes to the table with the best offer; it can also be about who comes with the most credible bid.

Moving on to tracking; he briefly touched on the concept of using red, yellow, and green traffic lights (red means that an indicator is significantly off track, yellow that it is a little off track, and green means that it is as expected.) The key is to take complicated progress data and transform it into easy to read visual images. He showed them being applied to code size, but they could be used for anything that can indicate progress (i.e., size, effort, cost, defects, and milestone attainment).

You can also use data about progress-to-date to predict a "trajectory" of where a project is going. This can be a valuable technique for determining if the current plan is still reasonable. These techniques can be done manually or with creative use of a spreadsheet package.

It is critical that you look at as many indicators as possible to insure that you are getting a complete picture. He illustrated this by asking if a pilot would be happy flying with only a clock and a fuel gauge to guide them. He believes that this is analogous to a software project being tracked by only watching cost and milestones.

Michael presented a case study from the Netherlands Telecom; they are using the red/yellow/green traffic lights. There is a "Quality Management & Control" function reporting directly to the Chief Executive. This function is responsible for collecting the data and showing management a monthly status of software projects. The reviews are to focus management actions and not to punish the guilty. Project data is submitted every month, and a red/yellow/green assessment is determined. If a project doesn't have data, then they are tagged as being "Red". All "Red" projects must have action plans to get back on track. He pointed out that this level of tracking isn't appropriate for every project. Netherlands Telecom applies it on about 80% of their projects.

Back to top

He presented some things to avoid and some things to strive for:

Demotivational Factors (Things to avoid):

• Measurement of people
• Things that don't focus on management issues
• Biased agendas
• Invalid approaches
• Perception of the drain -- process can't take more than it gives back
• Perceived lack of purpose

Things to strive for:

• Risk Analysis (e.g., Red, Yellow, Green)
• Benchmarking and process improvement (get the measures)
• Support technology investment
• Win new business (It's real easy to get dollars and budget when you meet your commitments)
• Make money
• Employ people
• Avoid unemploying people

Back to top

In different places of this talk, he addressed the problems associated with introducing change into an organization. In his opinion, attention to real process improvement is often jeopardized when an organization is largely in chaos because of projects in crisis. Process improvement can easily take a back seat to the fire drills and deadlines. This is a classic Catch- 22; the org is in chaos -- causing them to be unable to get the needed focus or cycles onto the improvements that could get them out of the chaos.

In closing:

If organizations can become successful at estimating and tracking, then they can find the rewards of projects being under control from the start (at time of commitment). They can then effectively manage projects mid-stream -- doing real risk management. Senior management can use techniques like red/yellow/green to identify risks to their projects early, and channel energy to help where needed. They can have the numbers to manage their software projects, much like a Wall St. trader or even a layperson investor using charts and visual indicators to manage a financial portfolio.

Questions and Answers (paraphrased):

Q: How does all of this apply if you are moving toward system integration (away from pure code production)?

A: The "size" shrinks so the other factors also go down. The benefits are then seen in geometric fashion. The tricky part is that building code in isolation can be easier to test. Testing large integrated systems can be very difficult. For example, you could have 10,000 lines of new code but have to regression test a "system" that represents 1,000,000 lines of code.

Q: Can you normalize the Productivity Index so that different types of projects can be compared?

A: This isn't a good idea. Normalizing tends to wash over differences that shouldn't be ignored.

Q: What types of companies are looking for this kind of help?

A: Right now, QSM is seeing many requests coming from the Telecom community. In addition, the Wall Street community has recently started becoming involved.

[Note: Just about all of the processes or techniques that he presented can be automated by the QSM tools SLIM and SLIM Control; however, I don't recall Michael ever mentioning that fact. This is good and bad; on the one hand it is nice that he didn't overtly use the SPIN for marketing purposes; on the other hand, it made some of his talk seem more complex and theoretical than it may have needed to be.]

Back to top

JOB BANK

Progressive Search Associates

Contact: Patrick Merten, 617-558-7026, patrick@world.std.com

ACCESS / VISUAL BASIC DEVELOPMENT Contract Assignment - 2 to 6 months. Responsibilities - Will develop reports and an invoice management system including screens for a client organization using Access and VB. Qualifications - Must have 1 to 2 years' solid experience in Access and some familiarity with VB. The selected candidate may also have the opportunity to train and use Active X.

MS SQL / NT / WEB/COLD FUSION DEVELOPER Contract Assignment -3 months Responsibilities - Will develop a work flow system using MS SQL, WinNT and Cold Fusion. Qualifications - Must have solid experience with MS SQL and NT. A background in WEB development is essential, and familiarity with Cold Fusion is a plus.

C / C++ / VISUAL BASIC / ACCESS / COBOL / SQL/EXCEL /JAVA and FORTE DEVELOPER. Contract Assignment - 3 months. Responsibilities - Various assignments to develop a variety of applications using the software listed above. Qualifications - Solid experience, at least 2 years developing applications In any of the software above.

MAC CONSULTANT Contract Assignment - 3 months Responsibilities - Consult with a client company in solving high level problems. Qualifications - Must have solid experience with PhotoShop and technical expertise working with Mac's in a networking environment.

INFORMIX Contract Assignment - 1-2 months. Responsibilities - Look at the current database design and make recommendations. Qualifications - Must have solid experience with Informix in a UNIX environment. Must have experience with IDEA functions, database design, and database tuning in a client server environment. Experience with Powerbuilder is useful but not necessary.

CURRENT PERMANENT OPENINGS - FEBRUARY, 1997

PROJECT MANAGER Responsibilities -In charge of scheduling for the entire company. Will track personnel and work assignments. Reports on projects by means of status reports and will analyze projects to make sure that they are profitable. Qualifications - The successful candidate must have solid management skills and a basic understanding of technical terms and functions. The ideal candidate should have a QA background with management experience.

DELIVERY MANAGER / PROJECT MANAGER Responsibilities - In charge of the overall management of projects including the following: tracking budgets; managing expectations for both the hiring company and the client company to make sure that clients needs are being met; writing proposals; and working closely with the client company to monitor projects. Qualifications - The successful candidate must have a technical background as well as management experience The ideal candidate should have consulting experience as well.

C/C++/ VISUAL BASIC/ACCESS / COBOL/SQL (EXCEL/JAVA and FORTE DEVELOPER Responsibilities - A variety of assignments to develop applications using the software listed above. Qualifications - Solid experience, at least 2 years, developing applications in any of the software listed above.

BUSINESS ANALYSIS

Qualifications - The successful candidate must have excellent communications skills. The position requires a high level of flexibility and maturity. Ability to pickup information quickly is essential. A broad functional background and a good understanding of programming and systems are a necessary prerequisite as well as excellent writing skills. Experience working in a large consulting firm is a plus. Education: BA and/or MS.

QA MANAGER

Responsibilities - Will set up a structured approach for QA as well as monitor quality and testing of software for individual projects. Qualifications - The successful candidate will have QA background from a software development company or a consulting firm.

SALES

Permanent and contract positions. Qualifications - The successful candidate will have prior sales experience either from a Software Company or consulting firm, and must have proven ability to close business. Ability to successfully maintain positive relationships with customers is essential.

Back to top

Aonix (formerly Thomson Software Products and IDE) is a company known for its innovative approaches to developing products and services that meet the needs of business and government customers. Our Ada division, located in BURLINGTON, MA is seeking two talented professionals who want to bring their expertise to the Ada team for Object Oriented and Safety Critical technology.

SOFTWARE QA/CONFIG MANAGEMENT ENGINEER

Will ensure that our Safety Critical Software is produced to the applicable certification standard and that developed materials are acceptable to certification agencies. Will also provide in-depth review of QA processes and the presence of analysis and testing evidence. Will review in-house standards and ensure that the evidence of compliance with safety standards is recorded and maintained in the config management system. Bachelor's degree and proficiency with Software Quality and/or Software Safety standards is required.

SENIOR RUN-TIME ENGINEER

Will participate in the development and implementation of the next generation of ObjectAda for Windows (an Ada 95 compilation development environment). You'll be responsible for exception handling, data allocation, memory management and task scheduling. Requires 6+ yrs. experience with solid background in multi- tasking, multi-threading, run-time environments.Knowledge of Windows 95 and NT is highly desirable.

For additional information, please send resume or contact: Cherie Flavin, Aonix, 101 Merritt 7, Norwalk, CT 06856. Email: caf@aonix.com. Fax: 203-845-7966. Call: 203-845-5247.

Back to top

Sanford Rose Associates

35 South Main Street 3rd Fl, Hanover, NH 03755

Contact: Tim McKegney, mckegney.sanford.rose@valley.net, Voice: (603)643-4101 Fax: (603)643-4272

My client is a rapidly growing company that produces a family of high performance, open, programmable digital switching systems used in a wide variety of applications for the telecommunications industry.

Their facilities are located in a non-urban, high quality of life location in Massachusetts. The company culture is very casual and team-oriented. Their compensation is very competitive, they are paying signing bonuses and offer generous, full relocation for the right candidates.

1. -Software Configuration and Test Engineers

   We are seeking an experienced Release Manager responsible for version control, with experience in creating and managing automated build process for real time software. (PVCS, RCS, SCCS, ClearCase). Also, Test Engineers with working knowledge of SS7, ISDN Protocols, T1/E1 Spans, C, C++, Call Processing, Load Generation Boxes, Protocol Analyzers, Automated Test Devices and Ethernet.

2. -Principal and Senior Software Engineers and Project Leads

   We have immediate openings for intermediate and senior software engineers with experience developing real-time embedded software for large telecom or datacom products. Exposure to industry standard real-time operating systems is a plus. Must have strong system design skills; experience designing and implementing layered software communications protocol stacks for redundant/fault tolerant systems also a plus. Strong experience in telecom networks, C, C++, OOD, SS7, ISDN experience are all attractive.

3. -Hardware Project Manager

   This is a senior hardware management position reporting to the VP Research and Development. This individual will be responsible for a range of projects in multiple vertical disciplines. Focuses will include the design and development of hardware for new products, features, and functionality.

4. -Principal and Senior Hardware Engineers

   There are two Principal Engineer positions available in R & D; focused on developing cutting-edge new products for telecom, advanced intelligent network, computer telephony and wireless applications. Also, there is a Senior Hardware Engineer position in the sustaining group, which is focused on feature definition and development through the life cycle of existing products. This individual should have exposure to the hardware design process of high end micro-processors, FPGA's, or high speed digital logic. A telecommunications background is always a plus.

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 through June.

We thank our sponsors, GTE and Raytheon. We also thank U/Mass at Lowell for hosting our Web page, Digital Equipment Corporation for Ed Maher's SPIN meeting reports, and the Rothman Consulting Group for Johanna Rothman's SPIN meeting reports.

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 monthly September through June. Letters, notices (including job postings), and contributed articles are welcomed. Articles do not necessarily represent the opinions of anyone besides their authors. We do not publish advertisements or job searches, but we gladly publish job postings.

IN THE SPIN is available by email and on our Web page. TO SUBSCRIBE send email address to rprice@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, job postings, calendar entries, quips, quotes, anecdotes, articles, offers to write, and general correspondence to Sallie Satterthwaite, 508-369-2365, otter@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