Conference Presentations

When Saying Yes Doesn't Help: Software Development as Codependent Behavior

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.

Lee Copeland, Software Quality Engineering
Design Patterns in Test Driven Development

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. Learn more about these design principles: commonality/variability analysis, open/closed principle, high cohesion, low coupling, prototyping, designing for current features, single point of maintenance, refactoring, unit testing, testability, and cost/benefit analysis. Adapt and apply these principles and design patterns to your TDD projects for the same benefits.

  • Fundamental principles of design patterns
  • Test-driven development (TDD) and refactoring
Thirumalesh Bhat, Microsoft Corporation
Design Testability and Service Level Measurements into Software

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. proprietary, and other similar questions can affect greatly the ability of an organization to carry out automated functional and performance testing-both positively and negatively. If the software or service is delivered to a separate set of end-users who then need to perform testing activities, the problems compound. Join Jay Weiser to find out about the important design and architecture decisions that will ensure more efficient and effective testability of your applications.

Jay Weiser, WorkSoft
End to End Security: Building Products Right

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. You will see demonstrations of security flaws that illustrate why security should be considered at every stage in the product process, from initial idea to golden master… and beyond. Learn to think about security holistically and take away a checklist of issues to consider at every step in the product lifecycle. Finally, gain insight into ways of building a development culture that is security aware and maintaining an efficient but secure corporate culture.

Richard Ford, Florida Institute of Technology
Patterns for Writing Effective Use Cases

Use cases are a wonderfully simple concept: document a system's functional requirements by writing down scenarios about how using it delivers value to its actors. However, writing effective use cases is more difficult than expected because you frequently must deal with difficult questions, such as: scope, level of detail needed for different people and projects, how to describe external interfaces, stored data, and more. You need a source of objective criteria to judge use case quality and effectiveness. Fill this critical information gap with a pattern language that provides simple, elegant, and proven solutions to common problems in use case development. Take away these use case patterns and profit from the knowledge and experience of other successful use case writers. And develop a new vocabulary for describing the properties of quality use cases.

  • The "signs of quality" and properties of a good use case
Steve Adolph, WSA Consulting Inc.
Better Software Conference & EXPO 2004: The Seven Habits of Highly Insecure Software

Over the past few years Herbert Thompson and his cohorts have scoured bug databases for the most malevolent and destructive security bugs ever to infest a released binary. Through that search they found that common characteristics and habits emerged-creating temporary files with secure data, trusting that system calls will succeed, foolishly relying on insecure third party components, and many others. In this session, he offers a startling and even scary accounting of the top seven habits of insecure software. Take away a red-teaming strategy that has broken some of the world's most secure software under testing contracts with Microsoft, IBM, the US DoD, and many others. Use this approach to make your software more secure, and you can sleep better at night.

  • The differences between security defects and other common errors
  • An intimate understanding of security faults as seen by hackers
Hugh Thompson, Florida Institute of Technology
Customer Focused Business Metrics throughout the SDLC

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. By focusing on the development cycle from the outside in, his organization provides business-based metrics dashboards to monitor and adjust the project plan throughout the development project. Find out how their performance dashboard helps the team and the customer stay on course and drive directly to the targeted results. Discover an approach to determine what customers really want and match product development to customer expectations.

Steve Wrenn, Liberty Mutual Insurance Information Systems
Leverage Earned Value Management with Function Point Analysis

In the Earned Value Management (EVM) approach, as work is performed, it is "earned" on the same basis it was planned-both the original plan and agreed to changes. Today, more and more software projects are using this approach. Function Point Analysis has been shown to be a reliable method for measuring the size of computer software based on detailed requirements and specifications. Function points can be leveraged throughout the EVM process to establish cost and schedule baselines, control project scope over the lifecycle, and quantitatively assess percent complete. Ian Brown delves into the concepts of EVM as applied to software development and the key conditions necessary to profitably employ this management technology. Learn how companies are using function point analysis to improve the technology.

  • Earned Value Management applied to software development projects
Ian Brown, Booz Allen Hamilton
Software Project Poker: Should We Keep Betting or Fold?

Software projects are like stud poker hands-all have great potential at the beginning, additional information becomes available as they progress, and it's hard to remain detached from the emotion of the game. The goal of an interim project review is to offer an independent analysis of the current state of a project and a pragmatic assessment of the project's chances of success or likelihood of failure. Learn the steps for performing an objective project assessment, getting the facts, and keeping emotions in check. Find out how to determine if a project can be saved or if it should be stopped. See examples of how to effectively present bad news to executives who might be tempted to throw good money after bad.

  • A model for conducting an interim project review
  • Questions to assist with an assessment of project health
  • Present difficult findings to encourage good business decisions
Payson Hall, Catalysis Group Inc
Testing your Web Site for Privacy, Quality, and Accesibility

Today's business world relies heavily on transactions conducted through the web. Because of this, brand image and how a web site is rendered to customers has become increasingly important. A poorly functioning web site poses significant risk for web-based companies. This presentation discusses the challenges involved when testing to ensure the quality of your company's web site and to ensure that the components of the site function properly. With the ever-increasing web complexity, specific tools and processes are required to manage these challenges.

  • Discover ways to ensure that your web site reflects your privacy policy
  • Learn how to manage your web sites's links to ensure that they remain current and unbroken, and ensure that web content is accessible to users
  • Learn about specific tools and processes to test and manage your web site
John Burg, IBM Global Services

Pages

AgileConnection is a TechWell community.

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