[AISWorld] Call for Papers: Software Product Lines: Engineering, Services, and Management minitrack at 48th Hawaii International Conference on System Sciences (HICSS)

[Käkölä Timo]

Call for Papers

Minitrack for

Software Product Lines: Engineering, Services, and Management
at
48th Annual Hawaii International Conference on System Sciences
January 5-8, 2015 (Monday through Thursday)
Grand Hyatt, Kauai, U.S.A.
http://www.hicss.hawaii.edu<http://www.hicss.hawaii.edu/>
by
Timo Käkölä                                     Andrea Leitner
University of Jyväskylä, Finland         Graz University of Technology, Austria
       timokk at jyu.fi                                andrea.leitner at tugraz.at

Software has become the key asset for competitive products and services in all industries. Thus, competiti­veness in software development, maintenance, and related ser­vices has become a concern for organiza­tions. Competitiveness can be increased through (1) internal strategies such as the strategic crea­tion and reuse of softwa­re assets and (2) external strategies such as outsourcing software de­velopment, maintenance, and/or services from third party service providers and acquiring off-the-shelf components from providers and open source communities. A viable third strategy is to develop both strategies in parallel. This minitrack focuses on the first and third strategy.

Software product line engineering (SPL) is an in­dustrial­ly-validated methodology for developing soft­wa­re-in­tensive systems and services faster, at lower costs, and with better quality and higher end-user satis­faction. It differs from single system development, as:
1.     It needs two development processes to work optimally: do­main engi­neering and application enginee­ring. Do­main engi­neering defines and realizes the commo­n and variable features of the product line by estab­lishing a common software platform. App­lication enginee­ring derives applications by exploiting the com­mo­na­lity and binding varia­bility built into the platform.
2.     It needs to explicitly define and manage varia­bili­ty. During domain engineering, variability is intro­duced in all as­sets such as requirements, architec­tu­ral mo­dels, components, and test cases. It is used during application engineering to mass-customize applications to the needs of customers.

The software product line engineering body of knowledge has mainly been created to enable industrialized software production. However, the extant software product line body of knowledge has not yet been integrated well enough with other rele­vant bodies. For example, substantial and long-term product portfolio planning, organizational learning, and investments are typically needed in corporations to fully adopt and leverage the product line strategy by establishing the common set of product line assets, building products from it, and having supportive processes and organizational structures in place. The product line strategy also tends to involve geographically distributed work in multiple sites and projects by a network of internal organizational units, external service providers, and open source communities. The work is knowledge-intensive and the assets to be created and reused involve types of knowledge such as business process models which are far more versatile than the software components that have been the focus of earlier reuse efforts. The network needs to be carefully orchestrated and the relevant knowledge needs to be identified, stored, and shared amongst the appropriate stakeholders. When open source communities take substantial respon­sibility for platform development, the leadership of the network becomes increasingly distributed and emergent. The control of any one stakeholder over the network and the produced assets will thus diminish, making product line planning and management ever more challenging. Finally, the products need to be serviced throughout their life-cycles and comprehensive service systems need to be built to increase customer satisfaction, generate new revenue streams, and to ensure that the feedback from the customers is effectively leveraged in improving the product lines.

The business, leadership, economic, organizational, process, service, and knowledge manage­ment related issues have not been systematically and comprehensively investigated from the viewpoint of software product lines. For example, product lines are seldom viewed in the literatu­re as services to customers that require the design of dedicated service systems. Organizations may fail in leveraging the product line strategy partly because the extant body of knowledge provides them with limited and fragmented guidance for adopting and enacting the strategy.

This minitrack welcomes contributions to the mainstream product line body of knowledge. To help integrate new bodies of knowledge in product line research and practice, the minitrack also welcomes contributions including but not limited to

  *   Business models and socio-technical ecosystem strategies for producing product lines
  *   Economic valuation of product lines
  *   Ecosystem, organizational, and process designs for product lines
  *   Distributed leadership in developing open source platforms and product lines
  *   Knowledge management practices and systems for product lines
  *   Service systems and their implications for product lines
  *   International standardization initiatives related to product lines
  *   Theory building and/or validation from the viewpoints of design and behavioral science
The minitrack is also interested in industrial experiences in product line engineering if they can be used

  *   to support academic and/or industrial courses on software product line engineering and/or
  *   to validate or challenge existing theories and/or create new theories relevant to the software product line engineering body of knowledge.

Deadlines for Authors
*         Before June 15: A one page abstract as an indication of interest is encouraged
       June 15: Submit full manuscripts for review as instructed. The review is double-blind; therefore, this initial submission must be without author names.
*         August 15: Acceptance/Rejection Notices to authors. It is very important that at least one author of each accepted paper register and attend the conference.
*         September 15: Submit final paper.
*         October 1: Early Registration fee deadline. At least one author of each paper should register by this date to secure publication in the Proceedings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aisnet.org/pipermail/aisworld_lists.aisnet.org/attachments/20140430/9c4091c1/attachment.html>