GFM changes

This commit is contained in:
William Sandner 2018-08-14 23:52:57 +02:00
parent f1aa208ee4
commit e6c1356aa0
3 changed files with 347 additions and 0 deletions

107
Glossary.md Normal file
View File

@ -0,0 +1,107 @@
**Process impact:** This file as a dictionary of terms defined as they
are used during the project. Writing out the definitions of terms and
acronyms here helps keep other documents more concise and precise. A
shared glossary helps prevent misunderstandings and makes it easier for
new team members to be productive.
Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
[G](#g) | [H](#g) | [I](#i) | [J](#j) | [K](#k) | [L](#l) | [M](#m) |
[N](#n) | [O](#o) | [P](#p) | [Q](#q) | [R](#r) | [S](#s) | [T](#t) |
[U](#u) | [V](#v) | [W](#w) | [X](#x) | [Y](#y) | [Z](#z) |
[Standard terms](glossary-std.html#standard_terms)
### Project-specific Terms
*TIPs:*
- *Define HTML anchors on your terms with id="TERMNAME" so that other
documents can link to the definition of specific terms.*
- *If there is any question about the meaning of a term, note it here.
If someone (e.g., the customer) gave you a definition to use, note
that here too. If something is best defined by using a hyperlink to
another document or website, include a hyperlink in the definition.*
- *If a term was used in the past, but is no longer going to be used,
you should keep it in the list, mark it as "deprecated", and link to
the term or terms that replace it. E.g., deprecated standard term
[bug](glossary-std.html#bug).*
- *Define only project-specific terms, or ones that a new team member
would not know. Don't define standard textbook terms that can be
easily found elsewhere.*
- *This glossary can serve as simple domain model or data dictionary.
You can define important data objects by describing their meaning
and key attributes. For example, see [student](#student) and
[GPA](#gpa).*
#### A
 
#### B
 
#### C
 
##### ::Class standing
- ::Computed attribute of [student](#student) based on number of
academic units completed. Used to determine priority in
course enrollment.
- ::Real-world meaning of values:
| | |
|-------------|---------------------------------|
| ::Freshman | ::Less than 90 units |
| ::Sophomore | ::Between 90 and 180 units |
| ::Junior | ::Between 180 and 270 units |
| ::Senior | ::More than 270 units completed |
#### D
 
#### G
 
##### ::GEF
::*n.* The [Graph Editing Framework](http://gef.tigris.org/). An open
source library for editing diagrams (boxes and arrows).
##### ::GPA
::*n.* Grade Point Average. GPA is a float between 0.00 and 4.00,
accurate to 2 decimal places. Computed from average of completed
course grades in transcript weighted by course units. Used to
determine student ranking, and to trigger Dean's List and
academic probation.
#### I
 
##### ::ICS
::*n.* Acronym for the [School of Information and Computer
Science](http://www.ics.uci.edu/) at [UC Irvine](http://www.uci.edu/).
#### S
 
##### ::Student
::*n.* A person who attends a school to earn a degree. Persistent
attributes include: student\_id\_number (primary key), GPA, major,
and years\_at\_school.
##### ::Senior
::*n.* A senior is special type of [undergraduate](#undergraduate) who
has a certain number of course credits on his or her transcript.
Years\_at\_school does not determine senior standing. TODO: how many
credits needed?
#### T
 
##### ::Term1
::Definition1
##### ::Term2
- ::Definition2a
- ::Definition2b
##### ::Term3
::Definition3
#### U
 
##### ::Undergraduate
::A type of [student](#student). *TODO: add more detail.*

88
Installation-Guide.md Normal file
View File

@ -0,0 +1,88 @@
*TODO: Fill in information about this product. Make sure to use the
**product** name and **external** release number, not internal
information.*
##### Product:
::PRODUCT-NAME
##### Release Number:
::X.Y.Z
##### Release Date:
::YEAR/MONTH/DAY
##### Customer Support:
:: For more information or support, please visit our
[website](http://www.COMPANY.com/products/PRODUCTNAME/) or
email us at <support@COMPANY.com>
---
### Introduction
::This document describes how to install and get started with
PRODUCT-NAME.
### Minimal System Requirements
::System requirements are described in the [release notes](Release-Notes).
### Installation
*TODO: Give detailed installation instructions. Make sure to test these
instructions by doing them yourself on a target machine.*
*TIP: For development releases, or products that are reusable components
rather than end-user applications, you should include information on
needed development and bugging tools, e.g., Ant and JUnit.*
#### What other software must be installed first?
::Before you can install this product, you must install the following
packages:
- ::[Java SDK](http://java.sun.com/)
- ::[Apache Tomcat](http://jakarta.apache.org/)
- ::[MySQL database](http://mysql.com/)
- ::[OTHER PACKAGES](http://)
#### How do I install PRODUCT-NAME?
:: Please follow these steps
1. ::STEP
2. ::STEP
- ::SUB-STEP
3. ::STEP
4. ::STEP
#### How can I uninstall PRODUCT-NAME?
1. ::STEP
2. ::STEP
- ::SUB-STEP
3. ::STEP
4. ::STEP
#### What if I encounter problems?
::Please see the troubleshooting section in the [FAQ](FAQ).
### Getting Started
*TODO: Briefly describe how the user would accomplish one or two of the
main use cases for new users. For development releases or reusable
components, include instructions on running unit tests.*
#### How can I run post-install unit tests?
1. :Compile the source code by typing "ant"
2. :Run unit tests by typing "ant test"
- ::A brief report will be shown on the console
- ::A detailed test report for any failed tests will be
in build/testout.
#### ::How can I quickly get started using PRODUCT-NAME?
1. ::STEP
2. ::STEP
- ::SUB-STEP
3. ::STEP
4. ::STEP

152
Status-Report.md Normal file
View File

@ -0,0 +1,152 @@
*TODO: Copy this file for each status report. Fill in the information
below. Email a notification to stakeholders when this report is made
available.*
*TODO: Edit the rows in the following table. In some rows, multiple
examples are given, you should select/edit only one.*
##### Project:
::[PROJECTNAME](Home)
##### Status Report Date:
::YEAR/MONTH/DAY
##### Next Internal Release Number:
::X.Y.Z
##### Release Date:
- ::Original estimate: YEAR/MONTH/DAY
- ::Current estimate: YEAR/MONTH/DAY
- ::Change Since Last Report: No change
- ::Change Since Last Report: Slipped 2 days
- ::Change Since Last Report: Saved 4 days
##### Open Issues (needing development):
- ::[17 defects](ISSUE-TRACKER-QUERY)
- ::[8 enhancements]()
##### Resolved Issues (pending verification):
- ::[0 defects]()
- ::[2 enhancements]()
##### Closed Issues:
- ::[34 defects]()
- ::[3 enhancements]()
##### Resources used this period:
- ::PERSONNAME: 18 hours.
- ::PERSONNAME: 15 hours.
- ::PERSONNAME: 10 hours.
- ::PERSONNAME: 12 hours.
##### Status Summary:
- ::Project completed. This is the final status report.
- ::Low risk. Project on track.
- ::Medium risk. Problems are being dealt with.
- ::High risk. Advice from management and stakeholders needed.
- ::Project canceled. This is the final status report.
##### Related Documents:
- [Project plan](Project-Plan) &gt; [Resource needs](Resource-Needs)
- [QA plan](QA-Plan)
- [Glossary](Glossary)
---
**Process impact:** This helps keep stakeholders informed of project
status so that they may correctly set expectations. Reasoned
explanations of slight changes in schedule are much better than major
unexplained slips.
### Detailed Status
TODO: Provide 1-4 paragraphs describing what has happened on this
project. The text below is just an example, replace it with your own
words.
::This week we focused on...
::Two major problems have been uncovered...
::We are approximately 30% of the way through the project plan, and
running about 2 days ahead of schedule...
::The reason for the change in estimated release date is...
::To stay on schedule, we have slipped enhancements [issue92](ISSUE-TRACKER-URL),
[issue 101](ISSUE-TRACKER-URL), and [issue 129](ISSUE-TRACKER-URL) to a later
release. These issues were selected because ...
### Risk Management
*TODO: List 3-10 of the top project risks that are still outstanding.
This list may be an **updated** copy from [project plan](Project-Plan.html#Risk-Management)
or a previous status report.*
- ::We could face major difficulties with the technology chosen for
this project. HOW TO AVOID/MITIGATE?
- ::We could have low quality that demands significant rework. HOW TO
AVOID/MITIGATE?
- ::We could incorrectly assess our progress until it is too late
to react. HOW TO AVOID/MITIGATE?
- ::There may be a mis-alignment of stakeholder goals or expectations.
HOW TO AVOID/MITIGATE?
### Upcoming Activity
*TODO: Provide a few bullets describing what you will do between now and
the next status report. The text below is just an example, replace it
with your own words. Link to open issues in the issue tracker whenever
possible.*
- ::Fix [issue 130](ISSUE-TRACKER-URL)
- ::Fix [issue 133](ISSUE-TRACKER-URL)
- ::Verify [issue 102](ISSUE-TRACKER-URL), [issue 103](ISSUE-TRACKER-URL),
[issue 107](ISSUE-TRACKER-URL), and [issue 109](ISSUE-TRACKER-URL)
- ::Conduct regular team meeting: Tuesday, 1 hour
- ::Conduct review meeting: Wednesday, 2 hours
- ::Make major progress on COMPONENT
- ::Work through next release checklist
- ::Continue functional testing
- ::Revise our integration procedure
- ::Release version X.Y.Z
### Tracking to Plan
*TODO: Copy the Work Breakdown Structure from the [project plan](Project-Plan) and paste it here.
Add a new column for actual effort spent so far by all team members.*
| Step | Description | Planned Hours | Spent To-Date |
|------------|----------------------------------------------------------------------|---------------|---------------|
| ::1. | ::Preparation | | |
| ::1.1. | ::Developer training | ::30h | ::0h |
| ::2. | ::Inception | | |
| ::2.1. | ::Requirements gathering | ::30h | ::0h |
| ::2.2. | ::Requirements specification | ::20h | ::0h |
| ::2.3. | ::Requirements validation | ::10h | ::0h |
| ::3. | ::Elaboration | | |
| ::3.1. | ::High-level design | ::5h |::0h |
| ::3.2. | ::Low-level design (break down by component) | | |
| ::3.2.A. | ::Object design | ::10h | ::0h |
| ::3.2.B. | ::User interface design | ::10h | ::0h |
| ::3.2.C. | ::Database design | ::3h | ::0h |
| ::3.3. | ::Design review and evaluation | ::5h | ::0h |
| ::4. | ::Construction | | |
| ::4.1.A. | ::System implementation | | |
| ::4.1.A.1. | ::Implement Component 1 | ::25h | ::0h |
| ::4.1.A.2. | ::Implement Component 2 | ::25h | ::0h |
| ::4.1.A.3. | ::Implement Component 3 | ::25h | ::0h |
| ::4.1.A.4. | ::Implement Component 4 | ::25h | ::0h |
| ::4.1.A.5. | ::Integrate Components (mostly done during component implementation) | ::5h | ::0h |
| ::4.1.B. | ::Technical documentation (break down by component) | ::10h | ::0h |
| ::4.1.C. | ::User documentation (break down by component) | ::10h | ::0h |
| ::4.1.D. | ::Testing | | |
| ::4.1.D.1. | ::Test planning | ::10h | ::0h |
| ::4.1.D.2. | ::Test code implementation (break down by component) | ::30h | ::0h |
| ::4.1.D.3. | ::Test execution | ::10h | ::0h |
| ::4.2. | ::Implementation review and evaluation | ::15h | ::0h |
| ::5. | ::Transition | | |
| ::5.A. | ::Release packaging | ::3h | ::0h |
| 5.B. | ::Documentation for other groups | ::3h | ::0h |
| ::6. | ::Reflection | | |
| ::6.1. | ::Postmortem report | ::10h | ::0h |
| | Total | ::329 hours | |