Docstoc

A Collaborative Approach for Reengineering-based Product Line Scoping

Document Sample
A Collaborative Approach for Reengineering-based Product Line Scoping Powered By Docstoc
					   A Collaborative Approach for Reengineering-based Product Line Scoping


      Muhammad A. Noor                             Rick Rabiser                  Paul Grünbacher
      Institute for Systems                                Christian Doppler Laboratory
  Engineering & Automation                              for Automated Software Engineering
  Johannes Kepler University                               Johannes Kepler University
      4040 Linz, Austria                                       4040 Linz, Austria
     man@sea.uni-linz.ac.at                     rabiser@ase.jku.at          paul.gruenbacher@jku.at


                      Abstract                             guidelines are available for scoping of product lines
                                                           which are to be introduced to existing products. How-
   Product line scoping is an important activity in re-    ever, economic pressures necessitate the reengineering
engineering-based software product line adoption.          of legacy assets. Activities to assess the domain poten-
Both business issues and technical concerns have to be     tial and scope the reuse infrastructure are considerably
handled adequately. However, involving stakeholders        different and more complex for a reengineering-based
representing these different concerns is not straight-     approach than for developing a new PL from scratch.
forward. Agile methods strongly emphasize stake-               Reengineering based PL adoption is an internal or-
holder involvement and customer collaboration. In this     ganizational task (as there is no external client); which
paper we propose a collaborative approach which is         is more suitable to be conducted in an incremental
intended to complement existing approaches for re-         fashion in order to manage risks and optimize the
engineering of legacy products in product line engi-       process continuously. However, there is a strong need
neering. It supports success-critical stakeholders         for team members to have a common vision about the
working collaboratively to converge on a product map       overall project. We suggest that this can be achieved
and a definition of reusable infrastructures. Our ap-      by performing the PL scoping upfront in a collabora-
proach is based on the WinWin requirements negotia-        tive way.
tion method which facilitates stakeholder collabora-           In the PuLSE framework [2] as later described in
tion and guidance towards mutually acceptable solu-        [18] the aims of scoping are to develop a product map
tions.                                                     and to identify and assess reusable assets which will
                                                           provide maximum business profit. A product map is a
1. Introduction                                            simple but powerful tool which shows the overall PL
                                                           in concise manner. Scoping in this context requires
   An increasing number of organizations are shifting      involvement of management, marketing, and sales per-
to a software product line (PL) approach to reduce         sonnel in order to address market and business aspects.
time to market and development costs while at the          No single stakeholder has all information necessary to
same time increase reliability and ease maintenance        estimate the cost of incorporating legacy assets into
[9]. Often product lines are not developed from            core assets for future reuse. In order to maximize the
scratch. Rather they are introduced to already existing    benefits for a given limited budget it is necessary to
products [12][17]. Research on reengineering-based         have a good estimate of cost and benefits. Benefits can
PL introduction is typically focused on the more tech-     be estimated by projecting historical sales data. Cost
nical aspects (e.g., [1]). Stakeholder collaboration has   can be estimated with the help of developers and archi-
received less attention so far.                            tects. At the same time stakeholder goals must be con-
   Reengineering processes in PLE are most effective       gruent with technical constraints of existing products.
when business objectives are reconciled with technical     Architects, developers, and maintenance staff have the
constraints. A critical task when developing a product     technical knowledge about the existing system. This
line is scoping. Comprehensive scoping approaches          knowledge is vital for scoping a PL for existing prod-
exist for the development of new product lines             ucts but is distributed among different stakeholders.
(e.g., [18]). However, comparably limited methods and      Mutually agreed solutions can therefore only be
achieved through close collaboration and knowledge             Senior management: The decision to adopt a prod-
sharing.                                                   uct line approach often comes from senior manage-
   In this paper we thus motivate the need for a col-      ment which outlines business objectives and allocates
