Uncovering Essential Software Artifacts through Business Process Archeology

46 Pages·2013·9.87 MB·English

Uncovering Essential
Software Artifacts
through Business Process
Archeology
Ricardo Pérez-Castillo
University of Castilla-La Mancha, Spain
Mario G. Piattini
University of Castilla - La Mancha, Spain
A volume in the Advances in Business
Information Systems and Analytics
(ABISA) Book Series
Managing Director: Lindsay Johnston
Production Manager: Jennifer Yoder
Development Editor: Austin DeMarco
Acquisitions Editor: Kayla Wolfe
Typesetter: John Crodian
Cover Design: Jason Mull
Published in the United States of America by
Business Science Reference (an imprint of IGI Global)
701 E. Chocolate Avenue
Hershey PA 17033
Tel: [phone]
Fax: [phone]
E-mail: [email protected]
Web site: http://www.igi-global.com
Copyright © 2014 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in
any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher.
Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or
companies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark.
Library of Congress Cataloging-in-Publication Data
Uncovering essential software artifacts through business process archeology / Ricardo Pérez-Castillo and Mario G. Piattini,
editors.
pages cm
Includes bibliographical references and index.
ISBN 978-1-4666-4667-4 (hardcover) -- ISBN 978-1-4666-4668-1 (ebook) -- ISBN 978-1-4666-4669-8 (print & perpetual
access) 1. Reengineering (Management) 2. Data mining. 3. Knowledge management. 4. Industrial management--Comput-
er programs. I. Pérez-Castillo, Ricardo, 1984- editor of compilation. II.
HD58.87.U53 2014
658.4’038--dc23

2013025562

