Offshore-outsourced software development risk management model

Islam, Shareeful; Houmb, Siv Hilde; Mendez-Fernandez, Daniel; Joarder, Md. Mahbubul Alam

doi:10.1109/iccit.2009.5407292

Cited by 7 publications

(7 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our studies results also agreed with this conclusion [IHMFJ09,IH10]. Therefore, the plan risk management task enforces the development team to consider a complete risk management process during requirements engineering so that risk assessment and management are formally integrated during the development.…”

Section: Plan Risk Managementsupporting

confidence: 78%

“…In our previous studies, only offshore software development projects were investigated where customers/ users are located in different locations [IJH09,IHMFJ09,IH10]. But the present study context is a software project for a local customer.…”

Section: Comparison Of the Study Results With Previous Researchmentioning

confidence: 99%

“…We have observed through the case studies [Isl09,IHMFJ09], that a requirement engineer is capable to contribute in risk management activities. In real project situation, for small or medium size project, there may not be any risk manager due to budget constraints [Isl09,IHMFJ09,IH10]. Project manager is concerned with the overall project execution and takes the additional role as risk manager.…”

Section: Integration Of Gsrm Into Requirements Engineeringmentioning

confidence: 99%

See 2 more Smart Citations

Software development risk management model

Islam

2009

Proceedings of the Doctoral Symposium for ESEC/FSE on Doctoral Symposium

Self Cite

View full text Add to dashboard Cite

Every software project by its inherent nature is unique and contains significant numbers of uncertainties from various perspectives such as time-to-market, budget and schedule estimation, product deployment or maintenance. If failing to control these uncertainties, it imposes potential risks not only during the development phases but also throughout the life cycle of the product. Software risk management is an effective tool to control these risks and contributes to increase the likelihood of project success. Risk management needs to be integrated as early as possible from a holistic perspective into the development. However a comprehensive risk management practice is not always possible due to resource problems, more emphasize on budget and schedule constraints and difficulties to concretely estimate the benefit of risk management.This thesis proposes a Goal-driven Software Development Risk Management Model (GSRM) that explicitly integrates into the requirements engineering phase. The integration provides an early warning of potential problems so that both preventive and corrective actions can be undertaken to avoid the causes of project failure. The framework is comprised of four layers, i.e., goal, obstacle, assessment and treatment, that support the identification, assessment, treatment and documentation of risks in relation to project-specific goals. GSRM is implemented in active on-going software development projects to empirically evaluate its usefulness, particular advantages and limitations in an industrial context. The results show that goaldriven approach is suitable for risk management and risk management is well integrated into requirements engineering phase. It is not always necessary to rank budget and schedule related goals and risk factors at the highest priority for risk management. At the early stage of the project risk factors related to estimation, project management, project scope, requirements, change management and human (i.e. customer/user and practitioner) and at the later stage risk factors related to user satisfaction and product usage are more frequent and severely affect meeting the project goals. If project risk factors are beyond the control of a project manager and project development environment, it is difficult to control the risks. The results conclude that early risk management practice is necessary and GSRM contributes to this direction for a successful project outcome. ZusammenfassungJedes Software-Entwicklungsprojekt ist einzigartig und geprägt von schwer planbaren Einflussfaktoren, wie time-to-market oder Budget, aber auch von Einflüssen resultierend aus der Integration und der Wartung. Die Beherrschung dieser Einflussgrößen ist unabdingbar für die Minimierung der Risiken während der Entwicklung als auch während des gesamtem Software-Lebenszyklus.

show abstract

Section: Plan Risk Managementsupporting

confidence: 78%

Section: Comparison Of the Study Results With Previous Researchmentioning

confidence: 99%

Section: Integration Of Gsrm Into Requirements Engineeringmentioning

confidence: 99%

See 1 more Smart Citation

Software development risk management model

Islam

2009

Proceedings of the Doctoral Symposium for ESEC/FSE on Doctoral Symposium

Self Cite

View full text Add to dashboard Cite

show abstract

“…It is worth stating that the focus of this paper is not to present in detail the GSRM framework but rather to present its applicability and its empirical usage in a case study. GSRM has partially been presented in other publications [34,35,36]. This section presents a brief overview of GSRM, which demonstrates some distinguished characteristics, i.e., i) the explicit integration of risk management into the early development stages, ii) the involvement of project stakeholders as an active contributor to the risk management process, and iii) the usage and modelling of goals to rationalize risk management.…”

Section: Overview Of the Goal-driven Software Development Risk Managementioning

confidence: 99%

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

Islam

Mouratidis

Weippl

2014

Information and Software Technology

Self Cite

View full text Add to dashboard Cite

Context: Building 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. Objective:Despite 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. Method:We combined case study method with action research. This allows to guide the development team for managing risks and to attain goals as well as to identify ways to improve the proposed methodology. The data is from multiple sources and analysed both qualitative and quantitative way. Results: When risk factors are beyond the control of the project manager and project environment then it is difficult to control these risks. Project scope affects all dimensions of risk. GSRM is a reasonable risk management method that can be employed in an industrial context. The study results compare with other existing study results, to generalize findings and to identify contextual factors. Conclusion: A formal early stage risk management practice provides early warning related to the problems that exists in the project and contributes to the overall project success. It is not necessary to always consider budget and schedule constraints top priority. There exist issues such as requirements, change management, and user satisfaction influence these constraints.

show abstract

“…The Risk List includes a description of all risks that are related to project-specific requirements. The conceptualisation of requirements risks is considered on the basis of an artefact model [28,29]. The Requirements Risks are implied by the various types of Requirements and we use the risk list as an interface to risk management.…”

Section: Risk List Natural Textmentioning

confidence: 99%

Artefact-based requirements engineering: the AMDiRE approach

Méndez

Penzenstadler

2014

Requirements Eng

View full text Add to dashboard Cite

The various influences in the processes and application domains make Requirements Engineering (RE) inherently complex and difficult to implement. In general, we have two options for establishing an RE approach: we can either establish an activity-based RE approach or we can establish an artefact-based one where project participants concentrate on the RE artefacts rather than on the way of creating them. While a number of activity-based RE approaches have been proposed in recent years, we have gained much empirical evidence and experiences about the advantages of the artefact-based paradigm for RE. However, artefact orientation is still a young paradigm with various interpretations and practical manifestations whereby we need a clear understanding of its basic concepts and a consolidated and evaluated view on the paradigm.In this article, we contribute an artefact-based approach to RE (AMDiRE) that emerges from six years of experiences in fundamental and evidence-based research. To this end, we first discuss the basic notion of artefact orientation and its evolution in recent years. We briefly introduce a set of artefact-based RE models we developed in industrial research cooperations for different application domains, show their empirical evaluations, and their dissemination into academia and practice, eventually leading to the AMDiRE approach. We conclude with a discussion of experiences we made during the development and different industrial evaluations, and lessons learnt. Evaluation Research Synthesis AMDiRE Artefact Model 1 Case Study 1 Artefact Model n Case Study n Operationalisation Models, Templates, Tools Internal Evaluation Case StudyFig. 1: The applied research method.developments lead to an improvement of previously used activity-based RE approaches, we do not provide such evaluation for AMDiRE in this paper. The reason is that we reached the point where it yet has to be shown whether our approach can be used by others if we are not involved at all, thus, we need an external evaluation independently carried out by unbiased researchers and practitioners not involved in the development of AMDiRE. For this reason, we make our contribution and its operationalisation (e.g. relating models, tools, and evaluation templates) openly accessible [37] and disseminate our results from 6 years of research with the article at hand. This lays the foundation for the final external evaluation, depicted on the right side of Fig. 1.Outline. The remainder of the article is as follows. In Sect. 2, we discuss the work directly related to our contributions, and the gaps we intend to close. We conclude with a discussion of the fundamentals in artefact orientation and the terminology we use in context of this article. In Sect. 3, we then introduce the background of artefact orientation resulting from our fundamental, conceptual, and empirical work in this area, i.e. introduce the previously developed artefact models and give a first introduction into the different case studies we conducted with those models. After discussing t...

show abstract

Offshore-outsourced software development risk management model

Cited by 7 publications

References 10 publications

Software development risk management model

Software development risk management model

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

Artefact-based requirements engineering: the AMDiRE approach

Contact Info

Product

Resources

About