laborative scoping approach which focuses on early         time and resources for the project. Senior management
involvement of stakeholders representing business and      is typically interested in cost-effective, timely, and
technical domains. We present an initial collaborative,    robust solutions which deliver the desired results with
stakeholder-centric approach for PL scoping, which         minimal exposure to risk. After the commencement of
can facilitate the incremental migration process from a    the project senior management has to ensure that busi-
conventional to a PL approach. Our approach is also        ness focus is not lost due to technical concerns.
consistent with agile principles, of collaboration,            Customers: In most cases it is not feasible to di-
shared vision, and incremental development. We do          rectly involve customers in internal product reengi-
not focus on bottom-up approaches which deal more          neering processes. Customer concerns and expecta-
with the technical aspects of reengineering, like for      tions have to be ascertained and incorporated through
example in [15].                                           representatives. For example, marketing and sales peo-
   Our approach is grounded in the well-documented         ple may bring in their knowledge about the market and
and proven approaches PuLSE [2] and EasyWinWin             detailed needs of different customers.
[5][7]. Our aim is to combine and tailor these ap-             Marketing and sales: Marketing and sales depart-
proaches to the described context. We use the three        ments have to generate revenue for the organization.
Pulse activities ‘product mapping’, ‘domain potential      They rely on products which are desirable for custom-
analysis’, and ‘reuse infrastructure scoping’ as a gen-    ers and meet their needs. Marketing and sales people
eral framework [18]. EasyWinWin is a collaborative         are essential to represent the business concerns in a PL
groupware-supported requirement negotiation method         adoption project. They have full access and under-
based on Boehm’s theory-W [6]. It is supported by          standing of historic sales data and feedback from cus-
several tools; however in this paper we adopt a Group      tomers. Based on that, future sale projections are made
Support System (GSS) to demonstrate our ideas. In          which help estimating the quantitative benefits of the
[13] it has been shown that EasyWinWin complements         project.
and supports agile methods by supporting the attain-           Software architects: Architects know the legacy
ment of a shared vision, the identification of critical    products which are to be reengineered. There are many
stakeholders and their extensive involvement. .            inherent complexities in reengineering-based product
   The remainder of this paper is structured as follows:   line development, e.g., when independent individual
In Section 2 we discuss success-critical stakeholders      legacy products are to be merged in a single platform
and highlight why their participation in product line      (PL infrastructure). There may be significant differ-
scoping is essential. We present our approach in Sec-      ences in terms of product architecture and implementa-
tion 3. There we also briefly discuss how collaboration    tion technology along with numerous combinations of
patterns helped us in defining the collaborative proc-     differences in non-functional attributes. The aim of
ess. In Section 4 we present the GSS tools and show a      reengineering is not only to enable reuse during devel-
prototype. Section 5 concludes this paper and presents     opment of core assets. Core assets should be developed
future research plans.                                     in such a way that unique features of different products
                                                           can also be easily reused. This makes early involve-
2. Typical Stakeholders in PL Scoping                      ment of architects essential.
                                                               Developers: The participation of developers is es-
   Agile methods emphasize the involvement of peo-         sential to assess different alternatives of legacy assets
ple in software engineering. The identification of         from a reusability perspective. Their knowledge facili-
stakeholders and their involvement is also central to      tates estimating the costs of changing different aspects
our proposed approach. Unresolved conflicts between        of legacy products.
stakeholders can jeopardise a project’s success. A col-        Maintenance personnel: Similar to developers,
laborative negotiation approach in PL scoping can help     maintenance staff is highly valuable in the early stages
to identify and overcome such conflicts to attain mu-      of product line scoping. Their intimate knowledge of
tual agreements and a shared vision among stake-           the strengths and weaknesses of existing products is
holders. Following Boehm’s spider web [4] we de-           essential. Feedback from the maintenance staff enables
scribe the success-critical stakeholders in the PL scop-   the evaluation of different PL evolution options to ease
ing context and briefly summarize their typical con-       transition to customers and to ensure product compati-
cerns:                                                     bility.
3. Collaborative Approach to PL Scoping                       ners, and (3) facilitates group collaboration through
                                                              guidelines and proper tools.
    The benefits of involving different stakeholders in
PL scoping are fairly obvious. The knowledge required         3.1. Key steps of the scoping process
for PL scoping is distributed among different people in
the organization. A collaborative approach can facili-            Product mapping, domain potential analysis, and
tate understanding the different stakeholder concerns         reuse infrastructure scoping are key activities for reen-
and converging on mutually acceptable solutions.              gineering-based product line scoping [2][18]. When
    Our collaborative reengineering-based product line        preparing a product map the products which will be
