On program development effort and productivity

Many claims are made in the literature concerning large productivity increases as a result of the introduction of various new programming tools and techniques. Seldom do the researchers substantiate these claims, however. Further, many of the reported studies have been unsuccessful because much of the existing research is methodologically flawed and poorly grounded in theory. This paper investigates the methodological problems of previous studies and reports the results of a field study conducted to assess the feasibility of conducting controlled studies of the programming process. A field study of COBOL programs from three commercial organizations investigated the effects of programming style (i.e., structured programming) and programmer skill on (i) the effort required to develop programs and (ii) programming productivity; program size was used as a control variable. The results of the study support the underlying concept: that use of disciplined approaches and well-defined variables leads to more readily interpretable and more conclusive results.     

Software productivity measurement using multiple size measures

Productivity measures based on a simple ratio of product size to project effort assume that size can be determined as a single measure. If there are many possible size measures in a data set and no obvious model for aggregating the measures into a single measure, we propose using the expression AdjustedSize/Effort to measure productivity. AdjustedSize is defined as the most appropriate regression-based effort estimation model, where all the size measures selected for inclusion in the estimation model have a regression parameter significantly different from zero (p<0.05). This productivity measurement method ensures that each project has an expected productivity value of one. Values between zero and one indicate lower than expected productivity, values greater than one indicate higher than expected productivity. We discuss the assumptions underlying this productivity measurement method and present an example of its use for Web application projects. We also explain the relationship between effort prediction models and productivity models.     

PROJECT TEAM SELECTION USING FUZZY OPTIMIZATION APPROACH

With their high potential, high motivation, great problem-solving ability and flexibility, project teams are important work structures for the business life. The success of these teams is highly dependent upon the people involved in the project team. This makes the project team selection an important factor for project success. The project team selection can be defined as selecting the right team members, which will together perform a particular project/task within a given deadline. In this article, an analytical model for the project team selection problem is proposed by considering several human and nonhuman factors. Because of the imprecise nature of the problem, fuzzy concepts like triangular fuzzy numbers and linguistic variables are used. The proposed model is a fuzzy multiple objective optimization model with fuzzy objectives and crisp constraints. The skill suitability of each team candidate is reflected to the model by suitability values. These values are obtained by using the fuzzy ratings method. The suitability values of the candidates and the size of the each project team are modeled as fuzzy objectives. The proposed algorithm takes into account the time and the budget limitations of each project and interpersonal relations between the team candidates. These issues are modeled as hard-crisp constraints. The proposed model uses fuzzy objectives and crisp constraints to select the most suitable team members to form the best possible team for a given project. A simulated annealing algorithm is developed to solve the proposed fuzzy optimization model. Software based on C + + computer programming language is also developed to experiment on the proposed model in forming project teams.     

Software development productivity of Japanese enterprise applications

To clarify the relationship between software development productivity and the attributes of a software project, such as business area, programming language and team size, this paper analyzed 211 enterprise application development projects in Japan using a software engineering data repository established by the Software Engineering Center (SEC), Information-Technology Promotion Agency, Japan. In the analysis, we first identified factors that related to productivity based on a parallel coordinate plot (PCP) and a one-way ANOVA. An in-depth analysis on each productivity factor was then conducted by selecting a project subset for each factor so that the effect of other factors is minimized. Our findings include that the average team size was the strongest attribute relating to productivity. The outsourcing ratio (percentage), which can be controlled by software development companies, and the business sector both showed a moderate relationship to productivity. Finally, product size (FP), the duration of development and the programming language were only weakly related to productivity.     

The factors that affect the performance of open source software development – the perspective of social capital and expertise integration

