Anyone familiar with Allocated Baselines and how/when to establish them in Operations & Maintenance projects?

Share URL
 
mstern11's picture
mstern11 asked on August 18, 2011 - 2:27pm | Replies (5).

Please help.

Tags: 
configuration management
o&m

5 Answers

bglangston's picture

Mstern,
Since you ask the question in the context of O&M, are you reverse engineering the system to establish allocated baselines?

I'm trying to clarify what you are asking because -- ideally establishment of the Allocated Baseline(s) would have begun back in the system life cycle process where the system requirements were being defined and the system design was being created (and probably be "finished" by the time the O&M stage was begun).

If in fact you are reverse engineering the allocated baseline(s), then my answer to your question would be "as soon as you can."

Since the system is already established, probably the first step would be to identify the components of the system. The probably next step would be to record (document) the current functional, performance, interoperability, and interface capabilities of or within the system (and assume that those currently accurate). Then you can parse (allocate) those requirements to each component. Reverse engineering assumes that the current operation of the system and components are in accord with what was required at the beginning. Basically, this is sort of a "cart before the horse" approach.

Under a more "classic" approach, a project would use the allocated baseline(s) to dictate what the various components are supposed to do, and then the system and components would be built to those specifications. Either this wasn't done or I'm totally not understanding the question.

mstern11's picture
mstern11 replied on August 18, 2011 - 6:21pm.

BgLangston,

Thanks so much for the response. Actually, I believe you understood the question perfectly. Here is the impetus for my question:

I am supporting 2 CMMI L3 projects which have been built and are on O&M. They typically each have 4 scheduled maintenance releases per year. I completed CM Plans for each, as they are entering new option years. I've been supporting these projects (in O&M mode) for a number of years and pretty much just rolled over the CM Plans, as they are, for the new Option Year.

So, when the documents were reviewed by Q/A, a comment came back that we should be maintaining/updating allocated baselines with each release. To him, this means that if any 'infrastructure' documentation is affected by a maintenance release (i.e. SDD, ICD, DDD, etc) the project would have to complete the document in the design phase prior to coding. Currently, we have the projects go through all waterfall phases of the SDLC, but do NOT require formal, signed off documentation prior to coding. So, in a nutshell, if we operate the way Q/A wants, there would be prohibitive schedule delays in our releases.

So, I was wondering if Allocated Baselines need to be maintained when a project was in this O&M state. I hope I've expressed the problem clearly. Your opinion would be of great help. Thanks again.

bglangston's picture

I thought of one other thing. IF, I say again, IF you allow the coding to precede the documentation work, then are you not reverse engineering, on a small scale to be sure, but reverse engineering nonetheless.

mstern11's picture
mstern11 replied on August 22, 2011 - 7:42pm.

Well, there's an argument that this can be construed as reverse engineering, however, and internal design document is created and peer reviewed for each change to the system. Once the review is completed (and findings closed) we consider the change ready for development.

By contrast, we can maintain an allocated baseline (as Q/A would prefer) and then we'd have to update each document therein, and then pass it to Q/A for a 3 day review and Document Mgt for another week. If we went this method, it would put too big a strain on our shedule.

bglangston's picture

If I'm reading this correctly, at this point, the change(s) to the docs are in fact "set in concrete," so I wouldn't consider this reverse engineering. Assuming a) all design docs impacted by the change are at least identified in the change proposal, b) your "internal design doc" shows the exact changes to be made to the docs, and c) peer review includes those responsible for the design docs, I can think of no reason why the coding shouldn't proceed. As I see it, QA would now have a single follow-on task (for each change) - make sure that the changes went into the docs as specifically stated. So, rather than reverse engineering, I would consider it more closely related to parallel development (one leg developing the code change and one leg inserting the change into the design doc).

Part of Configuration Status Accounting is keeping track of pending actions that still need attention on CI (Has this change been entered yet?). Of course the change document should not be closed until all the actions are completed.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.