Project Management and Software Development Processes:Integrating RUP and PMBOK

Daniel Antonio Callegari, Ricardo Melo BastosPontificia Universidade Caiblica do Rio Grande do Sul - PUCRS, Brazil

danielc4>irinfpucrs. br, bastos4&pucrs. br

Abstract to overcome these difficulties so to improve the overallquality of a given solution. Thus, building a software

Developing a software product is a unique effort product requires the planimng and the execution of athat involves dealing with activities and resources to project, and dealing with the administrative issues ofbuild the desired results. The elements involved in such such an effort. Most management "models" oran effort can be seen from two perspectives: the "guides" are not software-specific, although there aresoftware development process and the project successful derivations or proposals such as [7] andmanagement views. [19], which are influenced by one of the most

In order to develop a product with quality, we must referenced compilations of good practices on projectprovide an adequate combination of these two management, the PMBOK Guide, from the Projectdimensions. However, this integration is generally not Management Institute, PMI [6], [7].well addressed by the currently available software In the case of software engineering, there is andevelopment processes. extensive list of models (or frameworks) for

In this context, the PMBOK can provide the development processes. Many models for softwaremanagement perspective (project scope and lifecycle) processes include specific guidance, activities andwhile RUP, for instance, can bring the technical roles for the managerial issues underlying any softwareperspective (product scope and lifecycle). project, but in general they lack a more integrated

In this paper we present a model for software solution.project management based on PMBOK and its It is thus clear that, in one hand, we must develop aintegration with R UP. By formalizing an integrated more comprehensive solution that better integratesmodel we can address the possibility of automating a software development models and projectnumber oftasksfor software development management's best practices and concepts. In the other

hand, the complexity and the number of projects acompany's manager must simultaneously deal with

1. Introduction increases every day. As the number of projectsincrease, the manager must deal with a greater number

Since the early attempts to define a broader view of of variables. The answer to this twofold questionthe field of Software Engineering (as for IEEE seems to lie on tools that support productive andStandard 730 [1]), we have seen great improvements managerial decisions in the context of an organization.and contributions for its maturity including ISO/IEC This effort requires not only an in depth but a broader12207 [2] and, more recently, models such as the view of the current models of both areas (of course aCapability Maturity Model Integration (CMMI) [3], universal model that fits every software development[4], [5]. Developing a software product is a unique effort is unlikely to exist, but, as we point out in thiseffort that involves dealing with activities and artifacts research, the integration of models provides a means toto build the desired results. Besides, the development develop tools or to propose the automation of tasksof software systems is subject to many kinds of that may bring more successful results) [14], [18].uncertainty that are more related to management issues This study contributes to this integration by(such as scope time and resource constraints) [7] [5] analyzing two of the most used approaches in softwareTo be able to deal with them, researchers and companies: The Rational Unified Process, RUP (forpractitioners developed solutions to increase the ability the software process) and the PMBOK Guide (for

general project management). We first present an

Proceedings of the 2007 International Conference on Systems Engineering and Modeling1-4244-0771-0/07/$20.00 ©2007 IEEE

overview of the field of study and some problems manufacturing activities, the discussion of itsidentified (section 2). We then present the two base compatibility with software development bringsmodels used for the integration (section 3), followed interesting results, especially when it is used as a pointby an analysis and a description of the integrated of departure or a base model [6], [7]. Moreover, themodel (section 4). Conclusions, related research and PMBOK Guide was not conceived to be a process and,indication of future work are in section 5. hence, it does not point out what are and how the

actions on a project must be performed for the correct2. Overview and motivation: the need for development of a final product. It is supposed to bean integration applied to a productive process, according to the

domain of the final product - in our case, software. Inorder to develop an integrated model for the PMBOKThere are many software development processes and thevRUp av irst buil ferene mea

available, but they usually do not appropriately address modte fRU te PMBOftht tra esethe meaithe project management dimension - they generally conep in the sme lan satese inprovide just an adequate set of practices that supports docentatin for the lattr.Te meta-modethe suggested activities and associated workflows. In presentedier wer the latter. The meta-models

addition, most of the existing proposals for software . .development processes do not explicitly address Providing a conceptual model that presents this

