|| Overview | Process Concepts | Process Configurations | Process Glossary | Process Map ||
|Model-Driven Development Process|
| Business Analysis | Requirements Gathering | System Analysis | System Architecture | Detailed Design |
| Project Management | Project Support | Coding | Testing | Rollout |
|| Process | Stage | Task | Step | Guidelines | Template | Increment | Phase | Project | Change ||
|The main function of process is to make what is done predictable and repeatable from a management point of view.
When applied to software development it can also increase, in a number of ways, the quality of the software produced.
The first requirement of process is that it is documented. This process is documented as a set of html pages plus files that are accessible using commonly available and inexpensive applications. This means that the process can be made available on the desktops of all those involved in a project without exception. The process needs to be sufficiently well defined and documented that it covers the vast majority of the most important aspects of the work carried out on the project.
The second requirement of process is that it is followed. This can only be achieved if it substantially fits the way that people work currently, if those who have to work within it are sufficiently motivated to do so and if sufficient training is provided for aspects of the work that depart from the current procedure. Achieving these things is helped a great deal by making any given process easily customised and introducing it gradually so as not to upset any current work in progress. Conformance to the process should be monitored as part of increment assessments and problem areas addressed as the project progresses.
A good process is:
|A stage in this process is presented as a typical stage in a waterfall process. It may be mapped to a role or discipline that
is taken on by a team member.
If the process is to be used incrementally, then the stage will be performed once as part of an increment and so will be performed many times during an incremental project.
A stage decomposes into a number of tasks.
See the process overview for a graphical summary of the process stages.
|Multiple tasks are performed during each stage of the process, the order defined by a task flow. Each task is defined by a set of task guidelines which describe how a document or model is to be produced or updated. Normally templates and/or examples of the document or model are available.|
|Each task is broken down into a number of steps. The order in which the steps are performed is defined by a step flow.|
|Each task is defined by a set of task guidelines which describe how a document or model is to be produced or updated. The guidelines include: a list of inputs and outputs; an overview of the task; descriptions of the steps to be performed including detail on exactly how UML is to be used if modelling is to be performed; a step flow; references to relavent document and model templates and examples.|
|Most documents and model that are produced or updated by the performance of a task have associated templates. The use of templates for documents and models is one of the most important aspects of ensuring consistency in the way that documents and models are produced. Most documents and models contain instructions that guide their creation. The instructions should be removed once the document or model is completed.|
|In an incremental development process an increment consists of one pass through all process stages. Each increment, except, perhaps,
those in the scoping phase, produces properly engineered and tested code that has been fed back to the appointed user representative.
Increments are normally defined by the use cases to be covered, which in turn define the end user functionality to be produced. The resulting
software may be released to the end users once complete, or considered an internal engineering release.
An increment is also a unit of project planning which lasts between two and six weeks. Any unit of work of less than two weeks in length that produces increased or changed functionality is considered to be a 'Change'.
While increments define the end user functionality to be produced at the end of the increment, that does not mean that all work done during an increment is related exclusively to the functionality of the increment. Work done during the scoping and development phases will be aimed at defining the functionality of the whole system and developing the overall system architecture respectively. In this sense the increment is a unit of project management with a formal review point at the end of it that provides the metrics necessary properly to monitor the progress of the project and to adjust the project plan, if necessary, based on results.
The goals and nature of the increment are defined by the phase of the project within which it occurs.
|In an incremental project a phase is a collection of increments. In this process there are five phases in a project, each of which has a primary goal:
|A project is made up of two or more increments. Any project of less than four weeks is considered to be an increment or a change. The number of
increments in the project will depend on the timescale for the project.
The proportion of increments within the project that fall into each phase will be determined by the nature of the project. For example, a business process re-engineering project where the development of the software is to be outsourced may only contain scoping increments. A 'blue sky' project exploring new possibilities may only contain scoping and development increments. A project that increments the functionality of an existing system with no significant new architecture may consist only of scoping, production and delivery increments. A very dynamic and adaptive project may contain only development or production increments depending on the stability of the architecture.
|Any unit of work of less than two weeks in length that produces increased or changed functionality is considered to be a 'Change'.
Work will be done in each stage of the process as with an iteration but the scope of functionality will normally be very narrow. The documents and models
for the system will be updated to reflect the change. The change in functionality required results from a 'Change Request' which is created
by a user, user representative or analyst.
If the work to implement the change becomes greater than two weeks then it is promoted to an increment. Changes can be grouped into increments.
|Process Concepts - © CRaG Systems 2006 - 2013|