Experience with cots based systems cbs product line architectures
Download
1 / 6

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


  • 80 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Experience with COTS-Based Systems (CBS) Product Line Architectures' - troy-hays


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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 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


Vendor product experience
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)


Challenges
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


Lessons learned
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


Critical success factors
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


ad