Better Software Conference & EXPO 2006

PRESENTATIONS

There's Always Time for Pragmatic Project Planning

"Plan your work. Work your plan." Or, "Plan? Plan? We don't need no stinkin' plan." Which is the best approach for your software project? According to Robert Galen, neither is the right answer. Because software projects are expensive and challenging, you need a pragmatic project plan-one that is concise, targeted, useful, used, and adaptive. Beginning with a chartering process that leads to a high level project strategy, stakeholders determine the critical success factors and where to focus their planning activities.
Robert Galen, RGCG, LLC
There's Always Time for Pragmatic Project Planning

"Plan your work. Work your plan." Or, "Plan? Plan? We don't need no stinkin' plan." Which is the best approach for your software project? According to Robert Galen, neither is the right answer. Because software projects are expensive and challenging, you need a pragmatic project plan-one that is concise, targeted, useful, used, and adaptive. Beginning with a chartering process that leads to a high level project strategy, stakeholders determine the critical success factors and where to focus their planning activities.
Robert Galen, RGCG, LLC
Unintended Consequences of a Capability Maturity Mismatch--Evidence from a Quality Audit

In this presentation Michael Harris describes the findings of a quality assurance audit (PPQA) of the offshore outsourcing arm of a major U.S. software development company in late 2005. As the executive in charge of much of the development and as a member of the PPQA audit team, the Michael has a singular perspective on the expectations and the reality of the project.
Michael Harris, David Consulting Group
User Stories for Better Software Requirements

The technique of expressing requirements as user stories is one of the most broadly applicable techniques introduced by Extreme Programming. In fact, user stories are an effective approach on all time-constrained projects, not just those using Agile methods. Mike Cohn explains how to identify the functionality for a user story and how to write it well. He describes the attributes all good user stories must exhibit and presents guidelines for writing them. Learn to employ user role modeling when gathering a project’s initial stories.
Mike Cohn, Mountain Goat Software
Validation: What It Means in an FDA Regulated Environment

Even though formal validation may not be required in unregulated environments, many mission-critical applications could benefit from performing some of the same activities required for FDA regulated systems. Validation provides documented evidence showing, with a high degree of assurance, that a system will consistently meet its predetermined requirements.
Chrys Kyee, Genentech Inc
Web Services Interface Design - Pitfalls and Proven Techniques

Designing Web services is all about the interface. Although tools for Web services development have advanced to the point where exposing application functionality is simple, the ease of building Web services does not diminish the need for careful planning and a highly functional design. Dave Mount opens his presentation by spinning the cautionary tale of slapping together a Web services interface on a poorly structured application.
Dave Mount, J-Soup Software, Inc
When the Customer Does Not Know Best

Failure to really understand business requirements, technical specifications, and schedule dependencies has embarrassed more than a few test teams. Before you assign the first test engineer to a project, sit down face-to-face with the customer and keep asking questions until you fully understand the scope of the system or application under test, how they will use it, and what success looks like through their eyes.
John Scarborough, Aztec Software Inc
Why Are Requirements So Poorly Defined?

Studies have shown that the quality of the requirements is one of the most important factors in the quality of an application and also in the time and costs required to deliver a system. Yet requirements are almost always ambiguous, incorrect, incomplete, too high level, logically inconsistent, and communicated by rumor. The irony is that the various techniques-which have been around for decades-for writing better requirements have not been widely adopted. The culture and the management of the software process are equally to blame.
Richard Bender, Bender RBT Inc.

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.