Software project control and metrics

In the last years the role of software in daily life becomes more and more dominant. It's not limited anymore to the traditional domains, the administrative organisations (Government, Banking) and the High Tech industries (e.g. Aerospace, Automotive and Medical). Software gets also in-corporated in the low cost bulk domestic domain (Consumer Electronics) and the high cost 'unique' domain (e.g. Infra-structure and Energy). The mentioned industries, Infrastructure and Energy, are known for the high capital expenditure (CAPEX) projects. Software (Development) costs are most of the time a marginal component in the overall cost. However a number of situations occurred where software was crucial to the delivery milestone. Software has become more critical to these CAPEX projects. This requires a different focus on the measurement and the prediction / estimation models for software. For the traditional software service providers the most relevant issues are cost, . . .

Measuring the size of a project has always been a challenge in all the disciplines involved in project management. In software project management, defining a measurement unit for a project is even more difficult since the unique characteristics of the software make it invisible and untouchable, and therefore much more difficult to be measured. This paper presents a model that can contribute towards this issue. The MarkPoint presented can be considered as a sizing and measurement unit to a software project. The MarkPoints are based on the requirements of a project where their initial weighted distribution per requirement, implementation phase and other project elements makes the project size needed for the management of the project. The paper initially states the need for such models in the business world and defines the excepted environment for them to be applied successfully. The model and the overall concept is approach from a business and financial perspective, since it’s a business oriented approach driven by business needs and expectations in managing software project and investments.

An analysis of approximately 250 large software projects between 1995 and 2004 shows an interesting pattern. When comparing large projects that successfully achieved their cost and schedule estimates against those that ran late, were over budget, or were cancelled without completion, six common problems were observed: poor project planning, poor cost estimating, poor measurements, poor milestone tracking, poor change control, and poor quality control. By contrast, successful software projects tended to be better than average in all six of these areas. Perhaps the most interesting aspect of these six problem areas is that all are associated with project management rather than with technical personnel. Two working hypotheses emerged: 1) poor quality control is the largest contributor to cost and schedule overruns, and 2) poor project management is the most likely cause of inadequate quality control.

Every project - whatever the application field - should be managed taking into account at least four dimensions: Time, Cost, Quality and Risk. To manage these dimensions, a key tool for a Project Manager is to increase project visibility, defined as the amount of information about the project associated with its probability of occurrence. This paper uses the "iceberg" metaphor to introduce the ICEBERG (Improvement after Control and Evaluation-BasEd Rules and Guidelines) approach that can help Project Managers through the use of standard (de jure and de facto) ICT methods and techniques. This approach focuses not only on the management, and measurement, of resources, process and product, but also of the project and the organization itself. A list of candidate measures related to these 5 entities is suggested for a comprehensive software measurement plan in order to reduce project risk.

2009

Software Project Management has always been considered as a Herculean task for organizations and enterprises with limited or insufficient technical expertise and resources. The difference contradiction between business and engineering conceptions on project definition, management and success, resulted in project failures and catastrophic technological investments and business initiatives. This paper aims to contribute in software project management by identifying a new innovative measurement unit based on which software projects can obtain a volume that will be used throughout a project tracking process integrating business and engineering goals and objectives under a common project success perception. This new project tracking approach can assure financial and operational benefits by minimizing the lack of communication between business and engineering parties involved in the implementation of a software oriented investment or business initiative.

2007

In this paper we present an empirical study on factors that cause the success or failure of a software project. The study deals with the definition and validation of metrics and indicators to make more objective the meaning of success (and conversely failure) of a project, and correlates characteristics of a project (such as experience of the staff and the project manager, techniques used for requirement engineering, and so on) with its result. The study, performed on a number of Italian companies, can be easily replicated in other countries or within a company, in order to assess its software processes and steer its process improvement initiatives.

Software Project Management is a core topic in software engineering courses because it teaches how software projects planned, implemented, controlled, monitored, and evaluated. The development of theories in software metrics and prediction models builds on the broader project management field but also attempt to overcome the difficulties inherent in measuring an intangible object like software. This paper is situated within research into the factors that influence cost and time estimation for software projects that continue to challenge software development organizations. The study described in this paper explored technical and non-technical factors seen by Sudanese software practitioners as critical in estimation, and if not managed, can result in cost and time overrun or in some cases lead to project failure. Using a mixed-method approach, the research project was first informed through a qualitative study that explored the kinds of problems that face the estimation process from the perspectives of different staff levels. This part of the study revealed a number of factors that can be broadly categorized as technical factors, e.g. the skills of those involved in the estimation process, and non-technical factors such as the high level of uncertainty in the local business environment. The second part of the study focused on one of the leading factors, software project staff training and experience, using the survey method to examine how well the software engineering curriculum is aligned with skills required in the software market, especially those related to estimation. The recommendations this study produced on reducing estimation errors, whether geared towards companies or academia, are preliminary and may only reflect the local setting. However, they also drew upon the vast literature on cost estimation techniques and case studies in similar and more advanced settings. The problem of software effort prediction and estimation models has been a thorny issue in the software engineering field since the concept of "software crisis" and the field itself, as a response to the crisis, emerged in the late 1960s. It still seems to some that "After forty years of currency the phrase 'software engineering' still denotes no more than a vague and largely unfulfilled aspiration" [2]. This study develops our understanding of problems facing one of the young professions in the country, as well as contributes to the global body of research on developing techniques to manage the intricacy of software engineering compared to more established engineering disciplines.

2011 Joint Conference of the 21st International Workshop on Software Measurement and the 6th International Conference on Software Process and Product Measurement, 2011

To clarify the characteristics of cost-overrun software projects, this paper focuses on the cost to sales ratio of software development, computed from financial information of a midsize software company in the embedded systems domain, and analyzes the correlation with outsourcing ratio as well as code reuse ratio and relative effort ratio per development phase. As a result, we found that a lower cost to sales ratio projects had the higher relative effort ratio in the external design phase, which indicates that spending less effort on external design can cause decrease of profit. We also found that high outsourcing ratio projects had a higher cost to sales ratio, and that projects having a moderate code reuse ratio had a lower and disperse cost to sales ratio, which suggests that troubles in code reuse can damage the profit of a project.

Eric van der Vliet 45 Abstract Nowadays, Sogeti Nederland gets more and more questions from clients like: "What is your productivity rate for Java projects?", "What is your duration for building an application of 1000 function points?" and "What is your price per function point for a .Net project?" Literature shows us however, that there is no good answer to these kinds of questions. Putnam [1] is one of the people that show us that the amount of effort needed for a project highly depends on the duration chosen. Other factors that influence the answer to these questions might be: size, complexity and the amount of work that is being carried out on an offshore location (like India). It is therefore necessary to consider all the relevant factors when preparing a project estimation. However, if this has to be done on an ad hoc basis (whenever a client asks, or whenever a Request for Proposal comes in), it will take a lot of time to analyze the right projects. To make things faster and easier, Sogeti has developed a tool to estimate projects and to answer questions like the questions mentioned above. In the paper the tool and its underlying principles are introduced and the preliminary results are given.