a Knowledge Management System for Software Development Process

Proceedings of I-KNOW ’09 and I-SEMANTICS ’09 2-4 September 2009, Graz, Austria

226

TEAM – a Knowledge Management System for Software Development Process Ljiljana Stojanovic (FZI Research Center for Information Technologies at the University of Karlsruhe Germany [email protected])

Nenad Stojanovic (FZI Research Center for Information Technologies at the University of Karlsruhe Germany [email protected])

Abstract: In this paper we present a novel, semantic-based approach for supporting the software development process in a distributed environment. The approach is based on collecting and preserving knowledge used in the software development process in order to support its usage in similar cases later on. One of the main advantages of this approach is possibility to collect required knowledge automatically by observing the behaviour of a software engineer. The approach has been implemented in the TEAM software system and evaluated in three real-world use cases. Keywords: Knowledge Management, Software development process, Semantics, Context Management Categories: M.0, M.2, M.4, M.7

1

Introduction

Software development is a collective, complex, and creative effort. It requires the knowledge about the used programming language as well as the right understanding of the problem domain. To deal with complex software processes, it becomes essential to provide computer-based tools to support software developers to perform their tasks. However, the analyses show that standard software has 25 bugs per 1.000 lines of program and that the percentage of failures in software projects is about 70% (source: Standish Group, Chaos Report 2004). The causes of these failures are different, but most of them can be subsumed under the bad management of the knowledge required in the software development process. Failures in using libraries and repeated errors in compiling code are examples of mistakes that happen very often, are very costly and could be resolved just by better sharing of existing knowledge. Indeed, software development belongs to the very knowledge-intensive processes and current methods for managing knowledge in a software development process are obviously inappropriate ones. Although every software development project is unique in some sense, sharing similar experiences can help developers to perform their activities in a better way. Moreover, reusing

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

227

knowledge can prevent the repetition of past failures and guide the solution of recurrent problems. In this paper we present a new solution for managing knowledge in the software development process. In the nutshell of the approach is the usage of semantic technologies for representing and manipulating this knowledge. The main advantages of the proposed approach are: (i) exploiting and integrating existing information and collecting new knowledge; (ii) providing easy, rapid access to distributed knowledge; (iii) eliminating time and space constraints in communications through automatic provision of knowledge relevant for a given user context; (iv) stimulating people to share knowledge and to use shared knowledge. The approach has been developed and implemented in the scope of the EU TEAM project. The evaluation of the system shows clear benefits for the software development process in general. The paper is organized in the following way: in the second section we present the requirements for the knowledge management (KM) in software engineering (SE) process. In the third section our approach is presented in details. Fourth section presents the implementation and evaluation details, whereas section five contains related work. In section six we give some concluding remarks.

2

Requirements for KM in Software development process

As already explained, software development is a knowledge intensive activity and the standard knowledge management approaches can be applied as general frameworks for developing a KM solution in SE. In following we define the requirements for each of these KM phases in the SE domain (adapted from [Probst, 97]): x

Knowledge goals. Knowledge goals define the purpose of a KM system. In SE domain it means that we have to define which tasks (problems) should be resolved by the KM system.

x

Knowledge identification. This phase deals with the identification of structures (models) for representing knowledge. In SE domain it means that all possible knowledge sources (formal and informal) for the software development process must be identified and represented appropriately. The challenge is to represent very complex relations between these sources.

x

Knowledge acquisition. This phase deals with the gathering of the relevant knowledge from available sources. The challenges in SE domains are related to methods for gathering knowledge from experts in a nonintrusive fashion, i.e. by observing what they are doing.

x

Knowledge development. It consists of all the management activities intended to produce new internal or external knowledge on both the individual and the collective level. The challenge is SE domain is to develop appropriate visual paradigms for collecting knowledge.

x

Knowledge sharing/distribution. This phase deals with the efficient allocation of knowledge - i.e. how isolated knowledge can be made fruitful for the overall

228

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

organization. Since the software development process can be done in distributed teams, the challenge is the distributed architecture for sharing knowledge. x

Knowledge preservation. This is a process of maintaining knowledge important to an organization’s mission that stores knowledge/information over time and provides the possibility of recall for the future. Similarly to the previous phase, the challenge is the knowledge preservation in a distributed environment.

