Suborbital-Systems-Public/ReadySetGit
3
0
Fork 0
Code Pull Requests Packages Projects Releases Activity

GFM changes

Browse Source
This commit is contained in:
William Sandner
2018-08-15 00:37:52 +02:00
parent e6c1356aa0
commit 539106de83
21 changed files with 431 additions and 896 deletions
Download Patch File Download Diff File Expand all files Collapse all files

223
Risks.md
View File

@@ -1,27 +1,3 @@
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<link type="image/png" href="assets/logo.png" rel="icon">
<title>ReadySet Markdown</title>
</head>
<script src="https://www.w3schools.com/lib/w3data.js"></script>
<body>
<topbar style="display:none;">
<item><a href="index.html">Overview</a></item>
<item><a href="plan.html">Project Plan</a></item>
<item><a href="index-all.html">Workflows</a></item>
<menu name="Themes"><item><a id="settheme"><b>Current</b></a></item></menu>
<toc></toc>
</topbar>
<xmp theme="readable" style="display:none;">
<!-- Markdown content here -->
# Risks
---
##### Project:
::[PROJECTNAME](Home)
@@ -35,6 +11,7 @@
##### References:
- [Risk Management during Requirements](http://www.systemsguild.com/pdfs/s5req.lo%201.pdf) by Tom DeMarco and Tim Lister
- [Taxonomy-Based Risk Identification](http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr06.93.pdf) by Carr, Konda, Monarch, Ulrich, and Walker (SEI)
---
**Process impact:** This document records the major project risks, and
@@ -52,12 +29,78 @@ plans to control them. For each risk the plan should include:
general contingency plans. In this case you only need to give a
contingency plan if you have a special one for the particular risk.
The severity of a risk is its likelihood multiplied by its impact. Risks
are classified as minor if they have low likelihood, negligible impact,
or medium likelihood and marginal impact.
The severity of a risk is its likel
##### Project:
::[PROJECTNAME](Home)
*TODO: You should update these lists regularly. They should be reviewed
by customers and developers from time to time.*
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---ihood multiplied by its impact. Risks
are classified as minor if they hav
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---e low likelihood, negligible impact,
or medium likelihood and marginal i
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---mpact.
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---
*TODO: You should update these list
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---s regularly. They should be reviewed
by customers and developers from ti
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---me to time.*
### General contingency plans
@@ -95,7 +138,7 @@ delivery date.
|-----------------|---------------------------------------------------------------------------------------------------------------------------------|------------|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|-------------------|
| ::Requirements | Requirements are only partly known at project start. Customers may not allocate sufficient resources to exploring requirements. | Medium | Critical to Catastrophic | Requirements will be detailed first for the top priority goals. Indicator: Track the rate at which requirements are discovered. Contingency: request more customer effort. | Amber | Requirements Lead |
| ::Goals | Stakeholders goals may conflict. | Medium | Critical | Keep an explicit list of stakeholders goals. The project manager will report progress to each declared goal. | Green | Customers |
| ::Communication | Communication problems in development team. They are dispersed among several sites, and have not worked together before. | Medium | Critical | Use these [tools](sdm#communication) to help communication. The main indicator of miscommunication will be software defects detected by our [QA activity](qa-plan). | Green | QA lead |
| ::Communication | Communication problems in development team. They are dispersed among several sites, and have not worked together before. | Medium | Critical | Use these [tools](SDM#communication) to help communication. The main indicator of miscommunication will be software defects detected by our [QA activity](qa-plan). | Green | QA lead |
| ::Acceptance | Customer may accept delivery of the system although it does not really meet their goals. | Medium | Critical | Customers are asked to declare acceptance criteria as each release is planned. | Green | Customers |
| ::Scope | The total features requested may be beyond what the development team can deliver in the time available. | High | Marginal | Assign levels of important to the use cases. Make the first review of project scope after 12 months. | Green | Customers |
@@ -108,11 +151,99 @@ impact of a risk has increased to make it a "major" risk.*
|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|----------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|-----------------|
| ::Estimate | The development team might not be able to estimate the work time, preventing customers from deciding priorities effectively. | Medium | Marginal | The development team will gain experience in estimating the work, and deliver the first estimates after 12 months. We will compare estimated work to actual work. | Green | Project Manager |
| ::Retention | Some developers may leave the project before it is finished. | Medium | Marginal | Employing locations should provide support for continuing professional development. The project manager will discuss career goals with each developer, and try to assign tasks appropriately. | Green | Project Manager |
| ::Correctness | The system as delivered may have low take-up because of a lack of confidence in its correctness. | Low | Catastrophic | State of the art [QA activity](qa-plan). Contingency: stop development of new facilities until the quality of the existing code is assured. | Green | QA Lead |
| ::Usability | The system as delivered may have low take-up because of poor usability. | Low | Critical | We will have a UI style guide. Most of the development of the front end will be in close contact with customers. We will review usability later in the project. | Green | UI design lead |
| ::Correctness | The system as delivered may have low take-up because of a lack of confidence in its correctness. | Low | Catastrophic | State of the art [QA activity](QA-Plan). Contingency: stop development of new facilities until the quality of the existing code is assured. | Green | QA Lead
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- |
| ::Usability | The system as
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- delivered may have low take-up because of poor usability.
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- | Low
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- | Critical | We will have a UI style guide. Most of the development of the front end will be in close contact with customers. We will review usability later in the project. | Green | UI design lead |
| ::Desire | The stated requirements might not match the customers' desires and ambitions for the system. | Low | Critical | Incremental delivery of versions will provide experience of using the system, which will help the customers to identify the real requirements. Indicator: a developer saying "I think they mean ...", a customer saying "They know what I mean". Contingency: request customer review of requirements. | Green | Customers |
| ::Changes | After requirements have been documented and agreed, development activities begin to based on them, first design then implementation. If the requirements change later then effort is wasted. | Low | Critical | A change control procedure is required, so changes are only made when the cost is worthwhile. Indicator: compare cost of change to new development. Contingency: request customer review of requirements. | Green | Project Manager |
| ::Process | Some developers may not cooperate in common standards and processes. | Low | Critical | QA to check conformance, then discussions in development team meetings to change the standard or the actual practice as appropriate. | Green | QA Lead |
| ::Changes | After requirements have been documented and agreed, development activities begin to based on them, first design then implementation. If the requirements change later then effort is wasted. | Low | Critical | A change control procedure is required, so changes are only made when the cost is worthwhile. Indicator: compare cost of change t
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---o new development. Contingency: request customer review of requirements.
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- | Green | P
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---roject Manager |
| ::Process | Some develope
##### Project:
::[PROJECTNAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Related Documents:
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---rs may not cooperate in common standards and processes. | Low | Critical | QA to check conformance, then discussions in development team meetings to change the standard or the actual practice as appropriate. | Green | QA Lead |
| ::Maintainability | The system as delivered might be hard to maintain. | Low | Marginal | We will review the code for maintainability. | Green | Lead Developer |
| ::RISKNAME | ONE-TO-THREE-SENTENCES | Low or Medium or High | Negligible or Marginal or Critical or Catastrophic | ONE-TO-THREE-SENTENCES | Red or Amber or Green | PERSONNAME |
@@ -130,7 +261,7 @@ Not yet active
### Risk Checklist
#### Do the plans provide an indicator to detect each of the risks becoming active?
::Yes, if all activies are carried out as planned, we will know if any
::Yes, if all activities are carried out as planned, we will know if any
of the risks is becoming troublesome.
::No, some risks could creep up on us.
@@ -180,25 +311,3 @@ the project could deliver.
::No, everything depends on the alertness and strength of character of
the project manager.
<!-- End Markdown content -->
</xmp>
<div w3-include-html="_words-of-wisdom.html"></div>
<div w3-include-html="_footer.html"></div>
<script>
w3IncludeHTML();
</script>
<script src="http://strapdownjs.com/v/0.2/strapdown.js"></script>
<!-- Include it AFTER strapdown -->
<script src="assets/strapdown/strapdown-topbar.min.js"></script>
<!-- Include it AFTER EVERYTHING -->
<script src="assets/logo.js"></script>
<script src="assets/themeswitcher.js"></script>
</body>
</html>