Info

Shorter time frames result in an iterative process of design, prototype, develop, test, and deploy small elements. This process is known as growing software, as opposed to the old concept of developing software. Growing software engages the user earlier, each component has an owner or a small set of owners, and expectations are realistically set. In addition, each software component has a clear and precise statement and set of objectives. Software components and small projects tend to be less complex. Making the projects simpler is a worthwhile endeavor because complexity causes only confusion and increased cost.

Shorter time frames result in an iterative process of design, prototype, develop, test, and deploy small elements. This process is known as growing software, as opposed to the old concept of developing software. Growing software engages the user earlier, each component has an owner or a small set of owners, and expectations are realistically set. In addition, each software component has a clear and precise statement and set of objectives. Software components and small projects tend to be less complex. Making the projects simpler is a worthwhile endeavor because complexity causes only confusion and increased cost.

The "Chaos" report reflects the predominant beliefs among software managers, namely that the primary reasons for success and failure center on the requirements management process. The data imply that if organizations understand what they are building (the requirements), then how it gets built (the process) is not a big issue. But that is far from true: Requirements management activities typically consume only about 10% of life-cycle resources; the other 90% must also be performed successfully. Because requirements management activities dominate the early life cycle, they are an easy scapegoat. In contrast to what the data imply, the recommendations in the report for making the problem smaller are quite insightful and are consistent with the spirit of a modern iterative process.

Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially

This report [Defense Science Board, 1994] presents the following conclusions:

• Current Department of Defense practice was not compatible with commercial business practices.

• DOD program management approaches discouraged the use of commercial practices.

• There was a shortfall of sufficiently qualified software personnel at all levels of DOD.

• DOD had not fully identified the pros and cons of using commercial components.

• DOD did not emphasize architecture.

• DOD did not adequately promote technology transfer with the commercial market.

The report states that although DOD had performed numerous studies of software projects (18 were enumerated), the majority of the recommendations from these studies had not been implemented.

The principal reasons that DOD software projects get into trouble are identified as follows:

• Poor requirements definition

• Inadequate' software process management

• Lack of integrated product teams

• Ineffective subcontractor management

• Lack of consistent attention to process

• Too little attention to software architecture

• Poorly defined, inadequately controlled interfaces

• Software upgrades to fix hardware deficiencies

• Focus on innovation rather than cost and risk

• Limited or no tailoring of military standards

These primary recommendations are made:

• Exploit commercial practices (such as iterative development and architecture-first processes).

• Exploit commercial components and technologies.

• Invest more in software education for DOD people.

The report discusses ways to resolve the risks it identifies. It does not overhype the need to do a better job of defining and controlling requirements, as many previous DOD studies had done. This topic is mentioned and then discussed with appropriate emphasis, balanced with many other equally important factors. The "Chaos" report pins most of the blame for unsuccessful projects on requirements management deficiencies. The Department of Defense would have agreed in the late 1980s, but seems to have matured to a more balanced self-assessment and understanding of both the symptoms and the disease.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment