improving the efficiency of use of software engineering practices using product patterns

Information Sciences 180 (2010) 2721–2742

Contents lists available at ScienceDirect

Information Sciences

journal homepage: www.elsevier .com/locate / ins

Improving the efficiency of use of software engineering practicesusing product patterns

Maria-Isabel Sanchez-Segura *, Fuensanta Medina-Dominguez, Antonio de Amescua,Arturo Mora-SotoComputer Science Department, Universidad Carlos III de Madrid, Avda. De la Universidad, 30, 28911 Leganés, Madrid, Spain

a r t i c l e i n f o

Article history:Received 1 October 2008Received in revised form 22 March 2010Accepted 24 March 2010

Keywords:Product patternsCollaborative projects developmentCollective knowledgeProcess usabilitySoftware assets reuseProducts reuse

0020-0255/$ - see front matter � 2010 Elsevier Incdoi:10.1016/j.ins.2010.03.028

* Corresponding author. Tel.: +34 91 624 94 21; fE-mail addresses: [email protected] (M.-I. S

[email protected] (A. Mora-Soto).

a b s t r a c t

Low efficiency of use of software engineering best practices and poor quality of the prod-ucts developed are two of the main reasons for the failure of software projects. This paperdescribes an architectural model, based on the re-use of process and project assets sup-ported by collaborative mechanisms, which improves the efficiency of use of software pro-cesses; and a set of quality parameters under validation. This model was implemented inreal software projects.

� 2010 Elsevier Inc. All rights reserved.

1. Introduction

For over a decade experts have expressed the need not only for process improvement but also to demonstrate its benefits[2,16,62,63]. In the past few years, research and practice in process improvement have shown benefits such as cost savings,productivity increase, schedule accomplishment, quality improvement and customer satisfaction [49,62]. But, despite all theefforts made in software engineering, 66% of 13,522 software projects reviewed failed [64,70] because of poor project man-agement, low usability of software processes and little use of software engineering techniques.

These problems affect the whole software development industry and failure to deal with them properly leads to a wasteof time, money and effort for organizations.

In studying how to solve the low efficiency of use (one usability parameter) of software processes and techniques in soft-ware projects, we identified three main problems organizations face when they want to implement software engineeringbest practices and process improvement initiatives:

� Problem 1: They experience some difficulty expressing in a simple and practical way, how advanced their organization’smaturity level is [36,50].� Problem 2: The time required to deploy a software process improvement plan can take many years [7,62].� Problem 3: There are certain limitations in representing experience in processes and products generated [57,61].

. All rights reserved.

ax: +34 91 624 91 29.anchez-Segura), [email protected] (F. Medina-Dominguez), [email protected] (A. de Amescua),

http://dx.doi.org/10.1016/j.ins.2010.03.028

mailto:[email protected]




http://www.sciencedirect.com/science/journal/00200255

http://www.elsevier.com/locate/ins

2722 M.-I. Sanchez-Segura et al. / Information Sciences 180 (2010) 2721–2742

Although we believe that these three problems are interrelated, we have only focused on Problem 3. In this paper, wepresent a practical solution that gathers the experiences of processes and products and empowers their reuse, thus support-ing a team’s distributed structure.

In consequence, the low efficiency of use of processes and software techniques are resolved by achieving the followinggoal:

Goal 1: Reduce the time required to develop software products. This is achieved by implementing of a methodologicalframework for the reuse of the software process assets, based on software engineering best practices, and thetacit knowledge obtained from software project development. This framework supports the actual structure ofsoftware development teams.The following goals will also be achieved as a result of implementing the solution proposed in this work:

Goal 2: Improve several quality parameters of software products, using our reuse based solution (product patterns) as abasis of knowledge management, and a collaborative web portal to develop the software projects.

Goal 3: Decrease the rework of software products obtained from developing software projects, thanks to improve-ment in communication among team members and the transfer of the knowledge gathered in productpatterns.

We have combined software engineering best practices, reuse, knowledge management and collaborative work fields tosolve Problem 3.

Since the 1970s, a number of organizations have recognized the potential for software reuse to improve productivity andenhance the quality of the products being developed. Access to information is the basis for reuse. However, in most organi-zations, information is not accessible because it has not been previously gathered and stored, even though it is an importantasset that must be gathered for reuse, and transformed into innovation.

Reuse can be summarized as the process whereby an organization defines a set of systematic operating procedures tospecify, produce, classify, retrieve and adapt software artifacts for use in its development activities [47].

We believe that the reuse of process assets is the key to making software engineering processes and, in general, bestpractices, which imply greater productivity, more accessible. Knowledge management provides the mechanisms to gather,index, and retrieve information related to process assets. Process assets are products used or produced during the soft-ware development lifecycle. These products will be encapsulated in what we have defined as product patterns (describedin the next section), which is the element to be reused, and which will evolve through the different stages of knowledgemanagement: data, information, knowledge and innovation. In [67], a similar approach was taken to encapsulate theknowledge into patterns. The main deficiency is the pattern format proposed. We believe that a pattern retrieved fora new activity must provide the appropriate fields so that a search can be done. These fields have been added in ourproduct patterns format.

Knowledge management involves people who need to be organized so that they can to share their ideas, experiences andknowledge. The scenario becomes more complex when members of a software development team are geographically dis-persed, not only across a country, but also worldwide; a reality today because of globalization. CMMI [18], PSP [32], TSP[33], XP [8], SCRUM [65] are some of the reference models used to organize software development teams. With the exceptionof People CMM, all these models were created to deal with processes, activities and tasks management rather than peoplemanagement. This sometimes makes it difficult for people to share knowledge [66]; team members know what they have todo, but find it difficult to communicate with each other.

In order to overcome this difficulty and to integrate team members, especially a geographically dispersed team, a no-vel approach, called Virtual Team, emerged in the 1990s [54]. A Virtual Team is a geographically distributed group inwhich the team members communicate through electronic media to carry out a task. Collaboration and the use of infor-mation communication techniques are therefore essential for virtual teams to work collaboratively and to solve tasks[11].

In spite of some of the advantages of virtual teams, such as connecting ‘‘islands of knowledge” into self-organizing teams,sharing knowledge networks of professional communities and fostering cross-functional and cross-divisional collaboration,virtual teams need a team manager trained in new team management strategies and new ways of working as well as newinformation technology (IT) systems built to support teams.

Team members should have a virtual computer environment to facilitate communication for the virtual team to be suc-cessful. The above goals are achieved, and the existing communication issues in organizations solved, through the imple-mentation of an appropriate strategy (whether working collaboratively or not), technological support and a suitableknowledge representation artifact (product patterns).

In summary, this is a practical solution for the dissemination, use and reuse of business process assets based on processes,projects and knowledge management to improve the efficiency of use of processes in projects, some quality parameters of theproducts developed and the rework time throughout the software lifecycle. The proposed solution can be collaborative or non-col-laborative. The results obtained from its use in both cases will be explained later.

This paper is structured as follows: Section 2 analyzes related works, Section 3 describes the solution proposed by theauthors, Section 4 describes the validation and finally Section 5 presents the conclusions and future work.

M.-I. Sanchez-Segura et al. / Information Sciences 180 (2010) 2721–2742 2723

2. Related works

This section discusses some works that have been proposed to achieve similar goals; they mainly deal with knowledgemanagement, software reuse and collaboration among team members. The authors briefly present related works and high-light some of their limitations.

Several works have contributed to the growth of knowledge management and representation: Semantic Web [5,13,22,48],experience repositories [8,21,23,39], wikis [17,40,43,51,70], process assets libraries [26] and electronic process guides (EPG)[10,12,37,48,49,52]. Some limitations on representing the knowledge of software engineer experts have been found in theseworks. On the one hand, they are principally oriented to storing final products (Semantic Web) or focus on the process andnot on the product (experience repositories and EPGs). We propose a product-oriented approach (product patterns) becauseit is more portable that is, tasks are inherent to methods, methodologies, etc., but the same product can be obtained fromdifferent tasks in different methodologies. For instance, class diagrams can be obtained from the corresponding task inRUP [59], XP [8], Larman Method [40]. On the other hand, the previously mentioned works, which are based on linking textdocuments (software engineering wikis and process assets libraries), do not provide either project management capabilitiesor collaborative mechanisms that allow effective feedback of project assets after their execution.

Knowledge management requires suitable mechanisms in order to reuse knowledge and access its components. In thiswork, reuse focuses on identifying the appropriate artifacts and mechanisms that permit knowledge reuse from softwareengineering experts as well as project assets developed on previous software projects. The authors propose the use of prod-uct patterns to represent the knowledge the software engineering experts provided.

