1. Organizational Aspects for Reuse
Juliana Dantas
June 2, 2019

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

3. Motivation
June 2, 2019

4. Reuse processes are not simple technologies and methods
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
June 2, 2019

5. Introducing Reuse
June 2, 2019

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.
June 2, 2019

7. Inhibitor
June 2, 2019

8. Inhibitor
June 2, 2019

9. Inhibitor
June 2, 2019

10. Inhibitor
June 2, 2019

11. Inhibitor
June 2, 2019

12. Communication is a major barrier to extending reuse programs;
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
June 2, 2019

13. Produced specifically to be reused Derived from legacy systems
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
June 2, 2019

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
June 2, 2019

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).
June 2, 2019

16. Organizational Models
June 2, 2019

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

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
June 2, 2019

19. Organizational Models
Development Department
June 2, 2019

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
June 2, 2019

21. Organizational Models
Business Units
June 2, 2019

22. Organizational Models
Domain Engineering Unit
Resume: The domain 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.
June 2, 2019

23. Organizational Models
Domain Engineering Unit
June 2, 2019

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;
June 2, 2019

25. Organizational Models
Hierarchical Units
June 2, 2019

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
June 2, 2019

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: the way responsibility for product line assets is handled
Organizational units: the way is organized into units
June 2, 2019

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
June 2, 2019

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
June 2, 2019

30. Organizational Dimensions
June 2, 2019

31. Maturity of an Organization Reuse
June 2, 2019

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

33. Maturity of an Organization Reuse
Ad Hoc
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.
June 2, 2019

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.
June 2, 2019

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 initially only 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
June 2, 2019

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.
June 2, 2019

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

38. Reuse Maturity Framework
June 2, 2019

39. Reuse Maturity Framework
June 2, 2019

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)
June 2, 2019

41. Systematic Reuse Adoption [Griss,1997]
June 2, 2019

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
June 2, 2019

43. Project Management
June 2, 2019

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.
June 2, 2019

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.
June 2, 2019

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:
June 2, 2019

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.
June 2, 2019

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.
June 2, 2019

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.
June 2, 2019

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
June 2, 2019

51. References
[Lynex et al,1998] – Andy Lynex, Paul Layzell, Organizational Considerations for Software Reuse, 1998
[Peter et al, 2000] - Peter Knauber, Dirk Muthing, Klaus Schimid, Tanya Widen, Applying Product Line Concepts in Small and Médium-sized Companies, 2000
[Clements et al, 2005] - Paul C. Clements, Lawrence G. Jones, and Linda M. Northrop, John D. McGregor, Project Management in a Software Product Line Organization, 2005
[Bosch, 2001] - Jan Bosch, Software Product Lines: Organizational Alternatives, 2001
June 2, 2019

52. References
[SPC,1993] – SPC CMC, Software Productivity Consortium, Reuse Adoption Guidebook, 1993
[Koltun et al,1991] – P. Koltun, Hudson A, A reuse maturity model, 1991
[Griss,1997] – Ivar Jacobson, Martin Griss, Patrick Jonson, Software Reuse: Architecture, Process and Organization for Business Success, 1997
[PMI,2000] – Project Management Institute, A Guide to the Project Management Body of Knowledge, 2000
June 2, 2019