Component Based Software Estimation

1. Component Based Software Estimation Antonius Hermawan Irene Talaway David Vidal Nga Nguyen

2. Outline • Definition • Problems with traditional approach • Solutions • Different scale factors • Complexity size • Examples • Other techniques • Conclusion

3. Requires int er face Provides int er face Defines the services Defines the services that are provided from the component’s Component by the component environment that it to other components uses Component-based Software Engineering • Component-based software engineering (CBSE) is an approach to software development that relies on software reuse. • Components are independent so do not interfere with each other;

4. EstimationProcess Effort Estimation (COCOMO) Size/Function Points Estimation Size / FunctionPoints Effort Problem 1 2

5. CountingComplexity Class Diagram • No of interactions • No of interfaces Component Diagram • No of interactions • No of interfaces • Complexity of interfaces • Complexity of interactions Source: http://www.visual-paradigm.com/VPGallery/diagrams/Component.html

6. Process WH App. Specific Warehouse Application Form Report Stock Supply Communication Log Sales & Order User Managemnt CB Approach Traditional Approach Software cost is projected at the large grained system level COCOMO Function Point

7. Problems WH App. Specific Form Report Communication Log User Managemnt Problems • Cost estimating problem • Efforts estimating problem

8. Costs & EffortsEstimating • Intensity • Concurrency • Fragmentation • Team-size GUI

9. Costs & EffortsEstimating Personal GUI Report Security Log User Managemnt Project A • Component Project Experience • Programmer Project Experience Re-use A new project B GUI GUI

10. Methods for estimating component size

11. # Methods Linear Regression # Subclasses LOC # Events Neural networks Component’s type #GUI elements Lines of CodeMethod

12. Advantages Easy to calculate It can be automated Disadvantages Plattform specific One application used Source code not always available. Lines of CodeMethod – Advantages - disadvantages

13. Component complexity Composition Interaction Packing density Interaction density Incoming interaction density Average interaction density Outgoing interaction density ComponentComplexityMetrics

14. Component D ComponentA Component C Component B ComponentComplexityMetrics - Example Incoming Outgoing

15. Advantages Focusoncomponentsassembly Easytocalculate Disadvantages No practical case studies It'snotclearitspotential uses ComponentComplexityMetrics – Advantages - Disadvantages

16. Analysis CBSS & Classify components Determine interface complexity Determine interaction complexity Evaluate component complexity & Compute TUCP count Determina VAF & Compute the final Component point count. Componentpoints - Steps

17. Componentpoints - Classification User- Interface Components Service- Components Components Domain- Components

18. Componentpoints - Interface Complexity ILF EIF Component type Number of operations Number of parameters Weights Complexity table Interface complexity

19. Componentpoints - InteractionComplexity Primitive data types User data types Collaboration diagrams Information content. Interaction Frequency Complexity measure Interaction Complexity

20. Componentcomplexity IFCI ITCI Complexity tables # Components Weights Component complexity

21. 14 GSC: • Data and Online Communication • Distributed Processing • System/component performance • Development rigidity • User friendliness • System complexity • Installability • Operability • Maintainability • Multi-site use • System/component reliability • System/component portability • Component immaturity • Lack of component vendor support Final CP Count Estimate Influence of 14 GSC (General System Criteria) Estimate Influence of 14 GSC (General System Criteria) TDI No Influence Strong Influence Count VAF (Value Adjustment Factor) VAF = 0.65 + (0.01 x TDI) VAF Count Final CP CP = TUCP x VAF TUCP CP

22. Effort Estimation in CBSD • E = effort estmation (man-months) • EDSI = Estimate of Delivered Source Instruction • a,b constants • EAF = effort adjustment factor • How about cost for individual components? E = a (EDSI) b x (EAF) Intermediate COCOMO

23. Effort Estimation in CBSD (2) Count EDSI/MM Example: E = 3.2 (8.5)1.05 x 1 = 30 MM EDSI/MM = 8500/30 = 283 CMMNOM = EDSI/component EDSI/MM CMMNOM = 2000/283 = 7.06 CMMADJ =CMMNOM x EAF

24. Effort Estimation in CBSD (3) • This improvement over monolithic approach fails to capture relevant parameters in CBSD • Metrics affecting effort in CBSD: • Intensity : actual time spent on a component time scheduled for the component • Concurrency : many programmers are working on 1 component. • Fragmentation : 1 programmer is working on many components. • Programmer Project Experience : components have been completed • Component Project Experience • Team Size