Drawing on social capital theory, we develop a theoretical model aiming to explore how open source software (OSS) project effectiveness (in terms of team size, team effort and team's level of completion) is affected by expertise integration. This in turn is influenced by three types of social capital – relational capital, cognitive capital and structural capital. In addition, this study also examines two moderating effects – the impact of technical complexity on the relationship between cognitive capital and expertise integration, and of task interdependence on the relationship between expertise integration and task completion. Through a field survey of 160 OSS members from five Taiwanese communities, there is support for some of the proposed hypotheses. Both reciprocity and centrality affect expertise integration as expected, but the influence of commitment and cognitive capital (including expertise and tenure) on expertise integration is not significant. Finally, expertise integration affects both team size and team effort, which in turn jointly influence task completion. This research contributes to advancing theoretical understanding of the effectiveness of free OSS development as well as providing OSS practitioners with insight into how to leverage social capital for improving the performance of OSS development.     

Program generation system for modern hybrid computers

This paper describes the use of a new integrated hybrid programming system which provides equation oriented specification of continuous system simulation models and automated setup, checkout, and operation of the hybrid computer. The programming system is based upon the APBE compiler originally developed through the National Computing Center in England and the HYTRAN Operations Interpreter (HOI) implemented on EAI hybrid computers. In the new program generation system, both processors have been enhanced to enrich the languages and to provide compatible file processing so that the compiler generates a complete HYTRAM object program file which is processed on-line by the hybrid system for setup, checkout, and operation of the analog processor. The benefits of this automatic program generation over the manual process include significant reduction of programming time and cost, error free program setup and operation, and increased hybrid computer productivity.     

Empirical findings on team size and productivity in software development

The size of software project teams has been considered to be a driver of project productivity. Although there is a large literature on this, new publicly available software repositories allow us to empirically perform further research. In this paper we analyse the relationships between productivity, team size and other project variables using the International Software Benchmarking Standards Group (ISBSG) repository. To do so, we apply statistical approaches to a preprocessed subset of the ISBSG repository to facilitate the study. The results show some expected correlations between productivity, effort and time as well as corroborating some other beliefs concerning team size and productivity. In addition, this study concludes that in order to apply statistical or data mining techniques to these type of repositories extensive preprocessing of the data needs to be performed due to ambiguities, wrongly recorded values, missing values, unbalanced datasets, etc. Such preprocessing is a difficult and error prone activity that would need further guidance and information that is not always provided in the repository.     

An empirical study of the impact of team size on software development effort

In this paper, we investigate the impact of team size on the software development effort. Using field data of over 200 software projects from various industries, we empirically test the impact of team size and other variables—such as software size in function points, ICASE tool and programming language type—on software development effort. Our results indicate that software size in function points significantly impacts the software development effort. The two-way interactions between function points and use of ICASE tool, and function points and language type are significant as well. Additionally, the interactions between team size and programming language type, and team size and use of ICASE tool were all significant.

From Aristotle to Ringelmann: a large-scale analysis of team productivity and coordination in Open Source Software projects

Complex software development projects rely on the contribution of teams of developers, who are required to collaborate and coordinate their efforts. The productivity of such development teams, i.e., how their size is related to the produced output, is an important consideration for project and schedule management as well as for cost estimation. The majority of studies in empirical software engineering suggest that - due to coordination overhead - teams of collaborating developers become less productive as they grow in size. This phenomenon is commonly paraphrased as Brooks’ law of software project management, which states that “adding manpower to a software project makes it later”. Outside software engineering, the non-additive scaling of productivity in teams is often referred to as the Ringelmann effect, which is studied extensively in social psychology and organizational theory. Conversely, a recent study suggested that in Open Source Software (OSS) projects, the productivity of developers increases as the team grows in size. Attributing it to collective synergetic effects, this surprising finding was linked to the Aristotelian quote that “the whole is more than the sum of its parts”. Using a data set of 58 OSS projects with more than 580,000 commits contributed by more than 30,000 developers, in this article we provide a large-scale analysis of the relation between size and productivity of software development teams. Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect. Using fine-grained data on the association between developers and source code files, we investigate possible explanations for the observed relations between team size and productivity. In particular, we take a network perspective on developer-code associations in software development teams and show that the magnitude of the decrease in productivity is likely to be related to the growth dynamics of co-editing networks which can be interpreted as a first-order approximation of coordination requirements.     

A team building model for software engineering courses term projects

This paper proposes a new model for team building, which enables teachers to build coherent teams rapidly and fairly for the term projects of software engineering courses. Moreover, the model can also be used to build teams for any type of project, if the team member candidates are students, or if they are inexperienced on a certain subject. The proposed model takes students’ preferences and the teacher’s considerations into account when a team building process is required for any type of course. In addition, this paper investigates how team building models (RandomM: teams are built with randomly selected students; TeacherM: teacher selects the members for each team; StudentsM: students build their own teams and the proposed model) affect team performance and how gender differences affect project activities and team performance. A three-year (five semesters) teaching experiment was performed with the participation of 248 male and 79 female university students and a total of 67 software project teams. Two different One-way ANOVA tests were applied on the experimental data, and the results indicated that the proposed model was better than RandomM, TeacherM and StudentsM models in terms of project grades, and the effect of gender differences on the teams’ performance and project activities was negligible.     

Software Project Duration and Effort: An Empirical Study

Software projects frequently finish late and over budget. Much of the research to date has characterized this problem in terms of inadequate project estimation or incomplete requirements determination. In this study, we concentrate instead on understanding the relationship between project duration and project effort. Over time, a dynamic environment contributes to the expansion of project requirements, thus increasing the scope and effort required to complete the project, irrespective of initial requirements and anticipated project size. Further, frequent delays and interruptions in a project contribute to greater effort each time work is resumed. We develop and empirically evaluate a two-stage model to relate project duration and effort. Our results indicate a significant and positive relationship between project duration and effort, controlling for anticipated project size and other project characteristics. Our model also provides an estimate for the rate of environmental change while projects are in progress. We demonstrate the practical implications of our model by showing how it can be used in conjunction with time boxing techniques and new development methodologies to better scope software projects.     

The case for perspicuous programming

Traditional approaches to coding interactive programs, even literate programming, suffer from the problem of focusing on what the computer will do, not what the user wants it to do. The algorithmic code is primary and any documentation secondary, especially user documentation. Help facilities appear to be added as an almost independent exercise. We can solve this problem by focusing on the user documentation and regarding the algorithmic code as a mere adjunct. The production of an interactive program should start with the user documentation, with the majority of effort spent on developing and refining that documentation and its structure. Developers should add algorithmic code for any program module only after its documentation is complete and all parties have tested and agreed to it. This perspicuous programming approach seeks to produce programs for the user that are as unenigmatic as possible. With a touch of blithely false etymology, we could call this igmatic programming instead. Take your pick.     

可编程序控制器应用软件的结构化设计方法

本文通过引入现代软件工程的思想，紧密结合结合可编程序控制器独特的周期扫描运行机制，提出了梯形图的结构化设计方法。其设计过程分为三个步骤；一是利用功能表图建立对系统的功能描述；二 利用变换分析的方法建立软件的层次化模块结构；三是针对各功能模块，利用具体的梯形图指令实现各模块的功能。实现证明，这种方法 衣效地提高梯形图软件开发的质量和效率，适合于大型、复杂顺序控制系统梯形图应用软件的开发。     

A mapping model for assessing project effort from requirements

Since the effort required to develop a system depends on its requirements, it is important to consider the resulting effort when deciding on the requirements. Miscalculating the effort may lead to requirements that cannot be implemented within given budget constraints. In order to support requirements engineers in calculating the effort resulting from the requirements they elaborate correctly, we develop a mapping model for assessing project effort from requirements (MMAPER) in this paper. MMAPER incorporates effort estimation into requirements engineering and thereby enables engineers to proactively assess project effort without demanding that they spend significant additional time on this task. MMAPER measures system size using function point analysis and assesses the resulting effort using the Constructive Cost Model 2. The theoretical underpinning of the methods stems from theoretical perspectives from which we derive theories of how requirements determine the resulting project effort. We also take into consideration that it is important to distinguish requirements of different size but also implemented in different contexts for estimating the resulting effort. We empirically evaluate the model using data from five case studies which we conducted with a financial services organization. The developed model provides very accurate effort estimations, across both controlled experiments and field applications.     

基于过程的软件规模度量方法的研究

功能点分析是一种广泛使用的度量软件功能大小的方法,它不依赖于实现语言,度量出来的结果也可以在不同的开发过程之间进行比较。代码行度量需要对系统的内部有准确的了解。它是对软件产品（特别是编码）规模最直接的描述。本文综合了这两种规模度量方法的优点,针对一个多层MIS系统的迭代开发过程建立了一个规模度量模型,并将其应用到实际当中,使得项目开发者能够在过程中有效的把握进度制定合理的项目计划。     

Complexity measures for rule-based programs

Software complexity measures are quantitative estimates of the amount of effort required by a programmer to comprehend a piece of code. Many measures have been designed for standard procedural languages, but little work has been done to apply software complexity concepts to nontraditional programming paradigms. This paper presents a collection of software complexity measures that were specifically designed to quantify the conceptual complexity of rule-based programs. These measures are divided into two classes: bulk measures, which estimate complexity by examining aspects of program size, and rule measures, which gauge complexity based on the ways in which program rules interact with data and other rules. A pilot study was conducted to assess the effectiveness of these measures. Several measures were found to correlate well with the study participants' ratings of program difficulty and the time required by them to answer questions that required comprehension of program elements. The physical order of program rules was also shown to affect comprehension. The authors conclude that the development of software complexity measures for particular programming paradigms may lead to better tools for managing program development and predicting maintenance effort in nontraditional programming environments     

Enhancing development team flexibility in IS projects

Information system development projects face tremendous challenges because of business changes and technology changes. Research has shown that software team flexibility has a positive effect on project outcomes, but specific requirements for enhancing flexibility are lacking. Drawing from the input-mediator-outcome (IMO) team effectiveness framework, this research investigates the contextual inputs and team processes that lead to development team flexibility and how well team flexibility improves project outcomes. A survey was developed to consider a model derived from the IMO framework. One hundred fourteen members of information systems development project teams in China responded to the survey. Partial least squares analysis was used served to analyze the data. Results indicate that a participatory culture and cooperative norms are an effective foundation for improving required processes that include project coordination of the project and knowledge sharing activities. In turn, the improved process performance extends responses to changes in technology and the business climate. The improved flexibility in meeting change is predictive of outcomes related to project performance and quality of the final product.     

Error density and size in Ada software

The author and her colleagues have completed the development of a large project written in Ada. The project team kept error reports, and the many modules ranged greatly in size. They analyzed module size to see if there was a relationship with module quality. They used error density-defects per thousand lines-as an inverse measure of quality: the lower the error density, the higher the quality. The author presents and discusses the results, which lend support to the hypothesis that there is an optimal, intermediate module size     

Improving size estimates using historical data

A software project's estimate of effort commonly requires input specifying the project size, and a reliable size estimate depends on many factors. This study examines a completed C++ project and considers programming artifacts that we can readily trace to requirements and early class design     

Launching extreme programming at a process-intensive company

The author describes a project that was started using many extreme programming practices in a company that has a traditional formal development process. He discusses how XP was proposed to management, how the project seed was started and grown, what the team faced during its first six months, and what worked