13ICSQ
13th International Conference on Software Quality
Software Division of
The American Society for Quality
Karl Wiegers - Keynote Speaker
Karl Wiegers is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. His interests include requirements engineering, peer reviews, project management, risk management, and software metrics. Previously, he spent 18 years at Eastman Kodak Company, where he held positions as a photographic research scientist, software developer, software manager, and software process and quality improvement leader. Karl received a B.S. degree in chemistry from Boise State College, and M.S. and Ph.D. degrees in organic chemistry from the University of Illinois. He is a member of the IEEE, IEEE Computer Society, and ACM.
Karl’s most recent book is Software Requirements, 2nd Edition (Microsoft Press, 2003). He also wrote Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002) and Creating a Software Engineering Culture (Dorset House, 1996), which won a Productivity Award from Software Development magazine, as well as 160 articles on software development, chemistry, and military history. Karl has served on the Editorial Board for IEEE Software magazine and as a contributing editor for Software Development magazine. He is a frequent speaker at software conferences and professional society meetings.
Keynote: The Soft Side of Peer Reviews
Peer reviews are as much a social interaction as a technical practice. Asking your colleagues to point out errors in your work is a learned - not instinctive - behavior. This presentation describes some of the cultural and interpersonal aspects of peer reviews and inspections that must be considered when trying to install a review program in an organization. The concept of "egoless programming” is described as it relates to reviews. Suggestions are provided for how a reviewer should present issues to the author in a nonjudgmental way. Some aspects of management attitudes and behaviors are discussed, including 10 signs of management commitment to peer reviews. A case study illustrates the risks of managers using defect counts from inspections to evaluate individual authors. These risks include:
-
Developers might not submit their work for review.
-
Developers might refuse to review someone else’s work.
-
Reviewers might not point out defects they see.
-
Authors might hold unofficial “pre-reviews”.
-
Review teams might debate whether or not something is a defect.
-
The culture will have an implicit goal of finding few defects.
-
Authors might review small bits of work to avoid finding too many bugs.
Several reasons why people do not perform reviews and ways to overcome them are explored, including factors related to lack of knowledge, cultural barriers, and simple resistance to change. Some of the benefits that people performing different project roles can enjoy from a successful peer review program are itemized. The presentation also addresses some aspects of holding reviews that involve participants from different cultures. By understanding the social and cultural aspects of peer reviews, organizations can increase their benefits from this powerful quality and productivity improvement technique.
Tutorial: In Search of
Excellent Requirements
Requirements form the foundation for all the software work that follows. Arriving at a shared vision of the product to be developed is one of the greatest challenges facing the software project team, and customer involvement is among the most critical factors in software quality. The objective of this tutorial is to give attendees a tool kit of practices, reinforced with practice sessions and group discussions, that they can begin applying to improve the quality of the requirements development and requirements management processes in their organization.
Learn about tested methods that can help any organization improve the way it gathers, documents, and analyzes software requirements. Characteristics of excellent requirements statements and requirements specifications are presented and used to evaluate some sample functional requirements. The seminar emphasizes several practical techniques, including:
-
Customer involvement through a “product champion” model
-
The application of use cases for defining user needs and system functions
-
Writing software requirements specifications using a standard template
-
Construction of dialog maps to model user interfaces
-
Using prototypes to clarify and refine user needs
-
Using peer reviews to find errors in requirements
-
Using a requirements traceability matrix to connect requirements to design elements, code, and tests
The basic concepts of requirements management are described, as are practical methods for managing changes to requirements. These techniques can reduce project risk by improving the quality and control of the software requirements, thereby increasing the likelihood of a successfully completed project.
Tutorial Objectives:
-
Be able to recognize and classify different types of requirements information
-
Learn about many “good practices” for requirements elicitation, analysis, specification, validation, and management
-
Learn how to apply the use case technique for eliciting user requirements
-
Select appropriate techniques for representing requirements on your projects
-
Be able to critically evaluate requirements statements for ambiguity and other problems
Tutorial Outline:
I. Introduction to Requirements Engineering
A. Introduction to seminar, objectives, participant expectations
B. Define three levels of software requirements: business, user, and functional
C. Describe characteristics of high-quality requirements
D. Requirements development vs. requirements management
II. Practice session: small group discussions on requirements problems in their projects
III. Software Requirements Development
A. A requirements development process
B. The requirements analyst
C. The vision and scope document
D. Sources of requirements
E. Classifying requirements into categories
F. Customer involvement in the requirements process: the product champion model
G. Gathering user requirements through use cases
H. Practice session: identifying use cases for an airline reservation kiosk
I. Documenting requirements: the software requirements specification
J. Software quality attributes
K. Practice session and discussion: reviewing a portion of an SRS
L. Modeling user interfaces with dialog maps
M. Practice session: drawing a dialog map from use cases
N. Reducing the expectation gap through prototyping
O. Other methods of analyzing and validating requirements
IV. Software Requirements Management
A. Basic requirements management practices
B. Version and change management
C. Requirements change impact analysis
D. Requirements traceability
V. Practice session: Small group discussions on how
to apply solutions to the
requirements problems from the discussion in section II
VI. Wrap-up