FAQ on Software Engineering (Unit 5)
1. Modifying the software to match changes in the ever changing environment is called ________
1) Adaptive Maintenance
2) Corrective Maintenance
3) Preventive Maintenance
4) Perfective Maintenance
2. Software Project Management comprises of a number of activities, which consists of _______
1) Project Planning
2) Scope Management
3) Project Estimation
4) All the above
3. Effective Software Project Management focus on the four P’s. What are those four P’s?
1) People, Performance, Payment, Product
2) People, Product, Process, Project
4) None of the Above
4. If P is Risk Probability, L is Loss, then Risk Exposure is computed as __________________
1) RE = P/L
2) RE = P*L
3) RE = P+L
4) RE = 2*P*
5. Staff turnover, poor communication with the customer are risks that are extrapolated from past experience are called ________________
1) Business Risks
2) Predictable Risks
3) Project Risks
4) Technical Risks
Risk in Software Engineering refers to any problem that might occur during the development to incur some loss in the end product or in the process or in the successful completion of the project work itself.
Risk can be defined as follows:
- It is an uncertain event or condition that, if it occurs, has an adverse (negative) impact on project objectives such as time, cost, quality, or performance of the software product or process.
- Risks can arise from any person or any resource involved in the development process such as technology, people, processes, requirements, environment, or business.
👉 Examples of risks involved in software development:
- Key developer leaving the project (people risk)
- Technology newly introduced, not working as expected (technical risk)
- Sudden changes in customer requirements (requirement risk)
- Delay in hardware/software delivery (scheduled risk)
- Risk management is the process of identifying, addressing and controlling the risks before or after they occur during the lifecycle of software development.
- To deal with risks, software engineers use any one of the following strategies: Reactive or Proactive risk management.
- In Reactive approach, no major effort is made to identify or plan for risks beforehand. This approach is also called as the crisis management approach.
- Risks are addressed only after they occur in Reactive Risk management that often leads to cost overruns and delays.
👉 Example: A project team that does not anticipate the risk of a developer leaving.
When a developer suddenly quits, the team scrambles to reassign tasks and train a replacement, causing project delays.
- In Proactive strategy of risk management, risks are identified, analyzed, and planned for before they occur.
- The team develops risk management plans, including mitigation and contingency plans. This minimizes damage and increases project stability.
👉 Example: The project team that anticipates a key developer leave.
A proactive team cross-train other team members and document code thoroughly. When the developer actually resigns, the impact is minimal, and the project continues smoothly.
Question 2:
- In Software Engineering, risk refers to the possibility of an undesirable event that can negatively impact the successful completion of a software project.
- Software risk refers to the probability of loss combined with the consequences of that loss that may occur during the development of software
- Software risks can arise from people, process, technology, business, or external factors.
- Identifying, analyzing, and managing these risks early is crucial to ensure software projects finish on time, within budget, and with good quality.
A risk usually has three main components:
- Uncertainty – The risk may or may not happen.
- Loss – If the risk occurs, it can cause negative effects (cost, time, performance, quality, etc.).
- Impact – The severity of damage it can cause to the project or organization.
👉 Example:
- If requirements are not properly understood (uncertainty), the software may not satisfy user needs (loss), leading to project failure (impact).
Types of Software Risks:
Risks in software development can be categorized in different ways. A widely used classification is:
i) Project Risks
- Related to the environment in which the project is being developed.
- They affect schedule, resources, cost, and people.
- Examples:
- Unrealistic deadlines.
- Inadequate budget allocation.
- Lack of skilled developers/testers.
- Poor communication among team members.
ii) Technical Risks
- Related to the technology used in the project.
- They threaten the quality, performance, or functionality of the software.
- Examples:
- Use of new or unproven technology.
- Integration issues with third-party tools or systems.
- Technical complexity not well understood.
- Performance or scalability failures.
iii) Business Risks
- Associated with the market or business impact of the software product.
- Examples:
- Product fails to meet user needs.
- Competitors release better software earlier.
- Change in business priorities.
- Customer may cancel the project.
iv) Operational Risks
- Risks that affect the daily operation and support of the software.
- Examples:
- Inadequate maintenance plan.
- Poor documentation for users or developers.
- System downtime or data loss after release.
v) External Risks
- Risks beyond the control of the project team.
- Examples:
- Changes in government regulations or legal policies.
- Natural disasters (flood, earthquake).
- Market changes due to new competitors.
vi) Schedule Risks
- Directly related to time management of the project.
- Examples:
- Wrong effort estimation.
- Unexpected delays in key tasks.
- Dependency on external vendors or clients causing slippage.
vii) Cost Risks
- Related to budget overrun and financial mismanagement.
- Examples:
- Underestimation of total development cost.
- Increase in hardware/software licensing fees.
- Unexpected resource requirement.
Question 3:
Briefly explain the steps involved in risk planning for software development.
Risk planning in software development involves identifying, analyzing, and preparing strategies to manage potential risks that could affect the project. The key steps are:
-
Risk Identification:
List all possible risks that could impact the project — such as technical failures, cost overruns, schedule delays, or resource issues. -
Risk Analysis:
Evaluate each identified risk to determine its likelihood (probability of occurrence) and impact (effect on project objectives). -
Risk Prioritization:
Rank risks based on their severity (a combination of likelihood and impact) to focus on the most critical ones. -
Risk Response Planning:
Develop strategies to handle each major risk. Common strategies include:- Avoidance: Change plans to eliminate the risk.
- Mitigation: Reduce the likelihood or impact.
- Transfer: Shift responsibility (e.g., insurance or outsourcing).
- Acceptance: Acknowledge the risk and prepare contingency plans.
-
Risk Monitoring and Control:
Continuously track identified risks, detect new ones, and update risk plans throughout the project lifecycle.
These steps help ensure that risks are managed proactively, improving the project’s chances of success.
Question 4:
Discuss the RMMM plan in detail.
- The RMMM Plan stands for Risk Mitigation, Monitoring, and Management Plan.
- It is a crucial document in project management, particularly in software engineering, that systematically addresses the risks identified during the risk analysis process.
- Its purpose is to provide a structured strategy for dealing with potential problems to ensure that the project stays on track in terms of schedule, budget, and quality.
The plan is divided into three primary, sequential components:
This is a proactive activity focused on reducing the probability or impact of a risk event before it occurs. The goal is to avoid the risk entirely or reduce it to an acceptable level.
Objective: To prevent the risk from becoming a reality.
Key Activities:
- Identify Causes: Determine the root causes that could trigger the risk.
- Proactive Plan: Develop and implement strategies to eliminate or control those causes.
Examples of Mitigation Strategies:
- For high staff turnover risk: Improve working conditions, offer competitive compensation, organize project teams to disperse information widely, define clear documentation standards, and assign a backup for every critical technologist.
- For technical risks (e.g., complexity): Prototype the complex parts, conduct early and frequent technical reviews, and invest in specialized training
Documentation: Detail the specific mitigation steps, the resources required, and the timeline for execution.
This is the process of continuously tracking the identified risks, assessing the effectiveness of the mitigation efforts, and watching for new, emerging risks.
Objective: To determine if the predicted risks are becoming more or less likely, and to ensure that the mitigation steps are being applied correctly and are working.
Key Activities:
- Track Indicators (Risk Triggers): Monitor specific metrics or conditions that act as warning signs that a risk is about to occur. For instance, in the case of staff turnover, a project manager might monitor the general attitude of team members, interpersonal relationships, or unsolicited job inquiries.
- Regular Reviews: Periodically review the risk list (often maintained in a Risk Register or Risk Information Sheet - RIS) with the team to re-evaluate the probability and impact of each risk.
- Status Reporting: Communicate the current status of risks and the effectiveness of mitigation activities to all stakeholders.
This is a reactive strategy that comes into play if the mitigation and monitoring efforts fail and a risk actually materializes, turning into a problem.
Objective: To control the damage and recover from the problem with minimal disruption to the project.
Key Activities:
- Define Contingency Plans: For high-impact, high-probability risks, a detailed Contingency Plan (sometimes called a "Plan B") is created. This plan outlines the specific actions to be taken after the risk has occurred.
- Identify Resources: Determine the necessary resources (time, budget, personnel) required to execute the contingency plan. This budget is often called the Contingency Reserve.
- Example of Management Strategy: If a key team member quits (the risk becomes a problem), the contingency plan might involve immediately reassigning their critical tasks to the designated backup staff member, temporarily re-prioritizing the project schedule, or bringing in a specialized contractor.
- Responsibility and Authority: Clearly assign a Risk Owner (usually the project manager or a team lead) who has the responsibility and authority to activate the management plan when the risk threshold is crossed
A formal RMMM plan is typically documented with following details:
Risk Register/Information Sheets (RIS): A detailed log of all identified risks. For each risk, it records:- A description of the risk
- The probability of occurrence
- The potential impact/severity
- The trigger/monitoring indicators
- The Mitigation steps (proactive actions)
- The Contingency plan (reactive actions).
Methodology: A description of the overall approach to risk management, including tools and techniques.
Budget and Schedule: Allocation of resources and time for all risk-related activities.
Roles and Responsibilities: Clear definitions of who is responsible for each part of the RMMM process.