x

Knowledge use. This is the purpose of KM. It is the productive deployment of organizational knowledge in the working process. In SE domain the challenge is the proactive usage of knowledge, i.e. since software engineers are concentrated to some very sophisticated tasks, the better way is to bring the knowledge to them in particular situations (knowledge push) then requesting from them to interrupt the work and search explicitly for relevant knowledge (knowledge pull).

x

Knowledge Measurement. In this phase the whole KM system is evaluated. In SE domain the challenge is to determine the successfulness of the usage of knowledge artifacts, since due to very complex nature of the knowledge the causalities of the artifacts are quite complex. In the next section we present our approach for resolving these challenges.

3

TEAM System

The main goal of the TEAM system is to support capturing and usage of the knowledge and experience generated during the software development process. The general architecture of the TEAM system is presented in Figure 1. The decomposition is mainly based on functional encapsulation. The TEAM system has a modular, OSGi-based architecture, including different components, which can run separately and deliver different services. The components of the TEAM system are provided as Eclipse plug-ins. Due to Eclipse’s foundation in the OSGI Framework, Eclipse plugins are also valid OSGI bundles and can reuse OSGi framework services. The TEAM system consists of four major components: x The Context System (CS) component observes and interprets the developer’s interaction with the developing environment. Additionally, user interaction logs are analyzed by data mining techniques to predict future behaviour. x The Search and Recommendation (SR) component provides (keyword-based, structured and semantic) search functionality for the knowledge base and recommendations to solve problems the developer encounters. x The Knowledge Desktop (KD) provides the user interface for accessing the system functionality (e.g. search, recommendation) and also handles all other user interactions (e.g. configuration). x The Metadata Storage/ P2P (Peer-to-Peer) (MR) serves to store schema information and metadata of the TEAM system and handles the connection and information exchange with other TEAM systems in the TEAM network. The P2P component now included in the MR, because each other TEAM component is only concerned about storing the metadata and has no direct interaction with P2P.

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

229

Two components of the TEAM system (i.e. the CS and the KD) fundamentally depend on the Eclipse IDE platform, since the first is used to capture user’s interaction in the Eclipse developing environment and the second is embedded in the Eclipse developing environment. Additionally, the CS depends on the Operating System in order to retrieve context information. All other components are independent of developing environment. An additional user interface embedded in other developing environments (e.g. Visual Studio) could access functionality from a TEAM system, which is running as a background application. However, this case is only optional, since the TEAM system is implemented in the Eclipse IDE. Figure 1 shows the relationships of these modules. The KD is the single entry point to the integrated TEAM system enhancing the software developer’s way of working by supplying a user interface to functionalities such as knowledge acquisition (i.e. capturing knowledge), knowledge provision (i.e. creating knowledge items), knowledge usage (e.g. semantic search) etc. Thus it uses functionality provided by all other TEAM components. The KD for example, relies on the SR component in order to query and display search results.

Figure 1: Component model of the TEAM system The MR is a central TEAM component and thus involved in almost any functionality that deals with the knowledge. It offers a set of services related to the creation/removal/modification/usage/sharing of knowledge items to all other TEAM components. The CS monitors the developer’s activities during software development in order to recognize as soon as possible the need for support or the resolution of a problem. Discovery of a problem/solution is published to other components of the TEAM system that are registered for that. The communication is implemented using subscribe/publish mechanism. Currently, the SR is registered to be informed about discovered problems. To get more information about the discovered problem (e.g. used knowledge artifacts), the SR calls the corresponding services of the CS. Additionally, since a developer must be able to enable and disable at any time the monitoring functionality, the CS provides set of services for the configuration which are used by the KD. The SR provides to the KD the set of services related to the (keyword, structured and semantic) query construction and refinement. On the other hand, independently

230

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

how queries are constructed, they are executed either on the local or on the distributed storage. Regarding recommendation, the SR communicates with the KD in two different ways: a) synchronously, in the case that the recommendation is explicitly required by developers or b) asynchronously, in the case that the recommendation is automatically generated after a problem is discovered. Thus, to support this communication both the direct method calls and the subscribe/publish mechanism are implemented. Finally, the SR provides services for configuration (e.g. setting threshold) that are used by the KD. It supports all activities that comprise a knowledge process and in the rest of this section we discuss how building blocks of general knowledge management system (Section 1) are supported. 3.1

