Conference Presentations

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 gets to the root of the problem and discusses ways to address the poor requirements issues. Learn quantitative measures of the quality of the requirements specification and practical approaches to writing unambiguous requirements for your applications.

  • Early validation of requirements through testing
  • Moving user acceptance test design up prior to the start of coding
Richard Bender, Bender RBT Inc.
An Integrated Configuration Management System Revealed

Many people talk about an end-to-end software development process in which requirements are developed and transitioned seamlessly into code with tests tracing back to the requirements. Geree Streun has learned that an integrated configuration management system should be at the center of that process. She explains the criteria for evaluating and selecting a configuration management tool to support your development process and why configuration management should be implemented in an integrated way. Find out what an integrated configuration management tool can do for you, how much control to impose, and how much administration you can afford. Watch a demonstration of the integrated configuration management system Geree's company uses to record defects against any software artifact and to ensure that tests track to the current version of the requirements.

Geree Streun, ANS
Testing the Nth Release

Congratulations! Your team is entrusted with testing the next release of an excellent product, one your customers have depended on for years. How do you make sure the fifth, tenth, or even the fiftieth update release is as good or better than the first version? Mature products have their own testing issues, different from those faced with new products. Susan McVey discusses the issues many testers face with legacy systems: what to test and what to trust, dwindling resources, handling known problems, aging test cases, inadequate time to maintain infrastructure, and more. Susan shares the promises and the traps of automated regression testing suites and discusses ways to keep your tests and testware up-to-date and clean. Learn to iterate toward higher quality and keep up the enthusiasm of your team-even when they're testing the Nth release.

  • The technical debt that builds up in mature systems
Susan McVey, IBM Rational Software
Code Coverage Myths and Realities

You've made a commitment to automate unit testing as part of your development process or you are spending precious resources for automated functional testing at higher levels. You may be asking yourself: How good are those tests anyway? Are many tests checking the same thing while large parts of the code go completely untested? Are your tests triggering the exceptions that normally show up only in production? Are your automated tests adequately covering the code, the requirements-both, neither? Andrew discusses the truths and untruths about code coverage and looks at the tools available to gather and report coverage metrics in both the opensource and commercial worlds. He describes the different types of code coverage, their advantages and disadvantages, and how to interpret the results of coverage reports.

  • The concept of mutation testing and how it fits into a code coverage strategy
Andrew Glover, Vanward Technologies
Better Software Conference 2006: Agile Development and Its Impact on Productivity

Agile development projects are different. Sure, they still have high-level business requirements, but they usually lack system descriptions, technical design documents, and system architectures. The projects tend to be smaller than those employing more traditional methods, and much of the testing occurs concurrently with development. The teams tend to be very small and often in one room, more like a group of friends than a typical development team. How do these and other differences affect productivity and the resulting products? Based on his research and personal experiences, David Garmus discusses the differences between Agile and traditional methodologies and offers specific ways to measure these differences to help you decide: Is Agile development right for your next project?

  • The quantitative and qualitative differences between Agile and more traditional projects
David Garmus, The 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. Whether you are a developer, tester, manager, or analyst, you can learn to write user stories that will speed up development and help you deliver the systems that users really need.

  • Defining a user story and learning how to write one
  • Six attributes of all user stories
  • Thirteen guidelines for writing better user stories
Mike Cohn, Mountain Goat Software
How to Estimate Anything

Given the choice between making an estimate of the time and resources to complete a project or getting root canal surgery, most of us would rush to the dentist’s office. We know that the pain of a root canal is short lived ... poor estimates can cause us agony and frustration for months or even years to come. The good news and bad news is that anything can be estimated. However, the quality of the estimate will depend upon the effort invested in the estimate, how thoroughly the thing to be estimated is understood, the quality of relevant assumptions, and finally, luck. An effective process can improve everything but the luck. Join Payson Hall as he presents a practical estimation process that can be applied to estimate anything and then practice applying the process during his presentation.

  • What goes into any good estimate
  • How to develop a good estimate for complex things
Payson Hall, Catalysis Group Inc
Building Traceable UML Models

While effective for modeling requirements, analysis, or design of a software system, UML diagrams are typically used in isolation or only for portions of a system. The resulting inconsistencies have the potential to create more confusion than clarity, negating the investment in the modeling process. Explore tips, tricks, and techniques to build a complete, traceable UML model for all aspects of a software application. Thomas Bullinger shares ways to gather behavioral requirements and map them into UML use cases. Learn to map use cases onto sequence or activity diagrams and extract them onto class diagrams. In a recursive process, each of the UML diagrams and associated descriptions is logically related to ensure a complete problem model and a consistent design solution.

  • Create self-consistent UML models of requirements behavior and designs
  • Manage change in UML models to reflect updates to requirements
Thomas Bullinger, ArchSynergy, Ltd.
Essential Software Quality Planning

An old-yet still true-saying is "You can't test quality into a software product." By planning for the quality expected in your software, your team and management will focus on the big picture-integrating development methods, the test processes, and the customer and product requirements within the framework of a quality assurance perspective. Starting with the key element of quality planning and its benefits, Tony Raymond explains how to derive quality objectives from requirements using a "just enough" balanced approach. He introduces methods to confirm that the development lifecycle processes are consistent with quality objectives and discusses the relationship of the quality plan to the test plan. Take back examples of quality planning and test planning templates to use in your next project.

  • How to define "just enough" quality objectives
Tony Raymond, New Harbor Technical Management
Integrating Security into the Development Lifecycle

Software security is neither a development problem nor an IT operations problem. Rather, it is a paramount business problem requiring a multidisciplinary approach that minimizes organizational risk when delivering software products. By making a program-level commitment to security, IT organizations will be in the best position to defend their businesses from growing threats. Ryan English explores business management and the process components of defining, designing, instituting, and verifying secure development practices. He describes a broad set of principles that leading companies are adopting to improve the security of their software and outlines an application security program your company can implement. This approach requires a commitment to application security at all levels of management and offers the promise of a mature level of security without undue effect on the overall development process and delivery schedules.

Ryan English, SPI Dynamics Inc

Pages

StickyMinds is a TechWell community.

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