3.4 Activities and artefacts in the development process
The techniques used in the UP are also in other iterative and incremental processes based on an object-oriented approach to software.
Here, we identify the core activities to develop software. This will give you an initial understanding of how the activities you will learn about contribute to the overall development process. As mentioned earlier, different ways of subdividing the development process and different terminology may be used elsewhere.
Our core activities follow the UP disciplines:
- domain modelling – modelling what already exists in the domain
- requirements – identifying, categorising, prioritising and modelling what the system must do
- analysis – modelling how the structure and behaviour of the system will meet its specification from a user’s perspective, moving from the domain to a software solution
- design – deciding on the distribution of responsibilities to fulfil that specification
- implementation – producing code that will meet the user requirements
- testing – ensuring that the software does meet its requirements
- deployment – configuring the code to give a runnable system.
It therefore makes sense to talk of models corresponding to each of these activities. So we have a domain model, a requirements model, an analysis model and so on. However these models generally need to cover a number of views of the system. For example in the previous subsection we talked about structural and behaviour models. A domain model, for example, will usually include both of these. A design model typically consists of a number of more specific models.
There will be other documents that accompany the models, and so we will use the term artefact to refer to both models and other documents. The artefacts from the activities earlier in the list above feed into the activities that follow.