This book is published in the IGI Global book series Advances in Business Information Systems and Analytics (ABISA)
(ISSN: 2327-3275; eISSN: 2327-3283)
British Cataloguing in Publication Data
A Cataloguing in Publication record for this book is available from the British Library.
All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the
authors, but not necessarily of the publisher.
For electronic access to this publication, please contact: [email protected].
20
Chapter 2
Providing Automated
Holistic Process and
Knowledge Assistance during
Software Modernization
Gregor Grambow
Ulm University, Germany
Roy Oberhauser
Aalen University, Germany
Manfred Reichert
Ulm University, Germany
ABSTRACT
Software modernization remains a difficult, highly intellectual, labor-intensive, collaborative, and risky
undertaking involving software engineers interacting in knowledge-centric processes. While many tools
and several methodologies are available, current modernization projects lack adequate automated and
systematic operational process support. This chapter provides an introduction to the topic of automated
process and knowledge assistance for software modernization, giving background information on related
work in this area, and then expounds on various problems. To address these, a holistic solution approach
and guidance framework called the Context-Aware Software Engineering Environment Event-Driven
Framework (CoSEEEK) is described, which can support developers on software modernization proj-
ects, addressing such aspects as process dynamicity, extrinsic processes, process exception handling,
coordination, quality assurance, and knowledge provisioning. Subsequently, future research directions
are discussed and a conclusion is drawn.
DOI: 10.4018/978-1-4666-4667-4.ch002
Copyright © 2014, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Providing Automated Holistic Process and Knowledge Assistance during Software Modernization
INTRODUCTION process support. The intangibility of the product
represented in its source code artifacts poses a
Software applications are continuing to grow in significant comprehension challenge to software
size, with one recent study indicating that appli- engineers. To support them in their moderniza-
cations typically double in size as measured in tion tasks, various tools such as tools related to
lines of code every 4-5 years (van Genuchten & Model-Driven Architecture™ (MDA) (Mukerji &
Hatton, 2012). Size growth results in increasing Miller, 2003) from the Object Management Group
complexity and an increase in the total number (OMG), and various processes such as the (ISO/
of defects (Koru, Zhang, El Emam, & Liu, 2009). IEC 14764, 2006), Service-Oriented Migration
Over time, legacy applications continue to face and Reuse Technique (SMART) (Lewis, Morris,
additional challenges (Mens et al., 2005), in- & Smith, 2005), and eXtreme end-User dRiven
cluding increasing software maintenance costs, Process (XIRUP) (“D31b”, 2008) from the MOdel
quality assurance issues, and architectural and driven MOdernisation of Complex Systems (MO-
technological erosion (Ducasse & Pollet, 2009; MOCS)1 project can be used. Mostly, the former
Tan & Mookerjee, 2005). Software modernization are utilized for supporting the project participants’
is challenged with modernizing the language and/ individual tasks while the latter aim to help orga-
or technology used in a legacy application while nize the necessary collaboration and sequencing of
retaining its previous functionality, and as such work. However, this lack of integration may also
has a key place within the Software Maintenance be a crucial obstacle for holistic and technically
knowledge area of the Software Engineering Body supported process enactment in the software en-
of Knowledge (SWEBOK) (Abran & Bourque, gineering (SE) domain: On the one hand, projects
2004). Yet many reengineering efforts fail because and their processes are planned using abstract
they are unsystematically executed using ad-hoc process models, on the other hand the concrete
processes (Weiderman, Bergey, Smith, & Tilley, tasks are executed by different people working
1997). Various software modernization strate- with different software tools and techniques in
gies, processes, methodologies, and techniques order to manipulate a large number of different
have been developed over the years, and the artifacts (e.g., specifications, user documents,
appropriate selection, tailoring, and application source code artifacts, or tests). The tools are cru-
to a given modernization situation is dependent cial for the successful completion of the different
on many factors, including organizational con- tasks, yet their usage is neither directly connected
straints, budget, time, and resource constraints, to the process nor to each other. This promotes
experience, available competencies, risk, urgency, an ever-growing gap between the planned and
criticality, etc. (ISO/IEC 14764, 2006). Aspects the actually executed process. This disparity has
involved in modernization can include business negative effects for modernization projects and
process archaeology, process mining, business their produced software: First of all, proactive
process modeling, reverse engineering, software and reactive software quality techniques are often
architecture, model-driven software engineering, not systematically and satisfactorily integrated,
knowledge management, and static and dynamic since the actually executed operation process is
code analysis. unknown. Project planning with management
Software modernization remains a risky, dif- tools (e.g., in visual form such as a Gantt chart)
ficult, and highly intellectual process incorporating typically does not provide process governance nor
various automated and manual tasks performed by process execution support. Since quality assurance
specialized knowledge workers. The process lacks is not systematically and automatically integrated,
sufficient automated and systematic operational important quality actions (perhaps involving tools
21
Providing Automated Holistic Process and Knowledge Assistance during Software Modernization
for static code analysis, profiling, or test remedia- modernization projects, which could benefit from
tion) may not be executed in a timely fashion, and automated support for global collaboration in the
quality deterioration may go undetected. modernization processes.
An important part of modernization is recov- Towards addressing the aforementioned chal-
ering specific knowledge from existing software lenges, a tighter connection between the planned
assets. Business Process Archeology (Pérez- modernization process and concrete tooling and
Castillo, de Guzmán, Piattini, & Ebert, 2011) artifacts is desirable. To achieve this, we pursue
extracts abstract models of these legacy systems, an abstract holistic concept and implementation
including the company and the company operation framework named CoSEEEK (Context-aware
supported by this system. For example, business Software Engineering Environment Event-driven
process models, which can be quite complex and frameworK). Its main idea is the contextual,
be tied to various artifacts and should be well semantic extension of adaptable operational pro-
understood during the modernization effort by the cesses, collaboration support, and the automatic
software engineers. For this, knowledge manage- integration of SE tools, knowledge, and guidance to
ment and provisioning is also a crucial factor for be able to consistently manage how people execute
successful modernization, yet it is rarely if ever this process and manipulate various artifacts via
systematically integrated at the operational level. tools. This is illustrated in Figure 1.
E.g., knowledge may be recorded in wikis or On the abstract level, processes are specified
documents, but since it is not automatically situ- by the role of a process engineer by means of
ationally associated with source code, tools, and process models. These models contain the pro-
processes, it must currently be manually retrieved cesses to be executed as well as specifications of
by a software engineer when he or she perceives utilized artifacts, tools, roles, and additional sup-
the need and triggers a search or retrieval, and port information such as checklists. On the op-
effective and timely situational knowledge dis- erational level, there are users utilizing SE tools
semination opportunities are missed. such as IDEs, configuration management tools,
Besides these concrete problems, more general static code analysis tools, and artifacts like
issues exist caused by disparity of the abstractly specifications, source code, or checklists. Our
planned modernization process and the actually concept and system enable a direct connection of
executed process incorporating various humans, the abstract and the operational areas, integrating
activities, tools, and artifacts. Some important knowledge such as process guidance with SE tools
tasks executed within a modernization project and artifacts for concrete projects and organiza-
may not be explicitly covered by the process (e.g., tions. This is achieved by contextually extending
debugging) and therefore remain neither planned a Process-Aware Information System (PAIS),
nor traced. The same applies for dependencies which not only enables the explicit modeling of
between activities that are part of the process artifacts, tools and users, but also their direct
and others that are extrinsic to the process (e.g., connection to the activities governed by the PAIS
open issues or questions). This also has an impact (Reichert & Weber, 2012). Furthermore, via a
on the ability of the projects or organizations to sensor framework, the actual SE tools in use are
cope with process-related exceptions. These can integrated together with target artifacts connected
be of complex nature involving multiple actors, to the model in the contextually extended PAIS.
tools and artifacts, thus concealing the relation Overall, this chapter demonstrates an approach
between cause and effect. Additionally, for cost to automatically, dynamically, and systematically
and resource availability reasons, the trend towards support modernization process execution and
global software development may also affect collaboration. Required tools, knowledge, and
22
Providing Automated Holistic Process and Knowledge Assistance during Software Modernization
Figure 1. Connection of abstract and operational processes
artifacts are directly interwoven within abstractly Model-centric standards and associated model
defined processes and, in turn, operationally gov- and code-generation tooling can support modern-
erned and supported by our framework. Various ization. MDA (Mukerji & Miller, 2003) seeks to
publications from the authors and a forthcoming standardize portable and interchangeable design
doctoral thesis of Gregor Grambow are utilized, models that can be technology and platform
summarized and applied to the software modern- independent. To support model transformations,
ization domain. a Meta-Object Facility (MOF) is specified. Ac-
cording to the MDA approach, legacy systems
would have a platform-independent model (PIM)
BACKGROUND of the application or specification’s business func-
tionality and behavior that could be more easily
State-of-the-Art modernized by transforming this PIM to newer
platform-specific models (PSM) for new plat-
Modernization as a form of software evolution forms and technologies. Model-Driven Software
is differentiated from maintenance and from Development (MDSD) is broader, including both
replacement in (Comella-Dorda, Wallnau, Sea- additional alternative approaches to MDA and
cord, & Robert, 2000b), which describes various various MDSD tooling, for instance the Eclipse
modernization techniques for user interfaces, Modeling Framework (EMF) project2.
logic, and data. Software engineers involved in Various approaches to modernization include
modernization projects typically utilize a potpourri Software Evolution, Refactoring and Improvement
of various methodologies, processes, tools, and of Operational & Usable Systems (SERIOUS)3,
techniques. To provide an overall understand- which studied evolutionary software develop-
ing of the modernization undertaking, various ment techniques, tools and processes. Additional
modernization-related approaches and aspects model-driven approaches include Risk-Managed
are described. Modernization (RMM) (Seacord, Plakosh, &
23
Providing Automated Holistic Process and Knowledge Assistance during Software Modernization
Lewis, 2003) and XIRUP from the MOMOCS with other plug-ins in the context of global co-
EU-sponsored research project. operative activities. CAISE (Cook, Churcher, &
Knowledge acquisition during moderniza- Irwin, 2004) is a collaborative SE framework with
tion typically encompasses various analysis the ability to integrate SE tools and develop new
techniques. One form of categorization that SE tools based on collaboration patterns.
distinguishes the degree of internal knowledge The aforementioned approaches and tools
required is black-box vs. white-box recovery primarily focus on knowledge extraction within
and transformation. Black-box (Comella-Dorda, modernization, and lack holistic, process-oriented,
Wallnau, Seacord, & Robert, 2000a) focuses on and collaborative knowledge and quality assurance
awareness of the external component properties support for the entire modernization lifecycle.
and interfaces while white-box recovery includes
awareness and analysis of internal structures and Terminology
possibly code source when available (Weiderman,
Bergey, Smith, & Tilley, 1997). This section discusses and clarifies important
Various types of tools support knowledge terms and basic concepts that will be used through-
acquisition during modernization as described out the chapter.
in (Pérez-Castillo, de Guzmán, Piattini, & Ebert,
2011). To facilitate modernization tool interoper- • Process and Workflow: By process we
ability and data interchange, the OMG’s Archi- mean a systematic series of actions or steps,
tecture Driven Modernization (ADM)4 initiative which can involve one or more workflows,
standardizes metamodels in seven modernization- taken towards achieving some end state or
related areas. (Pérez-Castillo, de Guzman, Piattini, result that adds value to an organization.
& Avila-Garcia, 2009) makes use of ADM to By workflow we mean a more detailed se-
contextualize the data about legacy source code. ries of related tasks required to complete
MARBLE (Pérez-Castillo, 2012; Pérez-Castillo, some portion of a process, usually detail-
de Guzman, & Piattini, 2011) is an example of a ing the concrete tasks, procedures, steps,
tool that supports business process model recovery knowledge, inputs, outputs, people, and
while (Putrycz & Kark, 2007) addresses recov- organizations involved to process a piece
ery of business rules. For extracting models, the of work. It can be viewed as the partial or
use of domain-specific programming languages complete technical implementation of a
such as Gra2MoL (Cánovas Izquierdo & Molina, process.
2009; Izquierdo, Cuadrado, & Molina, 2008) has • Context / Contextual Integration: The
been proposed. The proper utilization of acquired notion of context, as used in this chapter,
knowledge plays a key role in decision-making refers to the various facts, events, and enti-
during modernization (Koskinen et al., 2005; ties that are part of a software project. They
Koskinen, Lintinen, Ahonen, Tilus, & Sivula, have in common that the projects partici-
2005). pants have to interact with them and that
For building an environment supporting col- they have an impact on each task a human
laborative work, CASDE (Jiang, Ying, & Wu, conducts as part of the process and using
2007) and CooLDev (Lewandowski & Bourguin, specific tools. Contextual integration refers
2007) utilize activity theory. CASDE features a to an integration of these tasks, the process,
role-based awareness module managing mutual the tools, and the humans with the context
awareness of different roles. CooLDev is an Eclipse to be able to incorporate all necessary and
IDE plug-in that manages activities performed important information in process execution
24
Providing Automated Holistic Process and Knowledge Assistance during Software Modernization
and make the whole project more effective typically specialized for these tasks. What is still
and efficient. missing is a holistically supportive system that
• Knowledge: In this chapter it refers to unites the various aspects of a project with the
project-, company-, or technology-specific related tasks, tools, artifacts, knowledge, operative
facts and information needed to effectively processes, and software engineers. This section
and efficiently complete the tasks a person identifies different problem areas of these crucial
must conduct during a project. Examples issues and elicits requirements for each area. To
include information about the applied de- illustrate these different problems, a practical
velopment process, the concretely used example from a software project is applied in
tooling, or specifics of the technology used. the following:
• Holistic: In the context of this chapter, the Example 1 (Software Project Problems): Imag-
term holistic is to be understood in rela- ine a company producing software. This company
tion to the entirety of a software project. suffers from problems that many companies in
Holistic project support means support that this domain share: they do not have real control
incorporates different areas of such a proj- over the approach and process of their projects,
ect as, e.g., knowledge management, qual- be they software development, modernization, or
ity management, or software development. other maintenance projects. Projects can thus not
Furthermore, holistic support means that be sufficiently monitored and controlled, result-
it also incorporates the abstract planned ing in budget, schedule, or quality deficiencies.
process as well as the concretely executed To counteract these problems, the company has
activities. introduced the usage of process models for all
projects to make them more controllable and
repeatable. However, as these high-level process
MAIN FOCUS OF THE CHAPTER models have shown to have relatively little impact
on the actual operational activities conducted in
Issues, Controversies, Problems the projects, the company has introduced a PAIS
to implement and support the process models au-
Software modernization and business process tomatically. Yet the success of this approach was
archeology are complex undertakings. Software also limited. Parts of the process models could
tools such as those previously mentioned sup- be automatically executed using workflows in
port many of the related tasks. Yet two crucial the PAIS, but these workflows were still too far
issues remain: The first is that support provided removed from the concrete tasks conducted in the
by these tools focuses primarily on automating projects. The project participants (e.g., software
certain modernization tasks such as transforma- engineers or requirements analysts) reported vari-
tion. However, despite advances, in our opinion ous issues: The activities in the PAIS were too
major software modernization projects cannot abstract and had no real relation to the real tasks
yet be fully automated and thus various manual conducted with their real SE tools. Furthermore,
tasks remain to be executed by software engineers the workflows were too rigid and didn’t allow for
like coding, bug fixing, and adjusting tests for the as hoc deviations that are usual in such a dynamic
modernization to succeed. While advanced tools domain. This also applied to problems resulting
are available, contextual support and guidance in in exceptional situations during project execution.
congruence with knowledge and process aware- Therefore, the prescribed workflows were more
ness remains unaddressed. The second crucial and more disregarded by the participants and even
issue is that tools that support various tasks are viewed as burdensome rather than helpful. The
25
Providing Automated Holistic Process and Knowledge Assistance during Software Modernization
workflows could also cover only a small part of Automated Process Governance: One problem
the work done in the projects. Many activities area is process tracking and guidance, referred to
remained unmodeled and unsupported. In addition here as automated process governance (cf. Figure
to this, the participants reported other remaining 2-1). If a project is to be executed in an effective,
issues: Often multiple people from multiple de- efficient, and repeatable manner, studies have
partments worked on artifacts that related to each shown that it should be based on a defined process
other (like an architecture specification and the (Gibson, Goldenson, & Kost, 2006). Many process
source code), but this relation was not properly models have been developed, some specifically
managed and inconsistencies emerged. The same for software modernization projects like XIRUP,
applied to the knowledge needed for each project. or other common SE process models such as
Besides some project specific wikis, there was no Scrum (Schwaber & Beedle, 2001), the Unified
management of such information and people often Process (Jacobson, Booch, & Rumbaugh, 1999),
had to spend much time in gathering or developing or the V-Model XT (Rausch, Bartelt, Ternité, &
it. Finally, as the quality of the source code was Kuhrmann, 2005). The problem with these mod-
not continuously managed and quality manage- els is that they typically exist only on paper or
ment was not tightly integrated with the process, web pages and are only used for process specifi-
the participants complained that they often had cation and documentation. Their impact on actors
to apply bug fixes or software quality measures and concrete activities remains low (Wallmüller,
under high time pressure at the end of a project. 2007). Automated support for executing such
In the following, concrete problem areas are process models is desirable. There are numerous
elicited for these common problems, Therefore, tools capable of automated workflow governance,
Figure 2 depicts these problem areas abstractly: but the automatically-assisted implementation of
a whole process model with such tools remains a
Figure 2. Problem areas in contemporary projects
26
Providing Automated Holistic Process and Knowledge Assistance during Software Modernization
challenge. Requirements for automated process process execution. These automatisms
support include the following: should, if possible, be easily configurable
for the users to avoid ‘hard coding’ proce-
• A tool or framework must be in place that dures and its associated inflexibility.
governs the process. In order to assist and • The process of creating software is very
not interfere, the tool user interface should dynamic and many factors in SE projects
remain on the sideline, not require extra ef- are not easily foreseeable. Therefore, a tool
fort, and not be cumbersome to use. This supporting that process should be able to
should be supported by easily accessible deal with dynamic situations to a reason-
user interfaces that are well integrated with able extent.
everyday work.
• The ability to cover the utilized SE process Context Integration: A second important prob-
models like those previously mentioned. lem area is contextual integration: Even if some
These processes have many different spe- automated process implementation and guidance is
cial properties that represent the nature present in a project, this does not necessarily mean
of each process. A tool or framework that that the specified and actually executing processes
aims at providing automated process en- align. The latter relies mainly on different actors
actment support must thus be capable of using different tools (e.g., requirement manage-
modeling these properties and cover the ment tools or IDEs) to manipulate various artifacts
processes to a large extent. that are crucial for the process. These activities
• The automatic distribution of human tasks and tool interactions are not directly modeled in
to the respective persons. the process models since they are too fine-grained.
• The correct execution of the modeled Thus, a dichotomy between the planned and actu-
workflows must be guaranteed by the sys- ally executed process may exist. Therefore a tool or
tem executing them. system enabling automated process support must
• Process implementation requires that an be able to deal with such contextual information
arbitrary number of sub-workflows can be with the following requirements:
connected to the activities of a workflow,
e.g., to model a number of different guided • To have access to contextual information, a
activities by different people that are part tool should be able to gather and integrate
of a development iteration of a process. information from various sources in its en-
• A system providing comprehensive sup- vironment. This should be possible in an
port for the SE process must implement automated fashion and without disturbing
the process in a consistent way, including users or other tools.
the connection of the abstract process areas • The contextual information must be pro-
(e.g., project, phase, iteration) with the op- cessed and combined to be able to gain vi-
erational workflows that directly concern able information from data that is gathered
the executing persons. in the SE environment.
• Automated process support should not cre- • To enable comprehensive process imple-
ate cumbersome extra work for the per- mentation support for SE, a system should
sons involved. Therefore, a tool aiming at be able to integrate the process contextu-
comprehensive process support should be ally into the project. Therefore, contextual
capable of easily executing automatisms data should be made available to the sys-
to support repetitive tasks associated with tem. However, this data must be usable for
27