GFM changes
This commit is contained in:
parent
f1aa208ee4
commit
e6c1356aa0
107
Glossary.md
Normal file
107
Glossary.md
Normal 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
88
Installation-Guide.md
Normal 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
152
Status-Report.md
Normal 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) > [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 | |
|
Loading…
Reference in New Issue
Block a user