Knowledge Goals in TEAM

The goal of the TEAM project is to develop a knowledge management system to support coding phase in the software development process. The TEAM knowledge management system enables better and faster capability of sharing and exploiting knowledge related to the error handling and component reuse in the software development process. 3.2

Knowledge Identification in TEAM

In order to increase knowledge transparency the TEAM knowledge management system is built based on TEAM ontologies (http://www.team-project.eu/ documents/D9 TEAM Ontologies.pdf) that are shown in Figure 2. They facilitate communication and information exchange, support systematic access to parts of the organizational knowledge base, connect various types of knowledge, infer implicit knowledge out of existing information, improve use of knowledge, etc.

Content layer

Ont olo TEA M

Interaction layer

gy

Organizational layer

Content Ontology

Organizational Ontology

Interaction Ontology

Knowledge Artefact Ontology

Annotation Ontology

Problem-Solution Ontology

Figure 2: TEAM Ontologies To provide better support for knowledge sharing and reuse, the TEAM project combines content, interaction and organizational information. Thus, in the TEAM project ontologies are used to describe the structure and content of the knowledge

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

231

artefacts, their usage and organisation and to provide a basis for determining how artefacts are related. Different layers model different types of information: x The content layer enables to determine the structure and content of software objects, related problem reports as well as the solution for problems. x The interaction layer that builds on the content, as people interact to participate in activities around the code (e.g. software development or problem resolution) describes the structure of interaction. x The organizational layer describes people, various roles they assume within the organisation, the projects they are involved in, teams performing the tasks, etc. The content layer consists of several ontologies. The goal of this distribution has been to force modularity in order to use these parts independently: x the knowledge artefact ontology - describes different types of knowledge artefacts such as the structure of the project source code, the components to be reused, software documentation, knowledge already existing in some tools, etc.; x the problem/solution ontology - describes the problems that may arise during coding and how they are resolved; x the annotation ontology - describes general software development terminology as well as the domain specific knowledge. The main purpose of the interaction layer is to observe user interactions with the system and to infer meaningful context information based on this – e.g. about the current activity of a developer or if the developer needs assistance. This has been modelled using the Interaction ontology. No knowledge flow can occur outside a shared organizational context, in which the work on artefacts is embedded. If this context is misinterpreted, the meaning that has been understood by a consumer/user and the intended meaning might differ significantly. The organizational context is formed by all organisation aspects including people, infrastructure, projects, etc. The semantics of the organizational layer is captured in the Organisational ontology. We note here that the TEAM ontologies model formal and informal knowledge related to software development process in a machine understandable form, which enables provision of a qualitatively new level of services, such as gap analysis. Additionally, TEAM does not intend to replace existing artefacts, but to help augmenting and leveraging the existing knowledge. A key enabler for this is the monitoring of developer's interactions inside their working environment, which is essential for realizing context-aware knowledge management system. 3.3

Knowledge Acquisition in TEAM

Role of the SR in knowledge acquisition One of the roles of the SR component is to automatically create initial knowledge base by “importing” already existing information into the TEAM system. The TEAM system does not replicate existing information, but rather provides explicit model. Indeed, introducing an ontological representation enables us to “understand” parts of the semantics conveyed by these artefacts and to establish additional traceability links among these artefacts and the software artefacts.

232

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

Knowledge acquisition is done by: - extracting metadata about knowledge artefacts (e.g. method identification) from structured content (e.g. code structure) and from natural language text (e.g. comment in code); - linking knowledge artefacts - having generated metadata for various kinds of artefacts, it is necessary to relate them semantically. For example, identifying concepts that appear in issue reports is essential for knowledge management support that the TEAM system aims to provide. Certain concepts, such as method names and log messages, are likely to appear in issue/bug reports and provide valuable hints about the code that is involved in producing the bug; - annotating knowledge artefacts by using a unified vocabulary, i.e. the Annotation ontology (see Figure 2) that ensures unambiguous communication. In this way the TEAM system is able to automatically acquire existing knowledge that could be useful for the TEAM most important tasks (e.g. error handling). The proposed solution does not require human processing/understanding, and more importantly provides support for integration. Role of the CS in knowledge acquisition The CS component addresses knowledge acquisition task by providing the TEAM system with powerful concepts for self-management [Kephart, 03]. It: - collects data about users’ interaction with IDE and enriches this data with semantics based on underlying ontologies; - analyses the semantically-enriched data using data mining methods; - creates a plan of action in a form of rules that are results of data mining methods; - executes these rules in order to discover whether a developer needs support, wants to share knowledge, etc. -

-

Knowledge acquisition is done in two modes: on-line acquisition of problem/solution knowledge through interpretation of an aggregated sequence of interaction data to a higher context (e.g. discovery of a problem) based on (i) developer’s interaction with IDE and (ii) the application of learned rules; off-line acquisition of learning rules that help in detecting problems encountered by developers.

In that way, the TEAM knowledge management system tends to be a userfriendly platform that captures information from the work process and automatically interprets it without extra effort for developers. By capturing interaction data, we avoid asking the developers explicitly since they tend to be reluctant to provide the feedback via filling questionnaires or forms. Additionally, the CS component integrates the results from the analysis of the usage data with the methods that guide the process of knowledge acquisition, which means that a kind of a “usage loop” is created.

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

3.4

233

Knowledge Development in TEAM

The TEAM system supports individual knowledge development as well as collective knowledge development. The KD component of the TEAM system provides a powerful user interface for developing knowledge. The KD focuses on interacting with the basic objects of the knowledge base, i.e. individuals and their relations (both data and object properties). The metadata development needs guidance from the ontologies. In order to allow for sharing of knowledge, newly created metadata must be consistent with the TEAM ontologies. Several modes of putting knowledge into knowledge base are supported: x manual metadata development: the TEAM ontologies are used in order to guide developers towards creating relational metadata. The KD component supports manual metadata development by dynamically creating dialogs whose content is generated based on an entity from the TEAM ontologies; x dynamic metadata development based on user behavior: Some metadata is set automatically based on the user’s contribution in creating knowledge base. For example, based on the number of positively assessed solutions defined by a user or frequency of the usage of his/her solutions, the value for the expertise level for this user property will be set. x implicit metadata development based on the application of rules: One of main advantages of using ontologies is reasoning, which enables creation of new, implicit information. An example is that, a user who wrote a frequently-used and positively assessed solution for a problem about a SE artifact is an expert for that artifact. x ontology extension: Besides of creating metadata, the developers are able to extend the Annotation ontology. Thus, ontology extension is also supported. 3.5

Knowledge Distribution in TEAM

The TEAM system fosters knowledge sharing. It occurs within communities of practice and interests (represented as P2P network), which can help speed up the learning curve. From a technological point of view peer-to-peer solutions are particularly well suited for knowledge sharing, because they make it possible for different participants (organizations, developers, or departments) to maintain their own knowledge structure while exchanging information. The P2P TEAM network is shown in Figure 3. From the functional point of view, the TEAM system supports three types of knowledge sharing: x knowledge pull: making local knowledge accessible to others who might be interested in it. The MR component is able to publish knowledge artefact stored in a private (local) storage into the public (distributed) store and to revoke it. Knowledge stored in the distributed part of the MR is available over the network by using the P2P services. x knowledge push: generating recommendation for resolving a problem discovered by the CS. This is done in an automatic way based on the solutions for that kind of problem or similar problems whose solution already exist in the repository.

234 x

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

inverse search: suggesting peers to share knowledge that other peer asked for. The SR component of the TEAM system recommends developers to share certain private information. Thus, developers receive actual information on the benefit of their effort.

Figure 3: Peers in a TEAM network with local (private) and public knowledge base 3.6

Knowledge Use in TEAM

To gain developer acceptance, the TEAM system is integrated into the software development organization’s process, allowing collecting and storing relevant knowledge as they are generated in the work. The main advantage of integrating knowledge management into an IDE is that knowledge management is put into software engineers’ workflow, since software development activities occur inside the computational environment rather than in the external world. Consequently, the TEAM system, i.e. the KD component that is the user interface for the TEAM system, is also integrated to the existing work environment. While TEAM develops a general framework for KM in IDEs, its prototype implementation is done for the Eclipse IDE. However, other environments can be used. The crucial part of the KD is the wiki. Its purpose is to provide assistance to software developers in accomplishing their tasks in a more flexible fashion and shorten their total effort in terms of time. In order to achieve this goal, the KD approaches software development documentation and related problem solving by combining lightweight yet powerful wiki technologies with semantic web standards. We chose wikis for their significant support in knowledge articulation by providing lightweight and flexible mechanisms as well as semantics in order to add structured formulation to the wiki contents. This combination gives software developers the opportunity to capture their knowledge related with a software development artefact exploiting a structured formalism. This knowledge will be then reusable, more easily shared and retrieved in the future by the semantic wiki’s resilient user interface.

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

3.7

235

Knowledge Preservation in TEAM

As shown in Figure 4, in the TEAM project we distinguish between local (private) knowledge, which is not available to others and public (distributed) knowledge which is available to others via the TEAM P2P network. The MR component addresses the issues of storing all knowledge. Whereas it ensures central control, standardization, high capacity, and robustness, the P2P part of it is viewed as a way of enabling distributed control, differentiation, customization, and redundancy. Regarding the local knowledge, the MR provides a consistent and reliable means of access to local knowledge. The local store consists of: a) T-Box, i.e. TEAM ontologies that represent schema (terminology) for representing knowledge; b) A-Box, i.e. metadata that represent instantiations of the entities defined in the TEAM ontology and c) Rules, i.e. axioms and general rules (e.g. for discovering a problem that a developer has during coding).

