June M. Verner

Case study: factors for early prediction of software development success

Abstract Project managers can make more effective and efficient project adjustments if they detect project high-risk elements early. We analyzed 42 software development projects in order to investigate some early risk factors and their effect on software project success. Developers in our organization found the most important factors for project success to be: (1) the presence of a committed sponsor and (2) the level of confidence that the customers and users have in the project manager and development team. However, several other software project factors, which are generally recognized as important, were not considered important by our respondents.

Case study: the effect of IS maturity on information systems strategic planning

We present a longitudinal study of the information systems strategic planning process (ISSP) within a large Australian organization and review the changes and developments that have taken place within this organization over a period of four years. We discuss ISSP with regard to its strategic relevance, factors affecting IS strategic planning, key issues in ISSP, the effects of infusion and diffusion levels, together with the effect of IS maturity on ISSP and ISSP on IS maturity. Our study shows that the adoption of ISSP methodologies has had numerous benefits within the organization.

In the 25 years since The Mythical Man-Month what have we learned about project management?

This paper discusses Brooks’ The Mythical Man-Month , a landmark work in the software project management field, and compares the software project management advice given there with practices employed some 25 years later. To find out the state of today’s practice 20 experienced software developers were interviewed regarding their impressions of factors leading to success or failure of software development projects. Their observations are compared with the points raised by Brooks in his seminal work. q 1999 Elsevier Science B.V. All rights reserved.

Prototyping: some new results

Abstract This research describes a survey of experienced software development practitioners in large organizations for their perceptions of the relative merits of the prototyping and waterfall approaches. Some results of earlier research are confirmed but a number of new insights are obtained. Prototyping is used by developers who are mainly concerned with early life cycle issues; improved communication with users, increased flexibility of the design produced and for early discovery of problems. Non-prototypers prefer to use a waterfall approach because they are more concerned with later life cycle issues—level of control provided, good communication with IS personnel, and the robustness and maintainability of the systems produced.

Predicting software development project outcomes

Case-based reasoning is a flexible methodology to manage software development related tasks. However, when the reasoners task is prediction, there are a number of different CBR techniques that could be chosen to address the characteristics of a dataset. We examine several of these techniques to assess their accuracy in predicting software development project outcomes (i.e., whether the project is a success or failure) and identify critical success factors within our data. We collected the data from software developers who answered a questionnaire targeting a software development project they had recently worked on. The questionnaire addresses both technical and managerial features of software development projects. The results of these evaluations are compared with results from logistic regression analysis, which serves as a comparative baseline. The research in this paper can guide design decisions in future CBR implementations to predict the outcome of projects described with managerial factors.

Information systems chargeout: a review of current approaches and future challenges

Based on over 20 years of information systems (IS) and management accounting literature, we present a critical review of IS chargeout research. The need for such a review derives from the conceptual difficulties and empirical limitations observed in past research, and from the management challenge of rapidly growing new information technologies (ITs). Our review systematizes the objectives and cost accounting methods underlying past developments in this area. We describe the features of successful chargeout systems, recognizing the current neglect of organizational-level objectives and follow this with a discussion of the advantages of chargeout systems, and the problems involved in their use. An investigation into the context of new ITs reveals a new surge of chargeout software products that require more organizationally oriented chargeout research. Finally, we present a model of chargeout systems evolution within a wider managerial and business context.

An Investigation into Software Development Process Knowledge

Knowledge management elevates individual knowledge to the organizational level by capturing and sharing information and turning it into organizational knowledge. In order to provide a better understanding of the most serious software project risks and the interrelations among risks, we collected software project data from developers. This data includes information about senior management, customers and users, requirements, estimation and scheduling, the project manager, the software development process, and development personnel. In order to elevate our data to organizational knowledge we conducted a variety of studies on this data and found that the most critical success factor was good requirements. Other critical success factors were either influenced by the requirements, or themselves influenced the development of the requirements.

S/C: A Software Size/Complexity Measure

A new software structural complexity metric is proposed which is a simple, yet powerful, extension of the normal lines of code count. This measure is shown to account for the differences in complexity of program statements in high-order languages and is useful in assessing control complexity of source programs objectively when the source code is available. The proposed measure also satisfies the seventh axiom of Weyuker’s software complexity measures (complexity is dependent on permutation of source statements). The measure has the potential (not fully evaluated here) for use in assessing the effort related to understanding software for software maintenance, debugging and generalization. In our pilot project, we found that the time taken to trace artificial bugs introduced in programs is explained better by S/C counts than by lines of code counts.

Using Competitive Intelligence to Develop an Automated Visa Approval System

The use of competitive intelligence techniques identified the need for an automated visa approval system to streamline straightforward visa decisions that allows analysts more time for problematic applications. Such a system facilitates the capture and use of lessons learned and encourages knowledge sharing to support global terrorism risk management. However, automation of visa approvals raises issues related to human rights, data quantity and quality, choice of models and the correct interpretation of contextualized results.

Some architectural features of ada systems affecting defects

In this study, we discuss some software architecture tradeoffs for Ada83 systems. External and internal complexities are specified for Ada packages and these complexities are related to the numbers of defects uncovered during testing using a non-linear model based on the negative binomial probability distribution. The non-linear associations among the software measures that we investigate are exploited to identify optimal relationships between context coupling and the number of visible declarations. The data we used to develop our model consists of Ada package characteristics from four software systems. Some of the packages are reused from previous projects and nondefect changes may have been made to these packages during the software development process. Therefore, in our defect model, we controlled for these two factors. For the 262 packages that we considered, our research shows that with respect to software defects there is too much context coupling, indicating that the architecture is far from optimum. If less of the workload were delegated to other packages and instead implemented within the package through hidden declarations, then context coupling might be reduced.