A software development methodology that uses software tools and business processes to integrate source control, Bug Tracking, requirements and Change Requests.

A sample UCM project may proceed something like this:

  1. The requirements document is written. Each requirement for the project is registered inside a database.
  2. The Use Cases for the project are written, based on the requirements. The use cases are registered in the database, linking them to the parent requirement. You may have a requirement "Shall be able to open files" which would map (simply) onto an "Open File" use case - the database would show that these two objects are linked.
  3. The designers use UML to design the project. Each Sequence Diagram, Class Diagram and System Diagram etc is linked up to the parent use case in the database. You can use this information to find out if a use case has been designed yet, or how much code a requirement will take to implement.
  4. At the same time, the test team write the first pass test strategies and plans. Each test requirement is linked to a use case in the database. Test plans are also linked to the parent test requirement. Here it is possible to query which use cases are properly covered by tests.
  5. Now the codemonkeys start to work. The Project Leader will have divided up the work and assigned people to certain tasks. Each developer will have a "Write database interface" type parent task assigned to them by the project leader, it will then be the developer's job to register sub tasks in the database. Each time the developer checks out or adds code to source control, the source control system will ask what task he/she is working on. Again, all this information is saved in the database. The project leader can use this information to see how much work a use case or requirement is really taking. All this information can be automatically inserted into a Microsoft Project type tool.
  6. Each task or sub task and the files associated with it are treated as single objects by the source control system. As each task is "finished", the developer "delivers" those changes from their work area into a central area managed by a build manager (I do this!). The build manager (with the project leader and senior engineers) then decides which "pieces" of work from each developer are used in a build. As each task is merged into the main source tree, the tree is built and tested. Once a piece of work is found to be stable, the main tree's "latest" version is moved "up" to include these latest changes. Whenever a developer updates his/her work area to synchronise it with the main tree, they receive the latest version - now with all the new changes.
  7. Once the project starts to take shape, the test team can use a testing tool to build their tests based on a test requirement or plan. The test team leader can use the database to find out how far along the coverage of the project is, or how many tests (i.e. work and time) are needed to test a particular requirement or use case.
  8. Once bug reports start to flow from the test team to the developers, they are registered as special tasks in the source control part of the database. The project leader assigns these tasks to the responsible developer, along with priorities etc. These defect tasks are then used in the same way as development tasks - they are associated with check outs/ins etc. This way the build manager can check that a defect is fixed in the current build by including the work delivered by the developer - or they can decide not to include a bug fix that may break other functionality.
  9. All this continues until release to manufacture. Now the customers have their grubby mitts on the software and start sending in millions of bug reports and change requests. The project leader can then assign these to the developers as before, but can also make a better judgement as to how much time and effort they will take to fix/implement.
  10. If new functionality is being implemented, the build manager will branch the project into a bug fix branch and a development branch. The bug fix branch looks like another developer to the new functionality branch, hence work can be delivered from bug fixes to the new version branch.

Even though this has turned out to be a large node (sorry), this is only a whistle stop tour of UCM.

In theory, it is a wonderful system that keeps the project under control. In practise, it is an excuse for companies like Rational Software to commit daylight robbery, charging vast sums of money for tools that have only a few more features than their open source equivalents.

Log in or registerto write something here or to contact authors.