|
|
Breakthroughs in Measurement and Benchmarking The "business of IT" is in the limelight more than ever. The economic, regulatory, and geopolitical changes of the past three years have made companies rethink everything from their IT cost structure to their service delivery models and the value of software to their enterprise. CIO's have asked for innovations to make software development more agile and adaptive and ways to more effectively communicate with their business units. These pressures have driven leaders to implement breakthrough ideas resulting in a focus on new (and more important) measures of performance. Quantitative techniques are now available to better align business and IT through the implementation of powerful and expressive product/service catalog structures. If your organization embraces these new methods and techniques, it will benefit from full transparency and an enterprise view of its software portfolio as a critical business asset.
|
Howard Rubin, META Group Inc
|
|
|
Software is Entering a New Dimension - Are You Ready? A revolution in the business of software is coming . . . The boundaries between the business and IT from one enterprise to another will disappear. The space around functional system silos will dissolve. How we develop and deploy software will have to undergo radical change, challenging our entire thought process about how, why, and for whom we build it. Already today, delivery cycle times are down to days and business processes embedded in software represent invaluable corporate intellectual property. Soon, service-oriented architectures will enable ad hoc application integration and sophisticated, dynamic user-driven software configurations. Web services, already deployed on many corporate Intranets, will be exposed to customers (and competitors as well as malicious hackers). These forces represent profound changes in how software is developed and deployed.
|
Linda Hayes, WorkSoft
|
|
|
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
|
|
|
Questions to Ask a Software Vendor about Security (and Verify) before Purchase How do you choose which software vendor's product to buy? For a long time, CRM packages, ERP systems, and other commercial software selection criteria have come down to factors such as performance, compatibility, reputation of the vendor, support, and price. Security, though, has become a looming factor in the total cost of ownership and the risk of selecting one software product over another. Ed Adams describes the tough questions you need to ask vendors about security and how to extract critical information from them. Find out the steps to verify that their statements are accurate and their answers complete. With an approach for quantifying security risk before purchase, your organization will make more informed acquisition decisions.
- A security assessment approach for purchased software packages
- Quantifying security risk in software packages before purchase
|
Ed Adams, Security Innovation LLC
|
|
|
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
|
|
|
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
|
|
|
State of the Practice in Application Development: A Basis for Benchmarking This presentation explains why knowing broad industry trends regarding application development is not enough to ensure a successful project. AD should be tightly bound to businesses. Existing measures need to be reviewed and service levels for usefulness in measuring attainment of goals that directly support each line of business need to be considered. Read on as the author details these and other important points.
|
Robert Solon, Gartner Inc
|
|
|
Applying Software Inspections Through the Software Lifecycle Setting the priority and severity of a bug is a business decision. Changing business conditions impact the priority and severity of a bug. It's important to ensure that the staff that is assigning the priority and severity are aware of all relevant business drivers. This article discusses
conducting software inspections through the software lifecycle.
|
Robert Sabourin, AmiBug.com, Inc.
|
|
|
Team Size and Its Effect on Peer Reviews This article discusses the prerequisites to quantitative management. How to create effective teams by determining recommended team size for inspections is also discussed.
|
Mark Paulk, Carnegie Mellon University
|