integration can lead to a formalization of concepts, andhumank ander kind ofterces, such as formal definitions of the process can be used to

s9e 10e generate tools for supporting that process, and may

In a recent analysis of the research being conducted also help tailoring the process (one such an example ison the field of Software Engineering (SE), Sjoberg et. presented in [20], where "the key idea is to use a model

al [I presented aopof a software process as input parameter for aal [11] presented a comparative distribution of tOpiCS sotae ngerig nvomn',wre"hsoftware engineelring envilronment', where ";theon SE research, where the topics of "process environment is supposed to 'behave' in accordance tomanagement" and "project/product management" the process model"). Also the area of Software Processappeared near four and three percent of their sample, Redesign (SPR) can benefit from another view onrespectively (against near 18%, 12% and 8% forrespods aainqus "tonerl8%, and 8% frcct formalization of the processes, as it needs input from"methods/techniques" "tools" and "product quality emiia an thoeia stde 1]

respectively). Despite the analysis was focused on the em following section sents a n le fidniicto of reerhrltd.ocnrle The following section presents a general view of the

identification of, rhesearcnumbersrrelatedto ontrred models used to develop the integrated meta-model. Weexperiments on SEathese numbers represent a measure based our research mainly on [6], [7] and on [15], [16]forallSE apes nalzed an thy ndiatethee i a for the project management model and the software

good relative level of research in the area of project pro eta- model Althou themanageent fr sofware nginering.process meta-model, respectively. Although themanagement for software engineering.

In order to have a more comprehensive software reference documents for the PMBOK and the RUPdescribe different kinds of models or meta-models, in

development proession that rincherludese th prjeto this paper we sometimes will call them just models forapplygoodprojectmanagement dimensionnrlev we nd toe simplicity. Due to space reasons, we did not include allapplyrgopri sodprojet managepment knowledgeTotheref

,

the details (such as all the attributes) of the models, butappropriate software development process. Therefore, oltheemnsecsayfrhexpnti.research on the field must begin with a completeunderstanding of the core concepts of the available 3. The base modelsbodies of knowledge and models, provide a mappingbetween them, and propose an integrated model that The PMBOK describes the best practices on projectcan guide practitioners towards belier management management, while RUP is a model that assists a teamand, consequently, belier products. to implement the best practices on softwareEven though there are some models and development. According to [9], the integration happensframeworks that embrace more project management as "the PMBOK framework is implemented duringconcepts (such as OPEN and SMSDM [12], [13], each iteration within a RUP project (in all four RUP[14]), the Rational Unified Process [15] and its derived phases - Inception, Elaboration, Construction andmodels provide more documentation and more case Transition) as part of the project managementstudies for the purpose of this research. dsiln.[.]Ta en ene otio Pt

In pralll, hePBOKis agenral-urpse gide the PMBOK key elements"?. In fact, it is important tofor pojecmangemet. Athouh ths boy of note that, although not extensive, project management

knowledge iS generally more applied to industrial and

2

1 ...1-

ir to

......... r jo .......................................................

1.7

if

Guidance: Fin is.to.start(F),Gtart-to-Btart(30),

is h-to-F in is h.(U ),

..rr aesto n Pa" enW..::::: Startmto-Finish(Sfl-Te chnique

rA ffltiMoFt kxxx.

XXX

Ma"a90M0fAPr0CeS9::.::.::.:row1 .._*

Organizational Chart*O................................................KnowledpArea::] inoutp uts

Z.::Corell(nowlledgeAr .::Fat.ildatWkgKnowledgeAr.oa::::

Mg . Equll iit Fa r.0K..Y...............

responsible

Figure 1. Main classes for the project management meta-model developed from [6] and [7].

activities in RUP are embedded in more than just the undertaken to create a unique product, service, or

Project Management discipline. resulf '.Our proposed model for project management As stated before, despite the concept of Roles, the

presents concepts that cover human and physical models for software development processes in generalresources, activities, deliverables, as well as time and do not explicitly address the notions of humanorgaEdzational concepts and their associated classes. In resources and other entities (such as stakeholders)parallel, the RUP meta-model (extracted from [16]) together with other kinds of resources (equipment,contains general classes that deal with the main material and work facilities, for instance). In addition,components of that model. In the following sections the PMBOK Guide defines a subclass of stakeholders,we briefly introduce the base models and then, in called "relevant stakeholders", described as thesection 4, we present the integrated model. resources that in fact work on the project, which can be

from inside the company or third parties.In Figure I we present part of the model for general

3.1. A project management meta-model based project management we designed through a detailedon the PMBOK Guide analysis of the concepts found on the PMBOK

references. In the model, Stakeholder is an abstractThe PMBOK Guide joins the knowledge of proven class, and a non-relevant stakeholder is classified as an

traditional and widely applied practices on project instance of the OtherStakeholder class.management (PM). One of the main concepts in PM is We can observe that almost half the model (thethat of stakeholders, which correspond to all the right side) is dedicated to express the resources

individuals and orgaEdzations that have any kind of (physical and human), the notion of stakeholdersrelation to a project [7]. Stakeholders take part in (people and orgaEdzations involved in the project), andactivities (or tasks) that are classified inside a number their associations with the activities. On the left side ofof Knowledge Areas, and may be supported by tools Figure 1, we begin by introducing the concept of an

and techniques. Activities consume and produce work organization, which has a collection of programs,products (or deliverables) bv usina, the a-p-pro-priate which in tum are collections of projects directed by

a project (the notion of role in the PMBOK is not development. In RUP the workflow details aredefined as a top-level concept such as activities and organized in disciplines that represent areas of concernstakeholders, but the reference text reinforces that this inside the project [15], [16].is an important concept) [7]. When defining anactivity, we must indicate the associated stakeholders.For every such association, we must provide which 1Arole is the stakeholder fulfilling, as well as his/her Tworkload. We may also associate a physical resourceused to perform that activity. .......S ...E9Y) -rt.....En..r. t

The PMBOK defines process groups (such asInitiating, Planimng, and Executing), and everymanagement process (almost 40 in total) is associated Arifc R... Tool .trto one or more knowledge areas (for example, Scope, ......-.......Time, Cost, and Risk, which are classified as core or .W...f......i Phafacilitating knowledge areas). Each activity on thePMBOK model belongs to a management process and Figure 2. The taxonomy of RUP [16]is also related to a knowledge area; it can also besupported by tools and techniques. Finally, activitiesmay be subdivided in Tasks, and may also be L..i...edependent on other activities by the Activity-Dependency class. Pearre

The remaining concepts enforce a project's Disciplinelifecycle being composed of phases, which in turn arerelated to the activities. Activities relate todeliverables as inputs and/or outputs and each & {3 iv / partk rr3deliverable has a type and a single responsible relevant _ O. nstakeholder. = Xflf __orklowELtai Role D..n

3.2. Basic models of the Rational UnifiedProcess /

The Rational Unified Process (RUP) is referred to .t. et

as an iterative software development process based on ..l...+supporteS thi.ttthe SPEM meta-model [15], [21]. The models in+ tiW

S-

Figure 2 and Figure 3, respectively, present thetaxonomy and the semantic model of RUP and were uextracted from [16]. According to this reference, the _ =taxonomy of RUP distinguishes the process elementsin two major categories: ClassifierElement, for the";things"? in the model, and OperationalElement, for Figure 3. The semantic model of RUP [16]their associated ";behavior"?. Among the first are, forinstance, Artifact, Role and Discipline, while thebehavior is a generalization for Activity, 3.3. A first comparison and critiqueWorkflowDetail, Phase and ToolMentor elements. In order to integrate these models, we must firstNote that the taxonomy says each ClassifierElement is idnfytectrbiosadhelwshymycomposed of one or more OperationElements (see the ideentifBythacntribuiongFurs2andthe flwsteymaasiy

identifiedflawbelow). ~~see there is an inconsistency between the taxonomyThe semantic model (Figure 3) shows a lifecycle and the semantic model: the taxonomy of RUP says

composed of phases, which have associated workflow that each ClassifierElement is a composite object ofdetails that define the flow of the activities. Each one or more OperationalElements. According to theartifact has a given responsible role and the roles semantic model, that is true for the all the pairs ({Role,modify the artifacts by way of the activities. The Ativity}, {Discipline: WorkflowDetail}, {Tool:activities have tools and tool mentors to guide their ToolMentor}, {LifeCycle, Phase}) except one:

