home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / software / 3388 < prev    next >
Encoding:
Text File  |  1992-09-08  |  5.6 KB  |  167 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!decwrl!pa.dec.com!rdg.dec.com!ryn.mro4.dec.com!bigun.enet.dec.com!anderson
  3. From: anderson@bigun.enet.dec.com (Keith J. Anderson)
  4. Subject: SEI speaker on Configuration Management
  5. Message-ID: <1992Sep8.044740.22053@ryn.mro4.dec.com>
  6. Sender: news@ryn.mro4.dec.com (USENET News System)
  7. Organization: Digital Equipment Corporation (Australia)
  8. Date:  8 SEP 92 14:35:27    
  9. Lines: 156
  10.  
  11. In May, the International Conf on Software Eng was held in Melbourne Australia.
  12. Unfortunately time and cost pressures kept me from attending. I was however
  13. lucky enough to be able to attend a seminar organised by the local Ada
  14. Association that took some of the speakers from ICSE around Australia. 
  15.  
  16. One of the speakers was Susan Dart from Software Engineering Institute at
  17. Carnegie Mellon University, who spoke on configuration management. The
  18. following is from my notes, but I cannot explain my notes now after so
  19. long. I imagine a copy of her longer ICSE talk is in the Proceedings.
  20.  
  21. She identified 15 different kinds of CM concepts. She has done a study of most
  22. common CM tools, but not all. She made the point early that any strong CM
  23. toolset is going to take at least 6 months to come productive with.
  24.  
  25. She listed the following as examples: CMS (DEC), Compass (CMPAC),
  26. DMS (Sherpa), DSEE, EAST (SFGL), Enterprise II, Endeavor, Gandalf, ADC, Adele,
  27. AmplifyControl, CADEX, CCC, Cedar, CMA, CMF, ISPW, ISTAR, Jasmine, Librarian,
  28. LIFESPAN, Maestro, NSE, PACT, Panicm, Panvalet, PCMS, Powerframe, PVCS,
  29. Rational, RCS, SCCS, SCLM, shape, SLSCE, SMS, Softboard, Supercase, Teamnet,
  30. Teamwork.
  31.  
  32.     She broke CM requirements down into 8 functionality areas:
  33.     - Components
  34.     - Structure
  35.     - Construction
  36.     - Auditing
  37.     - Accounting
  38.     - Controlling
  39.     - Process
  40.     - Team
  41.     and then went through each listing the key requirements in each. The
  42.     talk ended looking at CM directions being towards providing CM
  43.     Services, where a Service is a particular functionality that is treated
  44.     as a replaceable black box, and well-defined (semantics, interface,
  45.     and other properties included in reference models).
  46.  
  47.     She saw Repository service as being one of the CM services, Version
  48.     Control another, etc..
  49.  
  50.     Component Requirements: identify, classify, and access components:
  51.     . components
  52.     . versions
  53.     . configurations
  54.     . versions of configurations
  55.     . baseline
  56.     . project contexts
  57.     . repository
  58.     Structure Requirements
  59.     . system model
  60.     . interfaces
  61.     . relationships
  62.     . selection
  63.     . consistency
  64.     Constructure
  65.     . building
  66.     . snapshots
  67.     . optimisation
  68.     . change impact analysis
  69.     . regeneration
  70.     Team
  71.     . workspaces
  72.     . conflict resolution
  73.     . families
  74.     Controlling
  75.     . access control
  76.     . change requests
  77.     . bug tracking
  78.     . change propogation
  79.     . partitioning
  80.     Auditting
  81.     . history
  82.     . traceabilility
  83.     . logging
  84.     Accounting
  85.     . statistics
  86.     . status determination
  87.     . reports
  88.     Process
  89.     . lifecycle support
  90.     . task management
  91.     . communication
  92.     . documentation
  93.  
  94.     Team and Process "integrate" all requirements
  95.  
  96.  
  97.     The CM concepts areas that have developed with CM systems are:
  98.  
  99.     Concept            example
  100.  
  101.     Repository            RCS
  102.     Distributed Component    Sherpa DMS
  103.     Change set            Aide-De-Camp
  104.     System modelling        Jasmine
  105.     Subsystem            Rational
  106.     Object Pool            DSEE
  107.     Attribution            Adele
  108.     Consistency maintenance    CMA
  109.     Workspace            shape
  110.     Transparent view        SMS
  111.     Transaction            NSE
  112.     Context management        Powerframe
  113.     Contract            ISTAR
  114.     Change Request        LIFESPAN
  115.     Lifecycle model        CCC
  116.  
  117.     The different CM concept areas that have evolved can be mapped to her
  118.     requirements areas, in terms of primary focus?:
  119.  
  120.     Component            Structure, Construction
  121.  
  122.     Repository            Change set
  123.     Distributed Component    System modelling
  124.                     Subsystem
  125.                     Object Pool
  126.                     Attribution
  127.                     Consistency maintenance
  128.  
  129.  
  130.     Team            Process
  131.  
  132.     Workspace            Context management
  133.     Transparent view        Contract
  134.     Transaction            Change Request
  135.                     Lifecycle model
  136.  
  137.  
  138. No single CM system provides all functionality, Some systems provide many
  139. concepts, CM systems seem to be approaching a common model. Mechanisms poorly
  140. implemented: version control, logging for an audit trail, system modelling,
  141. baseline, email for communication, notion of a configuration, change request.
  142. Less frequently implemented : change set, subsystem, object pool, workspace,
  143. transparent view, transaction, attribution, consistency checks and
  144. maintenance. 
  145.  
  146. Standards : Project Support Environment Standards Working Group, for the US
  147. Navy's Next Generation Computer Resources, CAD Framework Initiative, 
  148.  
  149.     "The CM change process tends to be the focus of the corporate process
  150.     model. CM functionality tends to be the pivotal point that makes or
  151.     breaks an environment. Min CM capabilities: inventory tracking (release
  152.     mgmt), change tracking (change mgmt), history tracking (version
  153.     control)."
  154.  
  155.     Also refer to Mickey Williamson "Automated Software Configuration
  156.     Management: Issues, technology and Tools", Cutter information group,
  157.     1990; Fletcher, Backley, "Configuration Management Hardware, Software
  158.     and Firmware" IEEE Computer Society Press 1990.
  159.  
  160. -------------------------------------------------------------------------------
  161. EM: anderson@bigun.enet.dec.com        Keith J. Anderson
  162. or  anderson%bigun.enet@decwrl.dec.com    CASE and Information Management  
  163. Phone: (+61 6) 2754800            Digital Equipment Corp (Aust) P/L
  164. FAX  : (+61 6) 2473654            7 Barry Drive, Turner ACT 2601 AUSTRALIA
  165. X.400: c=au;a=otc;p=digital;o=digital;ou=sno;s=anderson;g=keith
  166. ***** My words are not those of my employer *****
  167.