Software Project Characteristics Research Articles

Does agile methodology fit all characteristics of software projects? Review and analysis

Does agile methodology fit all characteristics of software projects? Review and analysis

Does Agile Methodology Fit All Characteristics of Software Projects?

Does Agile Methodology Fit All Characteristics of Software Projects?

Optimization of software project evaluation system

Starting from the problems of imperfect evaluation index system, non-standard evaluation method and single factor of performance evaluation model, this paper applies the unified grey clustering analysis algorithm to establish the index system of software organization status and software project characteristics, and defines the connotation of software project performance. A new network topology design method is proposed, and a software project performance evaluation model based on fuzzy neural network is established. An improved particle swarm optimization algorithm is introduced to solve the problem of determining the connection weight coefficient of the evaluation model accurately and efficiently. This paper introduces the basic concept of project performance evaluation, and explains the necessity and importance of performance evaluation in the project.

Fuzzy evaluation model of software project performance based on grey clustering analysis

This paper introduces the general principles that should be followed in project performance evaluation: through the analysis of the main factors affecting software project performance evaluation, it provides a guiding principle for the construction of project performance evaluation index system including software project characteristics and project characteristics. The empirical study shows that the model can effectively evaluate software project performance and knowledge. It provides decision support information for software organizations to formulate risk aversion strategies, improve project performance level and other risk factors.

A study of software development project cost, schedule and quality by outsourcing to low cost destination

Purpose – The purpose of this paper is to find good values of onsite-offshore team strength; number of hours of communication between business users and onsite team and between onsite and offshore team so as to reduce project cost and improve schedule in a global software development (GSD) environment for software development project. Design/methodology/approach – This study employs system dynamics simulation approach to study software project characteristics in both co-located and distributed development environments. The authors consulted 14 experts from Indian software outsourcing industry during our model construction and validation. Findings – The study results show that there is a drop in overall team productivity in outsourcing environment by considering the offshore options. But the project cost can be reduced by employing the offshore team for coding and testing work only with minimal training for imparting business knowledge. The research results show that there is a potential to save project cost by being flexible in project schedule. Research limitations/implications – The implication of the study is that the project management team should be careful not to keep high percentage of manpower at offshore location in distributed software environment. A large offshore team can increase project cost and schedule due to higher training overhead, lower productivity and higher error proneness. In GSD, the management effort should be to keep requirement analysis and design work at onsite location and involves the offshore team in coding and testing work. Practical implications – The software project manager can use the model results to divide the software team between onsite and offshore location during various phases of software development in distributed environment. Originality/value – The study is novel as there is little attempt at finding the team distribution between onsite and offshore location in GSD environment.

A Longitudinal Study of the Impact of Open Source Software Project Characteristics on Positive Outcomes

This article formulates and tests a set of hypotheses about the success of open source software projects with respect to market penetration and human resource attraction. The authors collected data from 1025 open source software projects in a longitudinal study. The cross-sectional results show that the extent of a project’s operating systems, the range of translated languages, programming languages, and project age positively impact OSS projects’ positive outcomes with respect to market penetration and human resource attraction.

Developers’ Incentives and Open-Source Software Licensing: GPL vs BSD

Abstract One of the puzzling aspects of open-source software (OSS) development is its public good nature. Individual developers contribute to developing the software, but do not hold the copyright to appropriate its value. This raises questions regarding motives behind such effort. We provide an integrated model of developers’ incentives to describe OSS development and compare restrictive OSS licenses that force all modifications to be kept open with non-restrictive OSS licenses that allow proprietary ownership of modified works. Different incentives govern effort provision at different stages of the software development process. We show that open-source licenses can provide socially valuable software when a proprietary license fails to do so. We also show that restrictive OSS licenses generate greater effort provision in the design stage of software development relative to non-restrictive licenses. Endogenizing licensing choice, we find that a project leader chooses a non-restrictive OSS license if reputational concerns drive developers’ incentives, a proprietary license when there is a large population of users in the market and a restrictive OSS license if user population is small but reputational benefit is high. Our results resonate well with empirical findings and suggest additional testable implications about the relationship between licensing and software project characteristics. Finally, we also find that the market under-provides restrictive OSS licenses relative to the efficient level, suggesting the need for subsidizing restrictive licenses in some cases.

