This submission presents a new unified approach to processes modeling of software project management. It describes how we can use the PMBOK standard (Project Management Body of Knowledge) with combination of a general process approach to model and control software project cycle. The main purpose of this article is to simplify the whole software project realization by way of philosophy and methodology of the PMBOK, especially in domain of project plan creation, controlling, monitoring and executing. In conclusion of the article the mapping of processes and PMBOK knowledge areas into a process model of Software Development Company is shown. We assume that our suggested approach should improve security of software development through decreasing the number of faults.
Project management is applicable to all domains, where the projects are realized. Each project is possible to divide into a finite number of sub-processes, which are crucial to its complete successful realization.
We propose a new approach based on modeling of project processes. There are the main ideas and thesis described and an example of PMBOK standard mapped into a software project processes is presented.
In the following section the main foundations will be given that are crucial for expression and comprehension of a mutual context between terms of project management by PMBOK and software project life cycle.
In this section Project management background and present models will be introduced. Project management is a complex and extensive part of management. As the main information source will be used a project management standard called PMBOK because of its detailed description and relating things of all project management processes. The project processes are critical for each project, without reference to its orient, extent, duration etc.
The basic terms of project management are following [
The most frequent representation of project management is a model, with different defined environment, relations, entities and objects with specified properties and characteristics. We can divide the present models into: (1) models targeted on project management processes and (2) models targeted on a product.
Models targeted on project management processes describe project management processes applied into a generalized product/service development life cycle. Majority of those models have controlling functions targeted on the basic managerial functions, e.g. Planning, organizing, coordination, commanding and controlling. Managerial functions approach works on assumption that the organisations goals meetings, which implicate meetings the managerial work mission, is assured by reciprocal according with given function in the best way. Each of those sequential functions penetrate/get into parallel functions, e.g. Problem analysis, decision-making, realization (implementation), including coordination etc. We identify the actual control processes according to control function and the main purpose or a knowledge area, which is a process applied into. Project management processes are applied in individual project phases, which can be sequential or parallel. This models type is targeted on relation description among time, costs and extent. The main purpose of those models is a covering of the most of application domains.
Models targeted on a product are by the concrete specialization of project management for product application domains. The core of those models is the concrete product life cycle development where the project management processes are integrated into. The following Figure represents an example of a product oriented model applied to information technology domain. This model consists of individual phases targeted on product life cycle and project management is integrated into it.
Each of project management models above have usually collective the fact that a model is represented by some pattern which represents project management on a relatively high level of abstraction. More detailed level of abstraction is further described with text fragments only or some graphic pattern is used for it (in some cases with different syntax/semantics). Then models of project management describe more detailed a complete structure by different representative parts with not so much accurate details expression.
Present models miss an explicit expression of the following elements: • Structure and relation among PM-components (in different level of abstraction). • Clear objects properties and behaviour declaration of project management. • PM-processes and their relation described by previously entrenched objects. 9 Knowledge Areas:
Core Functions Scope mng.
Time mng.
Cost mng.
Quality mng.
HR mng.
Comm. mng.
Risk mng.
Procure.
mng.
Project Integration Management
In our approach to modeling of project management processes we gain from an
international standard PMBOK philosophy, which looks on project management as on
a system consisting of individual elements (knowledge areas). We separate each of
elements into partial processes, which are realized in those domains [
Figure 2 below depicts the critical relations and association in Project management.
The main participants of project management are the individuals or organizations, which are interested in a project (they are positively or negatively affected by a final product). An appropriate model of project management should be able to demonstrate the use and functions of individual participants in individual project management processes for different level of abstraction unambiguously and illustratively. The main participants of the project management are the following (depending on a concrete project – its extent, application domain, submitter etc.): project manager, quality manager, risk manager, sponsor, team members, customer, support staff etc. We can reach of a more detailed level of abstraction by dividing the project management into processes groups. The processes of those groups are consisted of individual activities. The basic processes groups are the following: Initialization processes, Planning processes, Executing processes, Controlling and monitoring processes, Closing processes.
Tools and techniques
Project success Project portfolio • Project 1 •
Project 2
Software development process starts with request estimation, which is foundation for workpackage definition. If the event occurs, that extent of the work is larger then expected, requests are changed. The moment of requests approving starts the main managing process, i.e. planning, monitoring and controlling. If some other requests occur, then must be agreed with customer and specification of tests must be changed. When plans are done and approved, design and implementation process starts. Its main outputs are parts of the final software work, which are subject to monitoring and integration (especially in case of large system development). The next step involves testing of completed build. When it's carefully evaluated that quality of final product attains the prescribed level, preparation of release may start. Decision on delivery is beginning for delivery process, which deploy the product and documentation. Finally, customer accepts or declines the final product.
In this section processes groups with their included processes and relations to process model and knowledge area are described.
Initiating group: • Planning group: •
Initiating process (part of scope management) – starts the whole project and is outside of our process model.
Plan assessment process (part of integration management) – assumes results of other planning processes and make them part of one document.
Scope planning process (part of scope management) – produces written document, which includes data for future project decisions.
Scope defining process (part of scope management) – divides the whole work into workpackages.
Activity defining process (part of time management) – states which activities must be done to produce required outputs.
Activity ordering process (part of time management) – states and documents causality.
Activity duration estimating process (part of time management) – estimates number of work units needed for completing individual activities. Time schedule assessment process (part of time management) – analyses activities ordering, duration and resource requirements to make out time schedule of project.
Resource planning process (part of cost management) – chooses resources (employee, material) and their quantity to proper executing of project activities. Cost estimating process (part of cost management) – estimates cost of resources needed to completing project.
Budgeted cost specifying process (part of cost management) – sets estimating costs for every activity in project.
Quality planning process (part of quality management) – determines which standards are relevant for project and how to realize them.
Organisational structure planning process (part of human resource management) – establish, documents and acquires project tasks, responsibilities etc. Employee acquiring process (part of human resource management) – acquires and assigns human resources for work on project.
All preceding processes relate to first part of process 3 on fig. 3 – i.e. planning. • • • • • • • • • • • • Executing group: •
Project plan realization process (part of integration management) – realizes activities from project plan. Scope verifying process (part of scope management) – formally confirms project scope acceptance.
Quality ensuring process (part of quality management) – regularly evaluates total project fulfilment to ensure that project satisfies relevant standards. Team building process (part of human resource management) – improves project performance by skills advancement of individuals and groups.
Controlling and monitoring group: •
Change coordination process (integration management) – coordinates changes for the whole project.
Operative scope management process (scope management) – controls operative changes in project scope.
Operative time schedule management (time management) – controls operative changes in project time schedule.
Operative cost management process (cost management) – controls operative changes in project costs.
Operative quality management process (quality management) – traces project outputs to ensure that they correspond to relevant standards and to order the way of removing unsuitable performances causes.
Other PMBOK knowledge areas In preceding paragraphs has been omitted these 3 main knowledge areas: • Communications management – main communication channels are set by roles and process map. • Risk management – main risk in software development companies are requirement and scope statements (both of these are subject to scope management). • Procurement management – in software projects is this very rare and unusual area. Process map of Software Development Company more emphasizes product oriented processes and on the other hand PMBOK is focused on management processes. From the viewpoint of PMBOK, integration is part of planning, controlling and monitoring. In software development practice, integration is usually part of main product process, i.e. assessment of work pieces into final product.
Suggested model (and its mapping to knowledge areas of PMBOK) is possible to enlarge and than describe individual processes and their participants in more detailed way. This is subject to future research.
There is a stronger stress on standardisation in project management in last decades. PMBOK is the answer to this need. Simultaneously, researchers looking for other areas which can be used or linked together with project management to ensure better functionality. Process approach becomes widely accepted across almost every part of management and that is why we realize the mapping of processes and knowledge areas of PMBOK into a general process model of Software Development Company described in this paper.
This approach should help project managers to better understanding of their own company’s processes and projects. Furthermore it makes some PMBOK’s knowledge areas more obvious and their relations to real software production, especially in domain of project plan creation, controlling and executing.
More transparent management of software development assists, with PMBOK in mind, more effective direction of actual software project and should improve security of the final product.
This research was supported by the Research Plan No. MSM 0021630528, SecurityOriented Research in Information Technology.