Since patterns were defined by Christopher Alexander in 1979 [1], they have been widely used in many fields. Today, theyare used for many solutions in software engineering [19]. Patterns represent solutions to problems that arise during softwareproject development. The most relevant among these are architecture reference patterns [14], architecture patterns [14,58],analysis patterns [24,38,55], design patterns [25], process patterns [3,4,27,29,56,69], improvement patterns [6], configura-tion management patterns [9], collaboration patterns [19,35], and organizational patterns [15,42,63].

Except for process patterns, the others are oriented to a specific process or phase during the software lifecycle. We haveprovided a more portable solution that can be used for any product developed during the software lifecycle. The productpatterns we propose offer maximum interoperability among software processes.

We should not forget that the human factor is a key aspect to the success of software development. Successful teams arebased on a set of strategies that must be known and used by all the team members. These strategies must be updated to caterfor the actual needs of teams, especially when virtual teams (people who are geographically dispersed) might be involved.We believe that the needs of local teams are a subset of the needs of virtual teams. There are some sociological and technicalissues surrounding virtual teams that have called for specific research attention [54]. Most of the current research on virtualteams is focused on the social-emotional field, trying to solve leadership and communication problems [53,54,71]. Theseworks have shown that specialized models need to be deployed depending on the context in which a virtual team is de-ployed, and communications tools play an important role in helping teams to achieve their goals.

The tools used for the integration and deployment of virtual teams may be a combination of several existing tools,such as instant messengers, e-mail clients, intranets or even the telephone [68]. However, several efforts have beenmade to integrate all communications and collaboration tools into a single tool or framework. With this in mind, weanalyzed some software tools, focusing mainly on (the following features) knowledge management, know-how reuse,project management, software process models deployment support, collaborative development platform and knowledgesearching. A brief analysis of the technological solutions that are closest to our solution is presented below and summa-rized in Table 1.

� CodeBeamer [34] is a collaborative development platform, based on J2EE, that offers application life cycle managementfeatures for development teams. It includes the main knowledge management capabilities (through a mechanism calledwiki asset linking), and project management and information retrieval. This tool lacks knowledge management formalismbecause wikis are considered content management systems [41] instead of a formal knowledge management artefact.Although this tool is intended to support software development, it does not provide a mechanism to select a softwareprocess model for the organization and project features or an electronic process guide to perform project activities.� IRIS Process Author [51] is a visual process management system that enables collaborative authoring and tailoring of pro-

cess assets. This tool focuses on process management and offers the possibility of exporting process content and config-uration to third party tools, such as Microsoft Project, for project management. Although this application also includessome knowledge management features, it lacks knowledge reuse for the organization and project context and constraints.For know-how representation it uses templates and wikis instead of a formal representation artefact such as patterns,ontologies or a thesaurus. It also lacks software process models management, project planning and project tracking tools.� Microsoft Visual Studio Team System (VSTS) [45] is an integrated Application Life-Cycle Management (ALM) solution

comprising tools, processes, and guidance to help everyone on a development team improve their skills and work (moreand) more effectively together. VSTS presents some deficiencies [44]: (a) it provides a wizard that allows the selection ofonly two process models templates (Agile, and CMMI), but this wizard randomly selects one of the process model tem-plates whether it is appropriate for the project under development or not. Our solution defines some criteria for templates

Table 1Analysis of technological solutions.

Software tools Features

Knowledgemanagement

Knowledgereuse

Projectmanagement

Software process modelsdeployment support

Collaborativedevelopmentplatform

Knowledgesearching

CodeBeamer [30] Yes No Yes No Yes YesIRIS Process Author [46] Yes No Yes No Yes YesMicrosoft Visual Studio Team

System (VSTS) [39]Yes No Yes Yes Yes No

Select Solution Factor [53] Yes No Yes Yes No NoBORE [29] Yes Yes No Yes Yes YesOnSSPKR [28] Yes Yes No Yes No YesProKnowHow [55] Yes No * Yes Yes No YesHipikat [18] Yes No No No Yes Yes

Our Solution Yes Yes Yes Yes Yes Yes

No *: The reuse mechanism provided are very weak. Lessons learned from the use of software lifecycle activities in projects are provided.


selection. (b) VSTSdoes not provide knowledge reuse or knowledge search to execute the activities proposed in theselected process model template. (c) VSTS provides a static electronic guide. We have developed a collaborative frame-work to cover knowledge management, knowledge reuse and project management deficiencies.� Select Solution Factory [59] is a tool that connects component-based development and solution assembly. It allows orga-

nizations to manage complex software development projects and implement code and software components reuse.Although this application is intended to ease software development and deployment, knowledge management and reusefeatures are absent. This tool offers support for some modelling methods, such as SSADM and Yourdon, but lacks softwareprocess models management support.

In addition to the above tools, some research prototypes were analyzed for knowledge management, know-how reuse,project management, software process models deployment support, collaborative development platform and knowledgetracking features.

� BORE [31] is a prototype tool designed to further explore and refine the requirements for tools supporting experience-based approaches. This tool is aimed at reusing organizational experience by packaging it in experience repositories.Although this tool offers a huge functionality for knowledge management, its main flaw is project management. In spiteof presenting tasks definitions for each role, it lacks vision of the project as a whole.� OnSSPKR [30] is a knowledge management based tool for supporting software process improvement. It composes and

organizes useful process assets into an ontology-based knowledge repository. It also supports software process knowl-edge storage for retrieval. This tool does not offer project management execution functionalities or software process mod-els management, neither does it support a clear collaborative framework in spite of implementing web portals.� ProKnowHow [60] is a knowledge management based tool for supporting software process improvement. It contains for-

mal and informal knowledge in the software process database of an organization. It uses two ontologies to establish thestructure of the organization’s memory and offers project management and some search capabilities for accessing pastprocess plans and lessons learned. However, it lacks practical representation for knowledge reuse and does not offeractive electronic software process guide or a collaborative environment for project execution and management.� Hipikat [20] This collaborative tool recommends artefacts developed for a software system that may be relevant to a soft-

ware developer who is working on the evolution tasks of a system. This tool can be viewed as a system for software devel-opers to retrieve recommendations from the project memory. Hipikat has two main functions: first the tool can develop aproject memory from artefacts that were created as part of the development of a software system (e-mails, source code,forum posts and project documentation) and second, it recommends artefacts selected from the project memory that itconsiders essential for a specific task. This tool lacks project management mechanisms and does not provide an electronicsoftware process guide.

The reuse mechanisms provided are very weak.

3. Description of the solution

The solution to achieving the goals mentioned in Section 1 is to develop software projects based on process assets reusethrough product patterns, supported by web technology and/or collaborative technology. The strategy proposed, using prod-uct patterns and the web technology (wiki), was validated in PHASE II of the experiment, and the one using web technologyand collaborative technology was validated in PHASE III. Fig. 1 shows the strategy deployment model. We have identified thesteps that must be followed when using product patterns, web technology and a collaborative platform.

Fig. 1. Model proposed for the strategy.


The remainder of this section is structured as follows: Section 3.1 describes the concept product pattern, which encapsu-lates the knowledge of software products to be reused; Section 3.2 describes the wiki structure that represents processes,projects and products patterns; Section 3.3 describes the collaborative web portal; and Section 3.4 describes the strategydefined to support interaction between the team members and the framework, including an example of use.

3.1. Product patterns to encapsulate process assets knowledge

‘‘Product pattern” is a new term that comes from the Alexandrian Patterns where a pattern can be described as ‘‘a recur-ring solution to a common problem in a given context and system of forces” [1].

We selected patterns for two main reasons:

1. Patterns, from their origins, were intended for reuse.2. The environment in which a software product is developed is similar to that of a pattern; a software product is developed

in a context to solve a problem and entailing a set of forces. The terms in bold are the key elements of a pattern description.

The aim of this paper is not to describe the types of patterns in software engineering. The main difference betweenpatterns in general and product patterns is that product patterns gather the knowledge of software engineering expertsto obtain a specific software product, understanding product as anything developed throughout the whole softwaredevelopment process. Product patterns are interconnected through their entries and exits and gather the experiencein the development of the software product they represent. A product pattern is described in terms of the followingfields:

� Name: The name can be a word or short phrase related to the product pattern.� Related Pattern: Static or dynamic relationships between this pattern and others.� Initial Context: The pre-conditions under which the pattern is applicable – a description of the initial state before the

pattern is applied.� Result Context: State or configuration of the system after the pattern has been applied. Describing the positive and neg-

