Header for Better Software Conference


Contact Software Quality EngineeringRegister for Better Software Conference

Software Quality Engineering

 

Concurrent Sessions

Go To:  Managing Projects & Teams | Plan-Driven Development | Agile Development

Process Improvement & Measurement | Testing & Quality Assurance | Security & Special Topics


Plan sessions
Plan-Driven Development
Traditional software development methods stress eliciting and documenting a set of requirements, followed by architectural and high-level design and coding, along with an integrated review and testing approach. Find innovative ways to hone your development practices and deliver higher quality software on a predictable schedule with the right level of staffing.

 W4 Wednesday, September 21, 2005, 11:30 AM
Managing and Sizing Functional Requirements
David Herron, David Consulting Group

The ability to clearly define and size user requirements is critical to the overall success of many software projects. You need effective requirements development and management skills to identify, describe, and record the functions requested by end users. With these in place you have the information necessary to assess project complexity and make reasonable size and level of effort estimates. David Herron describes reliable requirements gathering and documentation techniques including context diagrams, use cases, and mind maps. He discusses function point analysis as a software sizing methodology used by leading edge companies. These techniques, together with the associated tools and templates, provide you with the elements you need to more effectively develop, manage, and measure software requirements.

• Sizing functional requirements for project planning
• Diagramming techniques for documenting and clarifying functional requirements
• The value and complexity of the requirements using Function Points


 W5 Wednesday, September 21, 2005, 1:45 PM
Model Driven Architecture (MDA)—What’s in It for Developers and Testers?
Timothy Korson, Korson Consulting

The development world is changing faster than you may realize. According to the Object Management Group (OMG), the benefits of generating systems directly from UML models are significant to businesses and developers alike: reduced overall product life costs, faster development, better application quality, rapid deployment of new technology, and a higher ROI on new technology. In short, the hype is that MDA enables system integration strategies that are better, faster, and cheaper. However, the MDA approach represents a fundamental change in the way software is developed, and it revolutionizes how you allocate test resources and how you create system tests. Timothy Korson outlines the MDA process and then suggests ways to change quality assurance activities to mesh with the MDA development style. Take away a realistic view of the current state of MDA practices compared to the MDA promise and vision, offered by the OMG.

• Impact on developers, testers, and managers
• The hype and realities of generating systems directly from UML models
• A paradigm shift for testing and quality assurance


 W6 Wednesday, September 21, 2005, 3:00 PM
Software Factories: Hype or Hope for Real Advancement?
Gunther Lenz, Siemens Corporate Research, Inc.

The new concept of Software Factories, as proposed by Microsoft, promises to elevate software development to the next level. Siemens is pioneering this new methodology with the goal of improving product maintenance, quality, and time to market. Gunther Lenz explains the common elements and, more importantly, the differences between the Software Factories model and Model Driven Architecture (MDA), as proposed by the Object Management Group (OMG). Learn how UML 2.0, Domain Specific Languages, platform independence, product line development, and synchronization between models can all enter into the development process. Take away an in-depth understanding of the concept of Software Factories and its potential impact on tomorrow’s Software Development.

• The two most talked about approaches for Model Driven Software Development—Model Driven Architecture (MDA) and Software Factories
• Domain Specific Languages, software factory schema, product line development UML, platform independent models, and more
• Generate code from models


 T5 Thursday, September 22, 2005, 9:45 AM
Software Production Line Automation with Concurrent Development
C. Thomas Tyler, The Go To Group

The software development process can be optimized when it is thought of—and run—like a highly automated manufacturing production line. Rather than producing many identical widgets like a manufacturing plant, software organizations produce many programming changes. These changes may not be identical like manufactured widgets, but programming changes can start to look a lot like widgets when you look at the big picture. In this session, Thomas Tyler describes how to bring the processes and benefits normally associated with manufacturing to software development—efficiency, reliability, and extensive automation. Manufacturing organizations invest heavily in tooling and infrastructure to automate production lines, and they reap great rewards in efficiency. Find out what a software production line looks like, how it supports concurrent development, and how it can help you make better use of your limited development resources.

• The software development infrastructure as a software production line
• Constructing a software production line that enables concurrent development
• The business case to justify investment in software production line automation


 T6 Thursday, September 22, 2005, 11:15 AM
How Testers Can Fill the Requirements Gap
Robin Goldsmith, Go Pro Management

Testers frequently are frustrated by having to test a system without an adequate understanding of the expected results of the tests, often because the requirements are not well-defined or documented. Therefore, good testers learn how to discover the requirements they—and developers—need to do their jobs. Robin Goldsmith identifies approaches that testers can use to avoid the reverse engineering trap of inferring requirements from design. Learn to differentiate and focus on business/user rather than system requirements and understand the power of using approximations for corroboration. Find out how to enhance testing’s value by asking the right questions of the right people at the right time. Gain access to and cooperation from the business side while at the same time winning developers' appreciation.

• Unconventional approaches for filling the requirements gap
• Differentiating business requirements from system requirements
• How tests can serve as the requirements


 T7 Thursday, September 22, 2005, 1:30 PM
Getting to the Promised Land with CMM® and CMMI® Processes
Rick Hefner, Northrup Grumman

In hopes of delivering better software, cheaper and faster, many organizations have implemented the Capability Maturity Model (CMM®) or the Capability Maturity Model Integrated (CMMI®) for Software. Although they have achieved their desired maturity level and improvement goals, some organizations have seen little or no financial benefits. Find out if the underlying principles of the CMM® and CMMI® can help deliver higher productivity, predictability, and speed into your development. Get a truthful answer to the classic CMM® paradox: If you’re doing more work, how can it cost less and take less time? You will take away practical tips and techniques for realizing the qualitative and quantitative benefits promised by CMM® and CMMI®.

• The underlying principles of CMM® and CMMI® as they relate to productivity
• Return on investment from model-based improvements
• Timelines for realizing the benefits of CMM® and CMMI® compliant processes

CMM® and CMMI® are registered trademarks of Carnegie Mellon University.


 T8 Thursday, September 22, 2005, 3:00 PM
Let's Do It All Over Again: Configuration Mismanagement Techniques
Mark Pellegrini, Georgia Tech Research Institute

Being told about good configuration management practices is boring and does not do this vital process justice. What if you do it badly, as many development groups do today? The ultimate failure in managing the configuration of a software product is having it so horribly out of control that it cannot be rebuilt and must be rewritten from scratch. Few developers can claim this spectacular achievement, but many projects employ configuration management practices that result in rework and a loss of reputation with customers. Using humor and sarcasm, Mark Pellegrini looks at examples of how poor configuration management practices can sabotage product development productivity and generally make everyone’s life miserable. Avoid embarrassment by creating and auditing baselines, releasing controlled betas, documenting build procedures, avoiding undocumented components, using version control, and much more.

• What to look for in configuration management practices—both good and bad
• Justifying improvements in configuration management
• Examples of configuration management failures


Go To:  Managing Projects & Teams | Plan-Driven Development | Agile Development

Process Improvement & Measurement | Testing & Quality Assurance | Security & Special Topics


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

A Software Quality Engineering

Software Quality Engineering
Software Quality Engineering: Phone and FaxEmail SQE Customer Service
 © 2005Software Quality Engineering