1 / 24

Managing Long-Lived COTS Based Systems

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.

bernad
Download Presentation

Managing Long-Lived COTS Based Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related