4

{Artifact}. There are no composite elements for an more profound discussion and the details that underlieArtifact (in other words, there is no "behavior" for the the integration of the PMBOK and the RUP models.Artifact class).

Also, in RUP it is somehow strange to say that a 4. The integrated model for PMBOK androle is an aggregation of activities, and equally RUPsingular is the associative class Signature, which As we can see in Figure 4, the integrated model ispresents two mutually exclusive attributes (the composed by three main packages: (a) one for theindication that an artifact is used as an input or as an PMBOK derived model, (b) one for the softwareoutput for any given activity). development process (in this case, RUP) and finally (c)

Besides, while in RUP there is an explicit relation a "Common"i package that joins the concepts that arebetween a kind of role and a certain activity, in the present on both models.PMBOK there is no distinction whether an activity's When realizing an integration of two models, thepurpose is "productive" (in the sense that it directly conditions below can occur:contributes to the output product) or it is just a an overlapping of concepts (two classesmanagerial activity". with the same concept on each model) inOn the other hand, when comparing the semantic which case we cantransformandjoindthem

model of RUP to the proposed project management ich a we canctinside themmodel, we can find some correspondence. At first into a single concept inside the commonglance, we could directly map some concepts from package;RUP and the PM model: a relationship of concepts (a class of one

of the onginal models relates to some other* Activities. Activities represent almost the class on the other original model, but theysame concept in both models in that they do not represent the exact same concept),are defined as the actual work to be done; in which case we must create an

* Roles. In the PMBOK the general role is association between them; andpresumably the "project manager?? * classes with independent and distinctalthough other roles can be defined. The concepts from each original model, inroles on RUP are mostly "productive" which case we must leave each class in itsroles (such as developers, testers, and ownpackage.integrators);

* Phases. A project is organized in phases in To explain our model, we depart from theboth PMBOK and RUP (the Lifecycle "common"i concepts and then present the relations toconcept in RUP relates to a software the two original packages. Due to space reasons, weproject and is defined by "one complete only present the main contributions, despite the figurepass through the four phases: inception, and the whole model include more elements.elaboration, construction and transition") First, both models deal with the notion of a project,[15]. which has a collection of phases. Each phase has a

collection of activities. It is important to note that theWe can also bring a weaker kind of ming ng phases proposed by the PMBOK Guide do not directly

betweenthe followingrconcepts: map to those defined in the RUP. In an integrated* ProcessGroups (PMBOK) and model, when instantiating it for a given project, we

Disciplines (RUP), where these concepts must compose the sequence of phases and theirrepresent areas of concern inside the activities according to the product to be developed.project, as stated before; In the integrated model the activities are defined as

* Management Process (PMBOK) and abstract entities since we classify a given activity as aWorkflowDetail (RUP), that represent a managerial or a productive one. The activities can begrouping of processes or activities, decomposed into minor parts (RUP calls them Stepsrespectively; and PMBOK calls them Tasks). We kept the term

* Tools and Techniques (PMBOK) and from the PMBOK so we can reuse this name whenTools and Tool Mentors (RUP), as integrating to other software development processes insupport information or resources for the future. Activities can also have dependenciesperforming the activities, among them, which allows the definition of the order