4

Evaluation - Knowledge Measurement in TEAM

We have performed two types of evaluation of the usability of the TEAM system. The formative takes into account the easiness to capture, develop, use, share and preserve knowledge artifacts. On the other hand, the summative evaluation focuses on the importance of knowledge artifacts and how they fit with the company’s goals. Since we are lacking of space, we will present only the highlights from the formative evaluation that are directly related to the advantages of the system we mentioned in the introduction. We consider the scenario-based evaluation in which a scenario describes sequences of actions taken by a user with a specific goal in mind. To maximize the benefits of this method, we prepared questionnaires that end users had to fill out in order to reflect on their experience with TEAM system. The process was performed in a 2 hours online session (in total 3 sessions took place) using an electronic collaborative platform (CENTRA) where representatives three software companies with the guidance of the technical TEAM people used the TEAM system to complete certain tasks as described in predefined scenarios, i.e. how to find software components that should be reused, how to annotate code, etc. Users are, in general, very satisfied with the system. Remarks are, as usual in the case of new technologies, related to usability issues. We present here the results from the evaluation of the scenario “Resolve an error”, which is related to the resolution of an error in a coding scenario that is based on the usage of a (rather complicated) class library. The system’ provided benefits in this scenario are: 1) proactively avoiding errors by suggesting the user the best practice in using that library (in a non-intrusive way), 2) support in finding the root-causes of the error and its repair and 3) extending the knowledge base automatically after the error has been resolved. We measured the effectiveness of each of them, expressed in terms of: a) percentage of accepted suggestions (objective measure), b) percentage of useful, but accepted, suggestions (subjective measure: yes - no) and c) ease of usage (subjective measure, scale 1-10). For the subjective measure users were asked to provide an answer. The results are presented in Table 1.

236

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

Metrics: Objective: Avoid errors Repair errors Extend knowledge base

accepted suggestions (%) 66% 86% 91%

useful suggestions (%) 85% 78% 85%

ease of usage(average) 8.4 5.2 8.3

Table 1: Evaluation results Discussion: The percentage of accepted suggestions is quite high, except for the “Avoid errors”: an explanation is that our system is too sensitive and provides suggestions for information about classes when it is not necessary. On the other side, the ease of usage is quite high. The usefulness of accepted suggestions is high for all three cases. The ease of usage in “Repair errors” is rather low since it performs a kind of root-cause analysis which for an un-experienced could be difficult to understand.

5

Related work

There are several approaches for managing knowledge in SE. In this section we give a short overview of some of them. The Knowledge Dust to Pearls approach [Basili, 01] combines and makes use of benefits both from the AnswerGarden (which represents Knowledge Dust) and the Experience Factory (which represents Knowledge Pearls). It captures the knowledge dust that employees use and exchange on a daily basis and immediately, with minimal modifications, makes it available throughout the organisation. This process is accomplished by creating a system that supports peer-to-peer activities; i.e. the employees of the organisation help each other and fulfill the short-term return goals of a knowledge capturing and sharing approach. The Knowledge Dust to Pearls approach is influenced by the ideas of the Quality Improvement Paradigm (QIP) which provides a model for process improvement in software organisations. QIP uses the notions of continuous improvement and iterations as the main vehicle for planning, executing, evaluating, and improving processes. The backbone of the Knowledge Dust to Pearls approach is the Experience Factory which establishes a learning organisation. The Experience Factory is, however, a sophisticated approach that satisfies an organisation’s long-term needs of sharing experience. The Experience Factory [Basili, 94] is a framework for the implementation of the Quality Improvement Paradigm. The Experience Factory enables organisational learning and professes the need of existence of a separate support organisation. The role of the support organisation is to support the project organisation in order to manage and learn from its own experience. A complementary approach that satisfies the short-term needs of an organisation is the AnswerGarden approach [Ackermann, 90]. Holz presents in [Holz, 03] a detailed life-cycle model for POKM (ProcessOriented Knowledge Management) that is specific to software development

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

