Neither of these models may be very effective if software development is to be done by an individual or a small team of multi-skilled individuals who will take part in some or all of the activities For one thing, it is very dif cult for an individual to perform more than one of these activities simultaneously For another, these life-cycle models are organized to allow the information that has been compiled, developed or uncovered in each of the phases to be communicated to the developers who will do the next phase For a sole developer or a small team, much of this communication would be extraneous Instead of concentrating on communications, a small team of developers would probably nd a life-cycle that concentrated on ensuring that software requirements were correctly interpreted more effectively This is because determining software requirements is by far the most dif cult and error prone activity

In this life-cycle model, the system concept is developed progressively as the project proceeds I m suggesting it as a good model for building your rst few real programs (ie those you create beyond this book) When you are new to a language or programming environment, it is a good idea to develop a few prototype programs to see how everything can t together It is also useful to build small example programs that let you try out various techniques in isolation, since you are less likely to get bogged down in unnecessary complexities As the name of this life-cycle suggests, the software system evolves from a very primitive version to the nal release version Once the essential requirements of the software (what it must do) have been determined and the major software components have been identi ed, development starts by the construction of the most visible features of the software (eg in a database system, you might develop data input screens), and demonstrations of these to the customer, or testing them to see if they meet your own requirements Based on feedback from the customer, or on whether the software meets your personal requirements, the prototype is developed and demonstrated, and this continues until the customer agrees that the prototype system is adequate or you are happy with it Any remaining work is completed and the system is handed over to the customer This form of development is useful for developing small systems where there is no great risk to trying out a few ideas, or larger systems where the software requirements are dif cult to capture; for example, a transaction management system for a new type of company, where the actual work to be done by the system has not been fully de ned It is also useful when a customer is reluctant to commit to any statements of software requirements, perhaps due to them being unable to envisage how a computer system will be used in their work Using evolutionary prototyping (Figure 13), the customer can always see the state of progress The main disadvantage of this form of development is that it is impossible for the developer to know how long the development process will take No price can be put on the software at the outset A major risk is that the development can devolve into code-and- x Proper evolutionary prototyping requires proper requirements analysis, design, well-organized and maintainable program code, etc The main differences from the general form of life-cycle discussed earlier are that the work

progresses in smaller increments, and that requirements analysis, design and implementation are interleaved within each incremental phase as successive prototypes evolve into the nal product

For our purposes, we are interested in planning the life-cycle phases of a system developed in an object-oriented style in general, and one suited to the special facilities available to Visual Basic in particular Different forms of life-cycle are used in different circumstances, the variations being due to a number of factors, including: