Software Development Risk Research Articles

The impact of Software Process Maturity on Software Project Performance: The Contingent Role of Software Development Risk

Malgré les efforts croissants déployés pour améliorer les processus de développement des systèmes d’information (SI), la performance des projets d’informatisation demeure un sujet d’actualité dans l’industrie. Le taux d’échec de ces projets a été systématiquement documenté dans la littérature SI. (Wallace, 2004; El-Masry et Rivard, 2010). La gestion des projets de développement des SI est souvent caractérisée par une planification inadéquate, une mauvaise maîtrise du processus de développement global et un cadre de gestion imprécis (Slaughter, 2006). Le présent papier tente d’examiner le rôle modérateur du risque de développement SI sur l’impact du niveau de maturité du processus de développement SI sur la performance du projet. Un modèle basé sur le cadre CMM a été développé et testé. Des résultats révélateurs ont été observés à l’appui d’une enquête empirique effectuée auprès de 107 organisations ainsi que des résultats de l’analyse partielle des moindres carrés des données : (1) un effet positif du niveau de maturité du processus de développement SI sur la performance du projet tout en soulignant l’effet négatif du risque de développement SI sur la performance du projet et (2) le rôle contingent du risque de développement SI dans cette relation.Pour les chercheurs SI, l’intégration du construit risque de développement SI souligne le rôle clé de ce construit dans la conceptualisation CMM. D’un point de vue managérial, pour obtenir une meilleure performance des projets SI, les chefs et gestionnaires de ces projets devraient mettre en œuvre une conception plus efficace d’évaluation des risques de développement SI puisqu’une variation du niveau de ce construit peut renforcer ou affaiblir la relation entre la maturité du processus de développement SI et la performance du projet.

A WBS-Based Plan Changeability Measurement Model for Reducing Software Project Change Risk

In software development process, it is necessary to face challenge for plan changes. In order to effectively reduce development risk, software project must overcome the impact of plan change. In plan change process, affected development documents and plan items should be effectively isolated and immediately modified to reduce software development risk. In software project management plan (SPMP), Work Breakdown Structure (WBS) is a critical and necessary planning tool. For this, WBS-based plan must have high isolation capability and modification flexibility to reduce plan change risk. In this paper, in order to increase WBS-based plan change capability, changeability factors are discussed, and a WBS-based Plan Changeability Measurement (WBSPCM) model is proposed. Applied the quantification mechanism of WBSPCM model, WBS-based plan changeability problem and defect can be easily identified. Used rule-based correction and improvement manner, WBS-based plan can concretely increase changeability and reduce software development risk. The paper discusses and surveys WBS-based plan related characteristics and WBS-based plan changeability factors. In plan review activity, using inspection checklists help concretely collect WBS-based plan changeability quantified factors. Individual factor or measurement can only measure or evaluate the specific maintain quality characteristic (6). In order to improve and enhance WBS-based plan changeability, individual factor or measurement should make appropriate combination. Based on the metric combination model, in this paper presents a WBS-based Plan Changeability Measurement (WBSPCM) model. In WBSPCM model, planned documents quality, planned items modularity, work packages traceability and plan items re- estimation will be measured and combined. Applied the quantification mechanism of WBSPCM model, WBS-based plan changeability problems and defects can be easily identified. Used rule-based correction and improvement manner can concretely increase WBS-based plan changeability and reduce software development risk. In Section II, survey the relationship between the SPMP and WBS-based plan, and describe critical factors of software project failure. In Section III, changeability factors which affect WBS-based plan revision and adjustment capability are listed and discussed. In Section IV, propose a WBSPCM model, and present a rule-based changeability defects identification and improvement manner. In Section V, collect advantages of WBSPCM model and make a conclusion for the paper.

기업가 특성이 소프트웨어 혁신성 및 기업성과에 미치는 영향과 제도적 압력의 조절효과

This study shows that a sustainable competitive advantage and entrepreneurial characteristics are necessary for a software company to achieve competitive innovation and growth. This study investigates various software company characteristics and the effects of various company factors as its main research objectives. The data used in this research model were collected from software companies in South Korea. A total of 211 questionnaires were collected over a period of two months in 2013. EXCEL, AMOS, and SPSS were used to derive the study results. The hypothesis testing results of this study are as follows. First, a software company's entrepreneurial innovativeness and risk-taking behaviors have a positive influence on software innovativeness. A greater sense of innovativeness and entrepreneurial orientation leads to a higher propensity to take risks in software development. Second, the characteristics of software innovativeness, and flexibility have a significant influence on software company performance. Innovation during the initial periods of software usage can create a high demand for improvements and new features, requiring a flexible software design. Finally, this study analyzes the software features of entrepreneurial characteristics and the influence of institutional factors on the characteristics of individual innovativeness and software development. Entrepreneurial characteristics can affect governmental or institutional support, policies, and legal frameworks to promote the role of software innovativeness. The results of this study imply that software companies can adopt an entrepreneurial approach to promote technology development and product development for achieving a competitive advantage in the industry. This study also analyzes the environmental factors that affect the software industry and their implications for policy makers.

A Case Study on Risk Management Practice in Outsourced Software Migration Projects

While there are many studies conducted on software risk during the last two decades, very few have been published on software risk management practice in IT industry. In this paper we explore industry practice in the management of software development risks in outsourced software migration projects. We take the vendor perspective, post contract finalization. We conducted an online survey of 145 software projects executed by global IT vendors with process maturity of CMM Level 5. Based on this we built a statistical model relating software risk management factors with project outcome. An embedded case study of a large software migration project executed for a fortune 500 company was undertaken to check whether the model agrees with actual industry practice. The best practices and experiences from the project are also shared.

An empirical study on the implementation and evaluation of a goal-driven software development risk management model

ContextBuilding a quality software product in the shortest possible time to satisfy the global market demand gives an enterprise a competitive advantage. However, uncertainties and risks exist at every stage of a software development project. These can have an extremely high influence on the success of the final software product. Early risk management practice is effective to manage such risks and contributes effectively towards the project success. ObjectiveDespite risk management approaches, a detailed guideline that explains where to integrate risk management activities into the project is still missing. Little effort has been directed towards the evaluation of the overall impact of a risk management method. We present a Goal-driven Software Development Risk Management Model (GSRM) and its explicit integration into the requirements engineering phase and an empirical investigation result of applying GSRM into a project. MethodWe combine the case study method with action research so that the results from the case study directly contribute to manage the studied project risks and to identify ways to improve the proposed methodology. The data is collected from multiple sources and analysed both in a qualitative and quantitative way. ResultsWhen risk factors are beyond the control of the project manager and project environment, it is difficult to control these risks. The project scope affects all the dimensions of risk. GSRM is a reasonable risk management method that can be employed in an industrial context. The study results have been compared against other study results in order to generalise findings and identify contextual factors. ConclusionA formal early stage risk management practice provides early warning related to the problems that exists in a project, and it contributes to the overall project success. It is not necessary to always consider budget and schedule constraints as top priority. There exist issues such as requirements, change management, and user satisfaction which can influence these constraints.

Software Development Project Risk

Software development risk points to an aspect of a development task, process or environment which, if ignored, tends to adversely affect the project performance. Observations from literature show that while many studies on software project risk construct have been done in developed countries, there is scarcity of literature from Asian countries, especially India. Hence, this research was formulated with an objective of studying software development project risk in the Indian context. Data related to the presence of risk items was collected from 527 software development projects in India. This data was factor analyzed to identify five major risk dimensions namely Team risk, Project planning and Execution Risk, External risk, User risk and Project complexity risk. The resulting factor structure was validated through Confirmatory Factor Analysis. Software project risk was seen to be best represented by a second order factor model with five first order factors.

Intuitionistic fuzzy-valued Choquet integral and its application in multicriteria decision making

Our purpose in this paper is to show the integration properties of the intuitionistic fuzzy-valued Choquet integrals, by which improper applications of this type of Choquet integral in the multicriteria decision making can be avoided. We first propose some important operational properties of intuitionistic fuzzy values (IFVs) and give a short review of the methods of comparing IFVs in the framework of the multicriteria decision making. Then we give a detailed discussion on the aggregation properties of the intuitionistic fuzzy-valued Choquet integral (IFCI) and the intuitionistic fuzzy-valued conjugate Choquet integral (IFCCI). The difference in aggregation characteristics between the IFCI and the IFCCI in multicriteria decision making are also be investigated. Finally, we present an application of the IFCI and IFCCI-based multicriteria decision making method to assess the software development risks.

Managing Software Development Risk with the OODA Loop

Software development projects are subject to risks like any other project. These risks must be managed in order for the project to succeed. Current frameworks and models for risk identification, assessment and management are static and unchanging. They lack feedback capability and cannot adapt to future changes in risk events The OODA (Observe, Orient, Decide, Act) Loop, developed during the Korean War by fighter pilot Colonel John Boyd, is a dynamic risk management framework that has built in feedback methods and readily adapts to future changes. It can be successfully employed by development teams as an effective risk management framework, helping projects come in on time and on budget.

Integrating CMMI Maturity Level-3 In Traditional Software Development Process

CMMI defines the practices that are specially implemented by software development businesses to achieve success. Practices includes topics that direct about eliciting and managing requirements, decision making, measuring performance, planning work, handling risks, and more. In this paper we will discuss Capability Maturity Model Integration (CMMI) software process improvement maturity model and the process areas at various levels of CMMI in brief. The main emphasis of the paper is to discuss about the Risk Management (RSKM) which is one of process area at CMMI level-3. The purpose of Risk Management (RSKM) processes is to identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives. The main aim of the paper is to analyse the effect of integrating the CMMI maturity level-3(process area -RSKM) with the traditional software development process. It represents an attempt to organize the sources of software development risk around the principal aspects of the software development cycle.

Componentes de risco para a gestão de projetos de software

Riscos são fatores de incerteza que afetam a atividade humana em vários níveis. Gerenciá-los é uma questão chave para o sucesso dos projetos em que podem ocorrer. No campo do desenvolvimento de software, uma área em que é inerente um alto grau de incerteza e onde há a participação de vários profissionais envolvidos, gerenciar variáveis de risco se tornou uma necessidade. O presente estudo mostra a obtenção de uma categorização de riscos no desenvolvimento de software por meio de análise fatorial exploratória utilizando a técnica de análise de componentes principais (PCA - Principal Component Analysis). Para aplicar esta técnica foram coletadas estimativas de gravidade dos riscos e de probabilidade de ocorrência dos mesmos entre gerentes de projeto e desenvolvedores membros de comunidades virtuais na internet. A categorização de variáveis de riscos permite uma maior compreensão das suas relações e a possibilidade do tratamento das mesmas em um nível mais alto, lidando com fatores de maior grau de abrangência ao invés de se pulverizar esforços controlando muitas pequenas variáveis simultaneamente. Foram identificados sete fatores, sendo que seis deles revelaram boa confiabilidade interna: Gerência de Projetos, Equipe de Desenvolvimento, Escopo e Requisitos, Conhecimento e Incerteza Tecnológica, Relacionamento com o Ambiente Externo, Relacionamento com o Cliente/ Usuário e Valor/ Importância Atribuídos ao Projeto. O texto discorre sobre os resultados obtidos e aponta linhas de investigação para aprimoramento do arcabouço teórico da área, destacando possibilidades que podem ser aplicadas por Gerentes de Projetos e Desenvolvedores de Software nos seus processos cotidianos de gestão de riscos.

A note on risks in software development with imperfect testing

