Search results

The alternative to using source lines of code (SLOC) for costing software projects is to use function points. Functional point analysis (FPA), which was first introduced in 1979, has now been widely accepted as the industry standard for estimating software size and costs. International standard bodies like the International Function Point Users’ Group (IFPUG) has been maintaining a repository of data based on projects that were drawn from 14 countries in North America, Europe and Asia/Australasia. This paper presents the results of the analysis that was performed on these data together with recommendations such as benchmarks for software projects. Project measures such as functional size, work effort, project delivery rate, speed of delivery and project duration were analysed using the statistical package, Systat. Apart from project duration, all distributions were log‐normal, thus suggesting that the results can be used for software benchmarking. Regression analysis on the data further identified correlation of functional size with other project measures that can be used as a basis for planning and estimating software projects. Further work on the repository involves other project measures such as team size and software defects.

Programmer resources as measured in available hours are often a limiting or constraining resource in software projects and maintenance. A key element in software project management, therefore, is the forecast of required programming hours. Estimates based on past experience and similar projects are generally unreliable and usually underestimate the level of programming resources required. Function point counting provides a reliable methodology for estimating the level of effort required in software projects. Presents the results of using and modifying function point counting procedures in a maintenance environment where changes are often confined to one or more lines of code. The study indicates that even in this environment, function point counting procedures are useful. Finally, function point counting in the maintenance environment as discussed in this paper helped uncover problems in resource management, training, and personnel evaluation.

The purpose of this paper is to present business process point analysis (BPPA), a technique to measure business functional process size, based on function point analysis (FPA), and using business process model and notation (BPMN). This paper also discusses the assessment results of BPPA compared with FPA.

Two experimental studies with participants from academia and industry were conducted. The following aspects in the experimental studies were focused: similarity, application easiness, feasibility, and application benefits. The purpose of the experiment was to assess BPPA comparing with FPA as the BPPA design followed the FPA pattern.

Experimental results showed that both academia and industry groups highly rated similarity and application benefits for BPPA compared with FPA. However, only participants from industry highly rated BPPA for application easiness and feasibility. The results also showed that participants’ previous experiences did not influence their ratings on BPPA.

BPPA helps project managers to measure functional process size of business process management projects. As BPPA is derived from FPA, its mechanism is easily recognizable by project managers who are used to FPA. These results also show that both techniques are in most cases considered rather similar.

Software development projects are known for inaccuracies associated with elapsed time and total cost estimates. Attempts have previously been made to provide tools to facilitate estimation of just how much effort will be required. One such tool is the estimation of project size (and therefore effort and time required) using function point counts. This benchmarking tool facilitates measures of productivity relating this size to the person‐hours required. The problem with this is that such relative productivity measures assume labour hours to be homogenous and that the only measure of output is the size of the project. This paper investigates the use of data envelopment analysis as a method of benchmarking which overcomes these issues. The end result is a set of simple tools that can be used to determine whether a given project or project plan is efficient.

Mobile applications affect our everyday activities and have become more and more information centric. Effort estimation for mobile application is an essential factor to consider in the development cycle. Due to feature complexities and size, effort estimation of mobile applications poses a continued challenge for developers. This paper attempts to adapt COSMIC Function Point and Unified Modeling Language (UML) techniques to estimate the size of a given mobile application. The COSMIC concepts capture data movements of the functional processes whereas the UML class analyzes them. We utilize the Use Case Diagrams, sequence diagrams and class diagrams for mapping the Function user requirements for sizing mobile applications. We further present a new size measurement technique; Unadjusted Mobile COSMIC Function points (UMCFP) to get the functional size of mobile application using Mobile Complex Factors as an input. In this study eight mobile applications were analyzed using UMCFP, Function Point Analysis and COSMIC Function Point. The results were compared with the actual size of previous Mobile application projects.

Aims to present a team effectiveness analysis of software development teams and one means of improving the effectiveness of software development teams in quite an innovative manner, namely, by forming teams based on who can work effectively together.

