© 1999 Johanna Rothman. Abstract Companies create a variety of products, and different releases of those products, for many reasons. These range from market-testing trial balloons disguised as ‘beta tests’ to releases forced by incompatible changes in operating systems. Some have many changes, some have few. Some can tolerate fairly glaring defects, others have to
© 1999 Johanna Rothman “When will the project be ready for Beta?” “I think it will be ready next month. We’re more than 90% done.” “NEXT MONTH? You said ‘next month’ last month. You said you were more than 90% done last month too. We’re slipping this project a month every month. WHEN will you
More companies are looking towards globally dispersed software development teams to solve project staffing problems and make critical time-to-market deadlines. This trend is a fundamental change in how software projects are organized and implemented. Using the idea of “concurrent engineering” to deliver projects faster, you break up a project into smaller, less complex pieces and
by Johanna Rothman. This article was originally published in Software Development Magazine, June 1998. Large, permanent engineering cultural change–or process improvement–generally takes a long time to implement. However, key repeatable processes can free up time in an organization and let people spend more time on the creative work of software development. I recently worked with a
© 1998 Johanna Rothman Test managers really serve two very different customers, their testers and corporate management. For the testers, the test manager helps develop product test strategies, and provides test expertise to the testing group. For management, the test manager gathers product information so that corporate management can decide when the product is ready
© 1998 Johanna Rothman. Abstract Organizations struggle [1] with their process improvement efforts for a variety of reasons. Perhaps the most common struggle pattern is to take a long time developing a general understanding of their processes and then trying to define all possible alternatives in the product development process. This pattern leads to large,
by Johanna Rothman. © 1998 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the
© 1998 Johanna Rothman. Abstract Organizations produce and buy packaged software to save time and money. Often, the producers feel that savings will result from diminished product testing, but that wish may simply mean the software test professionals (STPs) won’t be given enough time to test and assess a software product as thoroughly as they
© 1998 Johanna Rothman. Most project managers want to reduce risk during a project. One way to reduce overall risk is to define and focus the project goals up front, and continually verify those goals and progress toward those goals during the project. Bob Grady [1], claims there are three common goals for software product
Copyright © 1998 Cem Kaner (kaner.com) and Johanna Rothman Many project managers don’t know what to expect from a testing organization. They don’t know what the group does, how the product is going to be tested, when things will be done, what deliverables to expect, or how to find this information out. Complicating matters, some