home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.ada
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!The-Star.honeywell.com!saifr00.cfsat.honeywell.com!wisniews
- From: wisniews@saifr00.cfsat.honeywell.com (Joe Wisniewski)
- Subject: Requirements Data Dictionary
- Message-ID: <1992Aug28.225743.7823@saifr00.cfsat.honeywell.com>
- Organization: Honeywell Air Transport Systems Division
- Distribution: inet
- Date: Fri, 28 Aug 92 22:57:43 GMT
- Lines: 55
-
- There may other newsgroups for which this posting is more appropriate, but since this occurring on a
- big Ada project (Boeing 777), I thought that it would be of interest.
-
- The issue of concern has to do with requirements data dictionaries (RDD) and design and code data
- dictionaries (ADD) for application data dictionary. By the time you are through reading this it may
- not be clear what I am asking for. Please be patient. I'll get there.
-
- The requirements analysis phase around here is pretty much the "good ol'" functional decompostion
- "method". Although a study was performed during the requirements phase to determine appropriate
- requiements analysis and design methodologies and oo techniques were the "winners", oora and ood
- techniques are for the vast majority of the project, not being done. Please, don't ask me how they
- decide to define a good package structure and not have a traceability nightmare on their hands.
- I have deep scars over those battles.
-
-
- Anyhow, there was an attempt to try and use strict Hatley/Pirbhai. but for the most part it is
- just good old functional decomp. Our small group however was able to convince our management to
- try an object-oriented requirements analysis approach (Seidewitz and Stark method) after we had
- done a standard functional decomp approach (We are not maintaining the functional decomp approach.)
- The rest of the program pretty much used IDEs StP (with bubbles and data flows, STDs, etc.) to
- do their software requirements analysis. Data Flows represent their external and major internal
- data flows.
-
- Now, to the point. There are those on the program who feel that there is a need to be able to
- automatically map the requirements data flows to design and code data flows. It has been very
- difficult to try and convince some people that there is not necessarily a direct algorithmic
- mapping between requirements data flows between requirements bubbles and code data flows. This
- is not just a funct. decomp vs. oo issue. If I were to implement a system using strict functional
- decomp techniques, there is still no guarantee of a direct mapping, much less than when one is
- trying to map major internal requirements data flows between "requirments bubbles" and design
- classes/code packages or whatever.
-
- I understand the need to be able to efficiently perform regression checks due to major exteral
- data flow changes that flow into the system. A tremendous amount of time and effort is being
- spent working on this RDD/ADD issue with marginal perceived benefit.
-
- What kind of experiences have you all had out there concerning this issue. What are lessons
- learned on this topic? Is it worth spending a lot of time and effort and mucho denaro having
- an RDD/ADD mapping?
-
- If anyone is interested in the merits and pitfalls of the oo approach we used/are using.
- email me directly and i'd be happy to fill you in.
-
-
- Thanx ahead of time.
-
- Joe Wisniewski
- Honeywll ATSD
- M/S 2M34E4
- Box 21111
- Phoenix, Arizona 85036-1111
-
- <wisniews@saifr00.cfsat.honeywell.com>
-
- "The opinins expressed are strictly my own...."
-