The team roles described by R. Meredith Belbin are utilized to improve the effectiveness of software development teams The procedure used in these analyses consists of: finding teams that indicate a commitment to, or interest in, participating in an analysis of their team; having all team members fill out the Belbin Self‐perception Inventory in order to gather data for analysis; interviewing the leader of the team in order to obtain an independent analysis and verification of the self‐perception data; analyzing the self‐perception data, looking for trends in the data from which subjective assessments can be made; Comparing the Belbin analysis with the interview information, identifying similarities and differences between the two, thus providing verification of the Belbin analysis.

Analyses of software development teams from within the industry demonstrate that Belbin's roles and the Belbin self‐perception inventory can be used to recognize important positive and negative features of a team. Thus, positive features can be encouraged, and negative features can be avoided or remedied.

This paper would be useful to managers and team leaders of software development industries to analyze their team and to bring out superior efforts of forming the team to get the work done.

Editorial This special issue of Industrial Management & Data Systems is a huge departure from our usual journal/ monograph style. This is an additional issue to the year's volume — a bonus in fact.

In this article an overview of the state‐of‐the‐art of Quality Function Deployment (QFD) in software development or also called software QFD is given. The differences between classic QFD in manufacturing industries and software QFD are described. Following that certain software‐specific QFD models (Zultner, Shindo, Ohmori, Herzwurm and Schockert), which can be considered the most appreciated ones in theory as well as in practice, are introduced. Experiences in practice with these software QFD models are presented as well. Finally, through explaining the main principles of a special QFD variant for e‐commerce, called continuous QFD (CQFD), the article will show that QFD is suitable for planning electronic business applications as well.

The structure of the economy continues to change; where once they are dependent on the productivity of a manual workforce, companies increasingly depend on the productivity of knowledge workers. Today, knowledge workers account for more than two‐thirds of the workforce, and thus should be the focus of strategic plans to improve productivity. Currently there are no universally accepted methods to measure knowledge worker productivity, or even generally accepted categories. This paper provides a taxonomy of knowledge worker productivity measurements, and identifies a number of productivity dimensions that are used to categorize the findings of previous research. Also describes the relative density of discussions along these dimensions and identifies critical areas for future research.

Cost-benefit (C/B) analysis helps to determine the economic feasibility of business software investments. Research literature and published practices do not recognize substantial software maintenance costs in C/B analysis. Current analyses emphasize the benefits of an initial investment but do not consider the recurring benefits of each enhancement during the software lifecycle. Such analyses could lead to incorrect investment decisions and lost business opportunities. This article aims to review current research on software lifecycle costs and develop a theoretically sound C/B analysis.

This article reviews current C/B analyses and discusses their shortcomings in treating the significant recurring maintenance costs. It analyzes the findings of various studies on software maintenance and synthesizes these findings to identify the nature of various maintenance costs and their benefits. Based on the synthesis, it theorizes various cost and benefit elements for inclusion in a revised C/B analysis.

This article identifies each recurring maintenance cost relevant to C/B analysis. It also identifies recurring benefits from each enhancement that hitherto have been omitted. Finally, this article discusses how these costs and benefits should be treated in the revised C/Bs analysis.

This is a conceptual paper proposing a new C/B analysis and requires an empirical validation.

This article provides a revision of the C/B analysis that is long overdue. It will help to justify a software investment correctly, rank software projects that compete for limited funds and help create a sound software project portfolio. Since 20% of software products may incur 80% of software investment, this analysis will help to make correct software investments and avoid lost business opportunities. This article also describes a practical method to use the revised C/B analysis.

This article provides a revision of the C/B analysis that is long overdue. It will help to justify a software investment correctly, rank software projects that compete for limited funds and help create a sound software project portfolio. Since 20% of software products may incur 80% of software investment, this analysis will help to make correct software investments and avoid lost business opportunities. This article also describes a practical method to use the revised C/B analysis.