Integrating these models naturally goes beyond a they should occur inside the project (such as thesimple mapping. The following section presents a PMBOK's work breakdown structure, or WBS).

5

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::: :::::::::::::

Figure ~ ~4.Teitgatdmdlfr MO n U

6 EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE iEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEE

They can also be supported by some kind of Guidance The Resources sub-package also includes the(Tools and Techniiques for PMBOK, and Tools and ResourceAvailability class, here explicitly providedTool Mentors in the case of RUP). to add relevant information regarding each resource's

As stated earlier, RUP has a Project Management availability when assigning them to the activities,discipline that incorporates PM concepts, but in the whether this is done manually or automatically.integrated model we took its constituent parts out of Finally, there are also some other associationsthe RUP and moved them to the PMBOK package. among the classes in this model that, for the sake ofManagement activities will typically produce simplicity, are not depicted or detailed in this papermanagement work products (deliverables, for the (examples include: a workflow detail has a collectionPMBOK), and productive activities will typically of associated roles; and also a relation betweenproduce artifacts - thus we kept both terms, as they PMBOK's knowledge areas and RUP's disciplines -may include different attributes. even though this is not a one-to-one relation).

Roles are concepts that appear in both models,although RUP is more emphatic than PMBOK in this 5. Conclusion, related and future workrespect. Like the activities, the roles in the integratedmodel were split into managerial roles and In this paper, we presented a proposal for theproductive roles. Each activity must be performed by integration of the main concepts of the PMBOK and aone or more roles. To each such an association a software development process model (RUP). We firststakeholder must also be present, including his/her identified the need for more development of a formalworkload in that relation (mandatory). A similar model that integrates well-known project managementrelation may occur to physical resources and their activities and a given model for software developmentrespective load (or work information). This processes. The first step was to design a model thatcontribution obligates the assignment of a real person was able to translate the main concepts of the(actually a stakeholder of a compatible role) to an PMBOK. Then, this model was used as a point ofactivity, which is a managerial action. departure for the integration to the RUP software

Any given activity has a single role responsible for process model.it (as enforced by good project management rules) [7]. As stated in section 2, the effort of this integrationAn activity may not only use a work product as input requires a two-perspective view: a managerialor output, but we extended this notion to allow for the (managing and phases) and a techniical one (executionthree distinctive associations: create, modify and use- and disciplines). The PMBOK brings a managementas-input (creates, updates, consults). perspective (providing project scope and lifecycle) and

Note that in the RUP meta-model the counterpart RUP, for instance, can bring the technical perspectiveassociation ("modifies") occurs between the artifact (product scope and lifecycle).and the role, providing a different interpretation. As While it is possible to say the PMBOK and the RUPboth original models define only the associations of have a great level of compatibility, we observed thereuses (input) and produces/modifies (output) for an are some issues that deserve more attention, eitherartifact or a deliverable, respectively, they do not make because one of the models incorporates a givendistinction from creation to an update. We added this concept and the other does not, or because somethird association to allow the automation of an concepts that appear on both models are not directlyinstantiated process considering the fact that we could compatible.not be allowed to remove an activity that creates an The idea for a tool that supports this challenge is toartifact if there is some other activity that modifies or design a mechanism that can deal with a significantuses-as-input that same artifact. part of the managerial and productive aspects of the

For each work product (the abstract class for development of a software product, helping to increaseDeliverable and Artifact) there is an associated type the overall quality of the resultant work.(DeliverableType or ArtifactType). Besides, a work The integrated model was designed with theproduct must have a version information for version following goals in mind:control (configuration management) and a boolean * it should allow the integrated planimng ofvalue for the attribute "isExternal", which must be true the product and management of thewhen the work product "should be subject to approval project;by the project sponsor or customer" [7], or even if it is * it should make the distinction of types ofactually delivered to the latter (i.e. not just an internal activities and types of work productsor partialwork product). (managerial and productive);

7

* it should allow the integrated scheduling of [3] Paulk, M.C.; Curtiss, B.; Chrissis, M.B.; Weber, C.V.activities, where a change in a certain kind Capability Maturity Model for Software, Version 1.1,of activity (managerial, for instance) may Pittsburgh, Software Engineering Institute, 1993.affect other managerial and productive [4] Ahern, D. M., Clouse, A, Turner, R. CMMI Distilled: A

activities, for example; Practical Introduction to Integrated Process Improvement,activitles, for example; Addison-Wesley, 2001.

* it should add the notion of availability to a [5] Chrissis, M. B., Konrad, M, Shrum, S. CMII:resource, so that this information can be Guidelines for Process Integration and Product Improvement,used to automate the resource allocation Addison-Wesley, 2003processes in software projects; [6] Duncan, W. R. A Guide to the Project Management Body

* it should also preview workload of Knowledge, Project Management Institute, USA, 1996.information for the associations of a role, [7] Schwalbe, K. Information Technology Projectactivity and stakeholder, preparing for Management, 2nd Ed., Thomson Learning, Canada, 2002.

[8] Charbonneau, S., Software Project Management - Aautomation (see [8]); Mapping between RUP and the PMBOK. Available at

* it should distinguish the possible relations http://www-128.ibm.com/developerworks/rational/library/between an activity and an artifact 4721.html, 2004.(create/update/consult); this allows [9] Cottrell, W., Standards, compliance, and Rational Unifiedverification and validation when Process, Part I: Integrating RUP and the PMBOK. Availableinstantiating (or tailoring) the model for a at http://www-128.ibm.com/ developerworks/ rational/real project. library/4763.html, 2004.

[10] Berki, E., Georgiadou, E., and Holcombe, M.

During the development of this model we also Requirements Engineering and Process Modelling inidentified some issuelopmenothaelneed sore Software Quality Management - Towards a Generic Process

identified some issues that still need more Metamodel. Software Quality Journal, Vol.12, No.3, 2004.development. A first work already in development is [11] Sjoberg, D., Hannay, J., Hansen, O., Kampenes, V.,the addition of OCL (object constraint language) Karahasanovic, A., Liborg, N., and Rekdal, A. A Survey ofstatements to the model to ensure the rules written so Controlled Experiments in Software Engineering. IEEEfar as natural language - some of them were presented Trans. on Software Engineering, Vol.3 1, No.9, Sep. 2005.in this paper - are consistent. Also, when extending the [12] Henderson-Sellers, B., Dud, R., Graham, I. and Collins,model it is important to be aware of the problems that G., 2000, Third generation 00 processes: a critique of RUtPmay arise when representing concepts that belong to and OPEN from a project management perspective, Procs.different levels of the MOF (meta-object facility) in a ASPEC 2000, IEEE Computer Society Press, Los Alamitos,siffeenglevelsgram of4 presents

MOFgood discussin). m CA, USA, 2000.

