From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5aa763fe62c20184 X-Google-Attributes: gid103376,public X-Google-Thread: f849b,5aa763fe62c20184 X-Google-Attributes: gidf849b,public X-Google-Thread: 115aec,5aa763fe62c20184 X-Google-Attributes: gid115aec,public From: Marin David Condic Subject: Re: Pratt & Whitney's Embedded Software - CMM Level 3! Date: 1999/04/20 Message-ID: <371C9894.A02D8471@pwfl.com>#1/1 X-Deja-AN: 468746253 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <371B6EC8.36B9C247@pwfl.com> <7fftel$6po@drn.newsguy.com> <371B9A5E.2804AC27@pwfl.com> <371BD9CE.F9D24397@ultranet.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada,comp.realtime,comp.arch.embedded Date: 1999-04-20T00:00:00+00:00 List-Id: Bruce L wrote: > > Marin David Condic wrote: > < 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