Re: Pratt & Whitney's Embedded Software - CMM Level 3!

[Marin David Condic <condicma@bogon.pwfl.com>]

Bruce L wrote:
> 
> Marin David Condic wrote:
> <<Any user could submit a
> change request against a system and the whole flow of the CR was
> automated - right to the point of being able to identify every artifact
> that was impacted by the CR and every CR that went into changing a
> particular version of a system or document.>>
> 
> OK.  How did you manage that?  One of my biggest problems is when engineers
> add or modify some functionality without doing a complete repercussion
> analysis.
> 
This would be tough to explain in any reasonably sized post!

Basically, all artifacts of a system reside in some document somewhere.
Documents have a granularity of a "paragraph". Any design diagram, chunk
of source code, text, tables, pictures, whatever, resides in some
paragraph somewhere. Paragraphs within and between documents can be
associated via a "Project Unique ID". So, for example, if you have 5
units which were derived from some requirement, it is possible to have
connected the requirement, the units, the test plan, etc. together via
references to Project Unique IDs.

Enter the change request. (It is just an electronic document where
anyone can basically say "Your control sucks - make it not suck." We're
talking developmental CM, not formal, governmental CM. A CR can be as
serious as "redesign these 50 requirements" or as simple as "you've got
a typo in paragraph 3.2.1") Someone files a change request. All changes
to any document must eventually be connected to some change request. As
you modify paragraphs, you have to check them in against a CR. At some
point someone (an administrator - a review board - how formal do you
want to be?) declares the CR "closed" and the changes become permanent.
When you publish a document or baseline a system you can identify all of
the closed change requests since the last publish or baseline. Given the
connectivity of change requests to paragraphs and paragraphs to each
other, you get real good traceability concerning what has been impacted.
The rest is just reporting programs or on-the-fly SQL code.

So, while lots of our engineers are no better than yours and may not
perform any repercussion analysis (not always necessary anyway - lots of
times changes are trivial) they at least have a way of doing so. By
saying "I propose to change diagram XYZ" you can identify the paragraph
it lives in, what it is connected to, what change history may have
already gone before, what tests are impacted or need to be run again,
etc. etc. In fact, this gets done quite a bit if someone is looking into
serious changes.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic