| Expand | ||
|---|---|---|
| ||
The first Dependencies Table provides information on features dependencies, lists expected Pull Request (PR) date (expected time this feature will be ready for integration), it also lists all the other known new code features that are blocking completion of this code. It lists all known features that depend on this feature being integrated. It also provides the date the PR was actually issued, the name of the integrator, the date the code was integrated and a hash/tag of the code integration into the ACME git repository. The information from this table feeds the overview table in the New Features Dependencies Overview page which is meant to be used by integrators to check the priority order in which the features should be integrated. It also provides an overview of all the new features and the expected integration dates. The second Checklist Table lists the code review steps to be taken in order. As you work on integrating your feature into ACME code, step along the Checklist table on your main page, obtain the approvals before going to the next step. For the phase 1 review, the Group Leads are the approvers, they can decide to sign on on the documentation or a verification step even if it is not completely finished, especially for the grandfathered features. The relevant documentation page does have to be created though and the explanation needs to be provided in Summary section as to why it is approved, what is the basis for approval. For example is there were tests performed on related feature and they proved indirectly that this feature works as expected, then the approver needs to document that. The Design Document page provides a description of the algorithms, implementation and planned testing including unit, verification, validation and performance testing. |
...
Design Document
...
The Verification and Unit Testing page provides the short information and links to the tests that were performed, together with the links to the runs, their provenance and their results. The same information is called for in The Performance Assessment page and The Validation page in phase 1 of code review process. |
Validation Testing: short-desciption-of-testing-here
Date last modified:
Contributors: (add your name to this list if it does not appear)
How will XXX be tested? What observational or other dataset will be used? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?
Planned Performance Testing
Performance Testing: short-desciption-of-testing-here
Date last modified:
Contributors: (add your name to this list if it does not appear)
How will XXX be tested? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?
...
| Page Properties | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
| Info |
| |||||||||||||||||||||||
Dependencies Table for this feature
|
| Expand | |||
|---|---|---|---|
| |||
|
Title: Some descriptive title
Requirements and Design
ACME Group
Date:
Summary
...
Requirements
Requirement: name-of-requirement-here
Date last modified:
Contributors: (add your name to this list if it does not appear)
...
Algorithmic Formulations
Design solution: short-description-of-proposed-solution-here
Date last modified:
Contributors: (add your name to this list if it does not appear)
For each requirement, there is a design solution that is intended to meet that requirement. Design solutions can include detailed technical discussions of PDEs, algorithms, solvers and similar, as well as technical discussion of performance issues. In general, this section should steer away from a detailed discussion of low-level software issues such as variable declarations, interfaces and sequencing.
Design and Implementation
Implementation: short-desciption-of-implementation-here
Date last modified:
Contributors: (add your name to this list if it does not appear)
This section should detail the plan for implementing the design solution for requirement XXX. In general, this section is software-centric with a focus on software implementation. Pseudo code is appropriate in this section. Links to actual source code are appropriate. Project management items, such as svn branches, timelines and staffing are also appropriate. How do we typeset pseudo code?
Planned Verification and Unit Testing
Verification and Unit Testing: short-desciption-of-testing-here
Date last modified:
Contributors: (add your name to this list if it does not appear)
How will XXX be tested? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?
Planned Validation Testing
|
| HTML Comment |
|---|
Labels to choose from for the 'Done ?' and 'Approved ?' columns
|
Checklist for the Code Review Process for this feature
| Action Required | Assignee - Task Owner | Link | Done ? | Done Date | Approved? | Approver | Approved Date | Notes |
|---|---|---|---|---|---|---|---|---|
| Phase 1 - Component Level Development and Testing | ||||||||
| Design Document | A3 CLUBB MG2 Design Document |
|
| |||||
| Verification and Unit Tests | A2 CLUBB MG2 Verification Phase 1 | | | |||||
| Performance Assessment | A3 CLUBB MG2 Performance Phase 1 | | | |||||
| Validation Tests | A3 CLUBB MG2 Validation Phase 1 | | | |||||
| Issue Pull Request | 59865f26a59c97d7953c67f82ff4eb9e2f7b0e41 | | 02 Oct 2015 | | ||||
| PR Integrator | - | 27 Oct 2015 | - | - | - | - | ||
| Phase 2 - Coupled System Integration and Testing | ||||||||
| Phase 2 Process Doc | | | ||||||
| Feature's Coupled Performance | | | ||||||
| Feature's Coupled Validation | | | ||||||
| Final Approval to part of ACME model | | - | - | - | - | |||