Coventry University Track Locate and Assemble Risk List CUTLASS-Risk List-V 1.

0

Version <1.0> 22 October 2011

TEAM-3

Coventry University Track Locate and Assemble (CUTLASS) Risk List Version <1.0>

CONFIDENTIAL

(c) TEAM-3, 2011

Page 1 of 6

Coventry University Track Locate and Assemble Risk List CUTLASS-Risk List-V 1.0

Version <1.0> 22 October 2011

Revision History
Date 22 October 2011 30 October 2011 Version <0.0> <1.0> Description Draft copy First version Author Kishen Gajanan Kishen Gajanan

CONFIDENTIAL

(c) TEAM-3, 2011

Page 2 of 6

Coventry University Track Locate and Assemble Risk List CUTLASS-Risk List-V 1.0

Version <1.0> 22 October 2011

Table of Contents

1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview

4 4 4 4 4 4

2. Risk 2.1 <Risk Identifier – a descriptive name or number> 2.1.1 Risk magnitude or Ranking 2.1.2 Description 2.1.3 Impacts 2.1.4 Indicators 2.1.5 Mitigation Strategy 2.1.6 Contingency Plan

4 4 5 5 5 5 6 6

2.2 <next Risk Identifier – a descriptive name or number>

6

CONFIDENTIAL

(c) TEAM-3, 2011

Page 3 of 6

Coventry University Track Locate and Assemble Risk List CUTLASS-Risk List-V 1.0

Version <1.0> 22 October 2011

1. Introduction
Projects during the time of development might overcome a lot of hurdles. There are few hurdles that a team might have a prerequisite knowledge during development. There will be a group of people who make a list of these hurdles in form of document knows as the Risk List.

1.1. Purposes
The main purpose of the risk list is to identify in advance, that what are the hurdles we might have to overcome before providing effective software to the clients.

1.2. Scope
Team 3 is given software that has to be developed for the Coventry University, for the safety of their students’ electronic device. We have to develop them software to register their electronic devices and later help finding them in case the device is lost in campus. The main scope of this document is to highlight the tasks that have to be done further during development in order to improve the efficiency.

1.3. Definitions, Acronyms and abbreviations
CUTLASS: Coventry University Track Locate and Assemble

1.4. References
None

1.5. Overview
This entire document makes a list of Risks that we might have to overcome. Further in this document we explain what are the varieties of risk, what are the damages that might be caused and what are the measures that can be taken for the benifiacry of the software.

2. Risks
2.1 Risk List
1. Functionality Risks 2. Generic Risk 3. System Dependant Risks

CONFIDENTIAL

(c) TEAM-3, 2011

Page 4 of 6

Coventry University Track Locate and Assemble Risk List CUTLASS-Risk List-V 1.0

Version <1.0> 22 October 2011

2.1.1 Risk Magnitude There are various types of risks based on various factors during building software. Here is a list of few major Risks our company has to overcome in order to provide an efficient product. 1. Functionality Risk – High 2. Generic Risk – High 3. System Specific Risk – Intermediate 2.1.2 Description During the development of software, as it is related with database to store the values and we also use servers. There might be an issue with the functionality of the servers and database which may lead to a failure of the project by losing valuable data. This particular risk is called as Functionality Risk. Generic Risk, this risk might occur during the initial stages of the development of the product. If the clients request are not identified or misinterpreted during initial stage, we might end up building a wrong product which leads to a total failure. System Specific Risk can be caused when the software is not compatible with the particular system configuration or the operating system. There are possibilities where the software might work on an advanced operating system but not on the outdated one. 2.1.3 Impacts Functionality Risk might lead to a total failure of the system or build wrong software Generic Risk might lead to launching a total different product which might not interest the client. System Specific Risk might lead for the software not to work on all electronic devices. 2.1.4 Indicators We have a system that detects if we losing a server or the database if it is going to crash. We have various methods to detect these changes in the system and a display screen always showing the threshold of the system. Generic risk, we have a panel of expwrtise who are in charge of understanding the clients’ requirements. They also ask many questions to the client and confirm the details twice before providing the overview of the project to the team.

CONFIDENTIAL

(c) TEAM-3, 2011

Page 5 of 6

Coventry University Track Locate and Assemble Risk List CUTLASS-Risk List-V 1.0

Version <1.0> 22 October 2011

Our company have advanced electronic devices to work with and hence we have a tool that we run on the software which indicates us if the particular function is able to run on all the systems. 2.1.5 Mitigation Strategy To reduce the occurrences of the risks during the development of the project, we have assigned a team who are in charge of using the tools to detect if we are going to have any trouble with the development. Set of expertise are in charge of monitoring the indicators constantly and give a warning to the team if at all a system is about to hit a bump. We also do constant checks in between and run some tests to make sure the systems are working efficiently. The team is also coming with a new system that would detect the risk at early stages. 2.1.6 Contingency Plan If the Functionality risk does materialize, alternate solution would be to look into our secondary memory and start the functions from the place where it was stopped. If server is not working efficiently, then we have an alternate server to provide little back up. Generic risk if it does materialize, alternate solution would be change the systems functionality from where the changes have occurred. We have a progress report from the client end, where they have a note on how the system is progressing and if any fault found, we can change the functionality from the previous check point. System Specific Risk, if this does occur, and then we have updating software provided periodically so that user can update the software on their system and use it normally. And further versions will be released as the technology improvises.

2.2 Next Risk Identifier
Based on the identified risk contents in the software, there are various measures to identify or track a risk. Few risks that we might face during the period might be “schedule risk” where we might reach our deadlines given to develop the software. Due to constant growth in technology, various electronic devices needs a upgraded software, this is where the “system specific risk” might be encountered. With the further upgrade to the systems and software, we need to have a record of the data and risks encountered or we might find it difficult to trace further risks “tracking risk”

CONFIDENTIAL

(c) TEAM-3, 2011

Page 6 of 6

Sign up to vote on this title
UsefulNot useful