SPOOZ Inc (SPZI)

[alliecorp]

A Methodology to Support Software-Release Decisions
Hans Sassenburg

Software is everywhere, and developing it has become a major worldwide industry. We find software embedded, for example, in watches, coffee makers, cars, televisions, airplanes, telephones, reservation systems, and medical equipment. Software not only pervades a multitude of products, but also is an important corporate asset, and demand is increasing. Yet software projects are characterized by schedule and budget overruns and the delivery of unreliable and difficult-to-maintain software products.

Despite an exponential increase in the demand for and dependence on software, many software manufacturers exhibit unpredictable behavior. It is sometimes difficult to determine, for example, a software product’s release date, its features, the associated development costs, or the resulting product quality.

Uncertainty in the release date causes difficulties in planning product promotions, customer training, and maintenance support. Resource utilization across projects can become inefficient and difficult to manage when projects do not meet schedules. Customers have difficulties planning for the introduction of new software into their organizations when a scheduled release date is missed.

The exponential growth of the number of software products and releases suggests that end users will be exposed to more defects if the software industry is not able to reduce defect potentials and increase removal efficiencies at a similar rate. Competitive pressures related to feature content, time to market, and product quality will make product-release timing decisions both more important and more complex.

A Strategic Software-Release Methodology

Software-release decisions often have strategic implications because of the high costs of reversing the decision. Prospective losses also may arise long after the release decision has been made; for example, in cases where liability leads to lawsuits. Existing decision models for product release often do not account for market strategy. Ideally, release-decision criteria should align with corporate strategy.

A software-release decision can be seen from different perspectives:

Maximizing behavior.

A software-release decision is a tradeoff between early release to reap the benefits of an earlier market introduction and deferred release to enhance functionality or improve quality. If a software product is released too early, the software manufacturer incurs the post-release costs of later fixing failures. If a software product is released too late, the additional development cost and the opportunity cost of missing a market opportunity could be substantial. These two alternatives must be compared to determine which alternative maximizes economic value.


Optimizing behavior.

A release decision is affected by the difficulty of verifying the correct implementation of functional and non-functional requirements. How much testing is needed? Software manufacturers must find the optimal level of information because information has its price in cost and time. In practice, cost and time will constrain the ability to retrieve complete and reliable information, so this search for information should be considered as an economic activity. This leaves the software manufacturer with the problem of finding the optimal level of information where marginal value equals marginal costs and marginal yield is zero. This optimal level is difficult, if not impossible, to find.

Satisficing behavior.

Decision-making in the real world is often unstructured and normally involves various stakeholders who may have reasons to release a system or software product because of political or business pressures even though they know that it still contains defects. A study of spacecraft accidents, for example, reveals that, although system and software engineering were inadequate during development, management and organizational factors—including the diffusion of responsibility and authority, limited communication channels, and poor information flows—played a significant role [Leveson 04].

Decision Implementation.

A decision is considered successful if there is congruence between the expected outcome and the actual outcome. This definition sets requirements for decision implementation. In practice, there are many obstacles to the successful implementation of almost any decision, including


- the reduced importance of a decision once it is made and implemented

- the control of the outcome of a decision by stakeholders not involved in making it

- the development of new situations and problems that command the attention of the decision-makers once the choice has been implemented

http://www.sei.cmu.edu/news-at-sei/features/2006/04/feature-2-2006-04.htm