The history of many software projects shows that requirements mistakes are the most expensive ones to correct late in development. So, why do we make big requirements errors over and over, even in mission-critical software projects? Karl Wiegers, author of a best-selling book on software requirements and a consultant on many such projects, shares his top ten requirements principles to help your organization produce accurate, consistent, and unambiguous requirements.
Better Software Conference & EXPO 2004
Focusing on the customer throughout the software development lifecycle (SDLC) is difficult to do. Teams often can become mired in technical problems, internal resource limitations, or other issues. Following the customer mantra of "Faster! Better! Cheaper!" Steve Wrenn offers measurement and process techniques that he has used to deliver projects on time, on budget, and, most importantly, meeting customers needs.
Design patterns are powerful tools when understood and employed properly. Combining design patterns and test-driven development (TDD) using a set of design principles will achieve higher productivity and quality than either practice alone. With numerous code snippets as examples, Thirumalesh Bhat describes the design principles and resulting patterns that have been extracted from TDD practices at Microsoft.
Design and architecture decisions made early in the project have a profound influence on the testability of an application. Although testing is a necessary and integral part of application development, architecture and design considerations rarely include the impacts of development design decisions on testability. In addition, build vs. buy, third party controls, open source vs.
In this session Paul Desantis takes you through the important aspects of requirements discovery, including sampling documentation, research, observation, questionnaires, interviews, prototyping, and joint planning.
Developers and testers sometimes get into a frustrating dance in which the developers provide code for test, the testers run tests and document findings, developers fix the problems and re-release for testing, and the testers rerun and document new, different problems, and so on. For good reasons teams often begin "formal" testing on new software while it is still being coded.
How do you build a product that is secure? Why are some products inherently more secure than others? Join Richard Ford as he shares his experiences, both building products and teaching other developers how to think about security. All too often, computer security is the last thing considered when building a new product; that is, security is relegated to a "bolt on" ... something to be added to the product before it can be shipped.
Expressing requirements as user stories is one of the most broadly applicable techniques introduced by eXtreme Programming and adopted by other agile development processes. User stories are an effective approach for capturing requirements from an agile project, not just those using XP. In this session learn what user stories are, how they differ from other requirements approaches, and why you should consider using them. You also will learn the six attributes all good stories must exhibit and see how to get started with user stories.
eXtreme programming emphasizes test-first coding-you write the tests before writing the implementation code. You can apply the same approach in design when developing a complex system, including an architecture to support testing. To be successful, systems developed with agile methods must support a high level of testability and test automation. For large distributed systems, more sophisticated testing is needed to help determine which components may be contributing to failures.
Test-driven (or test first) development (TDD) is an excellent method for improving the quality of software applications. It forces the programmer to focus on ensuring that the behavior of the objects at the lowest level of the system is appropriate. It also provides a mechanism to ensure that future source code changes do not break existing behaviors.