scoping approach uses PuLSE [2] as a general frame-           part of the product line are selected and features and
work. For defining a collaborative process we use             domains are determined. During domain potential
guidelines and patterns from collaboration engineer-          analysis the size and suitability of a domain for serving
ing [8] to improve interaction and decision-making of         as a core asset are assessed. Furthermore, collateral
stakeholders.                                                 costs of interdependencies and conflicts among fea-
    Achieving effective team collaboration is a consid-       tures of the domain and rest of the product(s) are iden-
erable challenge [10]. The area of collaboration engi-        tified. In reuse infrastructure scoping the potential
neering [8] aims to define repeatable work practices          costs and benefits to develop a domain as core asset
for recurring team tasks. These practices are based on        are quantitatively determined. Domains which promise
the assumption that team processes are much more              to yield the highest return on investment are identified
effective when explicitly modeled and structured.             and scoped unambiguously.
    Collaboration engineering identifies five general             Collaboration is essential in these three scoping ac-
patterns of collaboration that serve as building blocks       tivities:
for the conceptual design phase of a collaborative                Product Mapping: A product map contains do-
work practice. Each pattern characterizes a way in            mains, features, and products in tabular form and helps
which a group can move towards achieving its goal.            to visualize commonalities and variabilities of a PL at
The patterns are diverge, converge, organize, evaluate,       feature level. Product mapping starts with domain
and build consensus [8]: In diverge a group moves             identification. Domains which exist in legacy products
from having fewer to having more concepts with                and domains planned for the future constitute a product
which to work (e.g., a brainstorming activity). In con-       map. We can assume that stakeholders are well versed
verge people move from having many to a focus on a            with the products and the products’ domains. How-
few concepts worth more attention, and move from              ever, it is probable that not all stakeholders agree upon
less to more shared understanding of concepts and             the domain definition. Disagreements about features
labels (e.g., a moderated discussion about the brain-         and/or domains need to be revealed and discussed in
storming results). Organize means that a group starts         order to achieve a common understanding and to attain
to understand the relationships among concepts (e.g.,         consensus. While scoping domains through feature
structuring brainstorming results into different catego-      assignment, features can be discussed, refined, and
ries). Evaluate aims to understand the instrumentality        consolidated. Products to be in the PL also need to be
of concepts (e.g., voting to understand the preferences       discussed because it is possible to develop new prod-
of stakeholders). Align goals makes more individuals          ucts by using existing features in a different combina-
willing to commit to a proposal (e.g., discussing situa-      tion. Every existing product that is not part of the PL
tions where a team does not agree). Collaboration pat-        and new feature combinations should also be consid-
terns are typically supported with collaborative tools        ered. Therefore strong input from business people is
such as electronic brainstorming, group categorization,       required. Stakeholders have to agree on the assignment
group outlining, or voting tools, to name but a few.          of features to products. As noted earlier business needs
    EasyWinWin [7] is an example of a collaborative           should be compatible with technical realities. There-
process that makes use of these patterns of group inter-      fore features have to be prioritized according to their
action. This requirements negotiation method is based         business value and the technical feasibility, from a
on Boehm’s WinWin approach and complements the                reengineering perspective. Again possible disagree-
high-level WinWin approach with more detailed nego-           ments need to be revealed and discussed to build con-
tiation guidelines and tool support [14][13][5][7]. The       sensus.
potential benefits of adapting EasyWinWin in our re-              Domain Potential Analysis: In domain potential
engineering-based PL scoping scenario are manifold:           analysis domains are identified which have the highest
(1) The method is a well-documented and proven in             potential for reuse and promise the greatest return on
real-world settings, (2) it is an easy to use by practitio-   investment for reengineering them as core asset for the
product line. This activity is less challenging in the       Table 1. Collaborative, reengineering-based
reengineering context because products are already                         scoping process
successful in the market and the organization already        Activity           Purpose                                  Collabora-
has experience with the domain. Each domain is ana-                                                                       tion Pat-
                                                                                                                            tern
lyzed for certain parameters such as the size of the         (1) Review and     Identify and agree on domains
domain, reuse frequency in the future, complexity of                                                                      Converge
                                                             revise domains     contained in the legacy products
