This document defines risk and risk management strategies for software projects. It discusses reactive versus proactive risk strategies, with proactive being preferred. It describes approaches to categorizing, identifying, and assessing risks. Key aspects of risk management covered include developing a risk table, estimating probability and impact, and creating plans to mitigate, monitor, and manage risks. The overall goal is to identify risks early and take steps to avoid or minimize their impact on the project.
This lecture provides short and comprehensive view of software project and risk management. It has basic examples and calculations which is main concern of software project manager. This lecture helps to understand basics of risk management.
Risk management involves identifying potential problems, assessing their likelihood and impacts, and developing strategies to address them. There are two main risk strategies - reactive, which addresses risks after issues arise, and proactive, which plans ahead. Key steps in proactive risk management include identifying risks through checklists, estimating their probability and impacts, developing mitigation plans, monitoring risks and mitigation effectiveness, and adjusting plans as needed. Common risk categories include project risks, technical risks, and business risks.
Software Project Management: Risk ManagementMinhas Kamal
Software Project Management: ResearchColab- Risk Management (Document-7)
Presented in 4th year of Bachelor of Science in Software Engineering (BSSE) course at Institute of Information Technology, University of Dhaka (IIT, DU).
The document discusses various aspects of risk management for software engineering projects. It describes reactive risk management where risks are addressed after they occur versus proactive risk management where formal risk analysis is performed upfront. It outlines seven principles for effective risk management including maintaining a global perspective, encouraging open communication, and emphasizing a continuous process. The document also discusses different aspects of risk management such as risk identification, assessment, projection, and mitigation strategies.
Risk management in software engineeringdeep sharma
The document discusses risk management in software engineering. It defines risk as a potential problem that may or may not occur, causing negative impacts. It categorizes risks as project risks, technical risks, and business risks. It outlines the risk management paradigm of identifying, analyzing, planning, tracking, controlling, and communicating risks. It also discusses establishing a risk mitigation, monitoring and management plan to document the risk analysis work. The key is to identify risks early, evaluate and prioritize them, then develop and implement risk mitigation plans.
This document discusses software risk management. It defines risk as any unfavorable event that could hamper a project's completion and risk management as reducing the impact of risks. The importance of software risk management is outlined, noting it addresses complex systems, focuses on critical risks, and can reduce costs through less rework. Risk assessment involves rating risks based on their likelihood and severity to determine priority. Risk identification involves categorizing risks into project, technical, and business risks. Risk containment strategies include avoiding, transferring, and reducing risks. Methodologies discussed include software risk evaluation, continuous risk management, and team risk management.
Risk Mitigation, Monitoring and Management Plan (RMMM)Navjyotsinh Jadeja
Software Risk is an expectation of loss, a potential problem that may or may not occur in the future. It is generally caused due to lack of information, control or time.
RISK – Possible loss or problem (Specifically in S/W development process)
MITIGATION – Efforts or Process to overcome the Risks or reduce the impact. (Comes after Avoidance Scenario)
MONITORING – Check to ensure effective execution (Observation)
MANAGEMENT – The subtle are of dealing with the risk and keep moving forward
The document discusses risk management for projects. It covers risk identification, which involves categorizing risks and identifying known and predictable risks through checklists and questionnaires. It also discusses risk projection, which involves estimating the probability and impact of risks. Finally, it discusses developing a risk table to prioritize risks and plan risk mitigation, monitoring, and management strategies. The overall goal is to proactively address risks to avoid issues and have contingency plans.
This lecture provides short and comprehensive view of software project and risk management. It has basic examples and calculations which is main concern of software project manager. This lecture helps to understand basics of risk management.
Risk management involves identifying potential problems, assessing their likelihood and impacts, and developing strategies to address them. There are two main risk strategies - reactive, which addresses risks after issues arise, and proactive, which plans ahead. Key steps in proactive risk management include identifying risks through checklists, estimating their probability and impacts, developing mitigation plans, monitoring risks and mitigation effectiveness, and adjusting plans as needed. Common risk categories include project risks, technical risks, and business risks.
Software Project Management: Risk ManagementMinhas Kamal
Software Project Management: ResearchColab- Risk Management (Document-7)
Presented in 4th year of Bachelor of Science in Software Engineering (BSSE) course at Institute of Information Technology, University of Dhaka (IIT, DU).
The document discusses various aspects of risk management for software engineering projects. It describes reactive risk management where risks are addressed after they occur versus proactive risk management where formal risk analysis is performed upfront. It outlines seven principles for effective risk management including maintaining a global perspective, encouraging open communication, and emphasizing a continuous process. The document also discusses different aspects of risk management such as risk identification, assessment, projection, and mitigation strategies.
Risk management in software engineeringdeep sharma
The document discusses risk management in software engineering. It defines risk as a potential problem that may or may not occur, causing negative impacts. It categorizes risks as project risks, technical risks, and business risks. It outlines the risk management paradigm of identifying, analyzing, planning, tracking, controlling, and communicating risks. It also discusses establishing a risk mitigation, monitoring and management plan to document the risk analysis work. The key is to identify risks early, evaluate and prioritize them, then develop and implement risk mitigation plans.
This document discusses software risk management. It defines risk as any unfavorable event that could hamper a project's completion and risk management as reducing the impact of risks. The importance of software risk management is outlined, noting it addresses complex systems, focuses on critical risks, and can reduce costs through less rework. Risk assessment involves rating risks based on their likelihood and severity to determine priority. Risk identification involves categorizing risks into project, technical, and business risks. Risk containment strategies include avoiding, transferring, and reducing risks. Methodologies discussed include software risk evaluation, continuous risk management, and team risk management.
Risk Mitigation, Monitoring and Management Plan (RMMM)Navjyotsinh Jadeja
Software Risk is an expectation of loss, a potential problem that may or may not occur in the future. It is generally caused due to lack of information, control or time.
RISK – Possible loss or problem (Specifically in S/W development process)
MITIGATION – Efforts or Process to overcome the Risks or reduce the impact. (Comes after Avoidance Scenario)
MONITORING – Check to ensure effective execution (Observation)
MANAGEMENT – The subtle are of dealing with the risk and keep moving forward
The document discusses risk management for projects. It covers risk identification, which involves categorizing risks and identifying known and predictable risks through checklists and questionnaires. It also discusses risk projection, which involves estimating the probability and impact of risks. Finally, it discusses developing a risk table to prioritize risks and plan risk mitigation, monitoring, and management strategies. The overall goal is to proactively address risks to avoid issues and have contingency plans.
The document discusses risk management in software engineering projects. It covers risk identification by using risk checklists and questionnaires to determine known and predictable risks. It then discusses risk projection, which estimates the probability and impact of identified risks. Finally, it discusses developing a risk mitigation, monitoring, and management plan to proactively address risks through avoidance, monitoring, and contingency planning. The overall goal is to prioritize and systematically manage risks to avoid issues and keep projects on track.
The document discusses risk management and provides details on risk identification, projection (estimation), and mitigation. It defines risk and outlines two key characteristics - uncertainty and loss. Risks are categorized by project, technical, and business types. Steps for risk management include identifying possible risks, analyzing each risk's probability and impact, ranking risks, and developing contingency plans for high probability/impact risks.
Quality, quality concepts
Software Quality Assurance
Software Reviews
Formal Technical Reviews
SQA Group Plan
ISO 9000, 9001
Example
Internal and external attributes
The document discusses software quality management. It covers quality fundamentals like culture, costs and models. It describes quality management processes like quality assurance, verification and validation, reviews and audits. It discusses quality requirements, defect characterization and management techniques like static, people-intensive and dynamic techniques. The document provides details on quality measurement and testing to ensure software quality.
The document provides an overview of various software development processes and models, including traditional waterfall and iterative models as well as agile methods like Scrum and Extreme Programming (XP). It discusses key aspects of each approach such as phases, roles, meetings, practices, and values. The document aims to introduce different process options and considerations for developing software.
Risk management is important for software projects to identify risks that could impact cost, schedule or quality and put mitigation plans in place. The key steps in risk management are risk identification, analysis, planning, monitoring. Risks can be project risks, product risks, technical risks or business risks. It's important to identify both known/predictable risks as well as unpredictable risks. The goal of risk management is to anticipate issues and have contingency plans to minimize negative impacts.
The document discusses risk analysis and management for software projects. It defines risks as potential problems that could affect project completion. The goal of risk analysis is to help teams understand and manage uncertainty. Key aspects covered include identifying risks, assessing probability and impact, prioritizing risks, developing risk mitigation plans, and monitoring risks during the project. The document provides examples of risk categories, analysis steps, and strategies for proactive versus reactive risk management.
Agile development focuses on effective communication, customer collaboration, and incremental delivery of working software. The key principles of agile development according to the Agile Alliance include satisfying customers, welcoming changing requirements, frequent delivery, collaboration between business and development teams, and self-organizing teams. Extreme Programming (XP) is an agile process model that emphasizes planning with user stories, simple design, pair programming, unit testing, and frequent integration and testing.
This document outlines a presentation on risk management fundamentals given by the Federal Aviation Administration. It introduces the topic of risk management and defines key terms like hazard, risk, risk assessment, and risk control. It explains the importance of identifying hazards and assessing risk using a risk matrix to determine risk levels. Finally, it details the five steps of the risk management process: identify hazards, assess risk, make risk decisions, implement controls, and monitor the effectiveness of controls. The overall goal is to provide a framework for integrating risk management into an organization to make safer decisions.
This document provides an overview of risk assessment and management. It introduces risk management and identifies types and categories of risk. It then outlines the procedure for managing risk, including planning, identification, assessment, monitoring, and tracking. Tools and practices for risk analysis are presented, including impact analysis, probability analysis, risk mitigation strategies, and qualitative and quantitative analysis. Stakeholder engagement in risk appetite and tolerance is discussed.
This document discusses risk management in software engineering projects. It defines three categories of risks: project risks that affect schedule or resources, product risks that affect software quality or performance, and business risks that affect the developing organization. The risk management process involves identifying risks, analyzing their likelihood and consequences, planning strategies to avoid or minimize risks, and monitoring risks throughout the project. Several examples of common software project risks and their potential effects are provided.
This Presentation will describe you,
01. What is software project management
02. The Role of Software Project Manager
03. Risk Management
04. People Management
not only these point you will have with example.
The document discusses risk management frameworks and processes. It provides:
1) An overview of risk management, including highlighting risks at the project, program, and portfolio levels.
2) A risk management framework involving establishing context, risk identification, analysis, evaluation, and treatment.
3) Details of risk governance, including risk management plans, risk registers, governance documents, and ongoing and discrete risk activities.
The document discusses checkpoints in the software project management process. It describes three types of joint management reviews: major milestones, minor milestones, and status assessments. Major milestones provide visibility on system-wide issues and verify phase aims. Minor milestones review iteration content and authorize continued work. Status assessments provide frequent management insight. Different stakeholders have different concerns at checkpoints.
This document summarizes a website that provides information and resources for project managers on risk management. It includes definitions of project risk, descriptions of the risk management process and tips for identifying, prioritizing, and managing risks. Specific topics covered include risk identification techniques, using a risk matrix, the risk register form, and different strategies for responding to risks such as mitigation, transfer, avoidance and acceptance. Flowcharts and diagrams are provided to illustrate risk management concepts and processes.
The document discusses software estimation and project planning. It covers estimating project cost and effort through decomposition techniques and empirical estimation models. Specifically, it discusses:
1) Decomposition techniques involve breaking down a project into functions and tasks to estimate individually, such as estimating lines of code or function points for each piece.
2) Empirical estimation models use historical data from past projects to generate estimates.
3) Key factors that affect estimation accuracy include properly estimating product size, translating size to effort/time/cost, and accounting for team abilities and requirements stability.
Software Project Management (monitoring and control)IsrarDewan
Monitoring and Controlling are processes needed to track, review, and regulate the progress and performance of the project. It also identifies any areas where changes to the project management method are required and initiates the required changes.
Evolutionary models are iterative and incremental software development approaches that combine iterative and incremental processes. There are two main types: prototyping and spiral models. The prototyping model develops prototypes that are tested and refined based on customer feedback until requirements are met, while the spiral model proceeds through multiple loops or phases of planning, risk analysis, engineering, and evaluation. Both approaches allow requirements to evolve through development and support risk handling.
The document discusses defect tracking and management. It provides details on defect identification, reporting, tracking, resolution and using defect information to improve processes. A recommended structure is given for defect reports, including title, description, steps to reproduce, actual and expected results. Examples of a defect report and tracking sheet in Excel are also shown. The defect management process involves executing tests, logging discrepancies, reviewing with developers, assigning defects, retesting after fixes, and closing defects when resolved.
This document discusses risk management in software projects. It covers identifying risks through checklists and questionnaires, estimating the probability and impact of risks, and developing contingency plans. Key aspects include identifying risks proactively, analyzing each risk's likelihood and consequences, prioritizing high probability/high impact risks, and monitoring risks and triggers to mitigate potential issues. The overall goal is to anticipate problems before they occur and control risks in order to reduce disruption and keep projects on track.
The document discusses risk management in software engineering projects. It covers risk identification by using risk checklists and questionnaires to determine known and predictable risks. It then discusses risk projection, which estimates the probability and impact of identified risks. Finally, it discusses developing a risk mitigation, monitoring, and management plan to proactively address risks through avoidance, monitoring, and contingency planning. The overall goal is to prioritize and systematically manage risks to avoid issues and keep projects on track.
The document discusses risk management and provides details on risk identification, projection (estimation), and mitigation. It defines risk and outlines two key characteristics - uncertainty and loss. Risks are categorized by project, technical, and business types. Steps for risk management include identifying possible risks, analyzing each risk's probability and impact, ranking risks, and developing contingency plans for high probability/impact risks.
Quality, quality concepts
Software Quality Assurance
Software Reviews
Formal Technical Reviews
SQA Group Plan
ISO 9000, 9001
Example
Internal and external attributes
The document discusses software quality management. It covers quality fundamentals like culture, costs and models. It describes quality management processes like quality assurance, verification and validation, reviews and audits. It discusses quality requirements, defect characterization and management techniques like static, people-intensive and dynamic techniques. The document provides details on quality measurement and testing to ensure software quality.
The document provides an overview of various software development processes and models, including traditional waterfall and iterative models as well as agile methods like Scrum and Extreme Programming (XP). It discusses key aspects of each approach such as phases, roles, meetings, practices, and values. The document aims to introduce different process options and considerations for developing software.
Risk management is important for software projects to identify risks that could impact cost, schedule or quality and put mitigation plans in place. The key steps in risk management are risk identification, analysis, planning, monitoring. Risks can be project risks, product risks, technical risks or business risks. It's important to identify both known/predictable risks as well as unpredictable risks. The goal of risk management is to anticipate issues and have contingency plans to minimize negative impacts.
The document discusses risk analysis and management for software projects. It defines risks as potential problems that could affect project completion. The goal of risk analysis is to help teams understand and manage uncertainty. Key aspects covered include identifying risks, assessing probability and impact, prioritizing risks, developing risk mitigation plans, and monitoring risks during the project. The document provides examples of risk categories, analysis steps, and strategies for proactive versus reactive risk management.
Agile development focuses on effective communication, customer collaboration, and incremental delivery of working software. The key principles of agile development according to the Agile Alliance include satisfying customers, welcoming changing requirements, frequent delivery, collaboration between business and development teams, and self-organizing teams. Extreme Programming (XP) is an agile process model that emphasizes planning with user stories, simple design, pair programming, unit testing, and frequent integration and testing.
This document outlines a presentation on risk management fundamentals given by the Federal Aviation Administration. It introduces the topic of risk management and defines key terms like hazard, risk, risk assessment, and risk control. It explains the importance of identifying hazards and assessing risk using a risk matrix to determine risk levels. Finally, it details the five steps of the risk management process: identify hazards, assess risk, make risk decisions, implement controls, and monitor the effectiveness of controls. The overall goal is to provide a framework for integrating risk management into an organization to make safer decisions.
This document provides an overview of risk assessment and management. It introduces risk management and identifies types and categories of risk. It then outlines the procedure for managing risk, including planning, identification, assessment, monitoring, and tracking. Tools and practices for risk analysis are presented, including impact analysis, probability analysis, risk mitigation strategies, and qualitative and quantitative analysis. Stakeholder engagement in risk appetite and tolerance is discussed.
This document discusses risk management in software engineering projects. It defines three categories of risks: project risks that affect schedule or resources, product risks that affect software quality or performance, and business risks that affect the developing organization. The risk management process involves identifying risks, analyzing their likelihood and consequences, planning strategies to avoid or minimize risks, and monitoring risks throughout the project. Several examples of common software project risks and their potential effects are provided.
This Presentation will describe you,
01. What is software project management
02. The Role of Software Project Manager
03. Risk Management
04. People Management
not only these point you will have with example.
The document discusses risk management frameworks and processes. It provides:
1) An overview of risk management, including highlighting risks at the project, program, and portfolio levels.
2) A risk management framework involving establishing context, risk identification, analysis, evaluation, and treatment.
3) Details of risk governance, including risk management plans, risk registers, governance documents, and ongoing and discrete risk activities.
The document discusses checkpoints in the software project management process. It describes three types of joint management reviews: major milestones, minor milestones, and status assessments. Major milestones provide visibility on system-wide issues and verify phase aims. Minor milestones review iteration content and authorize continued work. Status assessments provide frequent management insight. Different stakeholders have different concerns at checkpoints.
This document summarizes a website that provides information and resources for project managers on risk management. It includes definitions of project risk, descriptions of the risk management process and tips for identifying, prioritizing, and managing risks. Specific topics covered include risk identification techniques, using a risk matrix, the risk register form, and different strategies for responding to risks such as mitigation, transfer, avoidance and acceptance. Flowcharts and diagrams are provided to illustrate risk management concepts and processes.
The document discusses software estimation and project planning. It covers estimating project cost and effort through decomposition techniques and empirical estimation models. Specifically, it discusses:
1) Decomposition techniques involve breaking down a project into functions and tasks to estimate individually, such as estimating lines of code or function points for each piece.
2) Empirical estimation models use historical data from past projects to generate estimates.
3) Key factors that affect estimation accuracy include properly estimating product size, translating size to effort/time/cost, and accounting for team abilities and requirements stability.
Software Project Management (monitoring and control)IsrarDewan
Monitoring and Controlling are processes needed to track, review, and regulate the progress and performance of the project. It also identifies any areas where changes to the project management method are required and initiates the required changes.
Evolutionary models are iterative and incremental software development approaches that combine iterative and incremental processes. There are two main types: prototyping and spiral models. The prototyping model develops prototypes that are tested and refined based on customer feedback until requirements are met, while the spiral model proceeds through multiple loops or phases of planning, risk analysis, engineering, and evaluation. Both approaches allow requirements to evolve through development and support risk handling.
The document discusses defect tracking and management. It provides details on defect identification, reporting, tracking, resolution and using defect information to improve processes. A recommended structure is given for defect reports, including title, description, steps to reproduce, actual and expected results. Examples of a defect report and tracking sheet in Excel are also shown. The defect management process involves executing tests, logging discrepancies, reviewing with developers, assigning defects, retesting after fixes, and closing defects when resolved.
This document discusses risk management in software projects. It covers identifying risks through checklists and questionnaires, estimating the probability and impact of risks, and developing contingency plans. Key aspects include identifying risks proactively, analyzing each risk's likelihood and consequences, prioritizing high probability/high impact risks, and monitoring risks and triggers to mitigate potential issues. The overall goal is to anticipate problems before they occur and control risks in order to reduce disruption and keep projects on track.
This document discusses strategies for managing risks in software engineering projects. It describes reactive strategies, where problems are addressed as they occur, and proactive strategies, where risks are predicted and planned for in advance. The document categorizes risks as project risks, business risks, technical risks, and risks related to staff size and experience. It provides examples of each type of risk and outlines a risk identification process involving creating a risk checklist to systematically identify known and predictable risks.
This document discusses risk management in software engineering projects. It covers risk identification, risk projection/estimation, and risk mitigation, monitoring and management. Key points include defining risk, categorizing risks as project, technical or business risks, using checklists and questionnaires to identify known and predictable risks, estimating the probability and impact of risks, and developing a risk management plan to mitigate high-probability, high-impact risks.
There are two main types of risk strategies: reactive and proactive. A reactive strategy monitors for risks but does not plan for them, while a proactive strategy identifies potential risks early and develops contingency plans. Some key risks include project delays or cost overruns, technical issues, and business risks. Risk identification involves checking known risk categories like project size, staff experience, and technology complexity. Risks are then estimated based on their probability and potential impact. Quality management aims to produce high quality software through techniques like quality control, assurance, and cost analysis. Six Sigma is a widely used strategy that defines requirements, measures current quality, analyzes defects, designs processes to avoid defects, and verifies the new process.
Kumar Bishwakarma gave a presentation on the basics of risk management. He discussed (1) reactive and proactive risk handling strategies, with reactive focusing on problems after they occur and proactive identifying risks in advance. He also covered (2) software risks like project, technical, business, known, predictable and unpredictable risks. Finally, he explained the process of (3) risk identification, projection, assessment, refinement, and developing a risk management, mitigation, monitoring and management plan to address risks throughout a project.
This document discusses risk management for software projects. It defines risk as the probability of suffering a loss and explains that risk management aims to reduce risks so the project can be delivered successfully to customers. The document outlines principles of risk management like taking a global perspective and continuous monitoring. It also categorizes types of software risks and describes the risk analysis process of identification, projection, assessment, and management through tools like risk tables. Finally, it presents the risk management paradigm of identifying, analyzing, planning, tracking, controlling, and communicating risks.
The document summarizes the project risk analysis process for NKS Private Limited, a software company. It describes NKS' background and outlines the key steps in risk analysis: risk identification, risk projection including probability and impact assessment, risk refinement, and developing a risk mitigation, monitoring and management plan. An example risk is provided relating to software component reuse. The summary provides an overview of the risk analysis process and examples discussed in the document.
This document discusses risk management in software engineering projects. It covers risk identification, estimation of probability and impact, and developing a risk management, monitoring and mitigation plan. Key aspects include categorizing risks, using checklists to identify known and predictable risks, estimating probability and impact on a scale, prioritizing risks, and developing contingency plans to reduce risks with high probability and impact. The goal is to take proactive steps to avoid risks and have plans in place to manage unavoidable risks in a controlled manner.
Software project management involves planning, estimating, scheduling, risk management, people management, reporting, and proposal writing to deliver high-quality software on time and within budget while maintaining an effective development team. Key aspects of project management include identifying and addressing risks, motivating the project team through satisfying their social, esteem and self-realization needs, and promoting cohesion among small groups of 4-6 members. Effective people management and teamwork are essential for software project success.
The document discusses software engineering risk management strategies. It describes proactive and reactive risk strategies, where proactive strategies begin before work starts to identify potential risks, while reactive strategies monitor an ongoing project. Key risks include project risks impacting budget, schedule, and resources, technical risks impacting quality and timeliness, and business risks impacting viability. Common business risks involve building something no one wants, a product no longer fitting strategy, sales not understanding the product, losing management support, and losing budget/staff commitment. Risk management aims to specify threats and focuses on known and predictable risks through risk identification techniques.
This document discusses risk management in IT projects. It defines risk as an uncertain event that can positively or negatively impact project objectives. Risk management is identifying, evaluating, and mitigating risks that could impact desired project outcomes. The major risks in IT projects are scope, schedule, resources, and technology. Effective risk management includes identifying risks, analyzing them, developing responses, controlling risks over the project, and following principles like open communication, integrated management, and continuous process.
The document discusses methods for identifying and assessing risk in software projects. It lists common risks like project size, business impact, customer characteristics, and development environment. It then provides 11 questions to assess overall project risk, focusing on factors like management commitment, user involvement, requirements stability, team skills, and resource adequacy. The degree of project risk is said to be directly proportional to the number of negative answers to these questions.
Risk analysis and management are important for software projects to identify potential problems and minimize their impact. There are various types of risks including product risks from unstable requirements or design, business risks from poor market fit or changes in strategy, and project risks from resource constraints or unreliable vendors. The risk management process involves risk avoidance, detection, control, and recovery through tools and techniques like risk anticipation rules, analysis tables, and prioritization of high impact risks to be addressed.
This document discusses risk management in project management. It explains that risk identification, probability assessment, and impact estimation are important activities for risk analysis. Risks can be proactively or reactively managed. Proactive management involves formal risk analysis and addressing root causes, while reactive management involves responding to risks as they occur. Key aspects of risk management include identifying risks, analyzing their probability and impact, developing a risk table to plan mitigation strategies, and continuously monitoring and managing risks throughout the project lifecycle.
This document discusses project risk management in software development. It defines risk as an uncertain event that can positively or negatively impact a project's progress or outcome. There are various types of risks including schedule risks from incorrect time estimations, budget risks from wrong cost estimations, and operational risks from failed processes or lack of resources. The top 10 universal risks to software projects are listed as user involvement, executive support, requirements inflation, schedule flaws, unrealistic expectations, staff turnover, project management, specification breakdowns, technology uncertainties, and not knowing what is at stake. The document recommends measuring risks, minimizing risks, communicating risks to stakeholders, monitoring risks, and modifying risk management processes based on experience.
The document discusses principles of software management and development practices. It covers:
1. Establishing iterative lifecycle processes that identify risks early through multiple iterations of problem understanding, solution design, and planning.
2. Transitioning design methods to emphasize component-based development using pre-existing code to reduce custom development.
3. Enhancing change freedom through automated tools that support round-trip engineering and synchronization across different formats and stages of the iterative development process.
Risk in software development refers to unforeseen events that can positively or negatively impact a project's progress, results, or outcomes. There are several types of risk, including schedule risks from wrong time estimations, budget risks from incorrect costing, operational risks from failed processes or systems, and technical risks such as changing requirements. Key sources of risk include user involvement, unrealistic expectations, staff turnover, and an unclear project scope or specifications. Risk management involves identifying, assessing, prioritizing, and taking coordinated actions to minimize threats and maximize opportunities. Actions include measuring risks, minimizing their impact, communicating about risks, and continually monitoring and updating risk assessments.
The document discusses risk analysis and management for software projects. It defines risks as potential problems that could affect project completion. The goal of risk analysis is to help teams understand and manage uncertainty. Key steps include identifying risks, estimating their probability and impact, prioritizing the most important risks, and developing a Risk Mitigation, Monitoring, and Management Plan to avoid, minimize, or prepare for the risks. The document provides examples of risk categories and checklists to help identify project, technical, and business risks.
This is an overview of my current metallic design and engineering knowledge base built up over my professional career and two MSc degrees : - MSc in Advanced Manufacturing Technology University of Portsmouth graduated 1st May 1998, and MSc in Aircraft Engineering Cranfield University graduated 8th June 2007.
We have designed & manufacture the Lubi Valves LBF series type of Butterfly Valves for General Utility Water applications as well as for HVAC applications.
Data Communication and Computer Networks Management System Project Report.pdfKamal Acharya
Networking is a telecommunications network that allows computers to exchange data. In
computer networks, networked computing devices pass data to each other along data
connections. Data is transferred in the form of packets. The connections between nodes are
established using either cable media or wireless media.
2. Definition of Risk
• A risk is a potential problem – it might happen and it might not
• Conceptual definition of risk
• Risk concerns future happenings
• Risk involves change in mind, opinion, actions, places, etc.
• Risk involves choice and the uncertainty that choice entails
• Two characteristics of risk
• Uncertainty – the risk may or may not happen, that is, there are no 100% risks
(those, instead, are called constraints)
• Loss – the risk becomes a reality and unwanted consequences or losses occur
2
3. Reactive vs. Proactive Risk Strategies
• Reactive risk strategies
• "Don't worry, I'll think of something"
• The majority of software teams and managers rely on this approach
• Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem rapidly (fire
fighting mode)
• Crisis management is the choice of management techniques.
3
4. CONTD…
• Proactive risk strategies
• Begins long before technical work is started.
• Steps for risk management are followed : Potential risks are identified, their probability
and impact are assessed, and they are ranked by importance.
• Primary objective is to avoid risk and to have a contingency plan in place to handle
unavoidable risks in a controlled and effective manner
5. Risk Categorization – Approach #1
• Project risks
• They threaten the project plan
• If they become real, it is likely that the project schedule will slip and that costs will increase.
• Identify potential budgetary, schedule, personnel, resource and requirements problems and
their impact on the software.
• Technical risks
• They threaten the quality and timeliness of the software to be produced
• If they become real, implementation may become difficult or impossible
• Hard to solve
• Identify potential design, implementation, interface, verification, maintenance problems.
• Business risks
• They threaten the viability (survival capability) of the software to be built
• If they become real, they jeopardize (put into risk) the project or the product
5
6. • Sub-categories of Business risks (Candidates for Business risks)
• Market risk – building an excellent product or system that no one really wants
• Strategic risk – building a product that no longer fits into the overall business strategy for
the company
• Sales risk – building a product that the sales force doesn't understand how to sell
• Management risk – losing the support of senior management due to a change in focus or a
change in people
• Budget risk – losing budgetary or personnel commitment
6
7. Risk Categorization – Approach #2
• Known risks
• Those risks that can be uncovered after careful evaluation of the project plan, the business and
technical environment in which the project is being developed, and other reliable information
sources (e.g., unrealistic delivery date, lack of documented requirements)
• Predictable risks
• Those risks that are extrapolated from past project experience (e.g., past turnover, poor
communication with the customer)
• Unpredictable risks
• Those risks that can and do occur, but are extremely difficult to identify in advance
• Example :
7
8. Steps for Risk Management
1) Identify possible risks; recognize what can go wrong
2) Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that it
will do if it does occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and catastrophic
4) Develop a contingency plan to manage those risks having high probability and high impact
8
9. Risk Identification
• Risk identification is a systematic attempt to specify threats to the project plan.
• By identifying known and predictable risks, the project manager takes a first step toward
avoiding them when possible and controlling them when necessary
• Generic risks
• Risks that are a potential threat to every software project
• Product-specific risks
• Risks that can be identified only by those with a clear understanding of the technology,
the people, and the environment that is specific to the software that is to be built
• This requires examination of the project plan.
• "What special characteristics of this product may threaten our project plan?"
9
10. Risk Item Checklist
• Used as one way to identify risks
• Focuses on known and predictable risks in specific subcategories (see next slide)
• Can be organized in several ways
• A list of characteristics relevant to each risk subcategory
• Questionnaire that leads to an estimate on the impact of each risk
• A list containing a set of risk component and drivers and their probability of
occurrence
10
11. Known and Predictable Risk Categories
• Product size – risks associated with overall size of the software to be built
• EXAMPLES :
• Estimated size of the product in LOC or FP?
• Size of database created or used by the product?
• Number of users of the product?
• Number of projected changes to the requirements for the product? Before delivery? After delivery?
• Amount of reused software?
11
12. CONTD…• Business impact – risks associated with constraints imposed by management or the
marketplace
• Amount and quality of product documentation that must be produced and delivered to the customer?
• Governmental constraints on the construction of the product?
• Costs associated with late delivery?
• Costs associated with a defective product?
• Customer characteristics – risks associated with sophistication of the customer and the
developer's ability to communicate with the customer in a timely manner
• Have you worked with he customer in the past?
• Does the customer have a solid idea of what is required?
• Has the customer taken the time to write this down?
• Is the customer willing to establish rapid communication links with the developer?
• Is the customer willing to participate in reviews?
13. CONTD…• Process definition – risks associated with the degree to which the software process has been
defined and is followed
• Development environment – risks associated with availability and quality of the tools to be
used to build the project
• Is a software project management tool available?
• Is a software process management tool available?
• Are tools for analysis and design available?
• Do analysis and design tools deliver methods that are appropriate for the product to be built?
14. CONTD…
• Technology to be built – risks associated with complexity of the system to be built and the
"newness" of the technology in the system
• Is the technology to be built new to your company?
• Do the customer requirements demand the creation of new algorithms, input or output
technology?
• Is a specialized user interface demanded by product requirements?
• Staff size and experience – risks associated with overall technical and project experience of
the software engineers who will do the work
• Are the best people available?
• Do the people have the right combination of skills?
• Are enough people available?
• Are staff committed for entire duration of the project?
• Will some staff be working only part time on this project?
15. Questionnaire on Project Risk
1) Have top software and customer managers formally committed to support the
project?
2) Are end-users enthusiastically committed to the project and the system/product to be
built?
3) Are requirements fully understood by the software engineering team and its
customers?
4) Have customers been involved fully in the definition of requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?
15
(Questions are ordered by their relative importance to project success)
16. 7) Does the software engineering team have the right mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the technology to be implemented?
10) Is the number of people on the project team adequate to do the job?
11) Do all customer/user constituencies agree on the importance of the project and on
the requirements for the system/product to be built?
• These questions are written acc to their importance.
• The degree to which the project is at risk is directly proportional to the number of
negative responses to these questions.
16
17. Risk Components and Drivers• Risk drivers are the reasons which can affect the performance/ cost/ schedule etc of a
project i.e. risk components.
• The project manager identifies the risk drivers that affect the following risk components (that
are affected by the risk)
• Performance risk - the degree of uncertainty that the product will meet its requirements
and be fit for its intended use
• Cost risk - the degree of uncertainty that the project budget will be maintained
• Support risk - the degree of uncertainty that the resultant software will be easy to correct,
adapt, and enhance
• Schedule risk - the degree of uncertainty that the project schedule will be maintained and
that the product will be delivered on time
• The impact of each risk driver on the risk component is divided into one of four impact levels
• Negligible (non risk category) , marginal, critical, and catastrophic (often lead to project
failure)
• Risk drivers can be assessed as impossible, improbable, probable, and frequent
17
18. Risk Projection (Estimation)
• Risk projection (or estimation) attempts to rate each risk in two ways
• The probability that the risk is real
• The consequence of the problems associated with the risk, should it occur
• The project planner, managers, and technical staff perform four risk projection steps (see next
slide)
• The intent of these steps is to consider risks in a manner that leads to prioritization
18
19. Risk Projection/Estimation Steps
1) Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low, 10-high)
2) Delineate the consequences of the risk
3) Estimate the impact of the risk on the project and product
4) Note the overall accuracy of the risk projection so that there will be no misunderstandings
19
20. Contents of a RiskTable
• A risk table provides a project manager with a simple technique for risk
projection
• It consists of five columns
• Risk Summary – short description of the risk
• Risk Category – one of seven risk categories (slide 11)
• Probability – estimation of risk occurrence based on group input
• Impact – (1) catastrophic (2) critical (3) marginal (4) negligible
• RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring, and
Management Plan
20
Risk Summary Risk Category Probability Impact (1-4) RMMM
21. Developing a RiskTable
• List all risks in the first column (by way of the help of the risk item checklists)
• Mark the category of each risk
• Estimate the probability of each risk occurring
• Assess the impact of each risk based on an averaging of the four risk components
to determine an overall impact value (See next slide)
• Sort the rows by probability and impact in descending order
• Draw a horizontal cutoff line in the table that indicates the risks that lie above the
line will be given further attention.
21
22. Risk factor with high impact + low probability of occurrence no significant amount of
management time needed.
Risk factor with high impact + moderate to high probability of occurrence
OR
Risk factor with low impact + high probability of occurrence
Carried forward into the risk analysis steps.
The column labelled RMMM contains a collection of risk information developed for all the
risks that lie above the cut off.
Management Risk concern
23. Assessing Risk Impact
• Three factors affect the consequences that are likely if a risk does occur
• Its nature – This indicates the problems that are likely if the risk occurs
• For example, a poorly defined external interface to customer hardware (a technical risk)
will preclude early design and testing and will likely lead to system integration problems
late in a project.
• Its scope – This combines the severity of the risk (how serious was it) with its overall
distribution (how much was affected)
• Its timing – This considers when and for how long the impact will be felt
• The overall risk exposure formula is RE = P x C , The quantified potential for loss that
might occur as a result of some activity.
• P = the probability of occurrence for a risk
• C = the cost to the project should the risk actually occur 23
24. Contd…
• For example, assume that the software team defines a project risk in the following manner.
• Risk identification. Only 70 percent of the software components scheduled for reuse will,
in fact, be integrated into the application. The remaining functionality will have to be custom
developed.
• Risk probability. 80 percent (likely).
• Risk impact. Sixty reusable software components were planned. If only 70 percent can
be used, 18 components would have to be developed from scratch (in addition to other
custom software that has been scheduled for development). Since the average component is
100 LOC and local data indicate that the software engineering cost for each LOC is $14.00,
the overall cost (impact) to develop the components would be 18 X 100 X 14 = $25,200.
• Risk exposure. RE = 0.80 X 25,200 ~ $20,200.
25. CONTD…
• The total risk exposure for all risks (above the cutoff in the risk table) can provide a means
for adjusting the final cost estimate for a project.
• It can also be used to predict the probable increase in staff resources required at various
points during the project schedule.
26. Risk Refinement
• As time passes, more and more is learnt about the project and the risk, it is possible to refine
the risk into a set of more detailed risks.
• Represent the risk in condition-transition-consequence (CTC) format
• Given that <condition> then there is concern that <consequence>.
27. CONTD…
• Using the CTC format for the reuse risk , you could write:
• Given that all reusable software components must conform to specific design standards
and that some do not conform, then there is concern that (possibly) only 70 percent of the
planned reusable modules may actually be integrated into the as-built system, resulting in the
need to custom engineer the remaining 30 percent of components.
• This general condition can be refined in the following manner:
• Subcondition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards.
• Subcondition 2. The design standard for component interfaces has not been solidified
and may not conform to certain existing reusable components.
• Subcondition 3. Certain reusable components have been implemented in a language
that is not supported on the target environment.
28. CONTD…
• The consequences associated with these refined subconditions remain the same (i.e., 30
percent of software components must be custom engineered), but the refinement helps to
isolate the underlying risks and might lead to easier analysis and response.
29. Risk Mitigation, Monitoring, and
Management
• An effective strategy for dealing with risk must consider three issues
(Note: these are not mutually exclusive)
• Risk mitigation (i.e., avoidance)
• Risk monitoring
• Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy and is achieved through a plan
• Example: Risk of high staff turnover
29
30. Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay,
competitive job market)
Mitigate those causes that are under our control before the project starts
Once the project commences, assume turnover will occur and develop techniques to ensure
continuity when people leave
Organize project teams so that information about each development activity is widely dispersed
Define documentation standards and establish mechanisms to ensure that documents are
developed in a timely manner
Conduct peer reviews of all work (so that more than one person is "up to speed")
Assign a backup staff member for every critical technologist
30
Strategy for Reducing Staff Turnover
31. • During risk monitoring, the project manager monitors factors that may provide an
indication of whether a risk is becoming more or less likely.
• In case of high turnover:
• General attitude of team members based on project pressures.
• The degree to which the team has jelled.
• Inter personal relation ships among the team members.
• In addition, manager should also monitor the effectiveness of risk mitigation steps.
• Risk management and contingency planning assume that mitigation efforts have failed and
that the risk has become a reality
• In case of high turnover:
• If a num of people announce that they would be leaving, but backup is available, info is
documented.
• Refocus resources, readjust the project schedule, enabling new comers who must be added to
the team.
• Those individuals who are leaving are now asked to stop all the work and spend their last few
weeks in “knowledge transfer mode”. 31
32. • RMMM steps incur additional project cost.
• Eg: spending the time to backup every critical technologist costs money.
• Therefore part of Risk management is to evaluate when the benefits accured by the RMMM steps
outweigh the costs associated with implementing them.
33. • Risk is not limited to the software project itself
• Risks can occur after the software has been delivered to the user
• Software safety and hazard analysis
• These are software quality assurance activities that focus on the identification
and assessment of potential hazards that may affect software negatively and
cause an entire system to fail
• If hazards can be identified early in the software process, software design
features can be specified that will either eliminate or control potential hazards.
33
34. Risk Assessment
• During risk assessment we further examine the accuracy of the estimates that were made
during risk projection.
• Rank the risks uncovered
• Begin thinking about the ways to control risks that are likely to occur.
• For assessment to be useful, manager gives a risk referent level. A level for performance
degradation, cost overrun, support difficulty or schedule slippage that will cause termination
of the project.
• A risk referent level has a single point called referent point/ break point at which the decision
to continue or to terminate are equally weighted.
35. • So, during risk assessment, we perform the following steps:
1.Define risk referent levels for the project.
2.Try to develop a relationship between each (ri, li, xi) and each of the referent levels.
3.Predict the set of referent points that define a region of termination, bounded by a curve or
areas of uncertainty.
4.Try to predict how compound combinations of risk will affect a referent level.
36. Seven Principles of Risk Management
• Maintain a global perspective
• View software risks within the context of a system and the business problem that is is intended to
solve
• Take a forward-looking view
• Think about risks that may arise in the future; establish contingency plans
• Encourage open communication
• Encourage all stakeholders and users to point out risks at any time
• Integrate risk management
• Integrate the consideration of risk into the software process
• Emphasize a continuous process of risk management
• Modify identified risks as more becomes known and add new risks as better insight is achieved
• Develop a shared product vision
• A shared vision by all stakeholders facilitates better risk identification and assessment
• Encourage teamwork when managing risk
• Pool the skills and experience of all stakeholders when conducting risk management activities
36
37. Summary
• Whenever much is riding on a software project, common sense dictates risk analysis
• Yet, most project managers do it informally and superficially, if at all
• However, the time spent in risk management results in
• Less upheaval during the project
• A greater ability to track and control a project
• The confidence that comes with planning for problems before they occur
• Risk management can absorb a significant amount of the project planning effort…but
the effort is worth it
37