Conference Presentations

GUI Usability Design and Validation with Paper Prototypes

Usability testing of early GUI designs with paper prototypes validates that you are building the right applications for your customers. This low-cost, high-impact practice allows you to rapidly evolve the GUI interface and find many design bugs early in the development process before coding begins. With this process, you can get external customers and internal users actively involved in designing and testing the GUI with tools they can easily manipulate. Based on project experiences at The MathWorks, Inc., you will learn how to move from the paper prototype to a coded GUI and a set of automated tests. In addition, you will learn to develop user documentation while working back and forth between the GUI and the test plan to clarify design choices.

  • Involving everyone in GUI design early in the project
  • User tasks and scenarios as the basis for GUI validation
Ann Walker, The MathWorks Inc
Pervasive XML for the Agile Enterprise

XML technology usage continues to grow and is being incorporated in enterprise applications. Industry groups are embracing XML as a mechanism to encourage standard data interchanges within their vertical industry. XML is now common in Web applications, desktop software, services-oriented architectures, and application configurations. Learn about Hartford Financial Services Group’s challenges and successes developing and deploying an enterprise strategy for XML in all their application tiers. Find out how they use the same schema for business rules engines, Web services, and user interfaces and how XML has become an integral part of their enterprise's service-oriented architecture. Take away a practical approach to manage and secure your XML based applications.

  • Changes in development practices when emphasizing XML implementations
  • A structure and process for managing XML schemas across the enterprise
James McGovern, Hartford Financial Services Group
Build the "Right Software" to Delight Your Customer

Many companies have implemented quality programs such as CMM®, TQM, Six Sigma, etc., to improve requirements and software development. However, these initiatives often focus on building the software right-meeting quality expectations and specifications-but do not necessarily focus on building the right software-the right functionality at the right time and at the right cost from the customer's perspective. Unmesh Gundewar explains how EMC employed the Goal, Question, Metric (GQM) methodology to identify key measurements that ensure the "right software" is being developed. Learn how EMC applies the Six Sigma approach to drive these measurements into the organization and the resulting software. Move beyond the processes designed to get functional requirements and specifications right as Unmesh shares experiences, the challenges faced, and lessons learned from building the right software.

Unmesh Gundewar, EMC Corporation
STAREAST 2000: Testing and Test Automation: Establishing Effective Architectures

Fast development cycles, distributed architectures, code reuse, and developer productivity suites make it imperative that we improve our software test methods and efficiency. What process assessments are available? How do you conduct an assessment? How do you guard against incorrect information? How do you know what to improve first? And how can you make successful improvements without negatively impacting your current work? Learn the answer to these questions and more from Intel’s experiences using the Test Process Improvement (TPI) model as a basis for two assessments with resulting scores, improvement suggestions, and adopted actions. You will hear about the high points and low points of using this process and see a comparison of the TPI model with the CMMI® Level 3 key process area.

  • The TPI and other models for test process assessments
  • A first-hand account of two test process assessment experiences at Intel
Edward Kit, Software Development Technologies and Hans Buwalda, CMG TestFrame Research Center
Undoing Testing Methods in Agile Projects

The period 2002-2004 was one of enormous progress in figuring out how testing fits in on agile projects. Test-driven design is more about designing and writing the code than about finding bugs. New testing tools such as xUnit and FIT came out and received a lot of use by early adopters. The hopeful notion that customers would write acceptance tests to find bugs was expanded, challenged, and deepened. With all that progress, it's hard to be dissatisfied with these methods in agile projects. But past ways of thinking are holding us back. To make further progress, we have to split our notion of testing into two parts: the task of after-the-fact product critique, and a role that has nothing at all to do with bugs and, really, little to do with the word "testing." Brian Marick, a founding member of the Agile Alliance, explains what that role presents and some ideas on how to fill it.

Brian Marick, Testing Foundations
People + Process = ROI!

Return on investment (ROI) is a widely used approach for measuring the value of new or improved technology and business processes. Rather than limiting the discussion on ROI calculations to cost cutting measures, the most significant opportunities often come from addressing the overall business objectives. You need to step outside the focus of the IT department and relate improvements to opportunities for increased business revenue and customer value. The resulting impact on revenues makes the ROI argument for process improvement a compelling one. Discover the myths and realties of software process improvement and how to build a business case for improvement initiatives. By aligning business goals with areas of leverage and improvement plans, you will find both business and IT management more receptive to software process improvement programs and initiatives.

  • The real ROI from software process improvement
Geoffrey Hewson, Software Productivity Center, Inc.
Adopting Agile Practices on Non-Agile Projects

Does your team want to take a stab at Agile development without making a full commitment? Or, are you a manager who has read or heard about Agile development and want to experiment with it before making a large upfront investment? Then, this session is for you. Projects without the authority, time, or inclination to cast aside traditional development processes still can improve code quality, respond to change quickly, and deliver more valuable functionality by adopting one or more Agile practices. Learn how to embed Agile practices like automated testing, continuous integration, short iterations, and small releases into environments with heavy process, fixed schedules, and traditional waterfall methods. Here is an opportunity to discuss your development problems within the context of the presentation and walk away with valuable Agile techniques you can implement one at a time.

Peter Schuh, Peter Schuh Consulting
Making Process Improvement Work with Six Sigma and the CMM/CMMI

In this presentation Terrence Craft, a Certified Six Sigma Black Belt, provides an experience-based look at how to make the capability maturity model (CMM®/CMMI®) work most effectively with Six Sigma. While CMM®/CMMI® give us the "what" should be done for software development, Six Sigma gives the tools to answer the "how." The overlap of the two approaches provides an opportunity to leverage the best from each. And, there's a synergistic effect that happens when you apply the benefits of the CMM®/CMMI® models with the tools and techniques from Six Sigma. Whether or not you are using CMM®/CMMI®, find out what the Six Sigma approach is all about and what it can do for your company.

  • The Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) process and how it applies to software development
  • An understanding of Six Sigma used with CMM® or CMMI®
Terrence Craft, First Data Resources
Using Defect Data to Make Real Quality Improvements

A large development organization was challenged to decrease production defects by at least 70 percent. Without extra money or time to install major process changes, what should be done? For a baseline, there was a production defect database that had been running at a steady state for over a year, but no way to size the many different projects and no appetite for either function points or measuring lines of code. In this interesting case study, Betsy Radley reports how they used approximations and sometimes crude assumptions to develop measurements from the defect data. These measurements identified applications that had the fewest product defects. Find out how they used that information to look for processes and tools used in these "good" applications and then applied them to the "bad" applications.

Betsy Radley, Nationwide Insurance Company
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

Pages

CMCrossroads is a TechWell community.

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