This study analytically assesses the statistical risk of releasing defective software that cannot be exhaustively tested, and of needlessly testing defect-free software. Specifically, it quantifies the probability of committing Type I (α) and Type II errors (β) in software development when one may release software that still is faulty or do needless testing since the test methods themselves may not be perfect. The study uses Truncated-Poisson and geometric distributed path lengths and Bernoulli-type inspection errors to link α and β to software design features, the development philosophies employed, and certain aspects that include code quality, cyclomatic complexity and the average length of basis paths. For risk reduction this study finds quantitative justification for raising test coverage, perfecting the test methods, the adoption of recent innovations and programming methods such as component-based design, SOA and XP as ways to raise the likelihood that the product developed will be fault free. Results are relatively robust with respect to the probability distributions assumed.

Layered Approach to Open Source Software Development Success

Open source has emerged as a widely accepted software development phenomenon which has tremendously brought about a significant paradigm shift from traditional software development methodologies such as top down design and stepwise refinement to an unconventional software development approach by means of collaborative software development method among a wide geographically dispersed interested developers and committed project participants while paying less attention to immediate “physical gains”. The open source approach focuses on highly diverse views of developer motivations; ranging from ego gratification, ideological satisfaction and gift culture for individual developers and open source motivations may be viewed from spreading the software development risks and associated maintenance costs at corporate organisational level. In this article, a five layered open onion model of open source was broadly examined. Analysis and evaluation were narrowed down to only the initiation layer of the open onion model. Results show that open source success largely depends on the quality associated with successful initiation of the project. Our findings also reveal that the most popular open source license is GPL and that license type has significant impact on project rank. The domain audience has negative impact on project rank and user interface has significantly negative impact on project’s domain audience. Open source project topics covered have a significant impact on the domain audience and a negative effect on the user interface. This research has also presented a conceptual framework of open source success tree.

Towards a Framework for Offshore Outsource Software Development Risk Management Model

Due to high demands on cost savings in software development projects, offshore outsource software development is becoming increasingly popular. Offshore outsourcing takes advantages of large labor pool in low- wage countries, round-the-clock development, and easy access to additional resources, in addition to the development cost savings. However, there are risks associated to this trend, as it brings new challenges into the development process, where some may even jeopardise the cost savings. The geographical and cultural distance is one part of the problem, inexperienced developers and lack of communication and a common cultural basis are other challenges. We therefore advocate the use of risk management (RM) to control risks in offshore outsource development. Here we present a RM framework tailored for such development contexts. The model; Goal-driven Software Development Risk Management modelling (GSRM) framework, assesses and manages risk during the early development phases, where risks can easier be tackled at a reasonable cost. The framework is comprised of four layers that together identify and link project goals, risks and treatments together in a goal-risk causal relationship model. The goal model makes use of an extended subset of the KAOS goal modelling language. We report on a study project focusing on the efficiency of the GSRM process model.

How does software project risk vary across projects? An exploratory study from India

Software development risk continues to be a major concern for software development organisations across the globe. Review of literature shows that while many studies on risk construct have been done, there is a scarcity of empirical studies on the possible variation in risk across project and organisational characteristics. This research, based on the data collected from 527 software development projects in India, checks how risk levels vary across different types of projects executed with different types of organisations. Major risk dimensions were identified and confirmed through a combination of exploratory factor analysis and confirmatory factor analysis. Possible variation in the risk scores across the sample was checked through a series of one way ANOVA tests. Risk levels were seen to be highly influenced by select project characteristics and organisational attributes.

Financial Pricing of Software Development Risk Factors

