rect rect rect rect rect rect rect
You are viewing an archived version of CBSE 2000. This page has been archived via the Internet Archive Wayback Machine for the ICSA conference series history. Some links on this page might not work.
← return to the ICSA homepage.
General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
engineering graphic
engineering
COTS-Based Systems
Overview
Activity Areas
Products and Services
References
Briefings, Courses, and Workshops
CURE (COTS Usage Risk Evaluation)
EPIC
Publications
COTS_Spot Column
Integration of Software-Intensive Systems
Performance Critical Systems
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
Rollover Popup Hints for Topic Navigation Buttons above
A Component-Based Development Case Study


Jim Q. Ning
jim.q.ning@ac.com
Andersen Consulting
3773 Willow Road
Northbrook, Illinois 60062-6212
U.S.A.
+1 847 714 2537  

 

Project Background

The client referenced in this paper is a global machinery manufacturer who currently goes to market through a global network of dealers. The client supplies these dealers with many disparate systems which include:

  • Custom-built, AS/400 "green screen" core systems
  • PC-based systems
  • Corporate 3270-based systems

The client wants to create a stronger extended enterprise by linking customers, dealers, and the corporation through the use of technology. To deliver this vision of an extended enterprise, the systems listed above need to be integrated, modified and enhanced.

 

 

Component Technology Objectives

To build the systems of the extended enterprise, the client selected component technology as a key enabler. The client believes that components will help to deliver:

  • An open architecture
  • Better systems engineering and easier maintenance


Figure 1
Figures in this file are displayed in a separate browser window. This window will remain open to display figures in this file, although it might be hidden behind other browser windows.
 

  • Ability to transparently re-locate processing in the future
  • Business that is developed once and reused across applications
  • Universal access
 

 

Architecture Overview

The project featured in this case study is currently delivering the first in a series of a component-based applications. This application is being built on a 3-tier client/server architecture that uses the AS/400 for the server platform. The overall architecture is shown in the diagram below.

The Java-based operationally thin-client, which is hosted in Internet Explorer, communicates with server-based business logic through the DE-Light (an IBM middleware product that supports DCE) RPC gateway. The client invokes operations on Business Event Controllers. The Business Event Controllers collaborate with Entity Components to complete an operation. The Entity Components interact with the database through Data Access Modules.

 

 

Lessons Learned

Development Lessons

  • Use most experienced resources on design
  • Design by business functions, not by architectural layers
  • Code shells improve productivity, but they do not help to develop programming skills
  • Mapping to an existing data model is difficult
  • Use variability analysis effectively to forecast future requirements
  • Component packaging is complicated by dependencies between components
  • Component development tools are immature
  • Vendor-provided training (on C++, Java, etc.) is not enough
  • Coordinating changes is more difficult
 

Architecture Lessons

  • Budget more (and resist to cut down) on architecture work
  • Define architecture early
  • Prototype a vertical slide of the application
  • Java-based thin clients are difficult to implement
  • Integrating Java applets with other desktop applications is difficult
 

Performance Management Lessons

  • Performance is impacted the most by application design
  • Excessive data conversions when integrating various technologies and platforms can lead to performance problems
  • Code shells can lead to performance problems
  • Excessive encapsulation can lead to performance problems
 

Testing Lessons

  • Testing is harder if development was done by architectural layers
  • Use automated testing as much as possible
  • Debugging is difficult and tools must be used
  • Testing efforts should happen earlier in the development lifecycle
  • Component dependencies impact testing
 

Project Management and Estimating Lessons
  • Extra contingency must be planned
  • Iterative development must be well managed
  • Project tracking can be more granular
  • There are more artifacts to manage and impact analysis is harder
  • Plan on spend more time to refine the build process
 

Client and Team Organization Lessons
  • Managing client expectations is more difficult since visible results come later than usual in component projects
  • Component technology impacts client's IS organization
  • Organizational communication overhead is significant
  • Plan to overstaff the development team
  • Greater collaboration between development team members is necessary
  • Use a matrixed team organization
  • Separate programming lead and project management roles
  • Designate full-time resources to legacy integration
  • Use outside contractors for programming skills only

download the PDF file


The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Copyright 2004 by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/cbs/cbse2000/papers/08/08.html
Last Modified: 11 August 2004