Experiences with certification of reusable components in the GSN project in Ericsson, Norway

1. Experiences with certification of reusable components in the GSN project in Ericsson, Norway Parastoo Mohagheghi and Reidar Conradi Dept. Computer and Information Science NTNU

2. Introduction • INCO project • University of Oslo, NTNU, Ericsson • Quality issues of COTS are not addressed by incremental process • Discuss methods for reusable component development and certification in GSN project at Ericsson in Grimstad

3. The local setting at Ericsson • The world´s leading suppliers of third generation mobile systems • Build robust, highly available systems for real-time applications, such as GPRS and UMTS • GSN ( GPRS Support Node) project: • Develop compoents reusable by applications • Define a common software arhcitecture • Define an overall reuse process

4. GSN application architecture Application-specific layer Business-specific layer Common parts Middleware layer System layer

5. The reusable artifacts • Software architecture • A layered architecture, its generic components and guildlines • Reusable components in the business-specific or middleware layer • Design patterns and more specific guildlines • Common process, based on adaption of RUP and including considerations about quality issues

6. Development of the architecture (1) • Originally for a specific GPRS application • Later used to develop architectural patterns and guidelines reusable for both GPRS and UMTS applications • The architecture should fulfil all the requirements including functional requirements and non-functional requirements (quality requirements)

7. Development of the architecture (2) • Top-down approach • Identify the building blocks of the architecture • Bottom-up approach • A later recognition of shared requirements • Identify reusable parts • A joint development effort across projects,teams, and organizations

8. Verify reuse of the architecture • How well can the architecture and components for a specific product meet the requirements for other products? • The degree the shared requirements are satisfied • How well are the architecture and components documented? How much information is available on interfaces and internal implementations?

9. Certification of reusable architecture • All components should be certified by inspections and unit testing. When the components are integrated, integration testing and target testing are done. • Quality requirements • Some quality requirements can be converted to a use case • Traffic model, measuring the behavior, simulation and target tesing, like performance and availability

10. Developing reusable components • The current process • How generic this components will be • Application-specific layer • Business-specific layer • Middleware layer • If the component is recognised reusable • Identify the degree of reusability • Identify the cost to make it reusable • Develop a verification plan for all the steps like inspection, prototyping, unit testing, system testing and extra test cases for reuse

11. Future issues • Improve the process for breaking down quality requirements • Improve the development process to capture these requirements in the model and specifications • Improve certification of quality requiremets.

12. Q5: Does perceived economic feasibility influence reuse? • Reuse may not be done if it is not believed to be economically feasible. • Levels of code reuse is compared with respondents agreement with the statement: “Reuse is economically feasible in my organization”. • Clear trend towards higher reuse as belief in economic feasibility increases • Conclusion: • perceived economic feasibility influences reuse • important to convince software engineers about the economic feasibility of reuse

13. Q6: Does reuse education influence reuse? • Comparing education about software reuse (at school) with individual levels of reuse shows that education on reuse does affect code and design reuse • Comparing education about software reuse (at work) with organizational reuse levels of lifecycle objects shows that education at work does affect reuse • Conclusion: • Education in school and at work improves reuse and is a necessary part of a reuse program

14. Q7: Does software engineering experience influence reuse? • General assumption that experienced software engineers are better practitioners • The survey shows no significant correlations between engineering experience and personal level of reuse. • Conclusion: • Software engineering experience has no effect on reuse of lifecycle objects • Maybe caused by historical lack of training in reuse

15. Q8: Do recognition rewards increase reuse? • Reuse incentives are considered to be necessary catalysts for reuse. • recognition rewards and cash rewards • Respondents say that rewards are rare • no cash bonuses • only a few with other recognition • Comparing levels of organizational code reuse between the two groups ”rec. rewards” and ”no rewards” show no significant differences • Similar findings for individual reuse • The findings contradict the common belief that recognition is a sufficient reward for reuse. • It may be that only monetary rewards are sufficient rewards

16. Q9: Does a common software process promote reuse? • Statement used in the survey: • “A common development process has promoted reuse across projects in our organization.” • Respondents generally do not agree on it. • This might mean: • no defined common process • the process has failed to support reuse • The correlations between the degree of agreement with the statement and the organizational reuse shows • moderate correlation for designs, test plans, and test cases • weak correlations for requirements, code, and user documentation • Conclusion • A defined software process that promotes reuse does affect software reuse levels

17. Q10: Do legal problems inhibit reuse? • Legal issues e.g.. regarding contracting, ownership are still unresolved and are thought to be a serious impediment to reuse • The statement: • I am inhibited by possible legal problems. • Most respondents (68%) report that legal problems do not appear to be an impediment • Conclusion: • No significant correlation between levels of reuse and reported inhibition by legal problems.

18. Q11: Does having a reuse repository improve code reuse • A reuse repository is a searchable collection of reusable assets. • Slightly higher median for reuse levels for organizations with a repository • Not statistically significant • Conclusion • Having a reuse repository does not improve reuse • A repository should not be the focus for organizations trying to improve systematic reuse

19. Q12: Is reuse more common in certain industries? • Respondents were asked to classify their company or business • Significant differences in reuse between different industries • higher level for telecommunication • lower level for aerospace industries • Reasons not currently known • Industries with low reuse might benefit from studying and adopting reuse practice in industries that lead in software reuse

20. Q13: Are company, project sizes predictive of organizational reuse? • Small organizations: • Is systematic reuse a realistic goal given the the scope of their domain and limited resources? • Large organizations: • Introducing systematic reuse may be unrealistic because of the large investment and time required • No significant correlation were found between organizational size and reuse levels • Conclusion: • Company and project size are not predictive of reuse levels • Organizations of any size may succeed to introduce systematic reuse

21. Q14: Are quality concerns inhibiting reuse? • It is commonly thought software engineers distrust assets developed outside and thus are less likely to reuse them. • No correlation between: • ”software developed elsewhere meets our standards” • ”what percentage of the parts you reuse are form external sources” • Experience in quality of reusable software have generally been favourable (69% agreement) • No correlation between personal reuse level and experience in quality of external software • Conclusion • Satisfaction with quality does not influence reuse levels • Does NOT mean that quality is unimportant

22. Q15: Are organizations measuring reuse, quality, and productivity? • Measuring reuse is important to determine success of the reuse program • Few organizations are currently measuring reuse (at most 25%) • Quality is more widely measured (42%) • Productivity measurement is relatively rare (32%) • Conclusion: • Many organizations do not measure reuse levels, quality, and productivity • These organizations cannot properly manage their software processes and products, including reuse

23. Q16: Does reuse measurement influence reuse? • Measuring an activity will tend to increase it. • Comparing median level of software reuse for organizations that are or are not measuring reuse. • The study shows no correlation • Conclusion: • Organizations that measure reuse do not use these measurements to improve reuse levels.

24. How to improve reuse • To improve systematic reuse concentrate on: • education about reuse • developers understanding on the economic feasibility of reuse • introduce a common development process that promotes reuse • make high quality assets available to developers