1. COP 4009 5 th Lecture October 3, 2005 COP 4009 Component-Based Software Engineering The Case for Components Fall 2005 Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Teaching/

2. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 4 Agenda  The Business Case for Components  COTs Myths  Common High-Risk Mistakes

5. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 6 Business Case  Component Types – GUI components – Service components – Domain components  Relationship between cost & complexity –Models build on one another GUI Components Service Components Domain Components Complexity Cost

7. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 7 Key Issues  Business goals  Technical sophistication  Organizational readiness  Infrastructure support  Reuse

8. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 19 Agenda  The Business Case for Components  COTs Myths  Common High-Risk Mistakes

20. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 22 COTS Myths  Lessons learned  Infrastructure Issues  Managerial Issues  Additional Issues

23. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 29 Agenda  The Business Case for Components  COTs Myths  Common High-Risk Mistakes

30. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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. Fifth Lecture on October 3, 2005COP-4009: Component-Based Software Engineering 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