How to plan software as a configuration item

Yesterday I got a question from a colleague about configuration items. In our projects we use a deliverable list to identify which items are being delivered by the project and which are being received from outside the project. To help projects plan their configuration items we have defined a deliverable list template.

The deliverable list template lists documents like various types of requirement specs, design specs, test specs, manuals, training materials, etcetera. It also contains an single entry for Software. Now the question was:

What software deliverables (and receivables) should a project plan for?

Obviously, the deliverable list template does not give much clues. But we know that the software consist of components, some of which are received from other projects or third party suppliers – and possibly modified by the project – and some of which are created by the project. Then, how do you know which software deliverables the project is going to deliver?

The answer is that it depends on the agreement with the customer of the project. The requirements agreed with the customer state what he will get, in terms of functionality, performance, quality and deliverables. And these deliverables should be listed in the deliverable list. If the requirements don’t state the (software) deliverables, then apparently the customer does not care as a long as the functional and non-functional requirements are satisfied.
In that case, the architecture or high level design determines the software deliverables. Even more, the architecture determine which of the software components are reused from other projects or third party suppliers and which are created anew.

Okay, now that requirements and architecture/design define which software deliverables and receivables are applicable,

how do we plan in which release they are delivered?

For projects with a single (final) release, it is simple: everything is released and delivered at the end. For projects with multiple releases, like incremental development or iterative development, it is more complicated but still quite simple.

The total work of a project is divided in “work packages”, chunks of work that deliver a number of (possibly internal) deliverables. These work packages are assigned to a release and this way it is determined that the deliverables of those work packages are delivered at that release. More precisely, the deliverables are packed together as a baseline and the baseline is released.

Now in many software development organizations, the work packages are handled just like problem reports and change requests. They are registered in the change control tool/database, and assigned to people and releases (or iterations). We could call them “work items”; the list of work items planned for a release or iteration (in a release plan or iteration plan) determines which software deliverables are released. You could list those deliverables in the deliverable list, but it is more practical and more accurate to generate a report from the change control database listing the work packages, problem reports and change requests assigned to a particular release or iteration.

Advertisements

About Frank Schophuizen (fschop)

Hi, my name is Frank Schophuizen and I am working as a consultant in CM, Agile and ALM for TOPIC Embedded Systems. I have over 30 years experience in software development in the technology industry, with the last 15 years mainly in process improvement, deployment and integration of methods and tools in the area of CM, Agile development and ALM. I am strongly interested in the complexities of collaboration and integrations in multi-project and multi-site organizations. I have worked with various technology companies such as Philips, ASML, NXP and Vanderlande, and with various tool vendors such as IBM Rational (e.g. ClearCase, Synergy, Jazz products) as well as open source tools (e.g. SVN, Git, Jenkins, Trac, Eclipse). I am living in Eindhoven, the Netherlands, with my wife. We have 3 adult children. My main hobbies are classical music and photography.
This entry was posted in configuration management, identification, planning, software development, tracking and tagged . Bookmark the permalink.

7 Responses to How to plan software as a configuration item

  1. bong says:

    nice…

    Like

  2. fashion says:

    one of the nicest blog i visited..please send me your updates here on my email id..

    Like

  3. vuhelp.net says:

    so nice blogger

    Like

  4. Thank you. Your blog was very helpful and efficient For Me,Thanks for Sharing the information.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s