reengineering, cost of reengineering, or cost of devel-      (2) Brainstorm
                                                                                Collect the features for different
                                                                                domains from stakeholders. Use one
oping it from scratch. In our context it is important to     features for
                                                                                brainstorming session per identified
                                                                                                                          Diverge
                                                             domains
mutually agree on the domains which will be probed                              domain
quantitatively later and exclude domains which are low                          Discuss the brainstormed features,
                                                             (3) Converge on    eliminate redundant information
value candidates.                                            features per       through moderated discussion, find
                                                                                                                          Converge
                                                                                                                          Organize
    Reuse Infrastructure Scoping: The outcome of a           domain             a common level of feature granular-
                                                                                ity in the team
domain analysis can be transformed into quantitative                            Elicit and agree on the products
benefit measures. However, it is not feasible to tackle      (4) Agree on
                                                                                which will be part of the PL, existing     Diverge
                                                             the products in
this technical problem at the stage of negotiation. This     the PL
                                                                                and planned for the future, in order      Converge
                                                                                to achieve common understanding
task can be best performed in tandem with reverse en-        (5) Assign         Participants assign features to
                                                                                                                          Evaluate
gineering (e.g., Pulse DSSA [1]) or after that. In our       features to        different products. Reveal differ-
                                                                                                                         Align goals
case it is important to not only scope the selected reus-    products (vote)    ences & revote if necessary
                                                                                Prioritize features according to
able assets at product map level but to also identify        (6) Prioritize &
                                                                                business value using input of prior
                                                             optimize fea-
assets at component (infrastructure) level. This is not      tures for busi-
                                                                                market studies and input from
                                                                                                                          Evaluate
                                                                                relevant stakeholders. Determine
trivial because in many cases the traceability between       ness value &
                                                                                the technical feasibility of features
features and the technical-solution’s components is not      feasibility
                                                                                from reengineering context
readily visible [15]. In such a situation preliminary                           Possible differences are revealed
                                                                                and reasons are discussed to
identification of the components belonging to selected       (7) Reveal
                                                                                achieve consensus. A revote is
                                                             differences &                                               Align goals
domains is a useful input for the reverse engineering        revote
                                                                                initiated after the discussion.
                                                                                Decide on feature evolution (drop,
team. It can help them to visualize the context and to
                                                                                continue, modify)
focus their efforts on more relevant areas.
                                                                The process is currently focusing on product map-
3.2. Defining the collaborative process
                                                            ping. As discussed above this activity is essential in
    In this section we show how the discussed tasks and     reengineering-based product line scoping. However,
activities can be fit into a collaborative process based    we will include the other two activities in the process
on patterns and guidelines from collaboration engi-         after receiving further feedback from feasibility stud-
neering. In order to come up with the collaborative         ies. In the beginning of the process, possible domains
scoping process, we analyzed generic activities which       are discussed. During this activity the benefits and
are performed in traditional scoping process. We            costs of domains can be explored thereby considering
grouped and tailored those activities, according to the     domain potential analysis.
specific needs of the context under discussion. Table 1         After step 3 (converge on features & domains) the
shows the activities of the process together with their     scoping of domains is completed. Each domain can
purpose and collaboration pattern. The collaboration        then be assessed for its suitability for reuse as infra-
patterns are technology-neutral and do not assume a         structure and the benefits of doing so can quantita-
certain collaborative tool. In fact one could also use      tively be assessed. Thereby partly the activity of reuse
paper & pencil-based techniques to enact the collabo-       infrastructure scoping is also covered and the other
ration patterns in Table 1.                                 half of this activity (reusable infrastructure scoping)
    The process follows the general EasyWinWin nego-        should be timed together with reverse engineering ac-
tiation process by defining the scope of the meeting        tivity as noted earlier.
(1), gathering input from the team and organizing the
collected ideas (2, 3), getting group input of prefer-      4. Providing tool support with a GSS
ences (5, 6) and revealing and discussing situations
                                                               Group Support Systems (GSS) facilitates and trig-
where the group members do not agree (7). The results
                                                            ger interaction in team. The allow to support groups
