| Software Construction Needs a Plan |
| There is a common perception among general
management that software is both cheap to produce and easy to change. 'Its only a bit of
software - it won't take you long'. Developers know that this is not true. Software is
extremely complex and, once a particular structure is in place, often long-winded and
difficult to change. |
An building architect knows this and creates a
drawing of the building from more than one direction, ensuring that the structure is
appropriate for the purpose of the building and that the dimensions are all consistent.
Only when this visual model of the proposed work has been approved is the job of laying
bricks begun. |
| Visualise In Multiple Dimensions and Levels of Detail
|
| Software is very abstract and hard to visualise. A
visual modelling language, such as UML, allows software to be visualised in multiple
dimension, so that a computer system can be completely understood before construction
begins. Furthermore, UML can be used to produce several models at
increasing levels of detail. The overall scope of the software can quickly and easily be
|
defined at the start of the project with a high level model allowing for
accurate estimation. Increasing levels of detail can then be added to each part of the
software as it is constructed, until finally the software appears as code. The code can
then be tested against a test model that is derived from the original model of
requirements. |
| Appropriate For Both New and Legacy Systems |
| UML is appropriate for both new system developments
and improvements to existing systems. It is a fallacy that in order to use a new modelling
technique on an old system, the old system will have to be completely 're-documented' in
the new style in order for any change to |
take place. The truth is that only those parts that
are affected by the change will need to be modelled. If they were badly documented or not
documented at all, then a lot of work would need to be done to understand them anyway in
order to make the change. |
| Documents Software Assets |
| Undocumented or badly documented software has a
reduced value as a company asset. With so much of the company's business process embedded
in obtuse software code, a company is vulnerable to losing an understanding of and control
over the business rules by which it operates. Gradual re-engineering of the company's
bespoke computer software in a way that makes the functionality of the software
transparent, |
brings those important assets back under control. It
removes the company from dependence on key personnel who may leave at any time and
improves understanding of the company's critical business processes. It even improves the
quality of software engineering staff because those who want to do a proper job will look
for companies that model with UML. |
| Unified and Universal |
| The Unified Modelling Language was created by Rational
Software in order to provide a standard for software modelling languages. It is now owned
and controlled by the Object Modelling Group, an independent organisation. UML has quickly
become the de-facto standard modelling language in the software industry. |
UML is a universal language because it can be applied
in many areas of software development. It includes user-definable extension mechanisms so
that it can be adapted for specific environments. Industry standard extensions now exist
for business modelling and web-based applications development. |
| Inherent Traceability |
| The Use Case Driven nature of modelling with UML
ensures that all levels of model trace back to elements of the original functional
requirements. This traceability between models comes without the extra effort of creating and
maintaining a 'traceability matrix' which can be a complex and time consuming job. |
The result is that the impact of a requested change
can quickly be estimated. A change in requirements can be traced though analysis and
design models into those components affected and even lines of code. The code affected can
then be traced back to the requirements and total regression testing effort calculated. |
| Accommodates Incremental Development and Re-Development |
| UML models respond well to an incremental development
environment. It is possible not only to develop only those parts of the model that are
required to satisfy the new requirements, but also to demonstrate that all the code needed
to fulfill those requirements is in place and that |
only the code needed to fulfill those requirements is
in place. This approach ensures that only the work needed to fulfill the current
requirement is done, while still developing in such a way that maximises re-use,
maintainability and extensibility. |
| Accommodates Parallel Development of Large Systems |
| Large complex UML models can be decomposed in a
totally user-definable way so that different parts of the model can developed
independently by different people or groups. Furthermore, given the right tools and change
management infrastructure, each part of each model can be independently change managed.
This facility enables |
independent, yet controlled and coordinated,
working on different parts of a project by different groups. Each group, however, still
has full visibility of the activity of other groups and is kept fully aware of all changes
that affect its own work. Automatic metric extraction can contribute further to improving
estimation. |