The ability to price (monetize) software development risks can benefit various aspects of software development. Cost estimators predict project cost by adjusting a project's nominal cost on the basis of risk factors' (cost drivers') expected values, but the predicted cost is often inaccurate because risk factors' actual values normally deviate from expectations. Because variability is a widely used risk measure in finance, this risk-pricing method relates risk factor variability to project cost variability. The method estimates two parameters for each risk factor: extra cost incurred per unit exposure and project sensitivity. Several areas can benefit from the benchmark risk-pricing parameters obtained when applying this method with a cost estimator such as Cocomo.

Monetary pricing of software development risks: A method and empirical illustration

The ability to price (monetize) software development risks can benefit various aspects of software development decision-making. This paper presents a risk pricing method that estimates two parameters for every individual risk factor: extra cost incurred per unit exposure, and project sensitivity, to that factor. Since variability is a widely used measure of risk in finance and decision sciences, the method derives risk pricing parameters by relating variability in risk factors to variability in project cost. This approach rests on the fact that a parametric cost estimator predicts project cost by adjusting the “nominal” cost of a project based on the expected values of risk factors (cost drivers), but the actual project cost often deviates from prediction because the actual values of risk factors normally deviate from expectations. In addition, to illustrate the viability of the method, the paper applies the method empirically with COCOMO data, to approximate risk pricing parameters for four risk factors (Personnel Capability, Process Maturity, Technology Platform, and Application Task). Importantly, though, the method could work equally well with data recorded based on other parametric cost estimators. The paper also discusses several areas that can benefit from benchmark risk pricing parameters of the kind we obtain.

Choquet integral based aggregation approach to software development risk assessment

Software is a crucial component of today’s business environment, and a superior risk management effort is required to adeptly steer software development projects. Software development risks are inherently dependent, in other words, mutually positive or negative assessments of some risks can influence the decision to accept or reject a project. This fact cannot be modeled with a traditional best compromise seeking method. Aggregation operations based on the family of fuzzy integrals include many operators and thus can express a variety of decision maker behaviors. This study proposes an integrated multi-criteria evaluation methodology for software development experts and managers to better enable them to position their projects in terms of the associated risks. The method relies on a special fuzzy operator, namely a two-additive Choquet integral that enables modeling various effects of importance and interactions among risks. The potential of the proposed methodology is exposed through a case study conducted in a Turkish software company.

Risks in software development with imperfect testing

This study analytically assesses the risk of releasing defective software that cannot be exhaustively tested and of needlessly testing defect-free software. Specifically, it quantifies the probability of committing a Type II error (s) in software development when one may release software that still is faulty while the test methods themselves may not be perfect. The study uses truncated Poisson and geometric distributed path lengths and Bernoulli-type inspection errors to link s to software design features, the development philosophies employed and certain aspects that include code quality, cyclomatic complexity and the average length of basis paths. For risk reduction, this study finds quantitative justification for raising test coverage, perfecting the test methods, the adoption of recent innovations and programming methods such as component-based design, SOA and XP as ways to raise the likelihood that the product developed will be fault-free. Results are relatively robust with respect to the probability distributions assumed.

Balancing Opportunities and Risks in Component-Based Software Development

The increasingly rapid change in information technology makes it essential for software development projects to continuously monitor and adapt to new sources of opportunity and risk. Software projects and organizations can increase their success rates in software development by better assessing and balancing their opportunities and risks. The authors summarize the incremental commitment model (ICM), a process framework for improved project monitoring and decision making based on balancing opportunities and risks. They give an example of how the ICM framework can improve component-based development choices based on assessment of opportunities and risks. They show how different opportunistic solutions result from different stakeholder value propositions. They elaborate on the risks involved in architectural mismatches among components, present a tool called the Integration Studio (iStudio) that enables projects to assess the most common sources of architectural mismatch between components. Finally, they present representative examples of its use.

Prediction of IS Project Escalation Based on Software Development Risk Management

Information system project failure is described as a common phenomenon. Escalation occurs when there are continued commitments for a troubled project and has been observed as one pattern of failure. The main purpose of this research was to investigate whether software development risks were the factors to discriminate between escalated projects and non-escalated projects. Thirty critical risks were selected and classified into nine risk categories under three dimensions such as product, people, and process. Probability and loss in each nine risk category were measured on the basis of 247 survey cases from IS professionals. The results show that the risk probability in the people dimension and the process dimension with management aspects was more important to predict escalation than the risk loss in those dimensions and the risk impact in the product dimension with technical aspects. The results imply that managerial factors are more critical than technical factors in predicting IS development project escalation. Additionally, it was noticed that the CMM level of an organisation was very significant to predict successful projects.