Developers' Incentives and Open Source Software Licensing: GPL vs. BSD

One of the puzzling aspects of open source software (OSS) development is its public good nature. Individual developers contribute to developing the software, but do not hold the copyright to appropriate its value. This raises questions regarding motives behind such effort. We provide an integrated model of developers' incentives to describe OSS development and compare restrictive OSS licenses that force all modifications to be kept open with non-restrictive OSS licenses that allow proprietary ownership of modified works. Different incentives govern effort provision at different stages of the software development process. We show that open source licenses can provide socially valuable software when a proprietary license fails to do so. We also show that restrictive OSS licenses generate greater effort provision in the design stage of software development relative to non-restrictive licenses. Endogenizing licensing choice, we find that a project leader chooses a non-restrictive OSS license if reputational concerns drive developers' incentives, a proprietary license when there is a large population of users in the market and a restrictive OSS license if user population is small but reputational benefit is high. Our results resonate well with empirical findings and suggest additional testable implications about the relationship between licensing and software project characteristics. Finally, we also find that the market under-provides restrictive OSS licenses relative to the efficient level suggesting the need for subsidizing restrictive licenses in some cases.

An Analysis of Characteristics of Software Projects Using Sales Cost Ratio and Project Metrics

An Analysis of Characteristics of Software Projects Using Sales Cost Ratio and Project Metrics

Project's priority assessment method in software enterprises based on hybrid weight

How to assess the project's priority is one of the key questions that software enterprises encounter when they are selecting the projects. From the characteristics of software projects,the authors aimed to provide an easy and feasible project's priority assessment method for software enterprises. First,an index system of project's priority assessment in software enterprises was constructed,then based on the index system,six steps to assess the project's priority were introduced,in which a method of combining the entropy weight with the subjective weight was applied to confirm the index weight. The method changed the defects of depending on the opinions of the experts. Lastly,an example was given to prove the feasibility. The comparison of this model and the method only reling on the subjective weight given by experts,show that the proposed model is more objective and consistent with the reality.

Project's priority assessment method in software enterprises based on hybrid weight

How to assess the project's priority is one of the key questions that software enterprises encounter when they are selecting the projects. From the characteristics of software projects,the authors aimed to provide an easy and feasible project's priority assessment method for software enterprises. First,an index system of project's priority assessment in software enterprises was constructed,then based on the index system,six steps to assess the project's priority were introduced,in which a method of combining the entropy weight with the subjective weight was applied to confirm the index weight. The method changed the defects of depending on the opinions of the experts. Lastly,an example was given to prove the feasibility. The comparison of this model and the method only reling on the subjective weight given by experts,show that the proposed model is more objective and consistent with the reality.

Modification of standard Function Point complexity weights system

Function Point (FP) is a software size measure, which includes the standard FP and many different models derived from it. The standard FP method created by Albrecht in 1979 is currently known as the International FP User group (IFPUG) version, which consists of three main parts: The first part is five components, and the second is the complexity weights that include three levels of complexity; simple, average, and complex. The third part is the general system characteristics of software projects, which consists of 14 technical complexity factors. Although, FP was widely used as a software size measure, but it still suffers from many weaknesses. One of which is the subjectivity in the weights system. In this paper a new FP weights system was established using Artificial Neural Networks. This method is a modification of the complexity weights of FP measure (IFPUG version). The final results were very accurate and much suitable when they were applied on real data sets of software projects.

Comments on ‘Considering quality in the management of software-based development projects’

Are technical problems or managerial problems the main cause of software problems? I agree with the author that many of the difficulties associated with software project management can be solved by better adherence to standard project management principles. However, I think that there are critical features of software production that render conventional project management approaches insufficient for software projects. In this context I regard conventional project management techniques as those appropriate to dealing with long-linked technology 1, i.e., serially independent production in which sequential activities are coordinated by means of a plan. Such techniques are sufficient for dealing with manufacturing processes but are not necessarily sufficient to handle software production, which is a design process. Walker 2 argues that software production is an 'intensive technology', i.e., a process geared to the production of highly dependent components that must be coordinated by mutual adjustment rather than by plan. He suggests that there are two major characteristics of software projects that need to be managed: