Skill management in software engineering

Transcription

1 Skill management in software engineering Paolo Predonzani, Giancarlo Succi ƒ, Tullio Vernazza Dipartimento di Informatica, Sistemistica e Telematica, Università di Genova, Genova, Italy Department of Electrical and Computer Engineering, The University of Calgary, Calgary, Canada Abstract Allocation of people is a crucial point in the success of software projects. Several techniques have been proposed to manage them in an optimal way, yet, when it comes to do the actual allocation, several constraints occur. The constraints regard the limited human resources and skills available in a firm and the possibly large number of projects that must be handled at the same time. The paper presents a technique to make allocation of people automatic at project level allowing all the constraints that may occur. Allocation takes into consideration skills: activities and roles require skills; people have actual skills. The technique to find a good assignment is based on flexible matching of skills between people and roles. Sub-optimal allocations are supported as required by real situations. 1 Introduction Project managers and resource managers face the problem of allocation of people to projects. The allocation process needs to be efficient and produce satisfying results for both people and the firm. Project managers and resource managers look at the resources required by the project and at the resources available in the firm: sometimes free resources are assigned to the project and sometimes resources already allocated are rearranged and moved from one project to another. Interchangeability of people plays a significant role in this process. Project managers and resource managers need a way to visualize the required and available resources and to evaluate "how good" an allocation of resources can be. An automatic technique and tool are very useful to make this process efficient and easy. The proposed technique starts with an analysis of skills both from the perspective of what is required by the activities and from the perspective of what is offered by the human resources. Then it seek a matching between the two perspectives. External and internal factors put constraints on this matching process. These factors are related to the fact that resources are limited, shared, and frequently already in use. Allocation of people is performed through a flexible matching of the roles people have and roles require. Skills are related to each other through a network which allows to replace a required skill with a similar one if the required skill is not available directly. Software industry still lacks a well defined and accepted set of activities, roles, and skills. Some successful practices exist but are not widespread. The proposed technique has proven very practical to manage skills in software firms because of the flexibility that it allows. The technique is also applicable to any firm that works on a project basis and that faces problems in allocation of limited shared resources. The graphical notation we use to represent relations between activities, roles, people, and skills is UML. The paper is structured as follows: section 2 presents an overview of previous work in this field; section 3 presents a description of the proposed technique; section 4 provides a step by step sample application ƒ Address for correspondence: Giancarlo Succi, Department of Electrical and Computer Engineering, The University of Calgary, 2500 University Dr. N.W., Calgary AB, Canada T2N 1N4. Giancarlo.Succi@enel.ucalgary.ca Predonzani, Succi, Vernazza Page 1

2 depicted through a set of diagrams, based on an imaginary software firm; section 5 draws some conclusions and presents possible expansions for this work. 2 State of the art Previous work in the field management of skills is mainly related to management of human resources in nonsoftware firms, although some software-related work exists. Krajewski and Ritzman [Krajewski and Ritzman, 1993] give a broad view of how firms can manage work and resources. They put emphasis on job design as "the specification of job content and of the employee skills and training needed to perform that job". From people's perspective, there are several work team approaches: problem solving teams (working out quality and productivity problems), special-purpose teams (working on specific problems of high relevance), and self-managing teams (with empowered and responsible members, decentralizing the decisions and flattening the organization hierarchy). These human resource patterns are enriched with a set of work measurements to measure, in a scientific way, their performance. Innes and Mitchell [Innes and Mitchell, 1994] follow Krajewski's and Ritzman's quantitative approach and propose the Activity Based Costing, a technique to keep trace of the resource requirements of activities. Activity Based Costing is aimed at providing an effective and realistic accounting technique. An approach designed for software firms [Benedicenti et al., 1997] focuses on technology transfer between different firms or between different departments belonging to the same firm. The approach considers activities, roles, people, and infrastructures as the core of the firm's process. Modeling this core allows replication in different environments. The approach relies on object orientation as the means to express the structure of the process. Skills are not taken into account. This technique targets the needs of managers who deal with transfer of knowledge. Jacobson [Jacobson et al. 1995] uses the object-oriented approach to model and re-engineer a firm. Reengineering is based on a deep understanding of how the process works and what the needs of the users are. Skills are collapsed into activities and cooperate to create added value for the user. ISPM [Bellone et al., 1995] is a decision support system to manage personnel career. ISPM traces and plans the careers of the employees versus time. Careers and training are integrated consistently with the objectives of the firm. ISPM proposes a decision making algorithm to support an automated solution to the problem. The paper also presents an interesting classification of skills in functional, managerial, methodological, and technical. Putnam and Myers [Putnam and Myers, 1992] address the problem of people management in software engineering from a quantitative approach. They consider the skills and, more specifically, the amount of people and skills required in different parts of the software lifecycle. Statistical analysis investigates the relations between the various numerical parameters that affect software production. 3 Management of skills for automatic allocation of people Assignment of people is usually performed at the beginning of projects and is required to ensure that the right people are assigned to the right activities, that the required know-how is available, and that people are not unnecessarily stressed by overwork. Analyzing the problem more in depth, we decompose projects in activities. The decomposition can be hierarchical, i.e., comprising several levels of activities, from elementary to aggregate, complex activities [Benedicenti et al., 1997]. Each activity requires a set of skills to be performed. Although the connection between activities and skills is straightforward, in many practical situations it is more adequate to connect activities indirectly, through roles. Roles represent a homogeneous set of skills. Roles add some complexity to the model but are useful because they represents a concept that most firms know and apply. More specifically, the advantage of using roles are the following: Predonzani, Succi, Vernazza Page 2

3 Roles already exist in firms. For instance, we can retrieve a list of roles from the firm s organization chart. Roles are easily connected to activities: one or more cooperating roles cover the skills required by an activity. Roles are easily connected to skills: a role is characterized by a set of skills a person should have to play the role. Sometimes roles are formed through training: each taught subject develops a skill of the role. Roles represent categories of people. People who can play a given role, i.e., belong to its category, are, to some extent, interchangeable to work in activities that require that role. People have actual skills. Skills can grow through working experience and training. Figure 1 depicts a formalization and a summary of the elements introduced so far. «stereotype» Activity * performs * «stereotype» Person * * plays * requires has * * «stereotype» Role * requires * * «stereotype» Skill Figure 1: Activity, role, person, and skill as stereotypes The notation we use is UML (Unified Modeling language) [Fowler et al., 1997]. Figure 1 is a UML metamodel diagram, i.e., it describes what the model can contain. The diagram is drawn according to UML s extension mechanisms [UML documentation]. Generally, extending UML is necessary (a) to focus modeling on a specific field, (b) to impose a semantics on the modeled elements, and (c) to add graphical adornment to specific elements. In our case the extension of UML is necessary for the following points: (a) To focus on the domain of human resource allocation. (b) To apply the semantics of feasible and optimal allocation of people to activities according to some criterion involving roles and skills. (c) To add eye-catching icons to models. Some of these icons are compliant with Jacobson s UML extension for business process modeling [UML documentation]; some are new and are needed to represent skills and roles. A summary of the icons used is shown in Figure 2. Figure 2: Stereotype icons Graphical adornment is usually optional and is convenient only if the graphical tool used to draw the diagrams supports it. Predonzani, Succi, Vernazza Page 3

4 3.1 Automation of people allocation The depicted model, if properly supported by a tool, lends itself to automation of the allocation of people. The basic idea is that people should be assigned to roles according to some matching between the actual skills people have and the required skills of the roles. When dealing with model involving the structure and the dynamics of the firm, a strict formalization is not adequate to catch the flexibility of reality. For instance, a strict matching of actual and required skills is not realistic in real allocations of people to roles. So, the model should allow a certain degree of flexibility in allocation, summarizable as follows: A person may not have all the skill a role requires. A person may have skills that are partially related to the skills a role requires. A person may play a role even if there are other people who have better skills for that role. These flexibility mechanisms take into consideration and allow sub-optimal allocation of people to single projects. Due to the limited shared resources firms have, local sub-optimal allocations and compromises are frequent and are the way to achieve optimal allocation at company level, considering all the projects together. In our approach the automatic tool tells the resource manager how good an assignment of a person is. Moreover, for a given role, it tells who are the top ten people matching the skill requirements of the role. The list of people can be shorter that ten elements if there are not enough people with skills significantly related to those required by the role. Figure 3 shows a snapshot of these features. Figure 3: Automatic management of candidates for role architect According to the example role architect is characterized by three skills: object-oriented design, effort estimation, and object-oriented analysis. The role has three possible candidates for assignment: Robert, Bill, and Pam. Robert is the best match as shown in his match number The match number is in the range between 0.00 (very bad match) and 1.00 (perfect match) and indicates how good the assignment of the person is for that role. Other people Bill and Pam are still valid candidates for the architect role when, for instance, Robert is too busy. 3.2 Match number So far the match number has been defined informally. To obtain a formal definition, we need to go one step deeper in the management of skills. Predonzani, Succi, Vernazza Page 4

5 The simplest case is when a person has exactly the skill a role requires. Figure 4 depicts this case: role1 requires skill1 and person1 has skill1. When trying to allocate person1 to role1, the match is perfect and the match number is 1.0. «role» role1 «person» person1 requires has skill1 skill1 Figure 4: Simple case: perfect match of skills The situation is more complex when person1 does not have exactly the skill role1 requires. For instance person1 may have skill2, as shown in Figure 5. «role» role1 «person» person1 requires has skill1 skill2 Figure 5 Potential mismatch in skills If skill1 and skill2 are totally unrelated, then the assignment of person1 to role1 would be a total mismatch indicated by a match number of 0.0. Nonetheless in many situations skills are related, i.e., a skill is a partial replacement for another skill. We depict skills relations as shown in Figure 6. skill2 related 0.9 skill1 Figure 6: Related skills Relations between skills are depicted as directed links with a relation weight on the arrow: a skill may be a replacement for another skill but the inverted situation may not be true. Although the most common case has bi-directional relations, directed links allow to specify different relation weights for the two directions. When assigning person1 to role1 with the depicted scenario, the resulting match number is 0.9. Relationship between skills is transitive. We change the scenario to show this feature (Figure 7). skill2 related 0.8 skill3 related 0.9 skill1 Figure 7: Transitivity of relations between skills A relation between skill2 and skill1 is implicitly present in this scenario and the relation weight is the combination of the relation weights found in the path between skill2 and skill1. We use multiplication to combine weights, thus, the implicit relation between skill2 and skill1 has a 0.72 weight. When assigning Predonzani, Succi, Vernazza Page 5

6 person1 to role1 (still assuming that role1 requires skill1 and person1 has skill2), the matching number would be 0.72 (Figure 8). «role» role1 plays[0.72] «person» person1 Figure 8: Allocation through related skills If there are multiple paths from one skill to another, the weight that connects the skills is the highest weight between the connecting paths. When there is no path from a skill to another, the weight connecting them is Example We present an application of the presented technique. We consider a software firm. For simplicity we consider only four employees: Pam, Sue, Bill, and Robert. The list can be easily expanded to manage realsize situations. There are basically three categories of skill: management skills, design skills, and programming skills. Management skills include: People management: relating to people as a manager. Communication: relating to people in group activities, where integration of different knowledge is necessary. Planning: decision about required future activities. Effort estimation: estimation of people and time required for planned activities. Cost knowledge: estimation of cost for activities, infrastructures, and external cost sources. Troubleshooting: managing simple, local inefficiencies and problems. Problem solving: managing global, structural inefficiencies and problems. The relations between the various management skills is shown in Figure 9. Figure 9: Management skill relations Design skills comprise object-oriented analysis and object-oriented design. Figure 10 shows the relations between them. Predonzani, Succi, Vernazza Page 6

7 Figure 10: Design skill relations Programming skills regard the knowledge of various object-oriented and procedural-oriented languages: Object-oriented programming in Java. Object-oriented programming in C++. Object-oriented programming in Object Pascal. Procedural-oriented programming in C. Procedural-oriented programming in Pascal Their relations are depicted in Figure 11. Figure 11: Programming skill relations The firm has five roles: Process architecture group member: responsible for software process definition and quality management. Architect: responsible for architectural and technological issues. Software designer: responsible for design of software applications. Project manager: responsible for scheduling, planning, and people management. Object oriented programmer: responsible for implementation of software applications. These roles require some skills, as shown in Figure 12. Predonzani, Succi, Vernazza Page 7

8 Figure 12: Role skill diagram Looking at what resources are available in the firm, we consider the four employees and their skills. Figure 13: Person skill diagram Let us consider a single activity: software development. This is a macro-activity that can be hierarchically decomposed in simpler activities. These sub-activities possibly require a subset of the roles the macroactivity requires. Software development requires four roles: architect, software designer, project manager, object-oriented programmer. To assign people to these roles we generate the top ten matches for each role. Figure 3 shows the matches for architect ; Figure 14 shows the matches for software designer, project manager, and object-oriented programmer. Predonzani, Succi, Vernazza Page 8

9 Figure 14: Top matches for software designer, project manager, and object-oriented programmer For simplicity we allocate one person to each role; generally any number of people can be allocated to roles. Looking at the charts we can, for instance, pick up the best person matching each role: Robert for architect, Bill for software designer, Robert for project manager, and Sue for object-oriented programmer. Although this is a possible and in some aspects good choice, we can make another allocation, as shown in Figure 15. Figure 15: Assignment of people to software development s roles This allocation differs from the previous one as it allocates Pam to project manager. This is still a good choice as Pam s match number is almost as high as Robert s (0.53 versus 0.55) and because Robert is already allocated to architect. Moreover Robert could be a project manager in some other project, which could make his allocation to this project as a project manager subject to stress and overwork. An indirect result of this analysis is that few people Sue and Bill are candidates for role object-oriented programmer. Moreover their match numbers are very low 0.16 and 0.15 and hardly sufficient to cover the requirements of the role. Thus the analysis has spotted a weak point in the software process of the analyzed firm that needs to be improved. Better training focused on skills related to object orientation would be a solution to the firm s problem. Predonzani, Succi, Vernazza Page 9

10 5 Conclusions and future work We have analyzed the advantages and a technique to manage the allocation of people to roles and activities in an automatic way. The technique exploits the definition of a set of skills required by roles and owned by real people. Allocation of people is performed through a flexible matching of the roles people have and roles require. The skills are related to each other through a network. The network allows flexibility in replacing skills with similar ones. The proposed technique is useful during early phases of software projects. Resource managers and project manager can visualize the available resources people and see how they fit into the requirements of the project. Automation provides easy access to information and efficient decision making. Flexibility in allocation manages common situations of limited shared resources. So far, our technique allows easy resource optimization at project level. The planned future work is an extension of the technique to explicitly represent multiple projects. This will allow optimization of resource allocation at firm level, i.e., considering several projects at once. Flexibility and multiple choices will be a primary requirement like for the current version of the technique. References Bellone, M., M. Merlino, R. Pesenti, ISPM: A DSS for personnel career management, Decision Support Systems, 15, pp , Benedicenti, L., A. Valerio, P. Predonzani, G. Succi, T. Vernazza, Corporate technology transfer by means of object orientation, The twelfth International Symposium on Computer and Information Sciences, Antalya, Turkey, october 27-29, Fowler, M., K. Scott, I. Jacobson, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, Innes, J., F. Mitchell, I costi di struttura Metodologie di analisi e di gestione, Egea, Jacobson, I., M. Ericcson, A. Jacobson, The object advantage business process reengineering with object technology, ACM Press, Krajewski, L. J., and L. P. Ritzman, Operations Management: Strategy and Analysis, 3 rd ed., Addison- Wesley, Putnam, L. H., W. Myers, Measures for excellence Reliable software on time, within budget, Prentice Hall, UML documentation, version 1.1, Predonzani, Succi, Vernazza Page 10