Content |
|
 |
Software development activities Software systems do not come from nowhere, and computer programmers do not simply sit down at a computer and start writing code. Each software system goes through its own life cycle. Although every systems life cycle is unique, there are certain activities that tend to take place in some form for most systems. There are different models of software life cycles, which are not a topic covered by this module. Such models describe, or prescribe, both the activities and the sequence(s) in which the activities take place. The summary of activities below is provided as some useful background. In the case of object-oriented systems development, often activities are repeated in a cyclic fashion, since problems/limitations of models may not be identified until the design or implementation stages. Or perhaps the system users, when presented with prototypes of systems identify new features of their real world system that need to be integrated into the software system model and design. Examples of activities occurring is software systems lifecycles might include:
Analysis and modelling An analyst or team of analysts performed a study of the real world system that a computer system is to be developed to support. There may be an existing real world system, there may also be an existing computer system, or the project may be the development of a new computer system to support some new department or organisation that does not exist at present. One important task in modelling is the identification of the boundaries of the system to be modelled and what the system is to include. Models are created (for any existing, and the new, system), based on analysis of the data, tasks, communication etc. between those components identified as included in the new system, and those outside. Analysis and modelling involve activities where you try to concentrate on certain more, or less, abstract views of the system and to avoid making assumptions about detail. So analysis is what we do when we try to produce a model of a system free of any internal technology. The enclosing system context may set technology constraints; for example, automatic teller machine (cash point) software may have to be analysed in a context of current machines and cards with magnetic stripes. Hence you don't have choices during analysis, but you do at the next level down (in terms of detail and precision), and this is called design. System design Based on some form of model and analysis, a design for the computer system can be created. Such a design is often, but not always, focused by having made the choice of programming language that the system is to be implemented in. Implementation A system design is implemented in a particular programming language (or several, for complex systems). Part of a system implementation may involve integrating existing computer sub-systems, and perhaps designing communication with external computer systems and databases. Often one or more prototypes are implemented, to test ideas, and perhaps to provide users to help in an improvement of the system modelling and design. Often the term ‘coding’ is used to describe the activity of actually writing computer programs. A note on terminology The term ‘programming’ is usually used in a general way, to describe all the activities of software development. One part of programming a computer system is the actual coding during implementation. Testing and evaluation Parts of, or the complete, implemented system are tested with real, and imaginary data. These software (sub)systems can also be tested by the real world users, or perhaps staff playing the roles of the eventual real world system users. The results of testing and evaluation often direct the software development team to perform one or more previous activities again. In such a way systems may be developed in an incremental fashion. Maintenance and enhancement Studies have shown that at least 70% of the costs associated with software projects are incurred after the system has been deployed. The work done after deployment is usually called maintenance. However, this term is misleading as it suggests that the software might degrade in functionality or performance if not ‘maintained’. Software is not like mechanical artefacts that perform less well if not, for example, cleaned and oiled. While software maintenance is most often associated with fixing bugs, in reality the major difficulties and costs are encountered when changes or enhancements must be made. Object technology is supposed to help here because it allows software to be better designed and implemented to simulate that world it is designed for. Hence, when changes appear in the real world, such as changes in tax laws or network arrangements, the software can be straightforwardly changed or enhanced. In the case of object-oriented systems development, the modelling, design and implementation are performed from an object technology perspective. The various techniques and programming languages of object technology should help in all these aspects of software development.
RITSEC - Global Campus |
