Risk Management

You might also like

Download as pdf
Download as pdf
You are on page 1of 4
ACTIVITY NO. 8 RISK MANAGEMENT A New software intended for the Registrars Office (department) in MQC will be developed and entrusted to you as the Project Head. The software is intended to: 1. Facilitate faster enrolment in the college 2. Track records of dropped, Incomplete and failed grades of students 3. Track professors encoding of Prelim, Midterm and Final Grades 4. History of students subjects taken and to be taken 5. List of subjects of all the programs offered in MQC. 6. List of subjects with pre requisites per programs offered in the College. The new software is intended to be used next semester (2nd Sem AY. 2022 — 2023). As the Project Head, identify, assess and evaluate the list of “risk” that you and your team of software specialist will encounter during the programming of the new software. List down at least 5 Risk. Explain, Evaluate, Give Level of Risk, and how to treat each risk identified. Answer (Analysis) 5 risk in software development 1. Lack of communication between the project team and the client. Lack of communication ranks among the highest risk in software development. Miscommunication results to significant delays and budget overruns. Level of Risk: High Solution: Choosing the right communication tool helps to organize conversationsand information exchange, reduces errors, and promotes smooth work. Make sure there is effective communication between the project leader, the team, and the client. Receiving feedback and exchanging of information will be significant to the success of the project. 2. Insufficient software testing Software testing is one of the top priority in software development. Through testing, developers able verify and evaluate if the software product does what it is supposed to do. Thus, lack of testing will increase the chance of experiencing issues, failures and glitches and bugs and also could cause security breaches. Level of Risk: High Solution e@ Validate and verify the software by examining whether or not the software satisfies the client's requirements. e@ Testing the functionality is also important, if the output product matches the desired results then the software is considered as ‘ok’. e@ Use the right tools and techniques for testing to improve the overall quality of the software. 3. Tight Time schedule for the completion of software. The time given by the client is not enough for the Project team to satisfy all the client's requirements in building the software. Level of Risk: Medium Solution: Discuss with the client the issue of not being able to meet all of its requirements in building the software due to tight deadlines. By suggesting that it either extend the deadline or advise the client to remove other requirements from the list. With those suggestions in hand, ask the client to provide the final list of software requirements. 4. Cost/budget risk @ The budget is not enough to fulfill all the project requirements. @ Underestimating project expenses in relation to the project budget will also cause delays. As a result, the project's cost will increase. Level of Risk: Medium Solution @ Discuss with the client that the budget is insufficient. @ Provide an estimated budget for software development so that necessary budget adjustments can be made. e@ Always include contingency budget in the plan for the unforeseen project expenses. 5. Scope variation risk As a result of end-user input, the client's requirements may change, which will delay the project's progress. The ongoing software development process will be significantly impacted if the customer consistently modifies the specifications for the ideal software it desires, such as by adding new requirements, modifying existing ones, or removing requirements altogether from the initial plan. This risk will drive up project costs as well as causing delays. Level of Risk: High Solution Maintain structured communication between the project team and the client at all times. All of the requirements provided should be considered final after consultation with the client. The contract should state that specifications cannot be changed when software development is already underway.

You might also like