are mutually agreed domains, features, and products,
                                                            without controlling the process in a rigid or prescrip-
scoped for reuse, based on business value, and techni-
                                                            tive way. GroupSystems is a commercially available
cal feasibility for reengineering.
                                                            Group System Support (GSS). It supports the modeling
of collaborative processes and provides capabilities for     its constituent tools. Figure 1 shows a snapshot of the
collaborative tasks. The success of a GSS for collabo-       activity ‘Converge on features & domains’. During this
rative processes is well documented for software engi-       activity features collected in the brainstorming session
neering tasks such as requirements definitions [7] and       are collaboratively assigned to different domains using
software inspection [3]. Selected tools relevant for our     the categorizer tool.
purpose provided include:                                        The categorizer is used by the moderator of the
    Group Outliner. This tool enables participants to        workshop on a public screen. The participants view the
create a tree-based outline. The tree provides a struc-      collected features in the brainstorming tool. The group
ture for collecting ideas. During discussions the tree       converges on a joint list of domains and features in a
can easily be modified. The tool can for example be          moderated discussion that takes the brainstorming re-
used to collaboratively work on a feature model.             sults as input.
    Brainstorming. Using this tool allows a group to
rapidly and effectively collect ideas. Experiences show
that a team of 10 people can collect 300+ ideas in 45
minutes.
    Categorizer. This tool is used to organize ideas into
different categories. Categories and the content of cate-
gories can easily be modified and moved to other cate-
gories (see Figure 1).




                                                                Figure 2. Voting result on a product map.

                                                                The GSS voting tool is convenient for quickly gath-
                                                             ering participants’ opinions and for building consen-
                                                             sus. Figure 2 shows the alternative analysis voting tool
                                                             with voting results on a product map (i.e., activity ‘as-
                                                             sign features to products’). Each participant gets an
                                                             electronic ballot to enter his preferred mapping. Later
                                                             on the tools highlights situations where people could
                                                             not agree using red cells. By considering the reasons
                                                             for disagreement stakeholders reveal hidden assump-
  Figure 1. Converge on features & domains                   tions and share knowledge in the team.
              (GSS Categorizer)
                                                             5. Conclusions and Further Work
    Alternate analysis. This tool provides voting capa-
bilities allowing a team to evaluate different alterna-         Product line scoping is an important activity with
tives against an arbitrary number of criteria. The tool      serious economical and technical implications. Scop-
also has powerful features to reveal situations in which     ing is necessary for both developing a PL from scratch
a team of stakeholder can not agree on an issue. This        and for reengineering-based PL adoption. However, in
capability supports building consensus in a team.            the latter case the focus lies more on the technical con-
    We conducted an internal prototype study using the       sideration of the assimilation of different products,
tools for a preliminary evaluation of our initial process.   domains, and features into one integrated infrastruc-
Our case study is the open source project management         ture. Due to the distributed nature of the knowledge
tool Ganttproject for which we started the definition of     necessary for scoping, a collaborative approach is re-
a product line. We performed the scoping exercise as         quired.
outlined in this paper. We wanted to find out whether           There exist few consolidated approaches which can
knowledge required at different steps of our process         guide the scoping process. We presented in this paper
can be presented in a structured manner using GSS and        such an approach which combines good practices of
PulSE, EasyWinWin, and collaboration engineering.                    tained Success with Group Support Systems”, Journal
The approach facilitates stakeholder involvement col-                of Management Information Systems, 19(4), 2003, pp.
laboration, a practice advocated by agile methods. Pre-              31-63.
liminary experience indicates that our approach is use-       [9]    P. Clements and L. Northrop, Software Product Lines:
                                                                     Practices and Patterns, SEI Series in Software Engi-
ful in supporting reengineering scoping process.                     neering. Addison-Wesley, August 2001.
    The need for our work is confirmed by reports on          [10]   G.J. de Vreede and R.O. Briggs, “Collaboration Engi-
