|
|
Adaptive Software Development Adaptive Software Development (ASD) is targeted for software teams where competition creates extreme pressure on the delivery process. Many process improvement techniques (CMM, ISO) are focused on optimizing practices that involve steadily increasing rigor. In contrast, ASD emphasizes producing high-value results based on rapid adaptation to both external and internal events. Listen as Jim Highsmith explains how the focal point of ASD is fundamentally different from traditional software process improvement approaches. Learn why "a little bit less than just enough" is ASD's guideline for implementing rigor.
|
Jim Highsmith, Information Architects, Inc.
|
|
|
Taking Test Automation Mainstream By now, most test organizations have implemented at least one test automation tool. However, the success of these tools is by no means guaranteed. Why is it that these products often fail to meet their potential? What can managers do to increase the tool's return on investment? Andrew Pollnew helps you with ways to ensure that tools support rather than hinder you. He discusses a number of common-but-flawed approaches to automation, then explains how to change them.
|
Andrew Pollner, ALP International Corporation
|
|
|
Testing Mission Critical Software Changes This paper is based on a recent experience implementing and testing a large new software capability in a
maintenance organization which had not dealt with a large change in some time. The capability was called
GPC Payload Command Filter (GPCF). While the task was completed successfully, it was not without
cost in terms of schedule slips and personal angst.
The purpose of this paper will be to help the verifier learn from what was done right and what was done
wrong, hopefully to avoid the pitfalls and emulate the successes. Specifically, the objective is as follows:
To provide guidance on how to successfully test a large new software capability using verification processes which have specialized over time to provide extremely effective results
for relatively small changes.
|
Alan Ogletree, United Space Alliance
|
|
|
Testing Your Software's Requirements Many testing organizations focus primarily on software executable code, but that's not the only thing you can test. For instance, did you ever consider testing your software requirements? When you test only code, you face some big disadvantages, not to mention that design defects often aren't even fixable because they demand too much effort, too late in the release cycle. In fact, it's difficult to even report some requirements defects since the developers have already committed to the design strategy. But if you test your requirements early in the game, you can discover defects before they're cast into designs and code, consequently saving your organization potentially huge rework costs.
|
Brian Lawrence, Coyote Valley Software
|
|
|
Going Beyond QA: Total Product Readiness The successful release of software requires more than just testing to ensure the product functions properly; success is also defined by how prepared the product is for advertisement, delivery, installation, training, support, etc. In this paper, we’ll discuss how testing can be expanded to cover all aspects of Total Product Readiness (TPR).
|
Douglas Thacker, Liberty Mutual Insurance Group
|
|
|
What's That Supposed to Do? The Archeology of Legacy Systems In testing utopia, all software products submitted for testing have thorough and comprehensive documentation describing how every program function should work. On planet Earth, however, test engineers usually have to make do under less-than-ideal circumstances. It's not uncommon for test engineers to be asked to verify the functionality of a critical legacy system which has no documented requirements whatsoever. While there are many reasons this can happen, the result is the same: You assume the role of an archeologist sifting through the layers of clues to reconstruct the specifications. Patricia Ensworth gives you instructions and tools so you'll be ready to roll up your sleeves and dig.
|
Patricia Ensworth, Moody's Investors Service
|
|
|
High Maturity Benefits and Blarney With more and more organizations claiming to be Capability Maturity Model (CMM) Level four or five, is high maturity all it's cracked up to be? This talk clarifies what attributes should be present in a true high maturity organization, and presents case studies where organizations benefited substantially from achieving these high maturity capabilities. It also addresses practices that, while they technically quality as high maturity, add absolutely no business value to development and its customers.
|
Bill Curtis, TeraQuest
|
|
|
Iterative Software Development - from Theory to Practice This paper describes how an iterative software development process has been adopted in RAFAEL, based on the Unified Software Development Process (USDP) introduced by Rational Inc. The paper identifies the core differences between iterative and waterfall software development, addresses the possible difficulties in applying the iterative
process and details the elements of an iterative software development process tailored to RAFAEL, in view of its activities, work products, reviews and other terminology
adaptations.
|
Amir Tomer, RAFAEL Ltd.
|
|
|
Sorting Out Six Sigma and the CMM While the Capability Maturity Model has become widely accepted as an approach to software process improvement, Six Sigma is becoming increasingly popular in manufacturing and service organizations. This has resulted in some confusion over methods and conflicts for resources. However, the two approaches are actually synergistic.
|
David Card, Software Productivity Consortium
|
|
|
Solid Software: Is it Rocket Science? While we can't guarantee that our software will never fail, we can take serious steps to reduce the risk. The toughest kind of system to build involves safety-critical software where the reliability requirements are extremely strict-and whose failure puts lives in jeopardy. Shari Lawrence Pfleeger looks at what "solid software" means, and explores ways we can achieve it. She examines solid software within the context of the proposed National Missile Defense System.
|
Shari Lawrence Pfleeger, Systems/Software, Inc.
|
