meljun cortes jedi slides-7.8 risk management

7/29/2019 MELJUN CORTES JEDI Slides-7.8 Risk Management

1/26

Software Engineering 1

Basic Software Project

Management

Risk Management

TOPIC EIGHT


2/26


It is considered a potential problem.

It may or may not happen.

It is better to: Identify them.

Assess its probability of occurring

Estimate its impact

Establish a contingency plan

Risk


3/26


Two Risk Characteristics

Level of Uncertainty

It is the probability that a risk can happen.

Degree of Loss

It is the extent of damage once the risk is realized.


4/26


Category of Risk

Project Risks

These are risks associated with the project plan. If suchrisk becomes a reality, chances are there would be

delays, budgetary and resource problems. Technical Risks

These are risks associated with the implementationaspects of the software. If such risk becomes a reality, itwould be very difficult for us to implement the project.

This may include design and interface problems,component problems, database and infrastructureproblems.


5/26


Category of Risk

Business Risks.

These are risks associated with the viability of thesoftware. If such risk becomes a reality, the software

will become a problem in a business setting. This mayinclude building a software that no one needs, building asoftware that cannot be market and losing budgetary andpersonnel commitment.

Known Risks.

These are risks that can be detected with carefulevaluation of the project plan, business environmentanalysis, and other good informational sources.


6/26


Category of Risks

Predictable Risks.

These are risks that came from past similar projects thatare expected to happen with the current one.

Unpreditable Risks. These are risks that are not detected.


7/26


Risk Table

It is a tool that allows software engineer identify and managerisk.

Risks

Identified

Category Probability Impact RMMM

Project Size Estimatesmay be too low. PS 60% 2

A large number ofgroup of end-users arenot identified.

PS 30% 3

No components arereused.

PS 70% 2

Members of the

steering committee arenot interested in theproject.

BU 40% 3

Project deadline is notnegotiable.

BU 50% 2

Staff turnover will behigh

ST 60% 1


8/26


Type of Risk

Product Size (PS).

These are risks that are related to the overall size of thesoftware that needs to be developed.

Business Impact (BU). These are risks that are related to the constraints imposed by

management or market.

Customer Characteristics (CC).

These are risks that are related to end-users requirementsand the ability of the development team to understand andcommunicate with them.


9/26


Type of Risk

Process Definition (PD)

These are risks that are related to the software process andhow the people involved in the development effort areorganized.

Development Environment (DE)

These are risks that are related to the availability and qualityof the tools that are used to develop the software.


10/26


Type of Risk

Technology TC)

These are risks that are related to the complexity of thesystem and the degree of newness that is part of the software.

Staff Size and Experience (ST). These are risk that are related to the overall technical and

project experience of the software engineers.


11/26


Risk Impact

1-Catastrophic.

It would result in failure to meet the requirements and non-acceptance of the software.

2-Critical. It would result in failure to meet the requirements with system

performance degration to the point of mission success isquestionable.

3-Marginal.

It would result in failure to meet the requirements would resultin degration of secondary mission.

4-negligible

It would result in inconvenience or usage problems.


12/26


Risk Mitigation, Monitor and

Management (RMMM) Plan It is a document containing a plan to manage each risk. It consists of the following:

Risk ID

Description

Context

Risk Mitigation and Monitoring

Contingency Plan


13/26


Risk Identification Checklist

Product Size Risks

Business Impact Risks

Customer-related Risks

Process Risks-Process Issues

Process Risk-Technical Issues

Technology Risks

Development Environment Risks

Risk Associated with Staff Size and Experience


14/26


Product Size Risks

How large is the estimated size of the software in terms oflines-of-code and function points?

How many is number of programs, files and transactions?

What is the database size? How many is the estimated number of users?

How many components are reused?


15/26



What is the business value of the software to the companyor organization?

What is the visibility of the software to senior management?

How reasonable is the delivery date? How many is the customers?

How many are the products or systems that interoperatewith the software?

How large is the project documentation?


16/26



Does the product documentation have quality?

What are the governmental constraints applied to thedevelopment of the project?

What is the cost associated with late delivery? What is the Cost associated with a defective product?


17/26


Customer Related Risks

What is the customer working relationship?

What is the level of the customers ability to state theirrequirements?

Are customers willing to spend time for requirementsgathering?

Are customers willing to participate in formal technicalreviews?

How knowledgeable are the customers in terms of thetechnological aspects of the software?

Do customer understand of the software developmentprocess and their role?


18/26


Process Risks-Process

Issues Does senior management show full support or commitmentto the software development effort?

Do the organization have a developed and writtendescription of the software process to be used on thisproject?

Do the staff members know the software developmentprocess?

Is the software process used before in other projects with

the same group of people? Has your organization developed or acquired a series of

software engineering training courses for managers andtechnical staff?


19/26



Issues Are there any published software engineering standards thatwill be used by software developer and software manager?

Are there any developed document outlines and examplesof deliverables?

Are formal technical reviews of the requirementsspecification, design and code done regularly? Do theyhave defined procedures?

Are formal technical reviews of test procedures, test cases

done regularly? Do they have defined procedures? Are the results of each formal technical review documented,

including errors found and resources used? Do they havedefined procedures?


20/26



Issues Do they have procedures that ensure that work conductedon a project conforms to software engineering standards?

Do they use configuration management to maintainconsistency among system/software requirements, design,code, and test cases?

Do they have documents for the statement of work, softwarerequirements specification, and software development planfor each subcontract?


21/26


Process Risk-Technical

Issues Are there any mechanism that facilitates clearcommunication between customer and developer?

Are there any specific methods used for software analysis?

Are there any specific methods used for component design? Are there any specific method for data and architectural

design?

Are codes written in a high level language? How much isthe percentage?

Are documentation and coding standards followed?

Are there any specific methods for test case design?


22/26


Process Risk-Technical

Issues Are software tools used to support planning and trackingactivities?

Are configuration management software tools used tocontrol and track change activity throughout the softwareprocess?

Are CASE tools used?

Are quality metrics collected for all software projects?

Are there any productivity metrics collected for previoussoftware projects?


23/26


Technology Risks

Is the organization new to the technology?

Do we need to create new algorithms, input or outputtechnology?

Do the software need to use new or unsupported hardware? Do the software need to use a database system not tested

in the application area?

Do we need to define a specialized user interface?

Do we need to use new analysis, design, or testingmethods?

Do we need to use unconventional software developmentmethods, such as formal methods, AI-based approaches,and artificial neural networks?


24/26


Development Environment

Risks Are there any software project management toolsemployed?

Are there any tools for analysis and design?

Are there any testing tools? Are there any software configuration management tools?

Are all software tools integrated with one another?

Do we need to train the members of the development team

to use the tools? Tools? Are there any on-line help and support groups?


25/26


Risk Associated with Staff

Size and Experience Is the staff turnover high? Do we have skilled team members?

Is there enough number of people in the development team?

Will the people be required to work overtime? Will there any problems with the communications?


26/26


Summary

Risks and Risk Management Category of Risk

The Risk Table

Risk Identification Checklist

meljun cortes jedi slides-7.8 risk management

Documents