ative effects.� Problem: Description of the problem to be solved.� Forces: Restrictions that are classified as follows:� Kind of organization.� Kind of system to be developed.� Kind of client.� Rationale.� Solution: Static relationships and dynamic rules to describe how to achieve the objective. The solution consists of:� Process.� Development time.� Activities diagram.� Adjustment degree (very low, low, normal, high very high).� Roles: People or participants involved.


� Entries: Previously obtained products necessary to develop this pattern:� Name (text).� Kind of information (.doc, .xml. . .).� Is software configuration management going to be applied? Yes/No.� Lessons Learned: Documented experiences gathered while using this pattern in previous projects:� Name (text).� Kind of information (.doc, .xml. . .).� Hyperlink.� Templates: Templates that can be used to obtain the exit of this pattern:� Name (text).� Kind of information (.doc, .xml. . .).� Examples: One or more sample applications of the pattern.� Exit: Product obtained when the pattern is used:� Name (text).� Kind of information (.doc, .xml. . .).� Is software configuration management going to be applied? Yes/No.� Collaboration: Collaboration among product patterns or among roles during the development of a product pattern.� Capability Level: Maturity level. This is useful when the product pattern represents a product included in a software

improvement approach:� Name (text).� Level (text).� Information Resources: References and documentation (for example, books, papers) used to develop this product.� Basic Knowledge: Previous knowledge required to understand and use this product pattern. (Note: this field was incor-

porated in the product pattern format once its representation had been validated in Phase II–subphase I. So a distinction ismade between the first version of product patterns format, where this field was not included, and the second version ofproduct patterns format where this field appears).

We visualize the use of product patterns in the same way architects use their structures. Architects have a set of provenand predefined solid structures and often reuse existing ones for new projects. With software projects, the project managerdistributes the work among the team members who have to find the best way to do the tasks assigned. We propose patternsas proven structures that can be reused for new projects, taking advantage of the experience gathered while using each pat-tern from previous projects.