237

processes. This life-cycle model for Software Engineering Process-Oriented KM (SEPOKM) is integrated into the life-cycle model performed by the organisation’s Process Group and becomes an essential part of a continuous organisational learning process. The main advantage of our approach is the usage of ontologies for the formalization of the SE knowledge and the context-awareness in order to personalize the delivery and usage of knowledge.

6

Conclusion

In this paper we presented TEAM knowledge management system which supports developers during the software development process to produce better quality software. Although benefits can be derived from individual tools addressing separate software development activities, the real power of the TEAM system lies in supporting the whole knowledge management process. Indeed, TEAM can be considered as integrated collections of services that facilitate software development activities by applying knowledge management paradigm in capturing, storing, disseminating, and reusing knowledge created during software process as well as in integrating existing sources. The backbone of the system are TEAM ontologies which define the shared vocabulary that is used to facilitate communication, search, storage, and representation. The ontology-background of the TEAM system enables to move from a document-oriented view of knowledge management to a content-oriented view, where knowledge artefacts are interlinked, combined, and used. Furthermore, the TEAM ontologies constitute the glue that binds the TEAM components together. Since all knowledge handled have a formal meaning (semantics) associated, it is accessible not only to human developers, but also to automated components/tools. The future work will be oriented toward expanding the collaboration between knowledge distributed between peers by using distributed complex event processing

References [Ackermann, 90] Ackerman, M. S. (1990), Answer Garden: A Tool for Growing Organizational Memory, Conference on Office Information Systems, COIS90, Cambridge, Mass. [Basili, 01] Basili, V.; Costa, P.; Lindvall, M.; Mendonca, M.; Seaman, C.; Tesoriero, R.; Zelkowitz, M. (2001) ,An experience management system for a software engineering research organization, Proceedings of the 26th Annual NASA Goddard Software Engineering Workshop. [Basili, 94] Basili, V. R., Caldiera, G., and Rombach, D. H. (1994), The Experience Factory, Encyclopedia of Software Engineering - 2 Volume Set, Wiley, pp. 469-476. [Holz, 03] Holz H. (2003), Process-Based Knowledge Management Support for Software Engineering, Doctoral Dissertation, University of Kaiserslautern, dissertation.de Online-Press. [Kephart, 03] Kephart, J., Chess, D., The Vision of Autonomic Computing, IEEE Computer, pp. 41-50, January 2003

238

L. Stojanovic, N. Stojanovic: TEAM – a Knowledge ...

[Probst, 97] Probst, G.B., Practical knowledge management: a model that works, Prism, No. second quarter, pp.17-33, 1997. [Watts, 05] Humphrey, Watts S. (2005), PSP: A Self-Improvement Process for Software Engineers, ISBN: 03213054931.