Evaluating logistic regression models to estimate software project outcomes

Cerpa, Narciso; Bardeen, Matthew; Kitchenham, Barbara; Verner, June M.

doi:10.1016/j.infsof.2010.03.011

Cited by 41 publications

(28 citation statements)

References 46 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The existing literature has presented a wide array of factors affecting the software development outcomes (McLeod and MacDonell 2011). Prior studies show that the factors are related to the entire software development lifecycle; for example, the factors of better understanding the sales, user and customers (Keil et al 1998;Moløkken-Østvold and Jørgensen 2005;Drew Procaccino et al 2002;Cerpa et al 2010), of determining the requirements (McLeod and MacDonell 2011), and of focusing on quality control and software testing (Jones 2008;Kaur and Sengupta 2011;Egorova et al 2010). Based on our results, however, it seems that teamlevel retrospectives are weak at recognising issues and successes related to the process areas that are external to the concerns of the teams (eg sales & requirements, general management and the product owner).…”

Section: Reflectionsmentioning

confidence: 99%

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

2016

View full text Add to dashboard Cite

Team-level retrospectives are widely used in agile and lean software development, yet little is known about what is actually discussed during retrospectives or their outcomes. In this paper, we synthesise the outcomes of sprint retrospectives in a large, distributed, agile software development organisation. This longitudinal case study analyses data from 37 teamlevel retrospectives for almost 3 years. We report the outcomes of the retrospectives, their perceived importance for process improvement and relatVed action proposals. Most discussions were related to topics close to and controllable by the team. However, the discussions might suffer from participant bias, and in cases where they are not supported by hard evidence, they might not reflect reality, but rather the sometimes strong opinions of the participants. Some discussions were related to topics that could not be resolved at the team level due to their complexity. Certain topics recurred over a long period of time, either reflecting issues that can and have been solved previously, but that recur naturally as development proceeds, or reflecting waste since they cannot be resolved or improved on by the team due to a lack of controllability or their complexity. For example, the discussion on estimation accuracy did not reflect the true situation and improving the estimates was complicated. On the other hand, discussions on the high number of known bugs recurred despite effective improvements as development proceeded.

show abstract

Section: Reflectionsmentioning

confidence: 99%

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

2016

View full text Add to dashboard Cite

show abstract

“…Based on the above criteria, Binary Logistic Regression (BLR), Naïve Bayes Classifier (NBC), Support Vector Machine (SVM), and K-Nearest Neighbor (KNN) machine learning techniques are selected [18][19][20]. Note, while BLR is a more traditional statistical modeling technique, as per Wu's data mining survey [21], NBC, SVM, and KNN are high-performing, modern algorithms considered to be within the top 10 most influential for classification.…”

Section: Modeling Approaches Overviewmentioning

confidence: 99%

Systems performance prediction using requirements quality attributes classification

2015

View full text Add to dashboard Cite

Poor requirements definition can adversely impact system cost and performance for government acquisition programs. This can be mitigated by ensuring requirements statements are written in a clear and unambiguous manner with high linguistic quality. This paper introduces a statistical model that uses requirements quality factors to predict system operational performance. This work explores four classification techniques (Logistic Regression, Naïve Bayes Classifier, Support Vector Machine, and K-Nearest Neighbor) to develop the predictive model. This model is created using empirical data from current major acquisition programs within the federal government. Operational Requirements Documents and Operational Test Reports are the data sources, respectively, for the system requirements statements and the accompanying operational test results used for model development.A commercial-off-the-shelf requirements quality analysis tool is used to determine the requirements linguistic quality metrics used in the model. Subsequent to model construction, the predictive value of the model is confirmed through execution of a sensitivity analysis, cross-validation of the data, and an overfitting analysis. Lastly, Receiver Operating Characteristics are examined to determine the best performing model. In all, the results establish that requirements quality is indeed a predictive factor for endsystem operational performance, and the resulting statistical model can influence requirements development based on likelihood of successful operational performance.

show abstract

“…Previous research shows that it is possible to build models that can predict the success probability of a software project (Abe et al, 2006;Cerpa et al, 2010;Vásquez, 2005). These models receive the states of a set of risk factors as input and return the success probability of the project.…”

Section: Introductionmentioning

confidence: 99%

“…Cross-correlation and principal components analysis have been used in previous research to identify the important factors within a similar data set for use in a logistic regression prediction model (Cerpa et al, 2010), but these tools do not address the relative importance of one variable over another in predicting project success. Other techniques such as automatic relevance determination (Wipf and Nagarajan, 2008) serve the same role as principal components analysis -mapping the original input space onto a reduced space that should make the given task easier to learn, but suffer the same problems.…”

Section: Introductionmentioning

confidence: 99%

The optimization of success probability for software projects using genetic algorithms

Reyes

Cerpa

Candia-Véjar

et al. 2011

Journal of Systems and Software

Self Cite

View full text Add to dashboard Cite

Evaluating logistic regression models to estimate software project outcomes

Cited by 41 publications

References 46 publications

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

Systems performance prediction using requirements quality attributes classification

The optimization of success probability for software projects using genetic algorithms

Contact Info

Product

Resources

About