home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2478 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.5 KB

  1. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!sol.ctr.columbia.edu!The-Star.honeywell.com!saifr00.cfsat.honeywell.com!wisniews
  2. From: wisniews@saifr00.cfsat.honeywell.com (Joe Wisniewski)
  3. Newsgroups: comp.lang.ada
  4. Subject: Requirements Data Dictionary
  5. Message-ID: <1992Aug28.225144.7717@saifr00.cfsat.honeywell.com>
  6. Date: 28 Aug 92 22:51:44 GMT
  7. Distribution: inet
  8. Organization: Honeywell Air Transport Systems Division
  9. Lines: 41
  10.  
  11. 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.
  12.  
  13. 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.
  14.  
  15. 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 th
  16.  
  17.  
  18.  
  19.  
  20. ose battles.
  21.  
  22.  
  23.  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 requireme
  24.  
  25.  
  26.  
  27.  
  28. nts analysis. Data Flows represent their external and major internal data flows.
  29.  
  30. 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 
  31.  
  32.  
  33.  
  34.  
  35. 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.
  36.  
  37. 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.
  38.  
  39. 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? 
  40.  
  41. 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.
  42.  
  43.  
  44. Thanx ahead of time.
  45.  
  46. Joe Wisniewski
  47. Honeywll ATSD
  48. M/S 2M34E4
  49. Box 21111
  50. Phoenix, Arizona 85036-1111
  51.  
  52. <wisniews@saifr00.cfsat.honeywell.com>
  53.  
  54. "The opinins expressed are strictly my own...."
  55.