RISKS IN SOFTWARE DEVELOPMENT

By June 20, 2015

 

As a result of the conditions on the global software market, the software industry is becoming more ruthless everyday. In recent years, software solutions have become extremely complex, and the complexity of software solutions is growing everyday (Sertić, 2002). The global market requires software with new features and capabilities developed in small time frames. Conditions on the global software market demand new levels of usability, quality, reliability, and performance from software solutions. The only chance for enterprises to survive on such a market is to build software that is better than the competition, in the shortest possible time. Building quality software in the terms defined by the conditions from the global software market is fundamentally hard and connected with a high level of risk (Hall, 1998). Risks are present in every aspect of software development. Software development is a special kind of engineering activity because of the involved knowledge and technology, so it is common to say that risks have an extremely high influence on the success of software development projects (Jones, 1994). There are numerous kinds of risks that can cause software development project failure.

A risk can be defined as a consideration that has some degree of probability of compromising the success of a software development project (Karolak, 1995). Formally, risk can be described as project variables that designate project success (Capers, 1994). Risk defines the probability that the software development project will experience unwanted and inadmissible events, such as termination, delays in project schedule and overrun of project resources. Risk is the possibility of suffering loss that describes the impact on the project which could be in the form of poor quality of the software solution, increased costs, failure, or delayed completion. Software development is specific because risks in software development can be classified in many categories. It is difficult to clearly define risk categories that could apply to a wide area of software development projects. The essence of risk classification is not in precisely defining risk categories, but in identifying and describing as many risks as possible on the project. Due to that, it is suggested that risks on software development projects should be classified according to the main impact areas (Ould, 1996).

For most software development projects, we can define five main risk impact areas: (1) The use of new and unproven technologies, (2) software system requirements, (3) software system architecture, (4) software system performance and (5) organizational and non-functional area.

The most important risk impact area is connected to the problems related to new technologies. The majority of software development projects is connected with the application of new technologies. The improper use of new technologies usually leads to project failure. Knowledge is the main problem connected with the use of new technologies (Sertić, 2002). In order to implement new technology, a development team should have sufficient knowledge about it. The importance of knowledge about technologies involved in a software development project is often disregarded. Software solution is built upon technological features, which are often new to a project development team. These technological features are often predicted at the beginning of a software development project, and only a software prototype can prove these predictions (Larman, 2002). The knowledge about these technological features can refine predictions about features and minimize the risk connected with the use of these technologies. A software development team should have sufficient knowledge in order to efficiently exploit technological features. The knowledge about the involved technologies is a precondition for a successful software development project (Ould, 1998).

The second important risk impact area is connected with software requirements. Software requirements are a common term for all users’ needs regarding software system functionality and quality of service. It is often very hard to develop the right software solution that absolutely meets users’ expectations. In order to develop a software solution according to user expectations, a software development team should discover a whole set of user requirements (Larman, 2002). These requirements, that must guide the entire development process, can be divided into functional and non-functional (Larman, 2002). Functional requirements define behavior of the software solution, while non-functional requirements define qualities and constraints to which the software solution must conform.

The process of the identification and definition of requirements is long and complicated, so it is common that requirements change during the realization of a software development project (Booch, Rambaugh & Jacobson, 2001). The change of requirements is a major problem in software development because the change of one or few requirements could impact the complete software solution and lead to the failure of a software development project. As a result, it is absolutely necessary to find the right requirements and to manage the change of requirements during a software development project.

The third important risk impact area is the architecture of a software solution. Software architecture could be described as a set of significant decisions about the organization and components of a software solution (Booch, Rambaugh & Jacobson, 2001). Software architecture must be defined in the early development phases in order to build a quality software solution. It is possible that software architecture defined in the early development phases does not satisfy all of the requirements set on a software solution. The software architecture can be verified only with a software prototype, which can be realized only in later development phases. Due to the importance of software architecture, many development processes focus directly on software architecture in order to build a quality software solution according to the defined requirements (Royce, 1998).

The fourth risk impact area is connected with software system performance. In order to satisfy non-functional requirements, a software solution should have satisfactory performance. The performance of a software solution could be tested only on a real and realized software solution. Thus, it is necessary to make predictions about software system performance in the early development phases. These predictions are very important because it is possible to develop a software solution that satisfies functional requirements, but it is too slow to fulfil performance requirements (Karolak, 1995). As a result, development team members, with experience in given technologies, should do performance predictions and assumptions.

The fifth risk impact area could be considered as the organizational and non-functional area. The risks connected with this area could be described as organizational problems and problems related to the project resources and schedule. Organizational problems may affect the realization of a software solution since only the efficient organization of software development leads to a successful software development project (Sertić, 2002). A defined project schedule could become a risk because there are many unwanted events that could cause a delay in software realization. It is a management problem to define a project schedule in order to satisfy both customers and developers (Ould, 1996). In order to fulfil defined project deadlines, resources given to the project should be sufficient. This means that every software development project should have enough project members with the right competencies and all the required resources for the planned completion.

Besides risk identification and specification, risks in software development should be addressed and managed. In software development, there are many choices of dealing with risks (Ould, 1998). Based on the risk impact area and type, risks can be avoided, restricted, mitigated and monitored (Jones, 1994). The best possible way of risk addressing is to completely avoid risks. There are a number of risks that can completely be avoided by the use of different technologies, changing requirements or project plans. The next best way to address risks on the project is to confine them. A risk can be confined in order to restrict the risk impact area to affect only a small part of a software development project. In order to reduce the impact area, risks must be identified and some changes on the project should be made regarding the technology and resources used. This is a proper way of addressing risks that cannot be avoided.

There are many risks that cannot be avoided or confined. These risks should be mitigated or monitored. Some risks on a project can be mitigated by the realization of a software prototype in order to try the risks and perceive if they will materialize or not. It is better that risks materialize on a software prototype than on a real software solution because a software development team can learn on a software prototype and discover a way to avoid or confine materialized risks.

If risks cannot be mitigated, they should be constantly monitored in order to track their materialization. For these risks, contingency plans should be done to define activities to be taken if they materialize. The risks that cannot be mitigated introduce a serious threat to a software development project, so they should be considered as highly important. After the materialization of such risks, a complete project assessment and decisions about the project future should be made. Risks can be identified and addressed in different phases of a software development project, but it is essential to identify risks as early as possible and address them promptly because the cost connected with exposed risks could be enormous (Larman, 2002).

Addressing risks is time-consuming. It takes time to change project plans in order to avoid some risks and it takes time to build prototypes needed for risk mitigation. Thus, it is difficult to address all risks at the same time. In order to successfully address risks that arise on a software development project, it is necessary to divide risks into categories by priority and to plan software development according to risk priorities. For successful project planning and realization according to risks categorized by priority, it is required to have risk management as a continuous activity on a software development project.