1 / 6

Experience with COTS-Based Systems (CBS) Product Line Architectures

Experience with COTS-Based Systems (CBS) Product Line Architectures. Don Andres 7 February 2001 703.803.5109. Project Context - C 2 Product Line. Project purpose was to develop COTS-based Command and Control Product Line Architecture Address wide range of DoD mission requirements

troy-hays
Download Presentation

Experience with COTS-Based Systems (CBS) Product Line Architectures

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. Experience with COTS-Based Systems (CBS) Product Line Architectures Don Andres 7 February 2001 703.803.5109

  2. Project Context - C2 Product Line • Project purpose was to develop COTS-based Command and Control Product Line Architecture • Address wide range of DoD mission requirements • Support Air, Missile, Space domains • Support Theater and Strategic missions • Driving Factors • Need to interoperate with existing systems, majority of which were developed as standalone systems • Incorporate commercial technology while still adhering to Government standards (time gap) • Resultant systems need to be highly reliable with near-real-time performance

  3. Vendor/Product Experience • Oracle - database, web server, web portal, development tools • Iona, BEA - middleware • Toplink - Object to Relational mapping for database objects • Tivoli, OpenView, CA - Network Management, Product Distribution, Inventory • Remedy - Network Problem Reporting • Government - DII COE (operating system, patches plus applications), Global Command and Control System (GCCS) • Rational - Rose, ClearCase, RequisitePro, ClearQuest, Dashboard, TestMate • Symantec - Visual Café (Development and debug tools) • Other Pieces (NT, Unix, Java Virtual Machine, PKI certificates) • Languages • C++, Java (New) • C, Fortran, Ada (Legacy)

  4. Challenges • System characteristics and performance parameters different, in many cases, than those for which the products were designed • Design/tailoring/negotiating some requirements • Government standards specifications, in many cases, lagged commercial state • e.g., Operating system levels/patches • e.g., versions of Java Virtual Machines • note: this was also an issue between Vendors/Products

  5. Lessons Learned • “Teaming”, or entering into a partnership with key vendor was critical to success • Dramatically reduced time-to-market • Eases the learning curve • Hands-on evaluation is critical • Substantiate that requirements (esp. performance can be met) • Understand the difference between “standards compliant” versus “based on standards” … may be synonym for proprietary (partial) implementation of a standard • Integration is not easy • Engineering rigor is still required • Not the schedule reduction silver bullet, can be very time consuming • Vendor support should be heavily weighted in evaluation criteria • More important than initial investment cost • Probably equal to capability • Built-in diagnostic/performance capability is important

  6. Critical Success Factors • COTS-based systems still need to be managed and maintained • Patches, version updates need to be incorporated in a timely manner • Resource sizing (CPU, memory, disk) need to take into account all of the products being used (esp. if there is the potential for concurrent execution) • The concept of peaceful co-existence is still, in many cases, a myth • Define benchmarks based on your own business rules and system characteristics • Integrated (those where several vendors products are involved) benchmarks are hard to analyze • Performance and resource utilization estimates are not always linear and many times do not transfer from business model to business model

More Related