Organizational Aspects for Reuse

1. Organizational Aspects for Reuse Juliana Dantas Juliana.dantas@cesar.org.br

2. Summary • Motivation • Introducing Reuse • Organizational Models • Maturity of an Organization Reuse • Project Management in Software Product Line (SPL)

3. Motivation

4. Focus[Lynex,1998] • Until most research into strategies for systematic reuse has focused on solution of the technical issues. • Reuse processes are not simple technologies and methods • Reuse requires the whole organization and funding of development to be revised. • Requires not only technical solutions but also significant restructuring of the way software is developed and managed

5. Introducing Reuse

6. Introducing Reuse[Peter, 2000] • Incremental introduction of reuse • One of the cited barriers to adopting reuse is the lack of consistency between environments, methodologies, technologies and standards used by various development teams • An organization needs to move through these levels and to do this they must remove increasing numbers of inhibitors.

7. Inhibitor

8. Inhibitor

9. Inhibitor

10. Inhibitor

11. Inhibitor

12. Inhibitor • Communication is a major barrier to extending reuse programs; • The most common experience to come out of reports on the introduction of a reuse process is not knowing how to obtain reusable components in the first place. • Most of the common reuse strategies rely on providing a repository of components

13. Reusable Components • Reusable software components may essentially be obtained from three sources: • Produced specifically to be reused • Derived from legacy systems • Produced as part of new developments

14. Obtaining Reusable Components • Produced specifically to be reused (stages) • Incentive program encourages submission of components to the repository • In the beginning the quality of submitted components falling as anything and everything is submitted • Discourages developers from making use of them • Look solely at obtaining components of a certain quality • Only well documented and tested components are submitted

15. Obtaining Reusable Components • Derived from legacy systems • Additional work required in order to place components in a repository or to make them more general purpose will have to be assigned as a project in itself with its own resources • Produced as part of new developments • A producer/consumer structure with some teams developing components (producers) which are integrated into systems by other teams (consumers).

16. Organizational Models

17. Organizational Models [Bosch,2001] • Four Organizational Models for Software Product lines(spl): • Development Department • Business Units • Domain Engineering Unit • Hierarchical Units

18. Organizational Models • Development Department • Resume: Concentrated in a single development department, no organizational specialization exists; No permanent organizational structure on the architects and engineers that are involved in the software product line. • Applicability: smaller organizations (-30 members) • Advantages: simple and communications between staff members is easy • Disadvantages: does not scale to larger organizations

19. Organizational Models • Development Department

20. Organizational Models • Business Units • Resume: Each business unit is responsible for the development and evolution of one or a few products in the SPL; • Unconstrained model: any business unit can extend the functionality of any shared component. • Asset responsible: An asset responsible has the obligation to verify that the evolution of the asset • Mixed responsibility: each business unit is assigned the responsibility of one or more assets, in addition to the product(s) the unit is responsible for • Applicability: number of staff member is between 30 and 100 • Advantages: allows for effective sharing of assets between a set of organizational units • Disadvantages: easily focus on the concrete systems rather than on the reusable assets

21. Organizational Models • Business Units

22. Organizational Models • Domain Engineering Unit • Resume: Thedomain engineering unit is responsible for the design, development and evolution of the reusable assets; • Applicability: number of staff member exceeds around 100; • Advantages: the model is widely scalable; reduces communication from n-to-n in the business unit model to one-to-n between the domain engineering unit; • Disadvantages: Difficulty of managing the requirements flow and the evolution of reusable assets; since the domain engineering unit needs to balance the requirements of all system engineering units. Causes delays in the implementation of new features in the shared assets.

23. Organizational Models • Domain Engineering Unit

24. Organizational Models • Hierarchical Units • Resume: Additional level has been introduced in the software product line. This additional layer contains one or more specialized product lines. • Applicability: in large or very large organizations with a large variety of log-lived systems (hundreds) • Advantages: its ability to encompass large, complex product lines and organize large numbers of engineers • Disadvantages: administrative overhead that easily builds up, reducing the agility of the organization as a whole, which may affect competitiveness negatively; considerable maturity with respect to software development projects is required for this approach to succeed;

25. Organizational Models • Hierarchical Units

26. Selecting Organizational Models [Bosch,2001] • Influencing Factors • Geographical Distribution: • The physical location of the staff involved in the software product line still plays a role; • Units that need to exchange much information should preferably be located closer to each other than units that can cooperate with less information • Project Management Maturity: • Units, communications -> relatively high level of maturity with respect to project management; • Organization Culture: • Kind of ‘cowboy’ or ‘hero’ culture exists in which individual achievements are valued higher than group achievements -> to be a serious inhibitors of a successful software product line approach

27. Organizational Dimensions [Bosch,2001] • Dimension that play role in the selection of the most appropriate organization model for SPL. • Product line assets: the way assets are treated depends on the type of products and the type of organization employing a product line approach • Responsibility levels: theway responsibility for product line assets is handled • Organizational units: the way is organized into units

28. Organizational Dimensions • Product line assets • Architecture: with little integration between the various units • Platform: once a shared architecture is a place, it becomes possible to define some basic functionality as shared components. • Components: share both the product line architecture and most of the components that are shared • Product specifies: product specific code is explicitly considered at the product line level

