13th International Conference on Software Quality

Software Division of
The American Society for Quality

Home ] Up ] 13ICSQ Program ] Sponsor & Exhibitor Opportunities ] Special Needs ] Dallas Info ] Hotel/Airline/Rental Car/Driving Directions ] Paper & Tutorial Presenter Information ] Volunteers Opportunities ] ICSQ History.htm ] Contact Us ] About ASQ ]


Wednesday Concurrent Sessions
Bill Curtis
James Bach
Johanna Rothman
Herb Krasner
Mary Sakry


Johanna Rothman - Invited Speaker

Johanna Rothman consults on managing high technology product development. She helps managers, teams, and organizations become more effective by focusing on project management, risk management, and people management. Johanna uses pragmatic techniques to help her clients apply effective practices that create successful teams and projects.

A frequent speaker and author on managing high technology product development, Johanna has written numerous articles and is now a columnist for Software Development, Computerworld.com, and StickyMinds.com. Johanna publishes Reflections, an acclaimed quarterly newsletter about managing product development, and an e-zine, “The Pragmatic Manager.” Johanna is a member of the clinical faculty of The Gordon Institute at Tufts University, which offers a practical management degree program for engineers, and served as the Program Chair for the Software Management Conference for two years. Johanna’s book, Hiring Technical People will be available in 2003

Presentation:  Shattering the Myth of Inadequate Testers

Why do projects “fail” in the test phase? Do teams have inadequate testers? Are they not doing adequate testing? Is the entire test organization inadequate?

We’ve heard blaming comments about testing and product quality since organizations decided they needed testing groups. Instead of blaming the testers for being inadequate, let’s talk about the testing. Why are so many organizations dissatisfied with their testing activities and perceive those activities to be inadequate? Why are we building organizations whose staff can’t perform the required work?

In this presentation, Rothman will look at how organizations tend to hire testers and other technical people, and alternatives to those techniques. This talk is for you if you’d like to refine your hiring requirements for great testers (or other great technical staff), or if you’d like to become a great tester (or be hired as one).

Tutorial: Everything Project Managers Need to Know About Requirements But Were Too Busy to Ask

Many of us start projects with fuzzy requirements or  mandates: “Get me a blatz by next June,” where the only defined piece of the project is the ship date. Or, maybe you start projects with a demand for a feature by a certain date. You have to decide how many other features you have to fit into this release, how many people you need, and how good it’s going to be — all before you have any idea what the initial demand truly is.

Welcome to project requirements. By adapting product requirements techniques to the project, you can determine what you’re supposed to do, how quickly, how well, and with whom.

As a project manager, you don’t just have to know the project’s requirements, you also have to know enough about the product’s requirements to plan, monitor, and complete the project. We’ll discuss how to iterate between the project and product requirements to build a plan and  a schedule, and plan for measurements and for release.  Attendees will learn to:

  • Define project requirements and how they are similar to and different from product requirements

  • Quickly learn their project’s requirements

  • Improve starting projects for success

  • Prevent disconnect between themselves and management

  • Develop communication skills about the project with the technical staff and management

Tutorial Outline:

1)      How to think about project requirements

a)      How project requirements are different and similar to product requirements

2)      Generating project requirements

a)      Context free questions

b)      Schedule, features, defects

c)      Cost, people, work environment

d)      Generating release criteria

e)      Generating success criteria

3)      Generating top-level product requirements

a)      Using Use cases for the project and the product

b)      Verifying project requirements with product requirements

4)      Using the requirements to generate a plan, a schedule, and a staffing plan

a)      Choosing lifecycles that reflect the project requirements

b)      Choosing practices that reflect the project requirements

c)      Creating a plan from the lifecycles, practices, and people you have

d)      Define and choose an appropriate staffing plan

5)      Managing expectations during the project

a)      Using the requirements to generate metrics

6)      Completing the project successfully

a)      Using release criteria

b)      Using the project metrics