An evolutionary perspective
6.1 System evolution and evolutionary systems
6.1.3 Critical Needs for Evolutionary Systems .1 Developing the right software
The need to develop the right software originates with the problem of requirements speci cation.
It is nearly always the case that the user does not know precisely how the software should behave before the software development begins. Only in very special and limited cases can the speci cations for software systems be frozen at the beginning of development. This is most certainly the case for C3I systems where the human user is central to the operational system. It is also the case in many real-time embedded systems where the operating environment takes the place of the user.
Unless everything is known about the operating environment a priori, the context of the software development will change. When the context changes, then the requirements change and so does the path of the development to the right software.
It is not unusual in procurement of large software systems to nd that application systems do not meet the needs of the user. Either the user has not been able to articulate the requirements, the requirements have changed during the period that the software is being developed, or the user does not really know what he/she wants before the system development starts. The purpose of user-centered development and evolution is to make the software satisfy initial needs and then to allow the software to evolve to satisfy continuing needs. This can be accomplished in a number of ways.
Real users need to be involved in the software development process throughout the lifetime of the software. During the requirements elicitation phase, the users must not only be interviewed regarding their perceptions of requirements, but they must also be presented with live prototypes
CHAPTER 6. AN EVOLUTIONARY PERSPECTIVE 62 demonstrating aspects of the completed system. Only through this experiential knowledge can the user distinguish what he/she thinks is needed from what is really needed. During the development phase, the users need to be using preliminary and functionally incomplete versions of the completed system so they may revise their stated needs. During the maintenance or evolutionary phase (after an initial capability has been elded) the user must continue to provide feedback as to possible enhancements that will increase the functionality of the system or increase their productivity.
Another important aspect of building the right software is concerned with its correctness. Not only must the software perform the correct application functions, but it must also perform those functions with a high level of assurance. The software must be correct with a high level of con dence and that correctness must be maintained as the system evolves.
6.1.3.2 Developing the software right
Developing the software right refers to the problem of using good practices to develop high quality software. High quality software is software that not only provides the right functionality, but also provides the other non-functional qualities. For example, the software should be maintainable and evolvable, modular, general enough to be transported to newer faster processors, consistent in structure and architecture, easily analyzable, and exible. In other words, the software should not only satisfy a set of functional requirements, but should also satisfy a set of non-functional requirements. In other words, the software should be well-engineered. Having a well-engineered system requires standard practices that are followed within organizations.
The discipline of software engineering is focused on turning the previous "art" of software development into engineering. That is, software should be developed according to a body of practice including standards, measurements, techniques, and notations that are well founded, understood and trusted as opposed as being crafted by artisans where quality is totally dependent on the skill of the programmer and on improvements made during test. One of the approaches used to provide an engineering safety net to software is to concentrate on the method by which the software is being developed. Software process is put in place and followed to assure against otherwise unforeseen problems in development.
Over the last ten years there has been a focus on "software process" which has called attention to the de ciencies of the engineering practices of developing large software systems. It has called attention to the need for the application of traditional engineering practices to software. SEI eval-uations have shown than most software development organizations are operating at a rudimentary level. In particular, they found that there are failures to develop written plans, failures to follow existing practices, failures to monitor and evaluate the process and the product, and failures to
CHAPTER 6. AN EVOLUTIONARY PERSPECTIVE 63 manage con gurations of large systems.
There is a particular need to establish and routinize practices that apply to evolutionary systems in particular. Practices must be established that address a new life cycle model that accommodates software that is elded early and continues to change over its entire lifetime. Further, these practices must be followed with some rigor.
Practices need to be instrumented so that it can be determined whether the practice can be repeated, improved, and optimized. Metrics need to be applied to processes as well as products.
Once this is done with respect to evolutionary systems there will be some reasonable way to predict cost and schedule and avoid costly overruns.
Finally, the system acquisition process needs to be modernized if the new evolutionary prac-tices are to become standard. If it is accepted that it is impossible to specify all requirements in the beginning and if it is accepted that initial requirements for operational systems will change as development progresses, then it must also be accepted that there be an incremental acquisi-tion practice. In other words, it is necessary for the acquisiacquisi-tion practices to be parallel to the development practices.
6.1.3.3 Developing the software rapidly and a ordably
Developing software rapidly and a ordably refers to economics of software development. Software that is developed and elded after a period of years without intermediate elded products is guar-anteed to fail because the world does not stand still. Technology changes, user needs change, and operating environment change. Sometimes these changes occur quite quickly. A ordable software is particularly important in view of decreasing budgets. Commercial practices have changed the economics of developing large software systems and the government should take advantage of these new business practices.
Both the software product and the software process need to address productivity and a ord-ability. Software products need to be considerably less costly than they have been in the past.
They also need to be more capable than in the past. Real time embedded systems are considerably more complex and the software components systems are consuming a considerably larger portion of the total e ort.
Three principles of future operational systems apply in the area of a ordability and productivity.
First there needs to be greater capability developed. Second, this capability needs to be developed at lower cost. Third, this capability needs to be elded initially in a much shorter time and then needs evolve quickly as well.
CHAPTER 6. AN EVOLUTIONARY PERSPECTIVE 64
6.1.3.4 Evolving systems to meet changing user needs
Evolving a system to meet changing user needs is re ected by a need to change software during long lifetimes. Rarely does the mission of large operational systems stay the same over long periods of time. As the mission changes, so must the software. Since rewriting the software from scratch is prohibitively expensive, it makes sense to design the software for change in the rst place. This concept is sometimes referred to as "Pre-Planned Product Improvement" (P3I).
Traditionally, maintenance has been considered a separate phase from development. Frequently, the maintainers of a system have had di erent skills from developers and use di erent tools. Main-tainers have been from di erent organizations than the developers. In many cases, contractors develop software for government organizations, and then government employees become the main-tainers. This discontinuity between development and maintenance has led to many problems in the past.
For legacy systems, there is still a need for evolutionary principles to be applied. It must be easier than it is now to x problems that are reported from the eld. It must be easier to enhance performance and functionality. It must be easier to accommodate changes in the operating environment. In other words, there needs to be evolutionary technology applied to existing systems so that they will be nearly as easy to maintain as newly developed systems. This will not be accomplished without some reengineering. There will be needs to refresh, rewrite, redesign, and redocument. However, over the long term, these costs can be more than justi ed by the savings achieved in maintaining "unmaintainable" systems.
The need for evolvability over the long term must be addressed from the very start of new system development. While it may be possible to reengineer legacy system, the big payo will come from newly developed systems. When evolution is a starting criteria, there can be a much bigger emphasis on engineering for change. There can be a much stronger emphasis on commonality, consistency, and structural integrity. Pre-planned product improvement addresses the need for change. It addresses the need to reduce long-term life cycle costs as opposed to short-term development costs.
It addresses the need to design software with new mission requirements in mind. New functionality needs to be tightly integrated with existing functionality rather than patched on at high performance costs and high maintainability costs.
CHAPTER 6. AN EVOLUTIONARY PERSPECTIVE 65