home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2479 < prev    next >
Encoding:
Text File  |  1992-08-29  |  3.4 KB  |  66 lines

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