Two conceptual notions are identified as controlling the current system/software development operations. Both greatly impact the development process. The first concerns requirements, while the second concerns program management responsibility.

The experience of practitioners is reported to be quite different than these notions would lead us to expect. The paper examines the implications of changing the conceptual notions bringing them into consistency with the practical experience.

Requirements according to these notions should be defined with complete rigor, and design must be exactly as specified (no more and no less than). Practice shows us that requirements not only mature slowly, but also change through the development and also the life-cycle.

A development project, according to the second notion, needs to be treated (to optimize schedule & dollars for this project) as if both the product and the process, by which the product is built, are new work unqualified by previous work. However practitioners, carrying out the development, feel the work is more similar to maintenance business than it is to new work (i.e. that it is qualified by previous work). This is because requirements are interpreted in terms of previous experience. Old designs and implementations are adapted to the "new" project. And old code (at least the executive part and/or application framework) is used as a springboard to create the new code. In fact reusability occurs naturally to the degree that it is able. But under current notions the reusability that is able to occur makes little impact on development cost.

The paper explores a product line approach to project development in which only very specific product line type requirements are expected to be fixed, and in which the unique project requirements are implemented by a product line development process.

This approach is shown to be consistent not only with practical experience, but also with the current technological advances which make the new concepts practical in to-day's environment.

Edward Averill

Affiliation

Refine Results

Management of the Software Problem