25. Effort Estimation in CBSD (4) Augmented COCOMO Model: • HOURS = number of hours devoted for component • COCOMO = result of intermediate COCOMO • PREV = number of comp. previously worked on (Component-project experience) • PROG = size of component development team (team size) • α, β1, β2, β3 are determined based on statistic HOURS = α + β1(COCOMO) + β2(PREV) + β3(PROG)

26. Another Estimation Technique

27. Select Estimators Algorithm Approach Technical Cognitive Process Oriented View Schedule determine by number of developer, individual skill level, productive work days/month, contingency

28. Select Estimators Algorithm MCm= w * MICm +w*m Object Metrics Algorithm (Boehm survey) Metrics for Object Oriented • MICm = Method Interface Complexity/size • m = Complexity/size metric for method evaluation • w = Weights, which obviously depend on metric m adopted. • MICm to adjust the traditional functional metrics for: • to take also into account complexities due to • to obtain measures even when the method • is only partially implemented or simply identified. Schedule determine by number of developer, individual skill level, productive work days/month, contingency

29. Select Estimators Counting and classify software elements Supporting Business application Planning Business application Infrastructure of reusable components Analysis Review Design Programming Integration Base metric of effort in person days Testing

30. Select Estimators Scope Project Architect Activity Profile Qualifier Technology Productive Workdays, Contingency Effort Team Size, Skill Levels Estimator Schedule Labor Costs Cost SELECT Estimator – Software Development cost estimation approaches – a survey

31. Select Estimators Applications – subsystems supporting business area Classes – business concept Project architect User cases – requirement from user Packages – supporting framework Components – abstraction of lower level Services – common system features SCOPE Estimator Base effort adjusted using qualifier to add and subtract INPUT Qualifier Complexity Reuse Genericity Technology Effort in person days, by activity – person in average skill OUTPUT Schedule determine by number of developer, individual skill level, productive work days/month, contingency

32. Select Estimators vsCocomo II Software development cost estimation approaches –A survey - Barry Boehm a, Chris Abts a and Sunita Chulani b

33. Select Estimators vsCocomo II Software development cost estimation approaches – A survey - Barry Boehm a, Chris Abts a and Sunita Chulani b

34. Conclusion • Traditional estimation approach failed to capture all aspects of component-based estimation approach • Component based software can be estimated by 2 approaches: • enhanced size estimation technique • more component based related aspects as adjustment factors • Component points is the most complete technique for size estimation from three different studies– lines of code, component complexity, component points.

35. Conclusion (2) • In order to capture component based related aspects, COCOMO could be adjusted in two ways: • Considering effort of each component. • Considering adjustment factors specific for component based software • Select Estimators is a good estimating tool for component based that has starting point from object oriented metrics based • Cocomo II still favorite tool for doing component based estimation process with necessary adjustment.

36. LiteratureReviewed [1] A. J. Albrecht and J.E. Gaffney, Software Function, Source Lines of Code and Development Effort Prediction: A Software Science Validation, IEEE Transactions on Software Engineering, vol. 9 , 1983 [2] Parag C. Pendharkar. An exploratory study of object-oriented software component size determinants and the application of regression tree forecasting models in Information & Management, Elsevier 2004. [3] Randy K. Smith, Effort Estimation in Component Based Software Development: Identifying Parameters [4] Randy K. Smith, Allen Parrish, Cost estimation for component based software development, ACM Southeast Regional Conference, 1998.

37. Literature Reviewed (2) [5] Sajjad Mahmood and Richard Lai, A complexity measure for UML component-based system specification in Software-practice and experience, Willey interscience 2006. [6]Thareendhra Wijayasiriwardhane and Richard Lai. A method for measuring the size of a Component-based system specification in the Eighth international conference on Quality software, IEEE 2008. [7] V. Lakshmi Narasimhan and B. Hendradjaya. Some theorical considerations for a suite of metrics for the integration of software components in Information Sciences, Elsevier 2007. [8] Kozaczynski, W., & Booch, G. Component-based software engineering. IEEE software, 15(5), 34-36, 1998.

38. Literature Reviewed (3) [9] Shimmi, A. Component Based Software Engineering. 2008 [10] Barry Boehm a, Chris Abts a and Sunita Chulan.Software development cost estimation approaches –A survey. Annals of Software Engineering 10 (2000) 177–205,2000 [11]P. NesiT.,Querci .Effort estimation and prediction of object-oriented systems. Journal of Systems and Software pages 89-102 Volume 42,  Issue 1, 1998