lessons learned when introducing product lines in in-                neering: Designing Repeatable Processes for High-
dustry. For example, Ebert et al. [12] report that a clear           Value Collaborative Tasks”, in the Proceedings of the
business focus, strong release planning, and require-                38th Annual Hawaii International Conference on System
ments management are essential for the success of                    Sciences(HICSS'05), 2005.
such an exercise. In [11] Dhungana et al. underscore          [11]   D. Dhungana, R. Rabiser, P. Grünbacher, H. Prähofer,
the significance of sharing architectural knowledge                  C. Federspiel, and K. Lehner, “Architectural Knowledge
among different stakeholders in PLE.                                 in Product Line Engineering: An Industrial Case
                                                                     Study”, to appear in Proceedings of the EUROMICRO
    In the future we will conduct a complete case study
                                                                     2006 Conference on Software Engineering and ad-
to fully explain and validate the process in our ongoing             vanced applications (SEAA), Cavtat/Dubrovnik, Croa-
collaboration with a large industrial organization                   tia, 2006.
which is currently introducing a product line.                [12]   C. Ebert and M. Smouts, "Tricks and Traps of Initiating
                                                                     a Product Line Concept in Existing Products", in the
References                                                           Proceedings of the 25th International Conference on
                                                                     Software Engineering (ICSE'03), 2003, pp. 520-527.
[1] J. Bayer et al., “Definition of Reference Architectures   [13]   P. Grünbacher, C. Hofer, "Complementing XP with
    Based on Existing Systems”, IESE-Report 034.04/E,                Requirements Negotiation", 3rd International Confer-
    2004.                                                            ence on eXtreme Programming and Agile Processes in
[2] J. Bayer et al., “PuLSE: A Methodology to Develop                Software Engineering, Alghero, Sardinia, Italy, 2002,
    Software Product Lines”, 5th Symposium on Software        [14]   P. Grünbacher, M. Halling, S. Biffl, H. Kitapci, and
    Reusability (SSR’99), 1999.                                      B.W. Boehm, "Integrating Collaborative Processes and
[3] S. Biffl, P. Grünbacher, and M. Halling, "A Family of            Quality Assurance Techniques: Experiences from Re-
    Experiments to Investigate the Effects of Groupware for          quirements Negotiation", Journal of Management In-
    Software Inspection", in Journal on Automated Soft-              formation Systems, 4(20), M.E. Sharpe Inc., 2004, pp 9-
    ware Engineering, Springer, 2006 (to appear).                    29.
[4] B.W. Boehm, D. Port, and M. Al-Said, “Avoiding the        [15]   P. Grünbacher, A. Egyed, and N. Medvidovic, “Recon-
    Software Model-Clash Spiderweb”, IEEE Computer,                  ciling Software Requirements and Architectures with
    33(11), 2000, pp. 120-122.                                       Intermediate Models”, Journal for Software and System
[5] B. Boehm, P. Grünbacher, and R.O. Briggs, “Develop-              Modeling (SoSyM), 3(3), August 2004, pp. 235-253.
    ing Groupware for Requirements Negotiation: Lessons       [16]   J. Knodel and D. Muthig, “Analyzing the Product Line
    Learned”, IEEE Software, 18(3), 2001, pp. 46-55.                 Adequacy of Existing Components”, 1st Workshop on
[6] B.W. Boehm and R. Ross, “Theory-W Software Project               Reengineering Towards Product Lines (R1PL’05),
    Management: Principles and Examples”, IEEE Transac-              2005.
    tions on Software Engineering, 15(7), 1989, pp. 902-      [17]   K. Schmid and M. Verlage, “The Economic Impact of
    916.                                                             Product Line Adoption and Evolution”, IEEE Software,
[7] R.O. Briggs and P. Grünbacher, "EasyWinWin: Manag-               19(4), July/August 2002, pp. 50-57.
    ing Complexity in Requirements Negotiation with           [18]   K. Schmid, “A Comprehensive Product Line Scoping
    GSS", 35th Annual Hawaii International Conference on             Approach and Its Validation”, in Proceedings of the 24th
    System Sciences (HICSS'02), Big Island, Hawaii, IEEE             International Conference on Software Engineering
    CS, 2002.                                                        (ICSE’02), May 2002, pp. 593-603.
[8] R.O. Briggs, G.J. de Vreede, and J.F. Nunamaker, “Col-
    laboration Engineering with ThinkLets to Pursue Sus-

				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:6
posted:4/18/2012
language:English
pages:6