FAULT LINKS: IDENTIFYING MODULE AND FAULT TYPES AND THEIR RELATIONSHIP

The presented research resulted in a generic component taxonomy, a generic code-faulttaxonomy, and an approach to tailoring the generic taxonomies into domain-specific aswell as project-specific taxonomies. Also, a means to identify fault links was developed.Fault links represent relationships between the types of code-faults and the types ofcomponents being developed or modified. For example, a fault link has been found toexist between Controller modules (that forms a backbone for any software via. itsdecision making characteristics) and Control/Logic faults (such as unreachable code).The existence of such fault links can be used to guide code reviews, walkthroughs, testingof new code development, as well as code maintenance. It can also be used to direct faultseeding. The results of these methods have been validated. Finally, we also verified theusefulness of the obtained fault links through an experiment conducted using graduatestudents. The results were encouraging

Factors, frameworks and theory: a review of the information systems literature on success factors in project management

INTRODUCTION We provide a critical evaluation of the literature on success factors in information systems projects, with a particular focus on organisational information systems development. This responds to recent editorial comment on the need for literature reviews that can furnish a foundation for theory building and research landscaping. METHOD. Relevant material was found in the core fields of information management, information systems, and project management. Additional material from domains such as business management and software development were also identified. ANALYSIS. Four broad research themes emerged from the analysis of the literature: (1) the identification and exploration of project success factors and success factor lists; (2) contributions of individual/group project success factors to project success (or failure); (3) causal interactions between individual/groups of project success factors and simulations of these; and (4) project success factor frameworks. RESULTS. A high number of unique project success factors exist. Some have attracted more attention than others, there is a lack of agreement on their relative importance, and few frameworks have been proposed to model their influence. To date it has been common practice to list project success factors, whereas less attention has been paid to the question of how knowledge of the existence of these factors can be used to eliminate problems in practice. Despite the amount of research in this area, the contribution of particular success factors to project success remains unexplored, as are causal interactions between individual/groups of project success factors, and simulations of these. CONCLUSION. Through the identification and analysis of the extant literature we identify opportunities for advancing knowledge of the practical and theoretical aspects of information systems project organisation, with particular reference to success factors and project success. Contributions from those who offer expertise in the sociotechnical analysis of systems implementations would be especially welcomed

Empirical research on Software Effort Estimation Accuracy

To improve the software development process is named by both the European Union and the United States government as an important task for society. The constant problem with effort overruns and estimation inaccuracy is a main part of the software development problem. Empirical research on software effort estimation is a key part of the continuing effort by researchers and practitioners to improve the way in which software development projects are carried out. As part of this effort, a study on eighteen of the latest projects at a Norwegian software consultancy was done. The study was done by interviewing the project managers responsible for the projects, having them provide key project data, and their assessments of different project properties related to effort estimation. The study focused on answering research questions related to: • The effect the contractor-customer relationship and customer properties have on estimation accuracy • The effect utilizing experience data has on estimation accuracy • The role of estimation accuracy when assessing software project success The analysis of the collected empirical data showed that reduced effort overruns was associated with increased contact frequency with the customer and contracts that share the risk between contractor and customer. Utilization of experience data, and the use of checklists, was also found to have a positive impact on estimation accuracy. There was not found any strong correlation between project managers’ project success assessment and estimation accuracy, indicating that estimation accuracy and project manager success assessment contribute with two different, but important viewpoints when software project success is to be assessed. In addition to the empirical study and its results, the thesis presents a review of existing group combination techniques for software effort estimation. The review was motivated by recent studies that have suggested that to do software estimation as a group is beneficial. The review presents techniques that vary largely as to how they structure the interaction among the group members, and how their opinions are aggregated. A thorough discussion on the argumentation behind the techniques, and the consequences they have is given in the review. The empirical data collected during the work with this thesis suggests different ways in which software contractors could improve their estimation ability and reduce their effort overruns. The conclusions of this thesis is, that to increase estimation accuracy, software contractors should: (i) involve the customer, and nurture the customer relationship, (ii) add some repeatable structure to the estimation process, but be careful not to add too much structure, (iii) gather and utilize experience data in the estimation process and (iv) evaluate projects when they are done. In doing the evaluation both objective data on effort, schedule and functionality compliance and subjective assessments of project success from key stakeholders, as customer, user, project manager, developers and management should be gathered