We have developed a catalog of product patterns, which is described later in this paper and is available online at (http://productpatterns.sel.inf.uc3m.es).

3.2. Process assets library description

This section describes the process assets library (PAL) that was developed to provide a central knowledge repository toacquire, define and disseminate the guides and the knowledge of software engineering experts which are necessary to de-velop software products.

PAL was implemented to gather the process assets knowledge of software projects in a wiki. Wikis [17,28,41] are pro-posed as tools to share the knowledge of the organizations because their features allow communication, collaborationand documentation of knowledge.

The wiki developed (http://productpatterns.sel.inf.uc3m.es) was implemented using an open source tool called Mind-touch Core. This tool gathers the product patterns catalog of the software engineering best practices and the tacit and explicitknowledge of software projects developed. Figs. 2 and 3 represent the wiki developed and its design, respectively.

The wiki is structured as follows:

Software Process Models: This section contains the software engineering software process models. Each model describesthe activities that use the product patterns as a knowledge base to develop each activity and obtain the product.Product Patterns: This section gathers the tacit knowledge of software engineering experts and contains a set of productpatterns: the analysis, design and management phases, and product patterns methodology. The product patterns formatis described in Section 3.1. The most relevant fields are the activity diagram, templates and examples.Project: This section contains the software projects developed. The wiki shows the activities developed in each project. If aproduct pattern was used to develop an activity, the name and a link to the product pattern are shown.

3.3. Collaborative web portal structure

The collaborative web portal provides the management and execution functionalities for the project under development:it allows the project manager to carry out the management processes – planning, organizing and tracking the project activ-ities, the team to develop the project and provides a site where the explicit knowledge of this project is gathered.

http://productpatterns.sel.inf.uc3m.es



Fig. 2. Wiki developed.

Fig. 3. Wiki conceptual map.



The collaborative web portal is made up of a main site consisting of the global vision and data of the project, and theworkspaces where the project activities are developed:

– The main site: The system provides a project plan listing all the activities and essential information (roles, priority, andprecedence of each activity), a notice board, a document library and a discussion forum for subjects relating to the project(Fig. 4 is an example of a main site).

– The workspaces: The system provides sites where stakeholders can work collaboratively (see Fig. 5 for an example of aworkspace). This shared site is made up of a plan of the activities that have to be performed in each phase of the project(analysis, design, and management), links to the wiki where the product patterns are, document libraries to gather theentry and exit products of each activity and virtual meetings for the stakeholders.

3.4. Strategy defined to support interaction with the framework developed: An example

As described in the ‘‘related works” section, the human factor is a key aspect for success in software development. A spe-cific strategy that meets the actual needs of the people involved in a software project is described in this work.

The strategy defined (Fig. 6) can be used in two different ways. The steps in gray must be followed when product patternsand the wiki are used; this specific deployment of the strategy was validated in Phase II of the experiment. If product pat-terns, wiki and collaborative capabilities are used, then the whole set of detailed steps must be followed; this specific deploy-ment of the strategy was validated in Phase III of the experiment. In the latter case, the strategy combines the specification ofa set of collaborative rules with reuse mechanisms, bearing in mind the different types of teams (traditional and virtual)which may be affected in software development projects.

This strategy is independent of the software process, organization type or project features and was used for/in the pro-jects validated.

Fig. 4. Example of a main site.

Fig. 5. Workspace of a project.


Before deploying the strategy, organizations must ensure that their personnel have completed/accomplished the follow-ing tasks:

– Identify the corporate processes needed to develop projects. The tacit and explicit knowledge must be elicited and encap-sulated into product patterns if this has not already been done. These patterns must be published in the corporate wikiand must be done by software engineering experts. For the validation of this paper, the authors took/this role.

– Have some experience with Gantt charts. The wizard must be implemented for the specific wiki selected and the projectmanagement tool. Our strategy provides a wizard to connect Microsoft Project with the Mindtouch Core wiki, should bothtools be needed.

– Have some experience with a collaborative tool.

The ‘‘School Management System” project, developed and validated in the SIAS Company in Mexico, describes a specificdeployment of the generic strategy (in italics), a technological environment of the deployment as well as details of its exe-cution. We selected the strategy deployment corresponding to Product patterns, a wiki and a collaborative portal because thesteps without the collaborative tool are a subset of the whole strategy.

This strategy was defined for the project manager and the development team, which included the analyst and thedesigner.

� The strategy for the project manager and the details of the project execution (in italics) follow:(1) Plan project. The project manager plans the project, defines the tasks to be developed, the schedule and roles for each

task. In order to plan the project, the project manager selects or defines the software process model and/or method-ology and decides which activities to deploy in the project. Once the activities have been defined, for each activity, theproject manager estimates the development time and assigns the roles to the team members. A specified project man-agement software is used to plan the project.

Fig. 6. Defined strategy.


‘‘School Management System”, SIAS Company.

The project manager planned the project, defined the tasks to be developed, the schedule and roles for each task, using the pro-ject management tool specified ( Microsoft Project 2007) and a project management technique called the Gantt chart. The pro-ject manager selected the Larman [40] method, which is object oriented and uses the Unified Modeling Language (UML) [46] toanalyze and design models. The project manager accessed the wiki to retrieve the knowledge on Management product patterns.These patterns were very useful to complete accurately the management activities mentioned above.

(2) Search for and instantiate product patterns. Once the project plan has been defined, the project manager looks for theproduct patterns in the knowledge base of the project and process assets of the organization and compares the con-text, problem and forces of the activity with the context, problem and forces of the product patterns. So, a mechanismmust be implemented to access the knowledge repository, and to look for the product patterns that carry out the fol-lowing rule:

If you find yourself in this context(and) with this problem(and) entailing these forces

thenmap a product pattern in your project(and) look for more product patterns


This provides the product patterns that best fit each activity. In the product patterns search, more than one productpattern for a specific activity may be found. In such a case, the project manager chooses the most appropriate productpattern by accessing the information on each product pattern in the knowledge repository and, based on his experi-ence, selecting one from among them. The following product pattern fields assist him in his decision:– Solution that provides the steps to obtain the product.– Examples of applying the product pattern.– Templates that allow the project manager to know the information required for this product pattern.– Lessons learned that provide tacit knowledge of how this product pattern was developed in previous projects.

‘‘School Management System”, SIAS CompanyThe search and instantiation of product patterns was implemented through a plug-in in Visual Basic 2006, thus adding anotherfunction to the Microsoft project planning tool. This plug-in looked for the product patterns in the processes and project assetsbase and instantiated a column with the product pattern that best fits each activity in the project plan. For this search, the pro-ject manager inserted the features of the activities: context, problem (activity) and forces in a window. With these data, theplug-in developed accessed the wiki and looked for the most suitable product patterns. The search engine used was Lucene,which is used by the Mindtouch platform helping people to browse in the Product Patterns. The proposed strategy provides awizard to connect Microsoft Project with the Mindtouch Core, providing the project manager the names of the product patternsand their links in the wiki. To instantiate the product pattern for each activity, the project manager accessed these links and,from experience, selected and instantiated the most suitable one. At that point, for each activity, the project plan containedthe activities, schedule, roles and links to product patterns.

(3) Import the project plan from the collaborative tool. The project manager imports the project plan from a collaborativetool where the project is to developed. With this data, the development team work collaboratively on the tasks andactivities in which collaboration is required. The collaborative platform selected to support the collaborative portalsmust provide the following collaborative capabilities:
– Better communication among different software projects roles.– Coordination of the activities among team members who need synchronous and/or asynchronous interaction,
regardless of their geographical location.– Integration with different systems in the organization.– Extension mechanisms through the application of programming interfaces.– Advanced search engine with many superior characteristics such as meta data management or automatic language

detection.– A familiar and user-friendly interface.

‘‘School Management System”, SIAS CompanyMicrosoft Office Sharepoint Portal Server (MOSS) was the collaborative platform selected because this tool complies with thefeatures specified in the strategy. A webpart using C# in Visual Studio 2005 was used to import the project plan from MOSSto a custom list with a Gantt view. In this way, everybody involved in the project could see the project plan.

(4) Modify the project plan. If required, the project manager can modify the project plan. In the collaborative strategydeployment, if the project plan is modified, the collaborative tool notifies the team members affected and they canaccess it to see these changes.

‘‘School Management System”, SIAS CompanyThe project manager had to plan this project twice because the ”Requirement specification” activities in the analysis phase andthe ‘‘Class Diagram” activity in the design phase were delayed. Although the project plan was modified twice, both versions werestored in the collaborative web portal. In this way, the project manager was able to check the deviation in time and cost from theoriginal project plan.In both cases, the project manager informed the team of the changes. Some team members requested a virtual meeting to clarifysome doubts about the new project plan. The project manager’s comments in the virtual meeting were published on the noticeboard as ‘‘frequently asked questions’ (FAQ).

(5) Participate in project execution. The project manager participates in the execution of the project. In the collaborativestrategy deployment, he can access and participate in virtual meetings, reply to comments and clarify doubts in dis-cussion forums, make comments on the notice board, check the state of the activities, communicate with team mem-bers, share his knowledge, etc. As the project manager can connect to a collaborative web portal at any time toparticipate in the project execution, communication with the development team is faster and more effective, allowingfull sharing of knowledge, both explicit (the project assets) and tacit (the know-how of activities and processes pro-ject), among team members.

‘‘School Management System”, SIAS CompanyThe project manager participated at all times in the execution of the project. The project plan marked a milestone for the devel-opment team because exit products were delivered after some activities were completed. The project manager reviewed these


deliverables and notified the development team of the changes made. The project manager stored the reports of the changes in adocument library called ‘‘changes”, and notified team members of the changes to their rework. She also clarified doubts throughdiscussion forums and participated in the virtual meeting to manage these activities.In this sense, the project manager was satisfied because this solution allowed her to carry out the project management and exe-cution in the same collaborative web portal. Thanks to this, she observed an improvement in communication among the devel-opment team, the consequent decrease in the rework and the reduced time in the software development.

(6) Track the project. The project manager accesses the activities and assets to keep track of their progress and checks thestatus of each activity. If there are delays in some activities, the project manager analyzes the reasons for the delayand tries to solve them, otherwise the activities have to be planned again.

‘‘School Management System”, SIAS CompanyThe project manager tracked the project through the collaborative web portal. He accessed the workspaces and checked the sta-tus of the activities (not started, started, in progress, finished). There were two delays because the client delayed a meeting oncapturing the requirements and a designer was ill. These delays were communicated, via email and the notice board, to the pro-ject manager who decided to plan the project again.

(7) Update Wiki. The project manager updates the knowledge repository with the explicit and tacit knowledge of the pro-ject developed, thus enriching the knowledge repository for reuse. The project manager is the only person whoupdates the wiki so that only verified and validated assets are published. This reuse has a positive impact on the pro-ductivity of organizations and reduces time and cost of the software project; team members obtain the knowledgeneeded to develop the activities of the project from the knowledge repository of their organization. It eliminatesthe need to look for the knowledge in books or external electronics resources, saving time and improving the produc-tivity of software projects.

‘‘School Management System”, SIAS CompanyThe data of the project gathered in the documents library of the collaborative web portal was updated in the knowledge repos-itory of the wiki. This functionality was added to the web portal through a webpart implemented in C#. The project managerclicked on ‘‘Update Wiki” to update the wiki. At that point, a new project was created in the structure of the wiki and the projectmanager added his experience in ‘‘lessons learned”. The project manager evaluated this functionality positively because he wasable to use the knowledge from previous projects in the subsequent software projects he had developed.

� The strategy for development team members is as follows:(1) Visualize the project plan. Each team member accesses the project plan and, specifically, the activities to be developed

as well as the roles and time estimated for their activities.

‘‘School Management System”, SIAS CompanyAll the members of the team, whose activities had been validated previously, accessed the Microsoft Sharepoint collabora-tive web portal (see Fig. 4). The development team could see the project plan and general information on the project on thenotice board. This view of the project was highly valued by the development team because it provided a global vision of theproject.

(2) Access workspace. Any team member can access their activities in a workspace assigned and carry out their tasks col-laboratively if the project manager so decides. In this workspace, the people involved can use all the collaborativecapabilities of the tool to develop the activity.
(2.1.) Add comments and queries in discussion forum. In this workspace a member of the team can add comments and
queries to share with the rest of the team.(2.2.) Call Virtual meetings. Team members can call virtual meetings to take decisions on the activities they have to

perform. They can also discuss the subjects posted in the forums.

‘‘School Management System”, SIAS CompanyEach team member accessed the workspace to execute the activities assigned. Fig. 5 illustrates the information needed to per-form the activities in the analysis phase.

(3) Verify the entry products needed to perform the activities. The team members have to verify whether the activity can beperformed in the order of precedence. If so, they must verify whether all the entry products needed in the activity areavailable. If they are not available, the people in charge of the activity that cannot be performed notify the team thatthey are waiting for this entry to develop their activity.

‘‘School Management System”, SIAS CompanyThe team members verified that all entry products needed to develop their activities were available. For instance, in the ‘‘UseCase Diagram” activity, the entry product is the requirements specification (http://productpatterns.sel.inf.uc3m.es/Prod-uct_Patterns/Analysis_Patterns/Use_Case_Diagram). If the requirement specification was not available, the team membersin charge of this activity were notified.

http://productpatterns.sel.inf.uc3m.es/Product_Patterns/Analysis_Patterns/Use_Case_Diagram

http://productpatterns.sel.inf.uc3m.es/Product_Patterns/Analysis_Patterns/Use_Case_Diagram


(4) Develop the activity. The team develop the activities assigned, only using collaborative functionalities in the collabo-rative strategy deployment. This collaborative solution is enhanced by the knowledge of the experts, which is gath-ered in what we called product patterns, and is readily available via the knowledge repository for all the teammembers. This is an important value our solution adds to a general solution based on a collaborative tool.

‘‘School Management System”, SIAS CompanyEach team member developed the activities assigned. Before starting each activity, the team members held a virtual meeting tocoordinate the work to be done. In this sense, the product pattern associated with each activity was used as a common guide tounderstand and develop the product. They retrieved the entry product from the entry library and developed the exit product inthe exit library, using specific tools to develop their activities. For instance, Microsoft Word was used to capture the require-ments specification. The team worked collaboratively online and offline. In this activity, a specific discussion forum was usedfor communication, two virtual meetings were held with the client and the status of the activities was updated daily. If a prob-lem arose the project manager was notified. As a result, the collaborative functionalities most frequently used were the discus-sion forum and the collaborative capabilities of the document editor (control versions and approval/reject document togetherwith the project manager’s comments).

(5) Retrieve processes and projects assets. The team can retrieve the processes and projects assets from the knowledgerepository at any time. The knowledge repository provides the tacit knowledge of the activities, examples of devel-oped projects and templates that help them to develop these activities.

‘‘School Management System”, SIAS CompanyThe development team retrieved examples of previous processes and projects assets from the wiki to develop their activities. Theinformation most valued was the product patterns fields: solution, templates and examples. They accessed the product patternswith greater frequency at the beginning as they were learning the steps using the knowledge the experts had provided. On aver-age, each product pattern was accessed 3–5 times.

(6) Update activities status. On completion of each activity, the completion percentage and status of the assets are updatedby the people in charge and the project manager is notified for his approval. Once an activity is approved, the exitproduct is published so that it is available for the activities that require it as an entry product.

‘‘School Management System”, SIAS CompanyThe development team updated the activities whenever their status changed. When the project manager approved the productobtained and considered the activity finished, the product was published so that it was accessible to the team members.

4. Using the solution in real projects: impact quantification

This section is structured into two Section 4.1 where the experiment is described and Section 4.2 where the results ob-tained after the experiment was completed are analyzed.

4.1. Description of experiment

This solution provides process assets reuse, through product patterns, supported by web technology and/or collaborativetechnology to improve the efficiency of use of software processes and some quality parameters of a set of selected softwareproducts in collaborative software projects.

In order to verify that the goals established in the introduction were met, we focused on a set of software products allo-cated for the analysis, design and management phases:

– Analysis Phase: Requirement Specification Pattern, Use Cases Diagram Pattern, Use Cases description Pattern, ExpandedUse Cases Pattern;

– Design Phase: Class Diagram pattern, Sequence Diagram pattern, Collaboration Diagram pattern, States Diagram pattern;– Management Phase: Albretch Function Points Estimation pattern, Cocomo Estimation pattern, WBS pattern, Gantt chart

pattern.

All the above-mentioned patterns were explicitly created, stored and published in the wiki (http://productpat-terns.sel.inf.uc3m.es/) for this experiment. The projects in this experiment have similar features and complexity and usedthe same set of phases and activities.

The following parameters were studied in all three phases of the experiment to validate the software products. Theseparameters are related to the goals described in Section 1:

– Development time for all the products in order to compare the time taken to develop a product with, and without, oursolution. (Goal 1)

– Requirements referenced for each use case description: This is related to the traceability of the requirements and is calledrequirements volatility. The ideal situation is for all requirements in the requirements specification document to be gath-ered on at least one use cases description. (Goal 2)

http://productpatterns.sel.inf.uc3m.es/


Fig. 7. Phases of the project.


– Number of classes in the class diagram, first and final versions. (Goal 2)– Number of methods in the class diagram, first and final versions. (Goal 2)– Number of reviews for each product generated. (Goal 3)

To validate these goals, six software projects were developed from May 2006 to April 2008 (Fig. 8). Each project wasdeveloped three times, once in each experiment phase (Fig. 7). Three projects P1, P2 and P3, were developed at Carlos IIIUniversity in Spain and three, P4, P5 and P6, at the SIAS and Alonso Software companies in Mexico. On average, all the pro-jects had the same complexity and the same expected time to develop them: six months. All the software engineers whoparticipated in this validation had between 2 and 4 years’ experience, and a Bachelor’s degree in computer science. Threesoftware engineers with different roles (project manager, analyst, designer and programmer) participated in each project.A total of 36 software engineers (SE), SE1–SE36, were assigned projects and were involved in the validation as Fig. 7indicates.

Table 2 shows how these software engineers participated in developing the projects.A brief description of the projects validated follows:

Project 1: A web system developed to manage reservations and stock-taking for the different dishes listed on the menu in a res-taurant chain.

Project 2: A web system developed to manage a funfair, including testing safety.Project 3: A web system developed to manage sports clubs. This system allows control of the club’s sports and cultural activities.Project 4: A web system developed to manage the news and advertisements in a newspaper.Project 5: A web system developed to manage schools (subjects, students, registration, etc.).Project 6: A web system developed to register the procedures of a public entity and to allow users to consult these procedures

online.

From the existing research methods in software engineering, the empirical method was used to validate our solution; firsta formal strategy was proposed and then evaluated through empirical tests in real projects.

The experimental technique, in combination with a survey, was taken from the empirical method to validate the phases ofour tests.

Table 2shows how these software engineers participated in developing the projects.

Phase I Phase II Phase III

Without product pattern With product patterns(first version)

With product patterns(final version),

With product patterns(Final version) and CSCW

Project 1 SE1, SE2, SE3 SE4, SE5, SE6 SE19, SE20, SE21Project 2 SE4, SE5, SE6 SE7, SES, SE9 SE22, SE23, SE24Project 3 SE7, SE8, SE9 SEl, SE2, SE3 SE25, SE26, SE27Project 4 SE10, SE11, SE12 SE13, SE14, SE15 SE28, SE29, SE30Project 5 SE13, SE14, SE15 SE16, SE17, SE13 SE31, SE32, SE33Project 6 SE16, SE17, SE18 SE10, SE11, SE12 SE34, SE35, SE36


Next, we describe the different phases of the experiment as well as the results obtained after their implementation:

1. Phase I: Six projects were developed without product patterns. The projects were developed exclusively by the organiza-tion between May 2006 and April 2007. They did not use the process assets library as a knowledge base or a collaborativeweb portal for the team to communicate and transfer the knowledge acquired. SE1–SE18 participated in the developmentof the six projects in Phase I. This phase was developed to gather implementation times and the set of quality parametersof the models developed (described above). The data gathered were compared with those obtained in Phases II and III; theanalysis of the results obtained is presented in Section 4.2.

2. Phase II: This phase was used to test the product patterns representation. The same six projects developed in Phase I weredeveloped with product patterns. In phase II, the project activities were developed using the strategy (Section 3.4) and theproduct patterns catalog implemented as a wiki (http://productpatterns.sel.inf.uc3m.es/). The project manager performedthe Gantt chart of the project and linked the most suitable product pattern included in the wiki to those activities basedon the problem, forces and context of the activity. In this way, each role knew what they had to do and how.This phase was performed in two subphases:� Phase II–subphase I: The first version (described in Section 3.1) of the product patterns was used to develop projects

P1, P2 and P3 t, and software engineers, SE1–SE9, participated in this sub phase. After the projects were developed,these software engineers filled in a questionnaire on product patterns format and use. In this subphase, the time toprojects development was also gathered and the quality parameters of the models developed (mentioned above) wereanalyzed.

� Phase II–subphase II: Following the suggestions of the software engineers who participated in subphaseI, a new field(Basic knowledge) was incorporated in the product patterns representation. The new version of the product patterns(described in Section 3.1) was tested in projects P4, P5 and P6, and software engineers, SE10–SE 18 participated. Afterthe projects were developed, these software engineers filled in a questionnaire on the format and use of product pat-terns. In this subphase, the time to projects development was gathered and the some quality parameters of the modelsdeveloped (mentioned above) were analyzed.

As can be seen, the software engineers who participated in Phase I participated in Phase II, but they were assigned in sucha way that they did not participate in the same project in both phases. Therefore, they did not have any previous knowl-edge of the project requirements, so this did not affect the results of the experiment.In this phase, the software engineers’ training in product patterns consisted of a 3-h face-to-face meeting for the projectsdeveloped in Spain, and two 2-h virtual meetings for the projects in Mexico. After these training sessions, the engineerswere prepared to use product patterns.At the end of this phase, software engineers were asked fill in a questionnaire (Table 3).

3. Phase III: The same six projects were developed between September 2007 and April 2008. The software engineers usedthe improved version of product patterns gathered in the process assets library through the wiki developed, the proposedstrategy and a collaborative web portal to develop software projects collaboratively, so the whole strategy described inSection 3.4 was deployed. On this occasion, the training for the second version of product patterns for use in a collabo-rative environment consisted of a 4-h face-to-face meeting for the projects developed in Spain and two 3-h virtual meet-ings for the projects in Mexico. Software engineers, SE18–SE36, participated in this phase. At the end of these trainingsessions, the software engineers were prepared to use the proposed framework. After the projects were developed, thesoftware engineers filled in a questionnaire on the format and use of product patterns format and use (see Table 3). Inthis subphase, the time to projects development was gathered and some quality parameters of the models developedwere analyzed.

4.2. Results obtained after the development of three experiment phases

All the products obtained in the second and third phases, using the wiki, the collaborative tool and the proposed strategy,were stored and later analyzed and published as examples of product patterns. Lessons learned from using product patternson real projects were also gathered for future developments.

During the execution of the projects, the software engineers’ questions on the use of the wiki or collaborative tools wereanswered. Recommendations for their improvement were gathered and will be considered in future works.

The document describing the whole experiment can be found at: http://sel.inf.uc3m.es/documents/experiment.pdfTable 3 summarizes each of the 36 responses to the questionnaires for Phases II and III. The goal of this part of the exper-

iment was to determine whether the software engineers had accepted and used the product patterns’ structure.From the analysis of the data on the representation and use of product patterns, it can be affirmed that product patterns

were highly valued (an average of 4.11 out of 5).On average, ‘‘solution” was the field software engineers most valued (4.44 out of 5). This field provides the steps to be

followed in order to accomplish the task assigned. ‘‘Templates” was next highly valued (3.67 out of 5) followed by ‘‘lessonslearned” (3.33 out of 5). The developer can use this information either as a source of information or to be more efficient.

By linking the experience of each software engineer interviewed with the values they assigned to fields: Solution, tem-plate, examples, information resource, we can affirm that:


http://sel.inf.uc3m.es/documents/experiment.pdf

Table 3Summary of the answers to the questionnaires.

Summary (average of 36 questionnaires gathered)

9 Questionnaires gatheredafter Phase II subphase Ivalidation (Product Patternsfirst version)

9 Questionnaires gatheredafter Phase II subphase IIvalidation (Product Patternssecond version)

18 Questionnaires gatheredafter Phase III validation(Product Patterns secondversion and CSCW)

1 The product pattern provides knowledge todevelop the activities of a software project. 1:never; 2: rarely; 3: occasionally; 4: frequently;5: very frequently

4.11 4.22 4.17

2 I required knowledge that the product patternsdid not provide. 1: never; 2: little; 3:somewhat; 4: much; 5:a great deal

1.56 1.11 1

3 How important are the following fields? 1:Unimportant; 2: little importance; 3: moderateimportant; 4: important; 5: very important

Solution 4.44 4.44 4.06Template 3.67 4 3.78Lessons Learned 3.33 3.78 3.94Basic Knowledge 2.75 2.89 2.78Information Resource 2.67 3 2.78

4 I think that the product patterns would bemore usable through web format 1: mostunlikely; 2: probably not; 3: possibly; 4:probably; 5: definitely

4.67 4.89 4.83

5 I think that product patterns training isimportant 1: never; 2: little; 3: somewhat; 4:much; 5: a great deal

4.44 4.56 4.28

6 Product patterns allow to reuse the knowledgeof others projects. 1: never; 2: rarely; 3:occasionally; 4: frequently; 5: very frequently

4 4.44 4.33

7 If you are Project manager respond to thisquestion: it is easy to choose product pattern.1: never; 2: little; 3: somewhat; 4: much; 5: agreat deal

3 3 3.17

8 If you are Project manager respond to thisquestion: It is easy to calculate estimated timeof an activity using the ‘‘solution” field of theproduct pattern (‘‘development time”) whenyou make the project plan. 1: never; 2: little; 3:somewhat; 4: much; 5: a great deal

4.33 5 5

9 If you are Project manager respond to thisquestion: The ‘‘entries” field allows to establishthe precedence among product patternstherefore among activities. 1: never; 2: rarely;3: occasionally; 4: frequently; 5: veryfrequently

4 4.33 4.33


– For the software engineers with less experience the field most valued was ‘‘solution” and at a secondary level, fields tem-plates, examples and references.

– For the more experienced software engineers the fields most valued were templates, examples and lessons learned.

From the comments in assertion 2, some of the less experienced software engineers, who participated in the validation ofthe product patterns in the Phase II–subphase I in projects P1, P2 and P3, suggested that incorporating some basic knowledgein the product pattern representation would help in the development of the steps identified in the activity diagram of the‘‘solution” field. So this field, called ‘‘basic knowledge”, was incorporated in the second version of product patterns andwas tested on the three other projects (P4, P5 and P6) developed in Phase II–subphase II. The rest of the software engineers(SE10–SE 36) did not include any comments about the incorporation of more information in the product pattern represen-tation after this improvement was carried out. After including this field in the pattern representation, in some cases, in asser-tion 2, the software engineers said that the ‘‘Information resources” field was very useful. As we have mentioned, all thesoftware engineers that participated in this experiment were given training in patterns. The value for this training was verypositive (4.44 out of 5).


In general, we can affirm that product patterns allow knowledge reuse in software projects: the software engineers af-firmed (an average of 4.67 out of 5) that product patterns must be accessible via web or at least in an electronic format.

The conclusions that we can draw from the project managers’ answers are:

– Medium level of difficulty experienced in selecting the appropriate pattern for a task. They affirmed that the more theyused the patterns, the easier it was to select them for tasks.

– Product patterns have a very positive influence on the development of the Gantt chart. Project managers affirmed that theinformation on the entries to the product pattern, exits, and time to develop the project was very useful to assign time foreach task once the product pattern had been assigned to the task.

An analysis of our goals achieved follows:Our first goal (Goal 1, Section 1) was oriented towards improving the efficiency of use of processes (measured in time

taken to develop software products). Fig. 8 shows the time taken to develop the selected products in all three phases; they-axis shows the activities of the project in ascending order of execution. It can be observed that it took the same time orlonger to develop the first few activities using product patterns because of the time needed to learn how to use product pat-terns. Product patterns provide the knowledge necessary to carry out the activities and the wiki facilitates knowledge trans-fer. Once the team developer knew how to use product patterns, it took less time to develop activities than the time neededto develop the same activities without them. The time was even reduced when the collaborative tool was used in phase IIItogether with the proposed strategy and the collaborative tools: knowledge transfer and communication and interactionamong team members improved in phase III and thus increased the organizations’ productivity.

The time required to develop an activity is only a value that, in many cases, does not reflect the quality of the productdeveloped. So, our second goal (Goal 2, Section 1) was to use our solution to improve some quality parameters of the prod-ucts developed: expanded use case diagram, classes and sequence diagrams.

We analyzed the traceability of the requirements using the use cases diagram description: volatility is related to the trace-ability of the requirements. The quality of the product developed is better when the volatility of the requirements is low orzero. The data gathered reflect that by using product patterns in Phase II, the number of requirements missed in the ex-panded use case diagram is lower than when the products were developed without them. The number of missed require-ments when the collaborative tool and the development strategy were used in Phase III did not decrease, so in this casethe improvement of the traceability of the requirements comes from the use of product patterns (Fig. 9).

Another parameter that reflects the quality of the products developed is the number of unidentified classes and methods inthe Class diagram in the first version of these diagrams. The data gathered show that the number of classes and methodsmissed while developing the class diagram using product patterns (including while using product patterns in combinationwith the collaborative strategy in Phases II and III) is lower than the number of unidentified classes and methods withoutproduct patterns (Fig. 10). We obtained this data by comparing the first version of the class diagram with the last version,which was accepted as the good one.

Another interesting fact is that the number of reviews on each product reflects the rework done during the softwaredevelopment (Goal 3, Section 1). Using product patterns, the number of product reviews due to errors or misunderstandingsis lower than the number of reviews on products developed without product patterns (Fig. 11). This means that the productsdeveloped using product patterns have fewer errors in the first versions, so the total number of reviews is lower. This solu-tion helps team members in two ways: it improves communication and provides them with the necessary information andknowledge encapsulated in the product patterns. As Fig. 11 shows, the estimation using COCOMOII passed the quality con-

Fig. 8. Average development time.

Fig. 9. Traceability of requirements.

Fig. 10. Classes and methods not identified.

Fig. 11. Average reviews done.



trol the first time it was reviewed when the product was developed using the corresponding product pattern, while two re-views were necessary when it was developed without product patterns.

The remainder of this section explains the most important feedback on our solution in real projects:Project manager:

� This role did not have any difficulty in developing the Gantt chart because this is a very common project managementtool. The most difficult step was to select the product pattern that best fits each activity to be developed when therewas more than one suitable pattern. We are working on a wizard that helps to decide which pattern to select, or evenselects a pattern automatically. One project manager was familiar with the product patterns in the wiki so he did not haveany difficulty in choosing the appropriate one for each activity.� The participation of this role throughout the project was fluent; no problems were detected regarding the use of the col-

laborative project portals as they are intuitive environments for project managers.� The lessons learned from the development of the project and the knowledge acquired were difficult for project managers

to incorporate in the wiki. However, they appreciated this step very much because of the benefits of having this informa-tion gathered and accessible for future projects. They said that because of similarities in projects their organizations usu-ally develop, this knowledge is very useful for the future.

Analyst and designer roles:

� The greatest difficulty for these roles was understanding the product pattern concept and how patterns are helpful todevelop the tasks assigned. To clarify doubts, some face-to-face sessions were needed for the Spanish projects andvideo-conference sessions for the Mexican projects. In these sessions, we explained how organizations benefit from prod-uct patterns, the strategy to develop the project, and gathering the tacit knowledge into patterns so this knowledge can beused in future projects. The people involved were explicit in their rejection of software engineering techniques for theirtasks. After explaining the benefits using product patterns and the wiki, they felt confident about working with the pro-posed strategy.� Once the survey was completed, we observed that the teams had evaluated positively the following product patterns

fields:� Solution. It provides, in an orderly and usable manner, the steps to be followed to accomplish an activity without hav-

ing to look for additional resources. So we can affirm that this field encapsulates the basic knowledge needed todevelop a product in a practical way.

� Template. It provides a set of useful templates to perform the activity. This was the most valued product pattern fieldaccording to the teams.

� Lessons learned. It provides valuable advice and real life experiences to perform the activities, thus avoiding problemspreviously encountered while performing similar activities in similar contexts.

� The teams were not reluctant to use the collaborative tool; they have positively valued the opportunity to use a collab-orative tool because little communication among team members and a global vision of the project had been an issuebefore. Thanks to the use of a collaborative tool, the teams affirmed that communication improved, it facilitated problemsolving through its communication capabilities and, for the first time, they had a global vision of the project execution.� The time the team members spent learning and adapting to the new collaborative strategy was worth it.

When validating our solution, the teams recommended some improvements or requested additional information to facil-itate the use of the solution. These recommendations and requests, and how we dealt with them are listed below.

� The teams asked us for a product pattern field showing the basic knowledge necessary to perform an activity so that any-one who is not familiar with an activity can know the previous knowledge or concepts he or she has to be familiar with.We have added a new field called ‘‘Basic Knowledge” that encapsulates previous knowledge required to use and under-stand a product pattern.� When using product patterns the teams, or some members of the teams, had problems with the embedded templates.

They asked us to include these templates in an electronic format. We have included a set of useful templates in the mostcommon electronic formats, such as DOC, TXT or XLS, in the collaborative tool and the product patterns wiki.� During the training sessions (on-line or in-person) the teams asked us to guide them in the execution of a product pattern.

We have published a set of problems and their solution in the product patterns wiki as a guide.� In some cases, certain team members were reluctant to share the knowledge across the different areas and processes of a

project. However, in the end all the members noticed the benefits of knowledge sharing through collaborative tools suchas collaborative learning, virtual meetings and collaborative problem-solving through forums and blogs.

5. Conclusions and future work

The goals of this paper were: to improve the efficiency of use of software engineering best practices, to check whether thissolution improves some quality parameters of the software products under validation and to improve communication


among the team members in order to reduce the amount of rework throughout the development of software projects. Fromthe data obtained from the validation, we can affirm that these goals were achieved. This represents one step forward toplacing software development on an equal footing with the rest of the engineering disciplines. As a result, people involvedin developing software projects can use software engineering practices more efficiently. In addition:

� The number of product reviews is reduced as less time is needed to obtain the quality of the product.� The requirements traceability improved so our solution reduced the volatility of the requirements.� The development time was reduced.

Our solution enhanced existing collaborative solutions by gathering the knowledge of the experts and the experiencesfrom previous projects in what we called product patterns. These product patterns are available through the Internet viathe framework knowledge repository. Our solution adds an important value to the existing general collaborative tool-basedsolutions.

The organizations that participated in the validation appreciate the feedback they have gathered from their own projects,and consider the reuse capabilities they incorporated in the development process very useful.

Users of product patterns have recognized that ‘solution’ as well as templates and examples are the most useful fields be-cause these fields inspire them to execute a specific activity when using patterns.

Organizations also benefitted from the rapid incorporation of new team members in the project under execution sinceknowledge transfer was facilitated, thanks to the knowledge gathered from previous experiences and published in the wiki.This reduces training time and results in cost savings for the organization.

These results are a starting point to deploy this solution in the whole organization and to measure its impact. Our solutioncan be improved if the recommendations given are follows:

� Transform the product patterns recovery wizard into a decision-support tool for project managers to perform projectactivities.� Provide patterns with a multimedia representation in the solution field.� Connect the wiki to a social network to motivate teams to add patterns, information on lessons learned or examples fields,

thus empowering knowledge transfer.

We plan to deploy our solution in other organizations to demonstrate that in solving Problem 3, we can reduce the timetaken to identify the maturity of the processes deployed in a company (Problem 1), and the time required for deploymentwill be controlled and even reduced (Problem 2). We would also like to define two more experiments: first to test whetherthe product patterns are useful for experts, and secondly to adapt the collaborative portal to be used without product pat-terns in order to measure the improvements a collaborative tool provides in the development of a software project.

As a future capability that is being incorporated into the proposed strategy, we are defining the mechanism to use socialnetworks features so that knowledge can be generated from the interaction among people working in the same, or different,organization.

Acknowledgements

This work has been partially funded by the Spanish Ministry of Science and Technology, through the TIC2004-7083 andTIN2009-10700 projects, and the Spanish Ministry of Industry through the PPT-430000-2008-54 project.

References

[1] C. Alexander, The Timeless Way of Building, Oxford University Press, 1979.[2] I. Allison, Y. Merali, Software process improvement as emergent chance: a structurational analysis, Information and Software Technology 49 (6) (2007)

668–681.[3] S. Ambler, More Process Patterns: Delivering Large-Scale Systems Using Object Technology, Cambridge University Press, 1999.[4] S. Ambler, Process Patterns: Building Large-scale Systems Using Object Technology, Cambridge University Press, 1998.[5] B. Antunes, N. Seco, P. Gomes, Knowledge management using Semantic Web technologies: An application in software development, in: Proceedings of

4th International Conference on Knowledge Capture, K-CAP ’07, Whistler, Canada, 2007, pp. 187–188.[6] B. Appleton, Patterns for conducting process improvement, in: Proceedings of Pattern Languages of Programming Conference, PLoP 1997, 1997.[7] V. Basili, G. Caldiera, D. Rombach, The experience factory, Encyclopedia of Software Engineering 1 (1994) 469–476.[8] K. Beck, eXtreme Programming Explained, Addison-Wesley, 2002.[9] S. Berczuk, B. Appleton, Software Configuration Management: Effective Team. Practical Integration, Addison-Wesley, 2003.

[10] F. Bjørnson, T. Stålhane, Harvesting knowledge through a method framework in an electronic process guide, Professional Knowledge Management3782 (2005) (2005) 86–90.

[11] T. Blomquist, M. Hälgren, A. Nilsson, Development of virtual teams and learning communities, in: Proceedings of 3rd International Conference onMultimedia and Information & Communication Technologies in Education, MICTE 2005, Caceres, Spain, 2005.

[12] N. Brede, T. Dyba, The use of an electronic process guide in a medium-sized software development company, Software Process Improvement andPractice 11 (2006) 21–34.

[13] J. Brunner, L. Ma, C. Wang, L. Zhang, D. Wolfson, Y. Pan, K. Srinivas, Explorations in the use of Semantic Web technologies for product informationmanagement, in: Proceedings of 16th International Conference on World Wide Web, WWW 2007, Banff, Canada, 2007, pp. 747–756.

[14] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern oriented software architecture, A System of Patterns, vol. 1, John Wiley & Sons,New York, 1996.


[15] J. Campbell, Interaction in collaborative computer supported diagram development, Computers in Human Behavior 20 (2004) 289–310.[16] P. Capell, Benefits of Improvement Efforts, Special Report CMU/SEI-2004-SR-010, Software Engineering Institute, 2004.[17] T. Chau, F. Maurer, A case Study of Wiki-based experience repository at a medium-sized software company, in: Proceedings of 3rd International

Conference on Knowledge Capture, K-CAP ’05, Banff, Canada, 2005, pp. 185–186.[18] CMMI SM Product Suite, 2001. Retrieved from: <www.sei.cmu.edu/cmmi/products/products.htm>.[19] J. Copplien, Patterns of engineering, IEEE Potentials 23 (2) (2004) 4–8.[20] D. Cubranic, G. Murphy, J. Singer, K. Booth, Hipikat: A project memory for software development, IEEE Transactions on Software Engineering 31 (6)

(2005) 446–465.[21] T. Dingsoyr, An evaluation of research on experience factory, in: Proceedings of 2nd International Workshop Learning Software Organizations, PROFES

2000, Oulu, Finland, 2000, pp. 55–66.[22] R. Falbo, L. Borges, F. Valente, Using knowledge management to improve software process performance in a CMM level 3 organization, in: Proceedings

of 4th International Conference on Quality Software, QSIC 2004, Braunschweig, Germany, 2004, pp. 162–169.[23] R. Feldmann, R. Carbon, Experience base schema building blocks of the PLEASERS library, Journal of Universal Computer Science 9 (7) (2003) 659–

669.[24] M. Fowler, Analysis Patterns: Reusable Object Models, Addison Wesley, 1997.[25] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1994.[26] S. Garcia, What is a Process Asset Library? Why Should You Care, Aimware Professional Services, 2006.[27] E. Garson, A Whirlwind Introduction to Process Patterns, Dunstan Thomas Consulting, 2006.[28] J. Gonzalez-Reinhart, Wiki and the Wiki Way: Beyond a Knowledge Management Solution, Information Systems Research Center February, 2005, pp.

1–22.[29] M. Hagen, V. GruhnChair, Towards flexible software processes by using process patterns, in: Proceedings of Software Engineering and Applications,

SEA, 2004, Cambridge, USA, 2004.[30] J. He, H. Yan, C. Liu, J. Maozhong, A framework of ontology-supported knowledge representation in software process, in: Proceedings of International

Conference on Intelligent Systems and Knowledge Engineering 2007, ISKE 2007, Chengdu, China, 2007.[31] S. Henninger, Tool support for experience-based software development methodologies, Advances in Computers 59 (2003) 29–82.[32] W. Humphrey, TSP(SM) – Leading A Development Team, Addison Wesley, 2005.[33] W. Humphrey, TSP(SM) – Coaching Development Teams, Addison Wesley, 2006.[34] Intland Software, codeBeamer, 2008. Retrieved from <http://www.intland.com/products/codebeamer.html>.[35] J. Isla-Montes, F. Gutiérrez-Vela, Diseño en base a patrones: Aplicación a sistemas hipermedia Colaborativos, 2004.[36] S. Kan, Metrics and Models in Software Quality Engineering, Addison-Wesley Professional, 1995.[37] M. Kellner, U. Becker-Kornstaedt, W. Riddle, J. Tomal, M. Verlage, Process guides: effective guidance for process participants, in: Proceedings of 5th

International Conference on the Software Process: Computer Supported Organizational Work, 1998, pp. 11–25.[38] V. Kodaganallur, S. Shim, Analysis patterns: A taxonomy and its implications, Information System Management 23 (3) (2006) 52–61.[39] L. Lai, A knowledge engineering approach to knowledge management, Information Sciences 177 (2007) 4072–4094.[40] C. Larman, Agile and Iterative Development: A Manager’s Guide, Addison-Wesley Professional, 2003.[41] B. Leuf, W. Cunningham, B. Leuf, The Wiki Way Quick: Collaboration on the Web, Addison Wesley, 2001.[42] S. Lukosch, T. Schümmer, Groupware development support with technology patterns, International Journal Human–Computer Studies 64 (2006) 599–

610.[43] I. Lykourentzou, K. Papadaki, D. Vergados, D. Polemi, V. Loumos, CorpWiki: a self-regulating wiki to promote corporate collective intelligence through

expert peer matching, Information Sciences 180 (2010) 18–38.[44] F. Medina-Dominguez, M. Sanchez-Segura, A. Amescua, J. Garcia, Extending microsoft team foundation server architecture to support collaborative

product patterns, Software Process Dynamics and Agility 4470 (2007) (2007) 1–11.[45] Microsoft Corporation, 2008. Visual Studio Team System. Retrieved from <http://msdn2.microsoft.com/en-us/teamsystem/default.aspx>.[46] R. Miles, K. Hamilton, Learning UML 2.0, O’Relly, 2006.[47] H. Mili, A. Mili, S. Yacoub, E. Addy, Reuse-Based Software Engineering: Techniques, Organizations, and Controls, Wiley Interscience, 2001.[48] N. Moe, T. Dyba, The use of an electronic process guide in a medium-sized software development company, Software Process Improvement and

Practice 11 (2006) 21–34.[49] M. Niazi, D. Wilson, D. Zowghi, Critical success factors for software process improvement implementation: an empirical study, Software Process

Improvement and practice 11 (2006) 193–211.[50] F. Niessik, H. van Vliet, Measurement program success factors revisited, Information and Software Technology 43 (2001) 617–628.[51] Osellus, IRIS Process Author, 2008. Retrieved from <http://www.osellus.com/IRIS-PA>.[52] M. Phongpaibul, S. Koolmanojwong, A. Lam, B. Boehm, Comparative experiences with electronic process guide generator tools, in: Proceedings of

International Conference on Software Process, ICSP 2007, Minneapolis, USA, 2007, pp. 61–72.[53] L. Plotnick, R. Ocker, S. Hiltz, M. Rosson, Leadership roles and communication issues in partially distributed emergency response software development

teams: a pilot study, in: Proceedings of 41st Hawaii International Conference on System Sciences, HICSS-41, Waikoloa, Hawaii, 2008.[54] A. Powell, G. Piccoli, B. Ives, Virtual teams: a review of current literature and directions for future research, The DATA BASE for Advances in Information

Systems 35 (1) (2004) 6–36.[55] S. Purao, V. Storey, T. Han, Improving analyses pattern reuse in conceptual design: augmenting automated processes with supervised learning,

Information Systems Research 14 (3) (2003) 269–290.[56] J. Ribó, X. Franch, Supporting Process Reuse in PROMENADE, Research Report LSI-02-14-R, Dep. LSI, Polytechnical University of Catalonia, 2002.[57] M. Rus, Lindvall, Knowledge management in software engineering, IEEE Software 19 (2002) 26–38.[58] M. Shaw, D. Garlan, Software Architecture: Perspectives On An Emerging Discipline, Prentice Hall, 1996.[59] Select Business Solution, Select Solution Factory, 2008. Retrieved from <http://www.selectbs.com/products/select-solution-factory.htm>.[60] L. Silveira, R. Almeida, Managing software process knowledge, in: Proceedings of 2nd International Conference on Computer Science, Software

Engineering, Information Technology, e-Business, and Applications, CSITeA 2002, Foz do Iguazu, Brazil, 2002, pp. 273–278.[61] J. Siviy, M. Lynn, R. Stoddard, CMMI and Six Sigma: Partners in Process Improvement, Addison Wesley Professional, 2007.[62] Software Engineering Institute, CMMI Executive Overview, 2006. Retrieved from <http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-exec-

overview06.pdf>.[63] I. Sommerville, Software Engineering, fifth ed., Addison Wesley, 2004.[64] Standish Group, Third Quarter Research Report, The Standish Group International Inc., West Yarmouth, MA, 2006.[65] K. Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004, ISBN 978-0-735-61993-7.[66] D. Stelzer, W. Mellis, Success factors of organizational change in software process improvement, Software Process: Improvement and Practice 4 (4)

(1998) 227–250.[67] V. Tavares, F. Santoro, M. Borges, A context-based model for knowledge management embodied in work processes, Information Sciences 179 (2009)

2538–2554.[68] R. Tissen, J. Page, M. Bharathi, T. Austion, Communication tools for distributed software development teams, in: Proceedings of ACM-SIGMIS CPR

Conference 2007, St. Louis Missouri, USA, 2007, pp. 28–35.[69] H. Tran, B. Coulette, B. Dong, A UML-based process meta-model integrating a rigorous process patterns definition, Product-Focused Software Process

Improvement 4034 (2006) (2006) 429–434.

http://www.sei.cmu.edu/cmmi/products/products.htm

http://www.intland.com/products/codebeamer.html

http://msdn2.microsoft.com/en-us/teamsystem/default.aspx

http://www.osellus.com/IRIS-PA

http://www.selectbs.com/products/select-solution-factory.htm

http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-exec-overview06.pdf

http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-exec-overview06.pdf


[70] J. Verner, J. Sampson, N. Cerpa, What factors lead to software project failure? in: Second International Conference on Research Challenges inInformation Science, 2008. RCIS 2008. Publication Date: 3–6 June 2008 Research Challenges in Information Science, 2008. RCIS 2008. On page(s): 71–80. ISBN: 978-1-4244-1677-6. INSPEC Accession Number: 10364857. Digital Object Identifier: 10.1109/RCIS.2008.4632095. Current VersionPublished: 2008-09-26.

[71] J. Woo, M. Clayton, R. Johnson, B. Flores, C. Ellis, Dynamic knowledge map: reusing experts’ tacit knowledge in the AEC industry, Automation inConstruction 13 (2004) 203–207.

improving the efficiency of use of software engineering practices using product patterns

Documents