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.
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 metrics and how they can be used to measure various attributes of software products and processes. It begins by asking questions that software metrics can help answer, such as how to measure software size, development costs, bugs, and reliability. It then provides definitions of key terms like measurement, metrics, and defines software metrics as the application of measurement techniques to software development and products. The document outlines areas where software metrics are commonly used, like cost estimation and quality/reliability prediction. It also discusses challenges in implementing metrics and provides categories of metrics like product, process, and project metrics. The remainder of the document provides examples and formulas for specific software metrics.
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.
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.
This ppt covers the following
A strategic approach to testing
Test strategies for conventional software
Test strategies for object-oriented software
Validation testing
System testing
The art of debugging
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.
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.
The document contains slides from a lecture on software engineering. It discusses definitions of software and software engineering, different types of software applications, characteristics of web applications, and general principles of software engineering practice. The slides are copyrighted and intended for educational use as supplementary material for a textbook on software engineering.
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 metrics and how they can be used to measure various attributes of software products and processes. It begins by asking questions that software metrics can help answer, such as how to measure software size, development costs, bugs, and reliability. It then provides definitions of key terms like measurement, metrics, and defines software metrics as the application of measurement techniques to software development and products. The document outlines areas where software metrics are commonly used, like cost estimation and quality/reliability prediction. It also discusses challenges in implementing metrics and provides categories of metrics like product, process, and project metrics. The remainder of the document provides examples and formulas for specific software metrics.
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.
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.
This ppt covers the following
A strategic approach to testing
Test strategies for conventional software
Test strategies for object-oriented software
Validation testing
System testing
The art of debugging
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.
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.
The document contains slides from a lecture on software engineering. It discusses definitions of software and software engineering, different types of software applications, characteristics of web applications, and general principles of software engineering practice. The slides are copyrighted and intended for educational use as supplementary material for a textbook on software engineering.
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.
This document provides an overview of Extreme Programming (XP), a software development methodology. It discusses key XP practices like user stories, acceptance tests, release planning, refactoring, and pair programming. XP aims to improve communication, keep designs simple, provide frequent feedback through testing, and encourage courage in decision making. It emphasizes delivering working software frequently in short iterations to ensure customer needs are met.
This document discusses different process models used in software development. It describes the key phases and characteristics of several common process models including waterfall, prototyping, V-model, incremental, iterative, spiral and agile development models. The waterfall model involves sequential phases from requirements to maintenance without iteration. Prototyping allows for user feedback earlier. The V-model adds verification and validation phases. Incremental and iterative models divide the work into smaller chunks to allow for iteration and user feedback throughout development.
Decomposition technique In Software Engineering Bilal Hassan
The document discusses different techniques for estimating software project costs and effort, including decomposition, sizing, and function point analysis. It provides an example of estimating the lines of code and function points for a mechanical CAD software project. Estimates are developed by decomposing the problem into smaller elements and tasks, and estimating the effort required for each. The accuracy of estimates depends on properly sizing the software and having reliable past project metrics.
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 software quality and defines key aspects:
- It explains the importance of software quality for users and developers.
- Qualities like correctness, reliability, efficiency are defined.
- Methods for measuring qualities like ISO 9126 standard are presented.
- Quality is important throughout the software development process.
- Both product quality and process quality need to be managed.
The document defines the software development life cycle (SDLC) and its phases. It discusses several SDLC models including waterfall, prototype, iterative enhancement, and spiral. The waterfall model follows sequential phases from requirements to maintenance with no overlap. The prototype model involves building prototypes for user feedback. The iterative enhancement model develops software incrementally. The spiral model is divided into risk analysis, engineering, construction, and evaluation cycles. The document also covers software requirements, elicitation through interviews and use cases, analysis through data, behavioral and functional modeling, and documentation in a software requirements specification.
The document discusses important concepts for effective software project management including focusing on people, product, process, and project. It emphasizes that defining project scope and establishing clear objectives at the beginning of a project are critical first steps. Finally, it outlines factors for selecting an appropriate software development process model and adapting it to the specific project.
The document provides an overview of the Software Engineering course for the second semester of the second year (B.Tech IT/II Sem-II). It includes details about the term, text books, unit syllabus, index of topics, and slides covering introductions to software engineering, the changing nature of software, software myths, generic views of process, the Capability Maturity Model Integration and personal and team software processes.
The document discusses use case diagrams in object oriented design and analysis. It defines use cases as descriptions of system functionality from a user perspective. Use case diagrams depict system behavior, users, and relationships between actors, use cases, and other use cases. The key components of use case diagrams are described as actors, use cases, the system boundary, and relationships. Common relationships include association, extend, generalization, uses, and include. An example use case diagram for a cellular telephone is provided to illustrate these concepts.
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 organization and team structures for software development organizations. It explains the differences between functional and project formats. The functional format divides teams by development phase (e.g. requirements, design), while the project format assigns teams to a single project. The document notes advantages of the functional format include specialization, documentation, and handling staff turnover. However, it is not suitable for small organizations with few projects. The document also describes common team structures like chief programmer, democratic, and mixed control models.
The document discusses component-level design in software engineering. It begins by defining a component as a modular and deployable part of a system that encapsulates implementation and exposes interfaces, according to the OMG. It then provides examples of object-oriented and conventional components. The document outlines best practices for component-level design, including principles like high cohesion and low coupling. It discusses design guidelines and walks through the steps for component-level design, including identifying classes, elaborating interfaces, and developing behavioral models.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
The document discusses various topics related to software project management including:
1. Definitions of projects, jobs, and exploration and how software projects have more characteristics that make them difficult than other types of projects.
2. Typical project phases like initiating, planning, executing, controlling, and closing.
3. Distinguishing between different types of software projects and their approaches.
4. Key activities in project management like planning, organizing, staffing, directing, monitoring, and controlling.
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.
This document discusses software quality factors and McCall's quality factor model. It describes McCall's three main quality factor categories: product operation factors, product revision factors, and product transition factors. Under product operation factors, it outlines reliability, correctness, integrity, efficiency, and usability requirements. It then discusses product revision factors of maintainability, flexibility, and testability. Finally, it covers product transition factors including portability, reusability, and interoperability. The document provides details on the specific requirements for each quality factor.
Software engineering a practitioners approach 8th edition pressman solutions ...Drusilla918
Full clear download( no error formatting) at: https://goo.gl/XmRyGP
software engineering a practitioner's approach 8th edition pdf free download
software engineering a practitioner's approach 8th edition ppt
software engineering a practitioner's approach 6th edition pdf
software engineering pressman 9th edition pdf
software engineering a practitioner's approach 9th edition
software engineering a practitioner's approach 9th edition pdf
software engineering a practitioner's approach 7th edition solution manual pdf
roger s. pressman
The document discusses software quality management and outlines five units: introduction to software quality; software quality assurance; quality control and reliability; quality management systems; and quality standards. It defines quality, discusses hierarchical models of quality including those proposed by Boehm and McCall, and explains techniques for improving software quality like metrics, reviews, and standards.
The document discusses context models and their use in system modeling. Context models illustrate the operational context of a system by showing what lies outside its boundaries, including other systems in the environment. They help define a system's boundaries and show how IT applications fit into the context of people and organizations. Two examples are provided: (1) a Mental Health Care Patient Management System (MHC-PMS) and its connections to other clinical systems; (2) an Automated Teller Machine (ATM) and its links to banking systems. Context models on their own do not show relationships between external systems, so additional models are needed.
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 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.
This document provides an overview of Extreme Programming (XP), a software development methodology. It discusses key XP practices like user stories, acceptance tests, release planning, refactoring, and pair programming. XP aims to improve communication, keep designs simple, provide frequent feedback through testing, and encourage courage in decision making. It emphasizes delivering working software frequently in short iterations to ensure customer needs are met.
This document discusses different process models used in software development. It describes the key phases and characteristics of several common process models including waterfall, prototyping, V-model, incremental, iterative, spiral and agile development models. The waterfall model involves sequential phases from requirements to maintenance without iteration. Prototyping allows for user feedback earlier. The V-model adds verification and validation phases. Incremental and iterative models divide the work into smaller chunks to allow for iteration and user feedback throughout development.
Decomposition technique In Software Engineering Bilal Hassan
The document discusses different techniques for estimating software project costs and effort, including decomposition, sizing, and function point analysis. It provides an example of estimating the lines of code and function points for a mechanical CAD software project. Estimates are developed by decomposing the problem into smaller elements and tasks, and estimating the effort required for each. The accuracy of estimates depends on properly sizing the software and having reliable past project metrics.
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 software quality and defines key aspects:
- It explains the importance of software quality for users and developers.
- Qualities like correctness, reliability, efficiency are defined.
- Methods for measuring qualities like ISO 9126 standard are presented.
- Quality is important throughout the software development process.
- Both product quality and process quality need to be managed.
The document defines the software development life cycle (SDLC) and its phases. It discusses several SDLC models including waterfall, prototype, iterative enhancement, and spiral. The waterfall model follows sequential phases from requirements to maintenance with no overlap. The prototype model involves building prototypes for user feedback. The iterative enhancement model develops software incrementally. The spiral model is divided into risk analysis, engineering, construction, and evaluation cycles. The document also covers software requirements, elicitation through interviews and use cases, analysis through data, behavioral and functional modeling, and documentation in a software requirements specification.
The document discusses important concepts for effective software project management including focusing on people, product, process, and project. It emphasizes that defining project scope and establishing clear objectives at the beginning of a project are critical first steps. Finally, it outlines factors for selecting an appropriate software development process model and adapting it to the specific project.
The document provides an overview of the Software Engineering course for the second semester of the second year (B.Tech IT/II Sem-II). It includes details about the term, text books, unit syllabus, index of topics, and slides covering introductions to software engineering, the changing nature of software, software myths, generic views of process, the Capability Maturity Model Integration and personal and team software processes.
The document discusses use case diagrams in object oriented design and analysis. It defines use cases as descriptions of system functionality from a user perspective. Use case diagrams depict system behavior, users, and relationships between actors, use cases, and other use cases. The key components of use case diagrams are described as actors, use cases, the system boundary, and relationships. Common relationships include association, extend, generalization, uses, and include. An example use case diagram for a cellular telephone is provided to illustrate these concepts.
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 organization and team structures for software development organizations. It explains the differences between functional and project formats. The functional format divides teams by development phase (e.g. requirements, design), while the project format assigns teams to a single project. The document notes advantages of the functional format include specialization, documentation, and handling staff turnover. However, it is not suitable for small organizations with few projects. The document also describes common team structures like chief programmer, democratic, and mixed control models.
The document discusses component-level design in software engineering. It begins by defining a component as a modular and deployable part of a system that encapsulates implementation and exposes interfaces, according to the OMG. It then provides examples of object-oriented and conventional components. The document outlines best practices for component-level design, including principles like high cohesion and low coupling. It discusses design guidelines and walks through the steps for component-level design, including identifying classes, elaborating interfaces, and developing behavioral models.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
The document discusses various topics related to software project management including:
1. Definitions of projects, jobs, and exploration and how software projects have more characteristics that make them difficult than other types of projects.
2. Typical project phases like initiating, planning, executing, controlling, and closing.
3. Distinguishing between different types of software projects and their approaches.
4. Key activities in project management like planning, organizing, staffing, directing, monitoring, and controlling.
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.
This document discusses software quality factors and McCall's quality factor model. It describes McCall's three main quality factor categories: product operation factors, product revision factors, and product transition factors. Under product operation factors, it outlines reliability, correctness, integrity, efficiency, and usability requirements. It then discusses product revision factors of maintainability, flexibility, and testability. Finally, it covers product transition factors including portability, reusability, and interoperability. The document provides details on the specific requirements for each quality factor.
Software engineering a practitioners approach 8th edition pressman solutions ...Drusilla918
Full clear download( no error formatting) at: https://goo.gl/XmRyGP
software engineering a practitioner's approach 8th edition pdf free download
software engineering a practitioner's approach 8th edition ppt
software engineering a practitioner's approach 6th edition pdf
software engineering pressman 9th edition pdf
software engineering a practitioner's approach 9th edition
software engineering a practitioner's approach 9th edition pdf
software engineering a practitioner's approach 7th edition solution manual pdf
roger s. pressman
The document discusses software quality management and outlines five units: introduction to software quality; software quality assurance; quality control and reliability; quality management systems; and quality standards. It defines quality, discusses hierarchical models of quality including those proposed by Boehm and McCall, and explains techniques for improving software quality like metrics, reviews, and standards.
The document discusses context models and their use in system modeling. Context models illustrate the operational context of a system by showing what lies outside its boundaries, including other systems in the environment. They help define a system's boundaries and show how IT applications fit into the context of people and organizations. Two examples are provided: (1) a Mental Health Care Patient Management System (MHC-PMS) and its connections to other clinical systems; (2) an Automated Teller Machine (ATM) and its links to banking systems. Context models on their own do not show relationships between external systems, so additional models are needed.
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.
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 analysis and management for projects. It defines risk as a potential problem that may or may not occur, and outlines why identifying and planning for risks is important for project success. The document then covers various aspects of risk analysis and management, including risk strategies, categories, identification, assessment, refinement, and developing plans to mitigate, monitor, and manage risks. The overall aim is to help project teams understand risks and put processes in place to avoid or minimize risks that could negatively impact a project.
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 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.
This document provides an overview of project risk management. It defines project risk as an event that could have a positive or negative impact on a project. Risk management involves identifying risks and developing plans to minimize their effects. The key steps in risk management are risk identification, analysis, response planning, monitoring and control. Managing risks helps improve project success rates, schedule and cost performance by moving from reactive to proactive decision making.
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.
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.
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.
This document provides an overview of project risk management. It discusses the goals of risk management, including identifying and planning for risks to help projects succeed. The key aspects covered are identifying risks, analyzing their probability and impact, planning responses, and continuously monitoring risks. Qualitative and quantitative approaches to analysis are outlined. The overall process aims to move projects from reactive "firefighting" to proactive risk-based decision making.
This document provides an overview of project risk management. It discusses what project risk is, the risk management process, and tools for risk identification, analysis, response planning, monitoring and control. The risk management process involves planning risk management, identifying risks, analyzing their probability and impact, developing response plans, monitoring risks throughout the project, and using tools like risk logs and templates. Managing risks proactively helps improve project success rates.
This document provides an overview of project risk management. It discusses the goals of risk management, including identifying and planning for risks to help projects succeed. The key aspects covered are identifying risks, analyzing their probability and impact, planning responses, and continuously monitoring risks. Qualitative and quantitative approaches to analysis are outlined. The overall process aims to move projects from reactive "firefighting" to proactive risk-based decision making.
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.
Risk management involves identifying potential risks to a project, analyzing their likelihood and impact, and developing plans to mitigate negative risks. Some key risks include staff turnover, requirements changes, and underestimating the time or resources needed. It is important to identify risks early, communicate about them, assign ownership, prioritize risks, and regularly monitor risks and mitigation strategies. Effective risk management can help promote the success of software projects by focusing resources and preventing potential problems.
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, 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.
The document discusses project risk management. It defines risk as uncertainty that could negatively or positively impact a project's objectives. There are various types of risks like schedule, budget, operational, technical, and programmatic risks. Risk management involves identifying, analyzing, and responding to risks throughout the project life cycle to help meet objectives. The key aspects of risk management are planning risk management, identifying risks, performing qualitative and quantitative risk analysis, planning risk responses, and monitoring and controlling risks. The overall goal is to minimize threats and maximize opportunities related to project risks.
Similar to Software Engineering (Risk Management) (20)
The document discusses software project planning and estimation. It explains that project planning involves estimating the time, effort, people and resources required. The key activities in planning are estimation, scheduling, risk analysis, quality planning and change management. Estimation techniques include decomposition, using historical data, and empirical models. Factors to consider in estimation include feasibility, resources like people and tools, and make-or-buy decisions about reusable software.
Testing is the process of executing software to find defects and verify requirements are met. It involves executing a program or modules to observe behavior and outcomes, and analyze failures to locate and fix faults. The main purposes of testing are to demonstrate quality and proper behavior, and to detect and fix defects. Testing strategies include starting with individual component tests and progressing to integrated system tests. Different techniques like black-box and white-box testing are used at various stages. Manual testing is time-consuming while automated testing is faster and more reliable. Testing continues until quality goals are met or resources run out. Debugging locates and removes defects found via testing.
The document discusses requirements engineering (RE) and software maintenance. It defines RE as the process of establishing what services a system should provide and constraints it must operate under. RE helps engineers understand problems and builds a foundation for design. The document also discusses why RE is important, types and categories of requirements, and the RE process. It then covers how software maintenance is needed to change systems after delivery, types of maintenance, and factors that influence maintenance costs such as team stability and program age.
This document provides an overview of software configuration management (SCM) concepts and definitions. It discusses SCM as the discipline for systematically controlling changes to software systems throughout the software life cycle. The key activities of SCM are identified as configuration identification, configuration change control, configuration status accounting, and configuration auditing. Baselines, configuration items, and the importance of SCM are also summarized.
The document discusses various software testing techniques, including black-box testing and white-box testing. It focuses on white-box testing techniques like basis path testing. Basis path testing uses the control flow graph of a program to identify the minimum number of test paths needed to guarantee that all statements are executed at least once. These basis paths are used to derive test cases that achieve full statement coverage. The cyclomatic complexity metric can be used to measure the number of independent paths in a program and guide test planning.
Software Engineering (Testing Activities, Management, and Automation)ShudipPal
The document discusses software testing activities, management, and automation. It covers major testing activities including test planning, execution, and analysis. Test planning involves goal setting, test case preparation, and test procedure preparation. Test execution allocates test time and resources, runs tests, and identifies failures. Test analysis evaluates results and provides feedback. The document also discusses test management roles and structures, including vertical, horizontal, and mixed test team models. Test automation tools can help improve testing efficiency.
QA and testing are both important for software quality but have different goals. QA is a preventative, process-oriented activity aimed at preventing bugs, while testing is product-oriented and aimed at finding bugs. Key differences between QA and testing are outlined. The document also defines terms like quality control, verification and validation. It describes various testing types like unit, integration, system and acceptance testing as well as techniques like black-box vs white-box testing and manual vs automated testing. Concepts covered include test plans, cases, scripts, suites, logs, beds and deliverables. The importance of a successful test plan is emphasized.
The document discusses various software testing techniques, including black-box testing and white-box testing. It focuses on white-box testing techniques like basis path testing. Basis path testing uses the control flow graph of a program to identify the minimum number of test paths needed to guarantee that all statements are executed at least once. These basis paths are used to derive test cases that achieve full statement coverage. The cyclomatic complexity metric can be used to measure the number of independent paths in a program and guide test planning.
The document discusses software quality assurance (SQA) and quality control (QC). It defines SQA as a planned set of activities to evaluate the development process and ensure software meets requirements. QC focuses on reviews, inspections, and tests to find and remove defects before product release. Formal technical reviews (FTRs) are important QC activities that involve evaluation of work products by other engineers to uncover errors early. The goal is to improve quality and catch the majority of defects in a cost-effective manner.
Software Engineering (Metrics for Process and Projects)ShudipPal
The document discusses software process measurement and metrics. Some key points:
1. Measurement is fundamental to software engineering as it allows processes to be evaluated and improved continuously. Metrics can be used for estimation, quality control, productivity assessment, and project control.
2. Process metrics are collected across projects over long periods to provide indicators for long-term process improvements. Project metrics enable managers to assess status, track risks, and adjust tasks.
3. Guidelines for metrics include using common sense, providing feedback, not evaluating individuals, setting clear goals, and not threatening teams. Metrics should indicate problem areas for improvement, not be considered negative.
This document discusses project scheduling for software engineering projects. It covers key topics such as:
- The importance of scheduling for establishing a roadmap and tracking progress on large, complex software projects.
- Basic principles of software project scheduling including compartmentalizing work, indicating interdependencies, allocating time and resources, and assigning responsibilities.
- Methods for defining tasks, networks, and timelines to plan and track schedules.
- Techniques for monitoring schedule performance such as status meetings, milestone tracking, and earned value analysis.
- Factors that influence schedules such as risks, changing requirements, estimates, and technical difficulties.
Project management involves planning, monitoring, and controlling a project from initial concept through deployment. It includes defining the project scope, decomposing problems, managing stakeholders, choosing an appropriate process model, and ensuring effective communication. Signs a project may be in jeopardy include poorly defined scope or needs, uncontrolled changes, unrealistic deadlines, lack of skills on the team, and failure to apply best practices.
Software Engineering (An Agile View of Process)ShudipPal
1) Agile processes emphasize self-organizing teams, communication, embracing change, and rapid delivery of working software. Several agile process models were created to address these principles, including Extreme Programming (XP), Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Scrum, and Crystal.
2) The Manifesto for Agile Software Development values individuals and interactions, working software, customer collaboration, and responding to change over processes, tools, documentation, contracts, and plans.
3) Successful agile processes deliver working software frequently, emphasize collaboration between customers and developers, and can adapt to changing requirements through incremental development.
The document discusses different prescriptive process models for software engineering projects. It describes the waterfall model as the oldest and most basic sequential model. Incremental process models like the incremental model and RAD model deliver functionality in increments to get early user feedback. Evolutionary models like prototyping and the spiral model are iterative and allow for changes through repeated prototype revisions or spiral loops of risk analysis, development and validation.
Software Engineering (Software Process: A Generic View)ShudipPal
This document provides an overview of software processes and engineering. It defines a software process as a series of predictable steps that lead to a timely, high-quality product. The document then discusses the generic process framework activities of communication, planning, modeling, construction, and deployment. It also covers umbrella activities like project management, reviews, and quality assurance that span the entire software process. Finally, it introduces the Capability Maturity Model Integration for assessing software processes and describes its five maturity levels from initial to optimized.
Software Engineering (Introduction to Software Engineering)ShudipPal
Software engineering is concerned with all aspects of software production. It aims to develop software using systematic and disciplined approaches to reduce errors and costs. Some key challenges in software development are its high cost, difficulty delivering on time, and producing low quality software. Software engineering methods strive to address these challenges and produce software with attributes like maintainability, dependability, efficiency, usability and acceptability.
This document provides an introduction and overview for a Software Engineering course. It outlines the course details including the instructor's information, class schedules, grading policy, textbooks, and topics that will be covered such as what is software, software quality, and software engineering. The key topics are software engineering as an engineering discipline for systematic and quantifiable software development, and the main challenges in software development are high costs, delays, and low quality. The objective of software engineering is to develop methods to consistently deliver high-quality software at low cost that can scale up for complex projects.
Cross-Cultural Leadership and CommunicationMattVassar1
Business is done in many different ways across the world. How you connect with colleagues and communicate feedback constructively differs tremendously depending on where a person comes from. Drawing on the culture map from the cultural anthropologist, Erin Meyer, this class discusses how best to manage effectively across the invisible lines of culture.
Get Success with the Latest UiPath UIPATH-ADPV1 Exam Dumps (V11.02) 2024yarusun
Are you worried about your preparation for the UiPath Power Platform Functional Consultant Certification Exam? You can come to DumpsBase to download the latest UiPath UIPATH-ADPV1 exam dumps (V11.02) to evaluate your preparation for the UIPATH-ADPV1 exam with the PDF format and testing engine software. The latest UiPath UIPATH-ADPV1 exam questions and answers go over every subject on the exam so you can easily understand them. You won't need to worry about passing the UIPATH-ADPV1 exam if you master all of these UiPath UIPATH-ADPV1 dumps (V11.02) of DumpsBase. #UIPATH-ADPV1 Dumps #UIPATH-ADPV1 #UIPATH-ADPV1 Exam Dumps
How to Create a Stage or a Pipeline in Odoo 17 CRMCeline George
Using CRM module, we can manage and keep track of all new leads and opportunities in one location. It helps to manage your sales pipeline with customizable stages. In this slide let’s discuss how to create a stage or pipeline inside the CRM module in odoo 17.
Brand Guideline of Bashundhara A4 Paper - 2024khabri85
It outlines the basic identity elements such as symbol, logotype, colors, and typefaces. It provides examples of applying the identity to materials like letterhead, business cards, reports, folders, and websites.
8+8+8 Rule Of Time Management For Better ProductivityRuchiRathor2
This is a great way to be more productive but a few things to
Keep in mind:
- The 8+8+8 rule offers a general guideline. You may need to adjust the schedule depending on your individual needs and commitments.
- Some days may require more work or less sleep, demanding flexibility in your approach.
- The key is to be mindful of your time allocation and strive for a healthy balance across the three categories.
Post init hook in the odoo 17 ERP ModuleCeline George
In Odoo, hooks are functions that are presented as a string in the __init__ file of a module. They are the functions that can execute before and after the existing code.
Creativity for Innovation and SpeechmakingMattVassar1
Tapping into the creative side of your brain to come up with truly innovative approaches. These strategies are based on original research from Stanford University lecturer Matt Vassar, where he discusses how you can use them to come up with truly innovative solutions, regardless of whether you're using to come up with a creative and memorable angle for a business pitch--or if you're coming up with business or technical innovations.
2. Risk Management
Risk management is one of the main jobs of Project Manager.
Risk management is a set of actions that helps the project
manager plan an approach to deal with uncertain
occurrences.
It involves anticipating risks that might affect the project
schedule or the quality of the software being developed and
taking actions to avoid these risks.
Risk management is an emerging area that aims to address
the problem of identifying and managing the risks associated
with a software project.
2
3. Risk Management
Risk in a project is the possibility that the defined
goals are not met. It is the inability to achieve
objectives within defined cost, schedule, and
technical constraints.
Most projects have risks, especially the big projects.
Risk management is the area that tries to ensure that
the impact of risks is minimal on –
– Cost
– Quality
– Schedule
3
4. Why is Risk Management important?
• History of software development is full of major & minor failures
(Because risks were not identified & managed properly).
– Projects run over budget
– Behind schedule
– Some abandoned midway
• Any project can encounter uncertainties in the form of increased
costs, schedule delays, and diminished qualities. Unless tackled,
these uncertainties can lead to major project disasters.
• Software is a difficult undertaking. Lots of things can go wrong.
Understanding the risks and taking proactive measures to avoid or
manage them –is a key element of good software project
management.
4
5. Risk Management
• What can go wrong?
• What is the likelihood?
• What will the damage be?
• What can we do about it?
5
6. Risk Management Process
What are the steps in Risk Management Process?, or
What are the major activities/tasks of a project manager in
risk management?
1) Risk Identification –possible risks are identified
2) Risk Analysis –risks are analyzed to determine the likelihood
and the damage/consequences. Risks are ranked by
probability & impact.
3) Risk Planning –A plan is developed to manage the risks with
high probability & high impact.
4) Risk Monitoring –Risk is constantly assessed & plans for risk
mitigation are revised.
6
7. Characterizing Risk
Risk concerns the future happenings
– What risks might cause software project to go awry? What can
we do today to avoid problems tomorrow?
Risk involves change
– How will changes affect timeliness & overall success?
– What aspects of the problem domain and solution are unstable?
Risk involves choice & uncertainty
– What methods & tools should we use? How many people
should be involved? How much emphasis on quality is
“enough”? We often make decisions based on incomplete
information.
RISK, like DEATH, is one of the few certainties of life.
7
8. Risk Strategies : Reactive vs. Proactive
Reactive Risk Management:
– Laughingly called “Indiana Jones school of risk
management”
– Risk management ==> Crisis management (“fire-fighting
mode”)
– Project team reacts to risks when they occur
– Software team does nothing about risks until something
goes wrong, then the team flies into action in an attempt
to correct the problem rapidly(this is called “fire-fighting
mode”). When this fails, “crisis management” takes over
and the project is in real jeopardy.
8
9. Risk Strategies : Reactive vs. Proactive
Proactive Risk Management:
– A considerably more intelligent strategy for risk
management
– Identify potential risks in advance
– Assess probability and impact
– Prioritize the risks by importance
– Establish explicit risk management plan
– But “Risk is unavoidable”( not all risks can be avoided), so
contingency plan is developed
9
10. Software Risks
Software risk always involves two characteristics –
1) Uncertainty –the risk may or may not happen; there
are no 100% probable risks.
2) Loss –If the risk becomes a reality, unwanted
consequences or losses will occur.
10
11. Software Risks
• When risks are analyzed, it is important to –
– Quantify the level of uncertainty
– The degree of loss associated with each risk
– Consider different categories of risks
11
12. Categories of Risks
What are the categories of risks encountered as software is
built?
– Project risks
– Product risks
– Technical risks
– Business risks
– Known risks
– Predictable risks
– Unpredictable risks
• Note that these risk types may overlap.
12
13. Project Risks
Project risks threaten the project plan. If risks become real,
then
– Project schedule will slip
– Costs will increase
Project risks affect the project schedule or resources.
Project risks identify potential budgetary, schedule,
personnel, resource, stakeholder and requirements problems
and their impact on a software project.
Examples: Experienced staff will leave the project before it is finished,
Essential hardware for the project will not be delivered on time, There
will be a change of organizational management with different priorities.
13
14. Product Risks
• Product risks are risks that affect the quality or
performance of the software being developed.
• An example might be the failure of a purchased
component to perform as expected.
• Other examples – Size underestimate, Requirement
change, CASE tool underperformance
14
15. Technical Risks
• Threaten quality and timeliness of the software to be
produced. If a technical risk becomes a reality,
implementation may become difficult/impossible.
• Technical risks identify potential design,
implementation, interface, verification and
maintenance problems.
• Other risk factors: specification ambiguity, technical
uncertainty, technical obsolescence, “leading-edge”
technology.
15
16. Technical Risks
• Technical risks occur because the problem is harder
to solve than we thought it would be.
– Is the technology new to you?
– New algorithms ?
– Interface with new/unproven HW/SW/DB?
– Specialized user interface?
– New analysis, design, testing methods?
– Unconventional development methods?
– Excessive performance constraints?
– Customer uncertain about feasibility?
16
17. Business Risks
Business risks threaten the viability of the software to be
built.
Business risks often jeopardize the project or the product.
Business risks affect the organization development or
procuring the software.
Top five business risks –
1) No market for product (market risk)
2) Product no longer fits in the business plan (strategic risk)
3) Sales force doesn’t know how to sell the product (sales
risk)
4) Loss of management support (management risk)
5) Losing budgetary or personnel commitment (budget risk)
17
18. Known Risks
• Uncovered after careful evaluation of the project
plan, the business & technical environment in which
the project is being developed and other reliable
information sources.
• Examples
– Unrealistic delivery date
– Lack of documented requirements
– Lack of software scope
– Poor development environment
18
19. Predictable Risks
• Predictable risks are extrapolated from past project
experience.
• Examples
– Staff turnover
– Poor customer communication
19
21. Seven Principles Of Risk Management
1) Maintain a global perspective—View software risks
within the context of system and the business problem
2) Take a forward-looking view—Think about the risks
that may arise in the future; Establish contingency plans
so that future events are manageable
3) Encourage open communication—If someone states a
potential risk, don’t discount it.
4) Integrate—A consideration of risk must be integrated
into the software process.
21
22. Seven Principles Of Risk Management
5) Emphasize a continuous process—The team must be
vigilant throughout the software process, modifying
identified risks as more information is known and
adding new ones as better insight is achieved.
6) Develop a shared product vision—If all stakeholders
share the same vision of the software, it likely that
better risk identification and assessment will occur.
7) Encourage teamwork—The talents, skills and
knowledge of all stakeholder should be pooled when
risk management activities are conducted.
22
24. Risk Identification
• Risk identification is a systematic attempt to specify
threats to the project plan ( estimates, schedule,
resource loading etc.)
• By identifying known & predictable risks, the project
manager takes a first step toward –
– avoiding them when possible
– controlling them when necessary
24
25. Risk Identification
• There are two distinct types of risks for each of the
categories we discussed
1) Generic risks – are a potential threat to every
software project.
2) Product-specific risks
– Can be identified only by those with a clear
understanding of the technology, the people, and the
environment that is specific to the software to be built
– To identify product-specific risks, the project plan &
statement of scope are examined
25
26. Risk Identification Method
One method for identifying risks is to create a risk item
checklist.
• The checklist can be used for risk identification and focuses
on some subset of known & predictable risks in the following
generic subcategories:
1) Product size—Risks associated with the overall size of
the software to be built or modified.
2) Business impact—Risks associated with constraints
imposed by management or the marketplace.
3) Customer characteristics—Risks associated with the
sophistication of the customer and the developer's ability
to communicate with the customer in a timely manner.
26
27. Risk Identification
4) Process definition—Risks associated with the degree to
which the software process has been defined and is followed
by the development organization.
5) Development environment—Risks associated with the
availability and quality of the tools to be used to build the
product.
6) Technology to be built—Risks associated with the
complexity of the system to be built and the "newness" of
the technology that is packaged by the system.
7) Staff size and experience—Risks associated with the overall
technical and project experience of the software engineers
who will do the work.
27
28. Assessing Overall Project Risk-I
Is the current software project at serious risk?
• Have top software and customer managers formally
committed to support the project?
• Are end-users enthusiastically committed to the project and
the product to be built?
• Are requirements fully understood by the software
engineering team and their customers?
• Have customers been involved fully in the definition of
requirements?
• Do end-users have realistic expectations?
28
29. Assessing Overall Project Risk-II
• Is project scope stable?
• Does the software engineering team have the right mix of
skills?
• Are project requirements stable?
• Does the project team have experience with the technology
to be implemented?
• Is the number of people on the project team adequate to do
the job?
• Do all customer/user constituencies agree on the importance
of the project and on the requirements for the product to be
built?
29
30. Risk Components & Impacts
• 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.
Impact Category: Negligible, Marginal, Critical, Catastrophic
30
32. Risk Estimation/Projection
• Risk projection, also called risk estimation, attempts
to rate each risk in two ways
– The likelihood or probability that the risk is real
– The consequences of the problems associated
with the risk, should it occur.
32
33. Risk Estimation/Projection
• There are four risk projection steps:
1) Establish a scale that reflects the perceived
likelihood of a risk
2) Delineate the consequences of the risk
3) Estimate the impact of the risk on the project
and the product
4) Note the overall accuracy of the risk projection
(to avoid misunderstandings).
33
34. Developing a Risk Table
• A Risk Table provides a project manager with a simple
technique for risk projection
– Estimate the probability of occurrence
– Estimate the impact on the project on a scale of 1 to 4,
where
4 = Negligible/low impact on project success
3 = Marginal impact on project success
2 = Critical impact on project success
1 = Catastrophic impact on project success
– Sort the table by probability and impact
34
35. Developing a Risk Table
35
A Risk Table provides a project manager
with a simple technique for risk projection
PS – project size risk
BU – business risk
36. Assessing Risk Impact
How do we assess the consequences of a risk?
• Three factors affect the consequences that are likely
if a risk does occur:
1) It’s nature-indicates the problems that are likely
2) Scope- Severity & its overall distribution
3) Timing- When & for how long the impact will be
felt
36
37. Risk Exposure (Impact)
• The overall risk exposure, RE, is determined using the
following relationship :
RE = P x C , where
– P is the probability of occurrence for a risk
– C is the cost to the project should the risk occur
• Risk exposure can be computed for each risk in the Risk Table,
once an estimate of the cost of the risk is made.
• Total risk exposure for all risks can provide a means for
adjusting the final cost estimate for a project.
• Note: If RE > 50% of Project Cost, viability of the project must
be reevaluated.
37
38. Risk Exposure: An Example
• 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% (likely).
• Risk impact. 60 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.
38
39. Risk Mitigation, Monitoring, and Management
• Mitigation—How can we avoid the risk?
• Monitoring—What factors can we track that will
enable us to determine if the risk is becoming more
or less likely?
• Management—What contingency plans do we have
if the risk becomes a reality?
39
40. The RMMM plan
• Risk management strategy can be included in the
software project plan or the risk management steps
can be organized into a separate RMMM plan.
The RMMM plan (Risk Mitigation, Monitoring and
Management plan):
– Documents all work performed as part of risk
analysis
– Used by Project Manager as part of the overall
project plan
40
41. The RMMM plan
• Risk mitigation
– Problem avoidance activity
– Proactive planning for risk avoidance
41
42. The RMMM plan
Risk monitoring
• Project tracking activity with three primary
objectives –
1. Assessing whether predicted risks occur or not
2. Ensuring risk aversion steps are being properly applied
3. Collect information for future risk analysis
• Determining what risk(s) caused which problems
throughout the project
42
43. The RMMM plan
• It is important to note that RMMM steps incur additional
project cost.
• Project planner performs a classic cost/benefit analysis.
• Adapt Pareto rule(80–20 rule) to software risks:
– 80% of the overall project risk can be accounted for by
only 20% of the identified risks.
– Work performed during earlier risk analysis steps will help
the planner to determine which of the risks reside in that
20%
• The RMMM Plan needs to be tracked & updated regularly.
43
44. Risk Information Sheets
RIS (Risk Information Sheet)
• Instead of developing a formal RMMM plan, some software
teams use RIS.
• In RIS, each risk is documented individually.
• In most cases, the RIS is maintained using a database system.
• RIS components:
– risk id, date, probability, impact, description
– refinement, mitigation/monitoring
– management/contingency plan/trigger
– current status
– originator, assigned staff member
44
45. Risk Management
• “If you know the enemy and know yourself, You
need NOT fear the result of a hundred Battles.”
• For the software project manager, The enemy is
RISK!
45
Sun Tzu ( Chinese General)