1 / 32

The Case for Components

The Case for Components. Fall 2005 Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Teaching/. Acknowledgements. Dr. George T. Heineman

btune
Download Presentation

The Case for Components

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. The Case for Components Fall 2005 Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Teaching/

  2. Acknowledgements • Dr. George T. Heineman • This course is based on the “CS 509 Design of Software Systems - Spring 2005” by Dr. Heineman with some adjustments to become appropriate for undergraduate students. Dr. Heineman has generously offered his course material (including the slides) and his help during preparation of this course. I am very grateful to him. • The original slides and the course material can be found at: • http://www.cs.wpi.edu/~heineman/html/teaching_/CS509/index.html • Dr. William Councill and other authors of the main textbook • Dr. Clemens Szyperski • Drs. Betty Cheng, Peter Clarke, Bernd Bruegge, and Allen Dutoit

  3. Why should you consider CBSE? • It is an engineering approach to solving complex systems • It divides large projects into smaller subprojects. • It is language independent • So, it can easily be used with legacy systems. • Components are often the only answer • For example, for complex and mission critical systems.

  4. Agenda • The Business Case for Components • COTs Myths • Common High-Risk Mistakes

  5. Business Case • “The financial impact of spending money. Rate of return, cash flow, length of payback period and other financial criteria are all part of the business case decision making process.” [GuruNet] • A well thought out business case • identifies the benefits and risks • calculates the costs and payback • provides the foundation for success

  6. Domain Components Complexity Service Components GUI Components Cost Business Case • Component Types • GUI components • Service components • Domain components • Relationship between cost & complexity • Models build on one another

  7. Key Issues • Business goals • Technical sophistication • Organizational readiness • Infrastructure support • Reuse

  8. Key Issues: Business Goals • CBSE is suitable for complex, mission-critical systems. • Components are robust, scalable, and flexible. • If this is not true in your case, then non-component bases tools may be quicker or cheaper to use. • You need to consider total cost of ownership (TCO) • CBSE provides a higher software quality.

  9. Key Issues: Technical Sophistication • Different components require different persuasive arguments • GUI components • Service components • Domain components • Using these categories, you can divide the business case into models that defer based on • Complexity • Cost • Organizational readiness

  10. Key Issues: Organizational Readiness • Organizational readiness encompasses • Existing development processes • Developer skill sets • Corporate culture • To gain the full benefits of component technology, you need a software engineering approach to • Development • Deployment • Don’t confuse “just enough” process with no process at all. • Usually a consulting organization can accelerate the rate of adopting CBSE.

  11. Key Issues: Infrastructure Support • When you move beyond using simple GUI components • Anytime you consider using components in layers lower than the GUI (in an n-tier architecture), you need to think about infrastructure support. • Additional hardware • Multiple application servers • The cost and personnel support for the application servers in production • The cost of training the existing staff • The cost of hiring new staff with appropriate skill sets

  12. Key Issues: Reuse • Reuse has significance impact on your business case • However, you need to consider both saving and costs in your planning. • Reuse programs can pay for themselves, but you cannot implement reuse without spending money to get there! • Remember that domain components usually have a high development or purchase cost. • Requires additional people, processes, and tools to initially. • The cost is higher, but the payback is substantial.

  13. Key Problems • Developing a business case for components vs. actually obtain the value you hope to achieve • You need to identify the areas of risk. • Wrong culture • hate additional up-front costs even if long-term benefits • Wrong goals • focus on building for today rather than future • Wrong purpose • use components improperly

  14. Key Problems: Wrong Culture • Some cultures can be narrowly focused • Time or cost pressure • In this case: • wait for a brief respite • or bring it by stealth and declare victory • The lack of infrastructure • Budgetary constraints may derail the project • In this case: • Deploy new technology on a small scale • Corporate culture may inhibit reuse • Reward systems based on the amount of the code developed! • People work according to how they are measured and rewarded!

  15. Key Problems: Wrong Goals • When you build reusable components, you are building for future. • What if you get it wrong? • It is difficult to anticipate future uses. • Business needs may change, even though the component is well-designed. • GUI, Services, and Domain Components • GUI might be your best bet, but there are so many available already • In dynamic markets • infrastructure services may remain more stable than the domain they serve!

  16. Key Problems: Wrong Purpose • GUI, service, and domain components • They are different from each other • They have a different scope and purpose. • They have differing needs • Infrastructure support • Developers skill sets • Do not use the same component for different purposes • Cause: poor analysis • Abstractions have mixed types of functionality • Can be avoided by good analysis and design

  17. Building the Business Case • Understand the concepts behind each model • Make sure you address the issues they raise • Modify the models for your situation • For each model, come up with a buy and build scenario. • GUI (40% improvement) • Service (150% improvement) • Domain (1000% improvement) • Focus energies appropriately

  18. Concluding Remarks • Component technology is clearly cost-effective. • Component reuse has a significant impact on your productivity. • Developing business case might be the only way to convince skeptics in your organization. • Watch out! This field is too immature to bet on any one approach to component development. • Use the three-level model and provide an incremental approach to building your business case.

  19. Agenda • The Business Case for Components • COTs Myths • Common High-Risk Mistakes

  20. COTS • “(Commercial Off-The-Shelf) Refers to ready-made merchandise that is available for sale.” [GuruNet] • Using COTS, we can rapidly create new applications today. • Key to success • Selection of the software component infrastructure. • Selection of the middleware or the glue that holds them together. • Key Issues • Volatility and flexibility of the requirements • The stability of component producers • The respective components the producers are supplying.

  21. COTS terms • Customer • Pays for application to be built • Component consumer • Assembles application from components • COTS component producer • Supplies components • Provides support and upgrades

  22. COTS Myths • Lessons learned • Infrastructure Issues • Managerial Issues • Additional Issues

  23. Component Myths: Infrastructure Issues #1: components have many advantages • usage may be negative • What components can do to you instead of for you! • #2: component systems can be top-down • must be built bottom up • #3: OPEN systems solves interoperability • plug-and-play doesn’t always work • #4: no need to test purchased components • testing even more important

  24. Component Myths: Infrastructure Issues #5: Components are carefully selected • Arbitrary selections more common • #6: Components have adequate documentation • Documentation not relevant to selling components • #7: Easy to configure component-based system to meet your needs • Easier to match component capabilities • 80% of reqs can be assembled at 20% of cost • You may end up configuring your process rather than configuring the components!

  25. Component Myths: Managerial Issues • #8: components built with best-practice • producers just as market-driven as everyone else • #9: one can buy a component • buy the right to use a version of a component • #10: Producers will fix problems • producers may fix problems in next version

  26. Component Myths: Managerial Issues • #11: Large customers can influence producers • Only market of supply-demand has influence • #12: component-based systems are best solution • expose weaknesses in system development • compresses development schedule • near-term success may lead to long-term failure

  27. Rules of Thumb • #2: Maximum shelf-life of COTS component is two years • #3: Half-life of COTS component expertise is 6 months • #5: No COTS-based solutions is DMS • Diminishing Manufacturing Source • # 12: COTS-based system will never completely satisfy customer’s needs

  28. Concluding Remarks • The Ultimate Solution • Setting up integrated product teams (IPTs) • Customers • End-users • Consumers • COTS producers • A COTS-based system might not always be the “best” solution available. • A custom implementation may be more cost-effective over the life of the project.

  29. Agenda • The Business Case for Components • COTs Myths • Common High-Risk Mistakes

  30. Common High-Risk Mistakes • It is easy to write success stories • We tend to forget our mistakes and failed projects. • What should we do? • Retrospection • Reflection • We can then see the nuances and pitfalls of our own actions and those of others.

  31. The Pitfalls • The lead architect role • Application architect and component infrastructure lead designer. • Immature component Infrastructure • The required infrastructure should be one version ahead • Size and Packaging of Subcontracted Components • Do not subcontract too large or too small components. • Distributed Development is Not Synonymous with CBD • Try to avoid distributed development. • Achieving Unambiguous Communication • Use extensive component specifications. • Large-Scale Legacy Integration Difficulties • Large systems evolve as a combination of the old and new systems • Collect Metrics Early • We can reliably size and cost the entire system.

  32. What should we do? • We can implement the following • A proven commercial component infrastructure integrated with good modeling and code development tools • A co-located organization • Avoid distributed organizations. • A mature organization that can follow complex development processes

More Related