|
|
A Strategic Approach - "Beta the Business" Beta testing is an industry standard practice to obtain user feedback prior to general availability of software. Have you ever considered that the Beta release can be used to validate the software's value to customers and application users? Extending the Beta concept will result in higher customer satisfaction (and higher revenue for commercial products). Also, you can employ Beta testing to evaluate not only the software product, but the distribution (and sales) process, training, customer support, and usage within your customers' environments. Far beyond just finding defects in the product, you can focus Beta testing on how well the software is meeting your customers' needs. What does that mean to the Development team and the organization as a whole? What are the risks and challenges that we face? What are the rewards?
|
Pete Conway, EMC Corporation
|
|
|
Continuous Integration Using an Open Source Platform Architecture 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.
|
Paul Duvall, Cigital, Inc.
|
|
|
eXtreme Architecture and Design for Test 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. For such complex systems, you should architect the system for testing rather than add testing functionality as an afterthought. Ken Pugh presents a framework that employs polymorphic-style internal and external interface patterns to ease the work of testing and debugging. He also covers adding test-only functionality, test-only outputs, and test-only logging to interfaces.
|
Ken Pugh, Pugh-Killeen Associates
|
|
|
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
|
|
|
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.
|
|
|
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
|
|
|
Navigating the Minefield - Estimating without Complete Requirements Your team is assigned to a new project, and you've had the kickoff meeting. Now, your boss' boss sends an email to you asking for a "guesstimate" of how long and how many people-days the project will take. What do you do? Even though developers and project managers can see the futility of doing premature, fixed cost estimates prior to requirements development, the industry still demands early estimates, often before a project is even named. Based on her experiences with similar projects, Carol Dekkers offers tips and tricks that she and others have used successfully to answer these difficult questions. Find out how to provide traceability when the original estimates turn out to be as inaccurate as the unknown requirements they represent.
- Early resource and time estimates without good requirements
- Organizing and documenting early requirements statements
|
Carol Dekkers, Quality Plus Technologies Inc
|
|
|
The Task StackProject Planning and Tracking Approach Task Stack Planning (TASAP) is a novel approach to systematic and quantitative project management. With this process you break down work into small "packages" that form the basis for comprehensive planning, tracking, and reporting activities. Team members participate in bottom-up planning activities, allowing unplanned work to be seamlessly integrated into the operational planning process. The operational plan is updated weekly with all results fed back into the overall plan. The TASAP approach is compatible with CMMI® operational planning requirements and is scalable to support large projects with low incremental overhead. Discover how to implement this integrated project planning process that supports distributed team settings.
- A project planning process for accurate schedule, cost, and quality predictions
- The linkage of operational and long-term planning
|
Gerold Keefer, AVOCA LLC
|
|
|
Key Factors for Making Offshore Development Work Inexpensive and technically competent labor in developing countries has made outsourcing some software development and testing activities an attractive alternative. As a result, more and more US-based companies are looking to India, China, and other countries to develop software. The success or failure of an outsource operation and whether or not it is a viable alternative depends upon some key factors important to both the outsourcer and the software provider. Using his personal experiences and others at Hewlett-Packard, Bhushan Gupta discusses the aspects of program management, communications, teamwork, process, interim deliverables, and cultural issues that will make or break an outsourced development project. Find out what types of outsourcer-vendor relationships work and ones that will most likely lead to failure, and get a first hand view of outsourcing at the ground level.
|
Bhushan Gupta, Hewlett-Packard USA
|
|
|
Teamwork and Good Communications are Key "Process" Areas, Too Most of the emphasis for development groups seeking improvement is to change processes and project management practices. But what are we missing? Why does our software often disappoint customers? One reason is quite simple-systems are built by people. People must work together, communicate well, learn from each other, and change personal behaviors based on experiences. In short they must operate as a team for the software to meet their customers' functional and quality needs. Based on her book, Achieving Software Quality through Teamwork, Isabel Evans offers a unique viewpoint on how to succeed in software development. Learn ways you can encourage (or stifle) teamwork; how to promote mutual understanding and tolerance of different communication styles; how different assumptions about quality can lead to failure or success; and methods for integrating teamwork and better communications into your existing processes and practices.
|
Isabel Evans, Testing Solutions Group Ltd.
|
