organizational aspects for reuse l.
Skip this Video
Download Presentation
Organizational Aspects for Reuse

Loading in 2 Seconds...

play fullscreen
1 / 52

Organizational Aspects for Reuse - PowerPoint PPT Presentation

  • Uploaded on

Organizational Aspects for Reuse. Juliana Dantas Summary. Motivation Introducing Reuse Organizational Models Maturity of an Organization Reuse Project Management in Software Product Line (SPL). Motivation. Focus [Lynex,1998].

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Organizational Aspects for Reuse' - Leo

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
organizational aspects for reuse

Organizational Aspects for Reuse

Juliana Dantas

  • Motivation
  • Introducing Reuse
  • Organizational Models
  • Maturity of an Organization Reuse
  • Project Management in Software Product Line (SPL)
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
introducing reuse peter 2000
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.
  • 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
reusable components
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
obtaining reusable components
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
obtaining reusable components15
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).
organizational models bosch 2001
Organizational Models [Bosch,2001]
  • Four Organizational Models for Software Product lines(spl):
    • Development Department
    • Business Units
    • Domain Engineering Unit
    • Hierarchical Units
organizational models18
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
organizational models19
Organizational Models
  • Development Department
organizational models20
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
organizational models21
Organizational Models
  • Business Units
organizational models22
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.
organizational models23
Organizational Models
  • Domain Engineering Unit
organizational models24
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;
organizational models25
Organizational Models
  • Hierarchical Units
selecting organizational models bosch 2001
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
organizational dimensions bosch 2001
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
organizational dimensions
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
organizational dimensions29
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
maturity of an organization reuse lynex 1998
Maturity of an Organization Reuse [Lynex,1998]
  • Ad Hoc
  • Opportunistic
  • Systematic
  • Cultural
maturity of an organization reuse33
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.
maturity of an organization reuse34
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.
maturity of an organization reuse35
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
maturity of an organization reuse36
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.
reuse maturity framework koltun 1991
Reuse Maturity Framework [Koltun,1991]
  • Initial/Chaotic
  • Monitored
  • Coordinated
  • Planned
  • Ingrained
reuse capability model spc 1993
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)
transition to a reuse business griss 1997
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
project management44
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.
project management45
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.
project management46
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:
project management47
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.
project management48
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.
project management49
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.
  • 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
  • [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
  • [SPC,1993] – SPC-92051-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