29. Organizational Dimensions • Responsibility levels: • Shared: bottom-up manner; responsibility by shared among the organization units • Responsible: an individual or a small team is assigned at the responsible for the particular asset • Engineered: a team is responsible for the development and evolution of a particular asset • Organizational units: the way is organized into units • Project: not employ a permanent assignment of staff to units; • Product: staff is permanently assigned to a particular product; • Shared Components: components are assigned to units that act as service providers to the product units • Architecture centric: organizing staff centers around a software architecture that is shared among the products

30. Organizational Dimensions

31. Maturity of an Organization Reuse

32. Maturity of an Organization Reuse [Lynex,1998] • Ad Hoc • Opportunistic • Systematic • Cultural

33. Maturity of an Organization Reuse • AdHoc • random reuse • developers tend to reuse either experience from previous projects • standard programming component libraries supplied with development tools or to modify modules of their own source code • Developers may also occasionally share components or experience with others but this is by no means planned and tends to happen accidentally as a result of informal problem discussion.

34. Maturity of an Organization Reuse • Opportunistic • Individual projects recognize the opportunity for reuse. • Some similar product has previously been built and they wish to use elements of legacy code or because a range of variant products is planned which may share common constituents. • Focus on only those products currently scheduled for development • The requirements of possible future developments or other unrelated current projects are largely disregarded and reuse becomes more a means to an end of completing a product than an aim in itself to improve the development process.

35. Maturity of an Organization Reuse • Systematic • Component library is instigated which allows components to be shared between projects. • To include artefacts from throughout the development cycle although initiallyonly source code and possibly designs are likely to be included • Reuse is also made a company or divisional goal and targets are set or incentives offered to encourage participation. • Managers fully back the idea of incorporating reuse into development

36. Maturity of an Organization Reuse • Cultural • Reuse becomes accepted into the organizations behavior • Here rather than requiring targets or incentives reuse is seen as part of the process of development and is used religiously by developers in order to improve their productivity.

37. Reuse Maturity Framework [Koltun,1991] • Initial/Chaotic • Monitored • Coordinated • Planned • Ingrained

38. Reuse Maturity Framework

39. Reuse Maturity Framework

40. Reuse Capability Model [SPC,1993] • Self-assessment and planning aid for the organization • Assessment model to understand the present state of the reuse practices within the organization • Implementation model to guide the implementation of the reuse program • Contains a set of critical success factors(22), each of which has one or more goals (60)

41. Systematic Reuse Adoption [Griss,1997]

42. Transition to a Reuse Business [Griss,1997] • Five-Step Process: • Creating a Directive to Reengineer the Software Business – high-level reuse business goals • Envisioning the New Reuse Business – develops high-level vision of the new architecture • Reverse-Engineering the Existing Software Development Organization – understand status of reuse • Forward-Engineering the New Reuse Business – develop • Implementing the new Reuse Business – installed • Continuous Process Improvement

43. Project Management

44. Project Management • Traditionally, a project is viewed as a temporary endeavor undertaken to create a unique product or service. According to this definition, projects have [PMI,2000]: • a beginning and an ending point; • clear outputs and goals (a charter for their existence); • a clear chain of responsibility, including an owner or lead; • schedule and resource requirements.

45. Project Management • Key product line activities • Product line organization projects (developing core assets; developing products that use those assets; managing these developments for the organization’s overall benefit) don’t always match these characteristics. • Successful product line engineering requires management and coordination of both the core asset and product development projects to meet the organization’s overall business goals.

46. Project Management • Organizational management • Close coordination among the core asset and product development projects. The two development operations constitute separate projects. • Product development project managers must understand each project’s role as a core assets consumer. • Core asset development project managers must understand each project’s role in the context of the products to be built from them. • A successful product line organization requires strong, visionary management. • This responsibility falls to the product line manager. Product line manager tasks are:

47. Project Management • Ensuring the appropriate organizational units, with the right staff and resources. • Ensuring an appropriate funding model for the creation and evolution of core assets. • Having appropriately trained people. • Establishing policies, process definitions, and a product line operating concept. • Planning the organization’s conversion to the product line paradigm.

48. Project Management • Planning and managing the product line’s evolution. • Establishing and monitoring the interaction mechanisms — such as communications, dependencies, feedback, and risk management —among product and core asset development projects. • Establishing the organization’s product line goals, as well as a measurement program to track progress in meeting them. • Planning and managing external interfaces, particularly with customers and suppliers.

49. Project Management • Planning and managing the product line’s evolution. • Establishing and monitoring the interaction mechanisms — such as communications, dependencies, feedback, and risk management —among product and core asset development projects. • Establishing the organization’s product line goals, as well as a measurement program to track progress in meeting them. • Planning and managing external interfaces, particularly with customers and suppliers.

50. Conclusion • Although the basic knowledge areas for traditional project management apply, product lines require specifically targeted management practices and techniques • Integrating systematic reuse into the development process is a difficult problem, to which the solution will vary from organization to organization. • There is no single path to reuse success, which can be followed by all; instead each company should tailor the experiences of others to find a solution that will work for them. • Only by looking for symptoms of possible problems in their development process can organizations hope to eliminate these problems and ease the introduction of their own reuse process