Software project complexity is a subject that has not received detailed attention. The purpose of this chapter is to present
a systematic way for studying and modeling software project complexity. The proposed model is based on the widely known and
accepted Project Management Body of Knowledge and it uses a typology for modeling complexity based on complexity of faith,
fact, and interaction.
KeywordsSoftware project management-Software project complexity
All content in this area was uploaded by Leonidas G. Anthopoulos on Apr 19, 2014
Content may be subject to copyright.
A preview of the PDF is not available
... Many studies on various types of software project have proven that their outcomes are far from the complete fulfillment of the initial requirements [10,11,12]. Most studies measure complexity either by measuring the software project product based on its attributes such as size, quality, reliability or the characteristics of software project process using attributes such as performance, stability, improvement [13,14,15]. As such the need to establish a systematic way to evaluate the software project complexity is important. ...
... These metrics will be evaluated by experts for their contribution in total project complexity and will be prioritized. Indicative measures for each of the PMBOK subject areas are presented in Table 1 [14]. Further, the definition of the evaluation scale for each metric is an important component in the measurement process. ...
Software projects are complex endeavors that quite often fail to satisfy their initial objectives. As such the need to systematically study and assess the complexity of software projects is quite important. This study presents a systematic framework for assessing complexity of software projects that is based on the study of project management subject areas as defined in Project Management Body of Knowledge (PMBOK). The presented framework is based on a model that combines the concepts of project, complexity model, complexity factor etc. is an attempt to systematically assess and compare the complexity of software projects. The whole concept has been implemented within Project Management Complexity Assessment Tool (PMCAT) and it is available as a software service over the web.
... Software projects are considered as the most complex ones and their outcome in various cases, is limited, since they fail to fulfil or to complete the initial requirements [2], [3]. Most studies measure software project complexity either by measuring the software project product based on its attributes such as size, quality, reliability or the characteristics of software project process using attributes such as performance, stability, improvement [4], [5], [6]. According to our view this is not adequate as there is a large number of factors that contribute to software project complexity and as such the need to establish a systematic way to evaluate the software project complexity is important. ...
Software projects are among the most complex endeavours today. The increased complexity had led to high numbers of software project failures in terms of time, cost quality etc. Software project complexity is one of the main reasons for these failures. Various approaches to measure software complexity have been proposed focusing on the software product complexity but without considering the complexity of the process. In this paper it is presented the results of an extended literature review and of a statistical analysis followed for identifying the main factors that affect software project complexity taking into account both technical and project management aspects of the software development process. CCS Concepts • Software and its engineering Software creation and management Software development process management • Social and professional topics Management of computing and information systems Project and people management
... Requirements prioritisation is a fundamental process of requirements management and usually of high complexity because it evolves various parameters of development process such as the number of requirements, cost, time restrictions, requirements volatility, etc. (Fitsilis et al, 2010;Berander and Andrews, 2005;Firesmith, 2004). Considering that the goal for a successful requirements prioritisation is to combine the wide range of stakeholder's priorities with the overall project objectives and constraints. ...
Research studies have shown that very often software projects fail to meet their requirements
in terms of quality, time and cost restrictions. It is widely accepted that amongst the main
reasons for these failures is the increased complexity of modern software projects due to their
special characteristics. In most cases, the complexity of software projects is measured either
by measuring the attributes of software project products or by measuring the characteristics of
software project processes. In our approach we suggest that the complexity of software projects
should be studied by applying structured project management techniques. In this research we
have used Project Management Body of Knowledge (PMBOK) as an appropriate underling
project management framework to identify complexity sources affecting software projects. In
this paper, we will report our findings on complexity sources for the subject area of project
scope management and on the metrics that could be used for measuring the complexity of
projects’ scope management.
Software projects are complex endeavors where the application of processes, knowledge, skills and tools is necessary, in order to increase the probability of successful completion. Traditionally software projects are analyzed controlled and monitored by controlling project scope, time, cost and quality. In this paper we present how social network analysis can be used in order to improve software project control. The presented model is based on meta-networks where basic project entities are combined for representing communication, collaboration, and knowledge. The analysis of the model is illustrated with sample data extracted from three software projects.
As global competitive pressure increases and product life cycles compress, companies are trying to shorten product development cycle times. The author investigates the relationship between the actual length of product development cycle times (in months) and several basic product development project strategy and process characteristics. The research quantifies how product development cycle times increase with increased product complexity and with product newness, how using a cross-functional team interacts with product newness in the way it acts to reduce cycle time, and how using a formal product development process interacts with product complexity in the way it acts to decrease cycle time. The findings suggest that using cross-functional teams is more important in projects in which less of the design is a carryover from a previous generation. Teams then had a large impact in reducing product development cycle times. In contrast, implementing a well thought-out process is more important in firms (or divisions of firms) developing complex products or services. The more complex a product, the more time a formal process eliminates from the development cycle.
Projects are and have always been complex. However, complexity is hardly managed or influenced. This paper discusses the concept of patterns of complexity, the minimal manageable “space” of complexity. In order to appraise this pattern, complexity was grouped in three types: faith, fact, and interaction. Based on this typology, 10 characteristics typically involved in projects were defined. This resulting pattern was quantitatively and qualitatively tested with eight projects through the perspective of the project manager. Based on these results, the set of characteristics, as well as the method used to assess its intensity, is discussed. The results show that the pattern of complexity embraces relevant characteristics to support the situated management of projects, maintaining the holistic and strategic view of projects. The predominant type of complexity perceived by project managers was the complexity of interaction. This highlights the importance of coordination in projects. However, the coexistence of these three complexities was a constant in projects.
It is widely acknowledged that traditional Project Management techniques are no longer sufficient, as projects become more complex and client's demand reduced timescales. Problems that arise include inadequate planning and risk analysis, ineffective project monitoring and control, and uninformed post-mortem analysis. Effective modelling techniques, which capture the complexities of such projects, are therefore necessary for adequate project management. This book looks at those issues, describes some modelling techniques, then discusses their merits and possible synthesis.
This chapter provides an overview of Analytic Hierarchy Process (AHP), which is a systematic procedure for representing the elements of any problem hierarchically. It organizes the basic rationality by breaking down a problem into its smaller constituent parts and then guides decision makers through a series of pair-wise comparison judgments to express the relative strength or intensity of impact of the elements in the hierarchy. These judgments are then translated to numbers. The AHP includes procedures and principles used to synthesize the many judgments to derive priorities among criteria and subsequently for alternative solutions. It is useful to note that the numbers thus obtained are ratio scale estimates and correspond to so-called hard numbers. Problem solving is a process of setting priorities in steps. One step decides on the most important elements of a problem, another on how best to repair, replace, test, and evaluate the elements, and another on how to implement the solution and measure performance.
A number of proposals have been advanced in recent years for the development of “general systems theory” which, abstracting from properties peculiar to physical, biological, or social systems, would be applicable to all of them. We might well feel that, while the goal is laudable, systems of such diverse kinds could hardly be expected to have any nontrivial properties in common. Metaphor and analogy can be helpful, or they can be misleading. All depends on whether the similarities the metaphor captures are significant or superficial.