Most everyone agrees that iterative development reduces risk, but, of the many iterative processes, which will work best in your environment and what tools do you need to be successful? Learn the latest techniques and strategies you need to verify you have chosen the right processes to ensure your success.

W19	Wednesday, September 29, 2004, 11:30 AM

With the growing popularity of agile methods like eXtreme Programming and the emergence of automated, open source unit testing frameworks such as JUnit, the idea that developers should actively participate in testing their own code finally is gaining broad acceptance. Numerous studies and countless examples show the tremendous benefits of having a suite of unit tests created by developers and always executed before integrating units into a build. Unfortunately, the majority of development organizations attempting to implement automated developer testing fail to achieve long-term success. Alberto Savoia shares the underlying reasons that most developer testing efforts fail to take off and, more importantly, offers his “Seven Laws of Developer Testing.” Arm yourself and your organization with the information and tools you need to make managed developer testing your best bet for delivering significantly better software.

• Developer unit testing as an essential component for higher quality software
• The seven laws of successful developer testing
• Free tools and resources to help you get started with managed developer testing

W20	Wednesday, September 29, 2004, 1:45 PM

For configuration management (CM) processes and systems, one size does NOT fit all. Although CM processes are applicable across all projects and product lines, you need an approach tailored to the size and complexity of each project and the systems you develop and support. GTRI/ELSYS has deployed a flexible configuration management approach that meets and exceeds these needs. Learn about the features that all CM systems should have, such as: the ability to reproduce product baselines, version control of all product related work products, flexible levels of control, and support for other management processes such as audit, peer reviews, and requirements. Find out how to organize work products to support multiple baselines, document build instructions, and verify baselines. Walk away with a new perspective on how to deliver robust, cost-effective CM capabilities for both large and small projects.

• A proven, scalable configuration management process
• Change control issues and solutions throughout the product lifecycle
• Configuration management techniques to support requirements development and traceability

W21	Wednesday, September 29, 2004, 3:00 PM

Vague requirements, undocumented design, poor code, and impossible schedules — these are the typical complaints of many developers. Whose fault is it? Of course, it is “their” fault — senior management, customers, users, etc. But, could we be part of the problem? Codependent behavior is defined as “a way of getting needs met that doesn’t get needs met. We do all the wrong things for all the right reasons.” When we agree to develop systems without understanding user needs, we teach others that participation in the project is not important. When we agree to absurd schedules, we teach others that our legitimate needs do not matter. In this compelling session, learn what codependency is, recognize codependent behavior in yourself and others, evaluate the negative effects of codependent behavior, and ways to respond more appropriately to unreasonable demands.

• The meaning of codependent behavior and why it is rampant in software development
• How codependency constrains choices and limits success
• Break out of your codependent behavior patterns

T25	Thursday, September 30, 2004, 10:15 AM

Using open source tools in a development and test environment can be a big relief for your budget. However, open source remains a foreign and often frightening concept for many developers and organizations. Today, open source options are available for all types of tools used in the development process. In this session, you will gain a better understanding of the tradeoffs between choosing open source and commercial tools. In addition, you will learn about the wide variety of open source tools available for many operating environments and how to locate the most robust ones. Danny Faught, who has actively evaluated open source tools as they have evolved over the last five years, provides an honest analysis of the benefits and difficulties you may encounter using these tools for development.

• Open source tools to consider for you and your team
• Details about the benefits and pitfalls of open source for development
• A sound basis for making the decision to obtain an open source or a commercial tool

T26	Thursday, September 30, 2004, 11:30 AM

Continuous integration is the process of performing a fully automated build, run often, usually daily, during software development. How do you develop a robust platform architecture to automatically integrate your software into builds? How can open source tools fill the gaps in your platform architecture? After examining the benefits of continuous integration, Paul Duvall discusses techniques, such as architectural validation, configuration management, automated unit testing, and report generation within the process. From a working reference implementation in Java, learn the attributes of an effective platform architecture for continuous integration. Additionally, Paul will introduce you to open source tools, such as Ant, Maven, CruiseControl, Eclipse, xUnit, and others that can help you implement a continuous integration architecture in your environment.

• Continuously integrating your software during development to improve software quality and reduce risk
• A robust platform architecture for continuous integration
• Open source to support the platform architecture

T27	Thursday, September 30, 2004, 1:30 PM

Security is a complex and often overwhelming issue. You cannot rely solely on trying to prevent hackers from entering your systems. Instead, you must ensure that the system safeguards itself if a hacker does break in. Three of the most common internal software weaknesses hackers exploit are dangerously constructed SQL, buffer overflows, and runtime exceptions that are not properly handled. Although testing existing code for these defects can help, it is not fool proof. You also need to make a concerted effort to prevent security vulnerabilities from being introduced as the team is writing code. Through the application of practices, such as static analysis, dynamic analysis, unit testing, and runtime error detection, you can jumpstart your security efforts and keep the hackers at bay.

• The most common internal software weaknesses that hackers exploit
• Ensure that code safeguards security if a hacker does break in
• Remove security vulnerabilities and improve the overall code quality and reliability

T28	Thursday, September 30, 2004, 3:00 PM

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. Using C++ as the example language, Robert Walsh presents an overview of test-driven development, available TDD testing frameworks, and a demonstration of a project started from scratch using TDD. You can apply these concepts to other languages, including Java and Visual Basic. Learn how to overcome the initial hurdles many developers experience when starting out with TDD.

• An introduction to test-driven development using C++ as the example language
• The testing frameworks available for TDD
• Programming tasks that are difficult to implement using TDD

Software Quality Engineering Home       Conference Home       To Exhibit       Get a Brochure       Register for Better Software Conference & EXPO 2004

feedback  © 2004