Managing Long-Lived COTS Based Systems - PowerPoint PPT Presentation

bernad
managing long lived cots based systems n.
Skip this Video
Loading SlideShow in 5 Seconds..
Managing Long-Lived COTS Based Systems PowerPoint Presentation
Download Presentation
Managing Long-Lived COTS Based Systems

play fullscreen
1 / 24
Download Presentation
Managing Long-Lived COTS Based Systems
550 Views
Download Presentation

Managing Long-Lived COTS Based Systems

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. National Research Council Canada Institute for Information Technology Conseil national de recherches Canada Institut de technologie de l’information Managing Long-Lived COTS Based Systems Dr. M.R.Vigder J. C. Dean Software Engineering Group Institute for Information Technology

  2. Outline • About NRC/IIT/SEG • Setting a baseline • System management activities • Management activities support • Where this fits in the life cycle • Conclusions ©1998 M. Vigder/J.C. Dean

  3. National Research Council of Canada • principal science and technology agency of the Canadian federal government • http://www.nrc.ca • 16 research institutes • Institute for Information Technology (IIT) • Undertakes focused, industry-oriented research in software and systems • 5 groups (including Software Engineering) ©1998 M. Vigder/J.C. Dean

  4. Software Engineering Group Main objectives • To help the Canadian software industry be more effective • Deliver software on time, within budget • Deliver quality software • To advance and disseminate software engineering knowledge • Via research • Via industry collaboration • Via education ©1998 M. Vigder/J.C. Dean

  5. Software Engineering Group Interests • Commercial off-the-shelf (COTS) software • Real-time and embedded systems • Configuration management • Human Factors in software engineering • Consortium for Software Engineering Research (CSER) ©1998 M. Vigder/J.C. Dean

  6. COTS Project • Vision • Explore issues associated with using COTS software components to build long-lived systems • Taken from the perspective of a system integrator • Goals • Provide guidance to developers • Robust, maintainable systems • Client • Department of National Defence - Canada ©1998 M. Vigder/J.C. Dean

  7. What Is A COTS Component? • A software component that has been obtained from a third-party and that the developer uses on an as-is basis • User of the COTS component does not modify the source in any way • COTS developer is responsible for maintenance and evolution of the COTS component • Identical copies of the COTS component are being used by different developers ©1998 M. Vigder/J.C. Dean

  8. Viewpoints To Consider • Component supplier • Build components that are open • System integrator • Components pre-exist • Components are supplied by a third party • Attempt to satisfy customer by configuring, tailoring, integrating and supplementing components • Customer • Acquire systems that are robust and adaptable ©1998 M. Vigder/J.C. Dean

  9. COTS Systems Development • Challenges • Source code is not available • Variable maintenance and release schedules • Software components provide too little, or too much, functionality • Limited influence on development directions ©1998 M. Vigder/J.C. Dean

  10. COTS System Management • Activities • Component life cycle management • Customization • Behavioural Analysis • Support • Architectures • Instrumentation • Configuration management ©1998 M. Vigder/J.C. Dean

  11. Management Activities • Component life cycle management • Evaluation of new or updated components • Test, and possibly rewrite “glue” and “wrappers” • Integration testing • Installation, deployment, moving and removing components ©1998 M. Vigder/J.C. Dean

  12. Management Activities • Customization • Types • Using plug-ins to add functionality • Configuration or preference files • Scripting • Combining services • Wrapping components • Standard templates or macros ©1998 M. Vigder/J.C. Dean

  13. Management Activities • Customization • Responsibilities • Selecting customizations for CM • Verifying CM processes are followed • Implementing a process for defining, implementing and testing the customization • Deploying the customizations ©1998 M. Vigder/J.C. Dean

  14. Management Activities • Behavioural analysis • Maintain and improve the capability of a system • Reconfigure system resources to improve performance • Troubleshooting • Identify and isolate the cause of failures ©1998 M. Vigder/J.C. Dean

  15. Support for Management Activities • Component life cycle • Architectural support • Framework for management of disjoint components • Configuration Management • Entire modules are tracked by version • Instrumentation • Status of the components ©1998 M. Vigder/J.C. Dean

  16. Support for Management Activities • Customization • Architectural support • Business processes encapsulated within mediators • Configuration Management • Maintain as source code and as components • Instrumentation • Built into the customization code ©1998 M. Vigder/J.C. Dean

  17. Support for Management Activities • Behavioural analysis • Architectural support • Detect, isolate and log component faults • Configuration Management • Track version incompatibilities • Instrumentation • Determine which component, or set of components, is at fault ©1998 M. Vigder/J.C. Dean

  18. Component Component Component Component Component Component Component Manager Architecture Concepts ©1998 M. Vigder/J.C. Dean

  19. Life Cycle Implications • Software maintenance • New goals • Upgrade driven • Not user requirements driven • Earlier concerns • Maintaining components during system development • Blurring the lines ©1998 M. Vigder/J.C. Dean

  20. Life Cycle Implications • Software management • Coordination concerns • Multiple product upgrade paths • Possible approaches • Incremental development • Consider upgrades as part of next increment • Individual upgrades ©1998 M. Vigder/J.C. Dean

  21. Conclusions • System management key activities • Component life cycle management • Customization • Behavioural analysis • Support • Architectural choices • Instrumentation techniques • Configuration management practices ©1998 M. Vigder/J.C. Dean

  22. Conclusions • System vs. software management • Difficult to separate responsibilities • Not a “new” concept • COTS Software-based Systems • Changed management focus • Liaison function more important • Life-cycle phases overlap ©1998 M. Vigder/J.C. Dean

  23. Comments • From this morning • Systems can be defined at different levels • Standard must support this • Commercial life cycle • Short scale/incremental development cycle needed • Warranty/escrow requirements are overblown • Can’t depend on warranties • Can’t keep up engineering cognizance ©1998 M. Vigder/J.C. Dean

  24. Information • Mark.Vigder@nrc.ca • John.Dean @nrc.ca • http://wwwsel.iit.nrc.ca ©1998 M. Vigder/J.C. Dean