Software Risk Identification - Book Report/Review Example

 Software Risk Identification The identification of software risk has turned out to be one of the major aspects to be considered in the software firms if their success is to be realized. Various scholars have proposed a number of models that can be made use of to manage software risks after their identification. In as much as these models are useful in software risk identification, some of them propose weak ideas in an attempt to identify and mitigate software risk. Among the four models provided, this study has selected the article 05381181 (incremental model) as the weakest. This is due to the fact that compared to the other three models; the article lacks proper premises to base its arguments. It does not demonstrate a thorough review of literature hence the arguments are invalid. In addition, the model simply tells us what should be done and not how what is to be done should be done. This article, unlike the others, does not have any quantitative presentation of data collected, either in form of a pie chart, flow chart or table. In addition it does not explain how what is to be done should be done. For these reasons it has distinguished itself as the weakest model brought forth in software risk identification. However the model has some relevant and appropriate strategies that if improved, can bring about great change in the software risk management sector. This model presents various risk factors and tries to suggest various methods of mitigating the identified risks. This study will therefore critically analyze the risk factors brought forth by this model and the mitigation strategy proposed. a) Few requirement descriptions This model claims that the customers are unable to illustrate the entire requirements at the onset of the project. As a result, these requirements continuously originate even during the process of software development. According to the model, this can greatly impact on the life cycle of the software development (Basit & Tanvir 2005). The model however fails to explain how this risk factor affects the life cycle of the software development. It proposes various measures of mitigating or avoiding this risk factor. It proposes for considering the disability of mentioning every requirement at the time of proposing that the two parties can arrive into a conclusion in determining the extent to which the project can change after a certain period of time. This strategy does not therefore directly solve the problem of software risk but is rather a precautionary measure to take care of software changes. Determination of the expansive outline of the software is also significant. It also suggests that the requirement provider ought to have sufficient knowledge about the domain and should be in a position to make clear all that he requires in the software. This proposal may not however be practical. It does not give much thought the individual differences. It assumes that people who use software services have vast knowledge on software. b) Project size estimation This model requires the experts in the development firms to assist in identifying the real scope of the project. They should ensure that the project is not under estimated. Similarly, there must be no over estimation of the capabilities of the team developing the software (Basit & Tanvir 2005). In as much as the actual scope of the project can be determined using software size estimation matrices and tools, it is not easy to determine the actual capability of a human being. Estimating the capability of the software experts may hence not be realistic. There is also a possibility that the experts may be incapable of scrubbing the requirements after being finalized by the two parties. c) Project funding uncertainty The model proposes that the software development team should not seek for any favor related to either requirement scrubbing or time, from the customers. It further states that the development team should possess sufficient commitments emanating from the funding bodies at the onset of the project to avoid facing any financial situation should the customer pull out from the project at a final stage (Basit & Tanvir 2005). The team is also expected to sustain good relations with their customers. It also advocates for giving the customer updates concerning the problems arising and the achievements at every point in time to inform them on the development of the project (Basit & Tanvir 2005). This gives them a chance to continuously fund the project. Despite being a good strategy, the actual funds required for a project may not be easily determined. Also, the customer may not be readily equipped with the funds at the point in time when the development team requires the funds when a problem arises. d) Staff experience The incremental model advocates for the hiring of experienced personnel. These experienced personnel help in saving the money. They also assist in bringing about more revenues than the one being incurred on him. In order to make this proposal effective, there is need to arrange joint seminars with lucrative institutions such as universities (Basit & Tanvir 2005). This allows for sourcing of potential graduates who can provide the necessary labor in the software sector. If there are adequate resources, the organization can organize at least monthly visits to renowned professionals outside the country or even within. Tutorial programs on the latest developments should also be arranged by the firm (Basit & Tanvir 2005). These strategies are aimed at giving the employees an occasion to share their thoughts and ideas with knowledgeable and experienced professionals. This enables these employees to learn in a practical manner. This step however lies on the ability of the employees to emulate and apply the new knowledge gained from the experts. Before venturing into this strategy, it is important therefore to assess whether it can result into the desired positive change or not. e) Rapid change of job This model advocates for trusting the employees and giving them sufficient relevant training to make them not to contemplate changing the job merely as a result of stressful environment or less motivation. The firm must make sure that the employees with much knowledge and experience are sustained in the organization (Basit & Tanvir 2005). In order to realize this, they should be given privileges and attractive perk such as medical and house allowances. However, this strategy fails to consider that other firms may have better and more lucrative rewards to employees. Extra benefits may also be offered through implementation of uniform systems of grading. To be able to fund all these projects, the firms can secure loans for the employees. In addition, the model proposes that the employees should updated on the salary packages provided in the market. Moreover, the junior employees as well as the employer are expected to show respectable behavior and respect towards the more experienced team leaders. This claim however needs to be improved. For any organization to realize success, respect should be made a two way thing. Both the juniors and the seniors should respect each other. f) Change in working circumstances by management To be able to get along with the changing problems, the management should be flexible enough to consider changing the situations of the project when the need arises. A good manager is expected to gather necessary requirements before starting the project (Basit & Tanvir 2005). He should not at any circumstance, force any employee to work beyond the designated time. They should also assess the availability of the employees within the required duration of a project before assigning new projects to them. Only those available for the whole period the project is to take are to be assigned the duty. The proposal appears tricky since it is rigid and fixed. It does not take into account the intervening factors such as illnesses that might affect these selected employees. There should be other workers who are strategically placed to assist incase the need arises. g) Staff inexperience The model proposes that there must be strict rules that bar employees from taking out the official documents out of the firm. This is to prevent unlawful transfer of documents to the external environment. This proposal however needs to be extended to cover not only employees but the whole body of the firm. h) Low estimation of time and cost According to this model, there should be no underestimation of the scope of the project (Basit & Tanvir 2005). The firm must also be optimistic all the time regarding the completion of the project. To achieve this, the model advocates for giving the developers confidence. Employees who have vast knowledge and experience should be granted a chance to exercise their abilities and to work efficiently. In as much as the scope of the project should not be estimated, the model fails to come up with a strategy that can gauge the exact cost and time required for a particular project. i) Hardware default changes The management should be in a position to forecast the advancement in technology in the hardware resources. The activities concerning the software development should execute on all the sectors of hardware for a number of years. The model however does not give a clear direction on how this technological advancement can be forecasted. It also fails to put into account the fact that the developed hardware may not be compatible with the previous ones. j) Requirement postponement Owing to the difficulty in identifying requirements, there should be no delays in any identified requirement (Basit & Tanvir 2005). All the possible situations must be estimated from the onset to gauge whether there is an overload or whether some have been left out. This can be realized when appropriate monitoring mechanisms are employed in the firm. It is however important to ensure that there is no rush in the requirements. The management should conduct feasibility test before starting any project to ensure that the project is worth venturing into. k) Technology Change This model brings forth the idea that the programmer is supposed to be encouraged to have competence in the use and handling of more than one tool. They must also be great thinkers to be familiar with the coming styles and practices in upcoming software development. The programmers also need to equip themselves with upcoming software tools The firm must not inflict some projects of new or unfamiliar procedures to the employees. For the use in training, during the training periods, the employees should be given technical assignments in order to assist them in learning the tools and assessing them in terms of their workability and to gauge whether they are sustainable for larger projects. Programmers who are specialist in advance programming environments should be hired to deal with new projects. In a successful team structure programmer dealing with orthodox environments are likely to be benefited. In as much as this proposal may seem to be helpful to the firm, it is not easily applicable. Technical software tools require vast knowledge and experience to operate. It could be helpful if the model proposed a way of encouraging the experts to use or handle these tools. l) Lack of technical feed back This model proposes the process of gathering requirement gathering is technical and deserves thorough consideration. It adds that the parties involved in this process should ensure effective communication at all the level. Communication should be made perfect both within the firm and also with the customer. For instance, before signing a contract, the head of organization is expected to consult its technical staff. These will the effect of minimizing the chances of loss. To successfully realize this, the model advocates for covering of all the requirements in the initial iteration. It stresses that that the development team should ensure that all the requirements are addressed. Reference Basit Shahzad, Tanvir Afzal, (2005). Enhanced risk analysis and relative impact factorization 1st ICICT, IBA Karachi, 27(28), 290-295. Read More