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

Fix markdown lint errors

Browse Source
This commit is contained in:
William Sandner
2023-03-24 17:29:16 +01:00
parent 0d20f4e5b1
commit c504fc26da
50 changed files with 702 additions and 637 deletions
Download Patch File Download Diff File Expand all files Collapse all files

123
Project-Plan.md
View File

@@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@@ -24,8 +25,8 @@ project. Key assumptions that affect the plan should be documented here.
The project plan should be updated throughout the life-time of the
project.
*TODO: Fill in the information above and below. Add or remove rows as
needed. Use the worksheet to help identify and scope resource needs.*
_TODO: Fill in the information above and below. Add or remove rows as
needed. Use the worksheet to help identify and scope resource needs._
### Summary of Project
@@ -101,59 +102,59 @@ to a project mailing list.
### Work Breakdown Structure and Estimates
*TODO: List tasks that will be needed for this project. Keep dividing
_TODO: List tasks that will be needed for this project. Keep dividing
tasks into subtasks until you feel that you have enough detail to expose
risks and make reasonable estimates in ideal engineering hours.*
risks and make reasonable estimates in ideal engineering hours._
*TIP: Label each step uniquely to show its position in the WBS, e.g.,
_TIP: Label each step uniquely to show its position in the WBS, e.g.,
Step 1.1.4.A. Use numbers for steps that you intend to do in sequence,
and use letters for steps that you intend to do in parallel. E.g., Step
1.1 comes before Steps 1.2.A and 1.2.B, but those two steps may be done
in parallel, and Step 1.3 will be done after all 1.2.\* steps have been
finished. Don't worry about renumbering if you delete a step.*
finished. Don't worry about renumbering if you delete a step._
| Step | Description | Estimate |
|-----------|-----------------------------------------------------------|----------|
| 1. | ::Preparation | |
| 1.1. | ::Developer training | 30h |
| 2. | ::Inception | |
| 2.1. | ::Requirements gathering | 30h |
| 2.2. | ::Requirements specification | 20h |
| 2.3. | ::Requirements validation | 10h |
| 3. | ::Elaboration | |
| 3.1. | ::High-level design | 5h |
| 3.2. | ::Low-level design (break down by component) | |
| 3.2.A. | ::Object design | 10h |
| 3.2.B. | ::User interface design | 10h |
| 3.2.C. | ::Database design | 3h |
| 3.3. | ::Design review and evaluation | 5h |
| 4. | ::Construction | |
| 4.1.A. | ::System implementation | |
| 4.1.A.1. | ::Implement COMPONENT-NAME 1 | 25h |
| 4.1.A.2. | ::Implement COMPONENT-NAME 2 | 25h |
| 4.1.A.3. | ::Implement COMPONENT-NAME 3 | 25h |
| 4.1.A.4. | ::Implement COMPONENT-NAME 4 | 25h |
| 4.1.A.5. | ::Integrate Components (mostly done during implementation)| 5h |
| 4.1.B. | ::Technical documentation (break down by component) | 10h |
| 4.1.C. | ::User documentation (break down by component) | 10h |
| 4.1.D. | ::Testing | |
| 4.1.D.1. | ::Test planning | 10h |
| 4.1.D.2. | ::Test code implementation (break down by component) | 30h |
| 4.1.D.3. | ::Test execution | 10h |
| 4.2. | ::Implementation review and evaluation | 15h |
| 5. | ::Transition | |
| 5.A. | ::Release packaging | 3h |
| 5.B. | ::Documentation for other groups | 3h |
| 6. | ::Reflection | |
| 6.1. | ::Postmortem report | 10h |
| | ::Total | 329 hours|
| Step | Description | Estimate |
| -------- | ---------------------------------------------------------- | --------- |
| 1. | ::Preparation | |
| 1.1. | ::Developer training | 30h |
| 2. | ::Inception | |
| 2.1. | ::Requirements gathering | 30h |
| 2.2. | ::Requirements specification | 20h |
| 2.3. | ::Requirements validation | 10h |
| 3. | ::Elaboration | |
| 3.1. | ::High-level design | 5h |
| 3.2. | ::Low-level design (break down by component) | |
| 3.2.A. | ::Object design | 10h |
| 3.2.B. | ::User interface design | 10h |
| 3.2.C. | ::Database design | 3h |
| 3.3. | ::Design review and evaluation | 5h |
| 4. | ::Construction | |
| 4.1.A. | ::System implementation | |
| 4.1.A.1. | ::Implement COMPONENT-NAME 1 | 25h |
| 4.1.A.2. | ::Implement COMPONENT-NAME 2 | 25h |
| 4.1.A.3. | ::Implement COMPONENT-NAME 3 | 25h |
| 4.1.A.4. | ::Implement COMPONENT-NAME 4 | 25h |
| 4.1.A.5. | ::Integrate Components (mostly done during implementation) | 5h |
| 4.1.B. | ::Technical documentation (break down by component) | 10h |
| 4.1.C. | ::User documentation (break down by component) | 10h |
| 4.1.D. | ::Testing | |
| 4.1.D.1. | ::Test planning | 10h |
| 4.1.D.2. | ::Test code implementation (break down by component) | 30h |
| 4.1.D.3. | ::Test execution | 10h |
| 4.2. | ::Implementation review and evaluation | 15h |
| 5. | ::Transition | |
| 5.A. | ::Release packaging | 3h |
| 5.B. | ::Documentation for other groups | 3h |
| 6. | ::Reflection | |
| 6.1. | ::Postmortem report | 10h |
| | ::Total | 329 hours |
### Deliverables in this Release
*TODO: List project deliverables in detail, with delivery dates.*
_TODO: List project deliverables in detail, with delivery dates._
| Deliverable Name | Description | Delivery Date |
|------------------|---------------------------------------------------------------|---------------|
| ---------------- | ------------------------------------------------------------- | ------------- |
| Deliverable Name | ::Description | Delivery Date |
| Deliverable Name | ::Description | Delivery Date |
| Deliverable Name | ::Description Description Description Description Description | Delivery Date |
@@ -161,20 +162,20 @@ finished. Don't worry about renumbering if you delete a step.*
### Schedule for this Release
*TODO: Make the rows in this table match the steps in your WBS above. If
_TODO: Make the rows in this table match the steps in your WBS above. If
you have a large number of detailed steps, you can skip the most
detailed ones. The columns of the table represent weeks of calendar
time. For each cell in the table, enter the number of hours ideal
engineering time that the team will spend on that task that week. Total
your hours across and down.*
your hours across and down._
*TIP: These hours should total to the same as the total of the hours
_TIP: These hours should total to the same as the total of the hours
listed in your [resource needs](Resource-Needs) document. And, the
hours for each type of effort resources needed should correspond to the
sum for each type of task.*
sum for each type of task._
| Task \ Week | W-01 | W-02 | W-03 | W-04 | W-05 | W-06 | W-07 | W-08 | W-09 | W-10 | W-11 | W-12 | Task Total |
|-----------------|------|------|------|------|------|------|------|------|------|------|------|------|------------|
| --------------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---------- |
| ::1. | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
| ::2. | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
| ::3. | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
@@ -189,10 +190,10 @@ sum for each type of task.*
### Risk Management
*TODO: List and rank the major risks of this project, and what you plan
_TODO: List and rank the major risks of this project, and what you plan
to do to mitigate each risk. If you don't plan to do anything to
mitigate the risk, state that. Use the risk list below, or the [risks
worksheet](Risks).*
worksheet](Risks)._
Please see the [risks worksheet](Risks).
@@ -203,15 +204,15 @@ Please see the [risks worksheet](Risks).
3. ::The schedule for this project is very short. We will manage this by planning a conservatively scoped functional core and series of functional enhancements that can be individually slipped to later releases if needed.
4. ::The performance of the system will be significantly impacted by the decisions made during the [database design task](#3.2.C). None of our current team members has experience with database optimization. To address this, we will arrange a review meeting with an experienced DBA or hire a consultant from the database vendor.
5. ::We could be underestimating known tasks.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
6. ::We could be underestimating the impact of unknown tasks.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
7. ::We could be underestimating the dependencies between tasks.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
8. ::We could have misunderstood the customer's requirements.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
9. ::The customer could change the requirements.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
10. ::We could face major difficulties with the technology chosen for this project.
HOW TO AVOID/MITIGATE?
11. ::We could have low quality that demands significant rework.
@@ -230,23 +231,23 @@ Please see the [risks worksheet](Risks).
::No, this is the only project that we are working on.
::Yes, and we have determined how many hours each person can actually
dedicate to this project.
dedicate to this project.
#### Are the same human or machine resources allocated to maintenance of past versions and/or planning of future versions during this release time period?
::No, this is the first release and we will not plan the next release.
::Yes, we predict that team members will spend an average of 20% of
their time maintaining previous releases and planning future
releases during this release time frame. Some weeks may be higher if
an urgent patch to a previous release is needed.
their time maintaining previous releases and planning future
releases during this release time frame. Some weeks may be higher if
an urgent patch to a previous release is needed.
#### Does this project depend on the success of any other project?
::No, this project stands alone.
::Yes, project P1 must provide library L, and project P2 must prove
the usability of feature F, and....
the usability of feature F, and....
#### Does any other project depend on this project?