single diagram([w14] presents a good discussion). [13] Henderson-Sellers, B., Collins, G. and Graham, I. UML-We are working on the same kind of integration compatible processes, Proc. HICSS 2001, IEEE Computer

with other software development process models, such Society Press, Los Alamitos, CA, USA, 2001.as OPEN and SMSDM [12], [14]. The next step of this [14] Henderson-Sellers, B., Gonzalez-Perez, C. Aresearch, which is already in progress, is the design of comparison of four process metamodels and the creation of aa tool that supports many of the questions addressed in new generic standard. Information and Software Technology,this paper. Other suggestions for future work relate to vol. 47, issue 1, January 2005.project portfolio management. [15] Kruchten, P., The Rational Unified Process. An

The model presented here serves as a prerequisite Introduction, Addison Wesley Longman Inc., Reading, MA,for the design of a full methodology for the planEsg USA, 1999.andrtepEdesgnfafutomationdofsoyftartheplanming [16] PEP - A RUP Adoption Process. Rational Processand re-planning (automation) of software projects in Engineering Process, Rational Unified Process, Beta Versionreal time. 2003.06.01.06, 2003.

Based on sufficient formalization of rules, an [17] Scacchi, W. Understanding Software Process Redesign,integrated approach could address the possibility of Analysis and Simulation. Software Process Improvement andautomating a number of tasks for the area of software Practice, 5: 183-195, 2000.development, bridging the gap between software [18] Lee, B., Miller, J. Multi-Project Management indevelopment processes and the best practices of Software Engineering Using Simulation Modelling. Softwareproject management. Quality Journal. Volume 12, Number 1, 2004.

[19] SWEBOK. Guide to the Software Engineering Body ofKnowledge. IEEE Computer Society, 2004.

10. References [20] Gruhn, V. Process-Centered Software EngineeringEnvironments, A Brief History and Future Challenges.

[1] IEEE Standard for Software Quality Assurance Plans, Software Engineering, Vol. 14, 1-4, Dec. 2002, pp. 363-382.IEEE, 1989. [21] SPEM - Software Process Engineering Metamodel,[2] ISO/IEC 12207. Information Technology - software life version 1.1, Object Mgmt. Group, Doc. 05-01-06, Jan. 2005.cycle, International Standard Organization, 1995.

8