From c504fc26dad8d4cdda0189d31b0ffffd2a18d1aa Mon Sep 17 00:00:00 2001 From: William Sandner Date: Fri, 24 Mar 2023 17:29:16 +0100 Subject: [PATCH 1/5] Fix markdown lint errors --- .vscode/settings.json | 7 +- Demo-Script.md | 2 +- Design-Architecture.md | 14 ++-- Design-Components.md | 10 +-- Design-Persistence.md | 9 ++- Design-Scalability.md | 27 +++---- Design-Security.md | 5 +- Design-Src-Org.md | 29 +++---- Design-UI.md | 83 ++++++++++---------- Design.md | 18 ++--- Document-Cross-Ref.md | 31 ++++---- FAQ.md | 13 ++-- Feature-Format.md | 9 ++- Feature-Set.md | 15 ++-- Features.md | 26 +++---- Glossary-Standard-Terms.md | 31 ++++---- Glossary.md | 45 +++++------ Home.md | 34 +++++---- Implementation-Notes.md | 29 +++---- Installation-Guide.md | 19 ++--- Interview-Checklist.md | 3 +- Interview-Notes.md | 19 ++--- Legal.md | 15 ++-- License.md | 9 ++- Project-Plan.md | 123 +++++++++++++++--------------- Proposal.md | 17 +++-- QA-Plan.md | 71 ++++++++--------- Release-Checklist.md | 35 ++++----- Release-Notes.md | 37 ++++----- Resource-Needs.md | 151 +++++++++++++++++++------------------ Review-Meeting-Notes.md | 6 +- Risks.md | 29 +++---- SDM.md | 5 +- SRS.md | 15 ++-- Status-Report.md | 31 ++++---- Summary.md | 29 +++---- Target-and-Benefits.md | 21 +++--- Test-Case-Format.md | 9 ++- Test-Cases.md | 15 ++-- Test-Run-Suite.md | 43 +++++------ Test-Runs.md | 7 +- Test-Suite.md | 37 ++++----- Use-Case-Format.md | 12 +-- Use-Case-Suite.md | 25 +++--- Use-Cases.md | 38 +++++++--- User-Guide.md | 13 ++-- User-Needs.md | 51 +++++++------ Workflows.md | 3 +- _Footer.md | 2 +- _Sidebar.md | 12 +-- 50 files changed, 702 insertions(+), 637 deletions(-) diff --git a/.vscode/settings.json b/.vscode/settings.json index 36d5450..fe39e0e 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,5 +1,4 @@ { - "markdownlint.config": { - "MD026": { "punctuation": "?" } - } -} \ No newline at end of file + "markdownlint.config": {}, + "cSpell.words": ["JDBC"] +} diff --git a/Demo-Script.md b/Demo-Script.md index 6e94241..1fea1d9 100644 --- a/Demo-Script.md +++ b/Demo-Script.md @@ -1,4 +1,4 @@ - + ##### Project ::[PROJECT-NAME](Home) diff --git a/Design-Architecture.md b/Design-Architecture.md index 9f28330..0d0b3a0 100644 --- a/Design-Architecture.md +++ b/Design-Architecture.md @@ -1,4 +1,4 @@ - + ##### Project ::PROJECT-NAME(Home) @@ -17,8 +17,8 @@ --- -*TODO: Answer the questions below to help you define your system -architecture. Some example text is provided.* +_TODO: Answer the questions below to help you define your system +architecture. Some example text is provided._ ### Overview @@ -49,7 +49,7 @@ architecture. Some example text is provided.* #### What are the components of this system? ::The components of this system are clearly defined in this [UML Model - with Component Diagram](LINK-TO-MODEL). +with Component Diagram](LINK-TO-MODEL). ::The components of this system are listed below by type: @@ -152,11 +152,11 @@ and down-time. ### Architectural Scenarios -*TODO: Provide architecture scenarios that show how objects will +_TODO: Provide architecture scenarios that show how objects will communicate across components, processes, and machines. Focus on scenarios where the architecture itself is changing, e.g., system startup, shutdown, adding or upgrading components, load balancing or -fail-over.* +fail-over._ The following sequence diagrams give step-by-step descriptions of how components communicate during some important usage scenarios: @@ -167,7 +167,7 @@ components communicate during some important usage scenarios: ### Architecture Checklist -*TODO: Evaluate your architecture with respect to each of your goals.* +_TODO: Evaluate your architecture with respect to each of your goals._ #### Ease of integration: Have mechanisms been provided for all needed types of integration? diff --git a/Design-Components.md b/Design-Components.md index c27c4de..40931e0 100644 --- a/Design-Components.md +++ b/Design-Components.md @@ -1,4 +1,4 @@ - + ##### Project ::PROJECT-NAME @@ -15,11 +15,11 @@ --- -*TODO: Briefly describe each component in the system. Focus on +_TODO: Briefly describe each component in the system. Focus on architectural issues such as communication mechanisms, environmental concerns that affect deployment options, and concurrency. Note key aspects of each interface, but avoid duplicating details of interfaces -that are specified in the UML class diagrams or other documents.* +that are specified in the UML class diagrams or other documents._ Each interface can be an API (application program interface), standard protocol (e.g., HTTP), config files, input data file format, or @@ -28,8 +28,8 @@ may have multiple interfaces: e.g., a server may handle requests in a standard protocol, but also have a config file, command-line options, an administrative control panel GUI, and a performance monitoring API. -*TIP: Use an HTML anchor for each component so that a direct link can be -made from other documents, issues, and email messages.* +_TIP: Use an HTML anchor for each component so that a direct link can be +made from other documents, issues, and email messages._ --- diff --git a/Design-Persistence.md b/Design-Persistence.md index 08427e9..517d318 100644 --- a/Design-Persistence.md +++ b/Design-Persistence.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -17,8 +18,8 @@ ### Overview -*TODO: Answer the questions below to help you design needed persistence -features. Some example text is provided. Add or delete text as needed.* +_TODO: Answer the questions below to help you design needed persistence +features. Some example text is provided. Add or delete text as needed._ #### What are the most important facts that a developer should know about persistent data storage in this system? @@ -112,7 +113,7 @@ attachments are written to files on the server hard disk. ``` ::Users store files anywhere on their computer, with the filename -extension ```.TST```. +extension `.TST`. #### What file system access controls will be used? diff --git a/Design-Scalability.md b/Design-Scalability.md index 2952782..f811a9b 100644 --- a/Design-Scalability.md +++ b/Design-Scalability.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -17,28 +18,28 @@ ### Overview -*TODO: Briefly describe the approach to scalability. Rank your -scalability goals for this design.* +_TODO: Briefly describe the approach to scalability. Rank your +scalability goals for this design._ ::2-4 SENTENCES. ### Relevant parameters -| Parameter | Description | -|---------------------|-----------------------------------------------------------------------------------------| -| ::registered\_users | ::Number of registered users in the database. | -| ::concurrent\_users | ::Number of users logged into the system at a given time. | -| ::map\_size | ::Number of game squares in the playing area. E.g., a 10 x 25 map would be 250 squares. | -| ::game\_pieces | ::Number of game pieces on the playing area at a given time. | +| Parameter | Description | +| ------------------ | --------------------------------------------------------------------------------------- | +| ::registered_users | ::Number of registered users in the database. | +| ::concurrent_users | ::Number of users logged into the system at a given time. | +| ::map_size | ::Number of game squares in the playing area. E.g., a 10 x 25 map would be 250 squares. | +| ::game_pieces | ::Number of game pieces on the playing area at a given time. | ### Scalability Mechanisms ### Performance Goals and Estimates -| Action | Goal | Time Formula | Description | -|----------------|--------------|-------------------------------|-----------------------------------------------------------------------------| -| ::login | ::1 second | ::O(Log(registered\_users)) | ::Time that it takes to look up a user by their login name in the database. | -| ::display\_map | ::1/5 second | ::O(map\_size + game\_pieces) | ::Time that it takes to redraw the game map and all game pieces. | +| Action | Goal | Time Formula | Description | +| ------------- | ------------ | --------------------------- | --------------------------------------------------------------------------- | +| ::login | ::1 second | ::O(Log(registered_users)) | ::Time that it takes to look up a user by their login name in the database. | +| ::display_map | ::1/5 second | ::O(map_size + game_pieces) | ::Time that it takes to redraw the game map and all game pieces. | ### System Scalability Checklist diff --git a/Design-Security.md b/Design-Security.md index 14853f5..e0a8256 100644 --- a/Design-Security.md +++ b/Design-Security.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -17,7 +18,7 @@ ### Overview -*TODO: Answer the questions below to help you design needed security features. Some example text is provided. Add or delete text as needed.* +_TODO: Answer the questions below to help you design needed security features. Some example text is provided. Add or delete text as needed._ #### What are the most important facts that a developer should know about the security of this system? diff --git a/Design-Src-Org.md b/Design-Src-Org.md index 05016c0..1f8adc7 100644 --- a/Design-Src-Org.md +++ b/Design-Src-Org.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -19,10 +20,10 @@ ### Overview -*TODO: Answer the questions below to help you define your source code +_TODO: Answer the questions below to help you define your source code organization and build process. Some example text is provided. Add or delete text as needed. E.g., not all projects try to be platform -independent.* +independent._ #### What are the most important facts that a developer should know about this source code organization and build system? @@ -40,12 +41,12 @@ projects at the Apache Software Foundation. ### Key Directories and Files in Developer Working Copies -*TODO: Describe the purpose of each directory that will appear in a +_TODO: Describe the purpose of each directory that will appear in a developer's work copy, also include any files that are important to the -overall structure or build process.* +overall structure or build process._ | Path | VC | Description | -|--------------------------------------|-------|---------------------------------------------------------------------------------| +| ------------------------------------ | ----- | ------------------------------------------------------------------------------- | | ::build.xml | ::Yes | ::Build file | | ::build.properties | ::Yes | ::Build properties file | | ::src/ | ::Yes | ::Source code | @@ -68,11 +69,11 @@ overall structure or build process.* ### Build Targets -*TODO: Describe the build targets that developers will use in daily -development. The examples below should fit most projects.* +_TODO: Describe the build targets that developers will use in daily +development. The examples below should fit most projects._ | Target | Description | -|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ::compile = default | ::Compiles Java source code and creates .class files under the "build" directory. | | ::dist | ::Packages the system for distribution/deployment to servers or end users. Specifically, it creates .war archive of compiled classes and configuration files. | | ::install | ::Places executable code into location where it will actually be executed. Specifically, it copies .war file into Tomcat's webapps directory for use. You must then restart Tomcat or use the "reload" link in the Tomcat Manager. | @@ -81,11 +82,11 @@ development. The examples below should fit most projects.* ### Build Configuration Options -| Property | Description | -|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| ::app.name | ::The name of this application. This should be one short word. Used in the name of resulting package files. Specifically, the .war file. And, it will be used to access the application via | -| ::app.version | ::Version number of this release. Used in the name of resulting package files. Specifically, the .war file. | -| ::webapps.path | ::Path to the Tomcat "webapps" directory. Defaults to C:\Program Files\Apache Group\Tomcat 4.1\webapps\ | +| Property | Description | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ::app.name | ::The name of this application. This should be one short word. Used in the name of resulting package files. Specifically, the .war file. And, it will be used to access the application via | +| ::app.version | ::Version number of this release. Used in the name of resulting package files. Specifically, the .war file. | +| ::webapps.path | ::Path to the Tomcat "webapps" directory. Defaults to C:\Program Files\Apache Group\Tomcat 4.1\webapps\ | ::These build system properties can be modified by editing the build.properties file. diff --git a/Design-UI.md b/Design-UI.md index 3d3bf40..82263a6 100644 --- a/Design-UI.md +++ b/Design-UI.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -17,9 +18,9 @@ ### Overview -*TODO: Answer the questions below to help you design the user interface +_TODO: Answer the questions below to help you design the user interface features of your system. Some example text is provided. Add or delete -text as needed.* +text as needed._ #### What are the most important facts that a developer should know about the user interface of this system? @@ -65,60 +66,60 @@ text as needed.* ### Content Model / Interaction Contexts -*TODO: List interaction contexts. Each interaction context is a "place" +_TODO: List interaction contexts. Each interaction context is a "place" where users see information and where they select commands or options. In a graphical user interface, a interaction context will eventually be implemented as a window or dialog box. In other applications, an interaction context may be implemented as, e.g., a web page, a voice -menu prompt, or a physical control panel.* +menu prompt, or a physical control panel._ -*TIP: Each interaction context is an exclusive mode: the user can only +_TIP: Each interaction context is an exclusive mode: the user can only use one interaction context at a time. All the components within one context are visible and usable at the same time. E.g., if a window has three tabs, that is three interaction contexts because only one tab can -be used at a time.* +be used at a time._ -*TODO: For each interaction context, list the abstract components within +_TODO: For each interaction context, list the abstract components within that context. Each component is a piece of information, or a user interface affordance. In a GUI, each abstract component will eventually become a widget, but the choice of specific widgets happens later. Choice of abstract components corresponds to step 2 in the [HTML prototyping example](http://www.ics.uci.edu/~jrobbins/htmlproto/index.html) -demonstrated in class.* +demonstrated in class._ -*TIP: Most high frequency use cases should be carried out in only one +_TIP: Most high frequency use cases should be carried out in only one interaction contexts. A use case that requires three interaction contexts could be hard to use. However, interaction contexts with too -many components can also be hard to use.* +many components can also be hard to use._ -| Interaction Context --Abstract UI Components | Purpose | Contents / Constraints / Behavior | -|------------------------------------------------|------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| ::[Login dialog](LINK-TO-MOCKUP) | ::Verify that the current user is actually the person that they claim to be. | | -| ::--Prompt | ::Tell the user that this dialog is to log in. | ::"Please log in". | -| ::--Message area | ::Give the user some feedback about the login process. | ::Initially blank. Changes to "Checking username and password" when the user presses "Login". Changes to "Invalid username or password, please try again", if login fails. | -| ::--Username | ::Identify the user account that the current user is trying to access. | ::The name of the user account. Regex: [-_a-z0-9]{1-16}. The application should not do anything that would help users guess usernames. E.g., this should not be a combo-box with recent users listed, and it should not offer auto-complete. | -| ::--Password | ::Verify that the current user knows a secret password that only the true user of that user account should know. | ::The password of 4-16 characters. Do not display the password on the screen. The application should not do anything that would help users guess passwords. | -| ::--Login | ::Allow the user to indicate that they have completed entry of their username and password. | ::"Login" Only enabled when Username != "". If the username or password is incorrect, delay a few seconds, and then clear all fields. | -| ::--Lost Password | ::Allow the current user to start a process of generating a new password for a given username. | ::"Forgot your password? Click here." Only enabled when Username != "". | -| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::[MAIN-WINDOW-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | -| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| Interaction Context --Abstract UI Components | Purpose | Contents / Constraints / Behavior | +| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ::[Login dialog](LINK-TO-MOCKUP) | ::Verify that the current user is actually the person that they claim to be. | | +| ::--Prompt | ::Tell the user that this dialog is to log in. | ::"Please log in". | +| ::--Message area | ::Give the user some feedback about the login process. | ::Initially blank. Changes to "Checking username and password" when the user presses "Login". Changes to "Invalid username or password, please try again", if login fails. | +| ::--Username | ::Identify the user account that the current user is trying to access. | ::The name of the user account. Regex: [-_a-z0-9]{1-16}. The application should not do anything that would help users guess usernames. E.g., this should not be a combo-box with recent users listed, and it should not offer auto-complete. | +| ::--Password | ::Verify that the current user knows a secret password that only the true user of that user account should know. | ::The password of 4-16 characters. Do not display the password on the screen. The application should not do anything that would help users guess passwords. | +| ::--Login | ::Allow the user to indicate that they have completed entry of their username and password. | ::"Login" Only enabled when Username != "". If the username or password is incorrect, delay a few seconds, and then clear all fields. | +| ::--Lost Password | ::Allow the current user to start a process of generating a new password for a given username. | ::"Forgot your password? Click here." Only enabled when Username != "". | +| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::[MAIN-WINDOW-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | +| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS | ### Technical Constraints / Operational Context @@ -156,8 +157,8 @@ four menu buttons along the right-hand edge of the screen. ### User Interface Checklist -*TODO: Answer the following questions to help evaluate the design. You -may add or remove questions to fit your project.* +_TODO: Answer the following questions to help evaluate the design. You +may add or remove questions to fit your project._ #### Understandability and learnability diff --git a/Design.md b/Design.md index 2465f5f..f697eac 100644 --- a/Design.md +++ b/Design.md @@ -1,5 +1,5 @@ + - ##### Project ::[PROJECT-NAME](Home) @@ -31,7 +31,7 @@ This design document describes a system that will satisfy the requirements of the [SRS](SRS). Decisions made in creating this design document are based on those requirements and an understanding of available technologies and components. Once the design has been drafted, work on the system implementation and unit testing may begin. -*TODO: Fill in the sections below. Add ore remove items as needed for your project.* +_TODO: Fill in the sections below. Add ore remove items as needed for your project._ ### Introduction @@ -59,8 +59,8 @@ interface and database design. ### UML Structural Design -*TODO: Link to a design model and/or design diagrams that describe your -system's structure in detail.* +_TODO: Link to a design model and/or design diagrams that describe your +system's structure in detail._ #### The system's structural design is described in the following UML model @@ -81,8 +81,8 @@ system's structure in detail.* ### UML Behavioral Design -*TODO: Link to a design model and/or design diagrams that describe your -system's behavior in detail.* +_TODO: Link to a design model and/or design diagrams that describe your +system's behavior in detail._ #### The system's behavioral design is described in the following UML model @@ -107,10 +107,10 @@ system's behavior in detail.* ### UML Design Checklist -*TODO: Answer the following questions to help evaluate your design. Add +_TODO: Answer the following questions to help evaluate your design. Add or remove questions to fit your project. If you cannot answer a question positively, that may indicate an aspect of the design that should be -revised.* +revised._ #### Correctness: How do you know that this design is correct? @@ -148,4 +148,4 @@ revised.* - ::Yes, everyone understands. Feedback is welcome. - ::No, this is a risk that is noted in the - [Risk Management](Project-Plan#Risk-Management) section. + [Risk Management](Project-Plan#Risk-Management) section. diff --git a/Document-Cross-Ref.md b/Document-Cross-Ref.md index 2b15bc3..e655439 100644 --- a/Document-Cross-Ref.md +++ b/Document-Cross-Ref.md @@ -1,21 +1,22 @@ - -*TODO: This template is not done yet. Feel free to contribute your ideas.* + + +_TODO: This template is not done yet. Feel free to contribute your ideas._ This document defines the artifacts the team creates during your software -development process. Documenting artifact types helps define the inputs and -outputs of each development task. The producer/consumer matrix helps document +development process. Documenting artifact types helps define the inputs and +outputs of each development task. The producer/consumer matrix helps document the software development workflow. ### Artifact Producer / Consumer Matrix -| Read By \ Written By | Everyone | Project Manager | Product Manager | Dev Team | QA Team | Tech Writer | Tech Support | Operations | Sales | -|----------------------|----------------------------------------------------|--------------------------------------------------------------------------|------------------------------------------------------|------------------------------------------------------------------------------------------|--------------------------------------------------------------|---------------------------------------------------------------|----------------|-------------------------|----------------------------| -| Everyone | [Release-Checklist](Release-Checklist), [SDM](SDM) | [Overview](Overview), [Proposal](Proposal), [Plan](Plan), [Risks](Risks) | [SRS](SRS) | Mockups, Prototyes, Working-product | | [User-Guide](User-Guide), [Release-Notes](Release-Notes) | | | | -| Project Manager | [Status-Report](Status-Report) | [Resource-Needs](Resource-Needs) | | [Review-Report](Review-Report) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | Support-issues | | Customer-feedback | -| Product Manager | | | [User-Needs](User-Needs) | | | | Support-issues | | Customer-feedback | -| Dev Team | | Task-assignments | | [Design](Design) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | | | | -| QA Team | | Task-assignments | | [Design](Design), [Status-Report](Status-Report) | [QA-Plan](QA-Plan), [Test-Suite](Test-Suite), Defect-reports | [FAQ](FAQ), [Install](Install) | Support-issues | | | -| Tech Writer | | Task-assignments | [User-Needs](User-Needs) | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback | -| Tech Support | | | | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback | -| Operations | | | [User-Needs](User-Needs) | [Design-Architecture](Design-Architecture), [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | | -| Sales | | | [User-Needs](User-Needs), [Demo-Script](Demo-Script) | [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | [Demo-Script](Demo-Script) | +| Read By \ Written By | Everyone | Project Manager | Product Manager | Dev Team | QA Team | Tech Writer | Tech Support | Operations | Sales | +| -------------------- | -------------------------------------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------- | -------------- | ---------- | -------------------------- | +| Everyone | [Release-Checklist](Release-Checklist), [SDM](SDM) | [Overview](Overview), [Proposal](Proposal), [Plan](Plan), [Risks](Risks) | [SRS](SRS) | Mockups, Prototyes, Working-product | | [User-Guide](User-Guide), [Release-Notes](Release-Notes) | | | | +| Project Manager | [Status-Report](Status-Report) | [Resource-Needs](Resource-Needs) | | [Review-Report](Review-Report) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | Support-issues | | Customer-feedback | +| Product Manager | | | [User-Needs](User-Needs) | | | | Support-issues | | Customer-feedback | +| Dev Team | | Task-assignments | | [Design](Design) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | | | | +| QA Team | | Task-assignments | | [Design](Design), [Status-Report](Status-Report) | [QA-Plan](QA-Plan), [Test-Suite](Test-Suite), Defect-reports | [FAQ](FAQ), [Install](Install) | Support-issues | | | +| Tech Writer | | Task-assignments | [User-Needs](User-Needs) | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback | +| Tech Support | | | | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback | +| Operations | | | [User-Needs](User-Needs) | [Design-Architecture](Design-Architecture), [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | | +| Sales | | | [User-Needs](User-Needs), [Demo-Script](Demo-Script) | [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | [Demo-Script](Demo-Script) | diff --git a/FAQ.md b/FAQ.md index bdd2909..b4bea42 100644 --- a/FAQ.md +++ b/FAQ.md @@ -1,11 +1,12 @@ - -*TODO: Answer these common questions. Some sample answers are provided -for you. Add new questions and new sections to fit the needs of your -users.* + -*TIP: This FAQ is for end users, you may want to write FAQ's for other +_TODO: Answer these common questions. Some sample answers are provided +for you. Add new questions and new sections to fit the needs of your +users._ + +_TIP: This FAQ is for end users, you may want to write FAQ's for other types of stakeholders such as potential customers, open source -contributors, members of a developers' network, or administrators.* +contributors, members of a developers' network, or administrators._ ### General Information diff --git a/Feature-Format.md b/Feature-Format.md index 6117946..e9dc241 100644 --- a/Feature-Format.md +++ b/Feature-Format.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -19,8 +20,8 @@ feature specification template into your [Features](Features) document. This file itself should not be edited to hold specific features. -*TODO: Copy and paste this feature specification template as many times -as needed in your [Features](Features) document.* +_TODO: Copy and paste this feature specification template as many times +as needed in your [Features](Features) document._ --- @@ -42,7 +43,7 @@ Description: Precise Details: -- ::LOGICAL CONSTRAINT +- ::LOGICAL CONSTRAINT - ::LOGICAL CONSTRAINT Notes and Questions: diff --git a/Feature-Set.md b/Feature-Set.md index 1325cd9..87837cf 100644 --- a/Feature-Set.md +++ b/Feature-Set.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -25,24 +26,24 @@ feature set by priority, functional area, actor, business object, or release can help identify missing, extra, or poorly motivated features early. -*TODO: Before writing individual feature descriptions, list all the +_TODO: Before writing individual feature descriptions, list all the features that you think you will need. Organize them so that missing features appear as blanks on this page, and extra features will appear to be extras that don't fit anywhere. See the [feature format](Feature-Format#further-information) document for more -tips on specifying features and feature sets.* +tips on specifying features and feature sets._ -*TIP: Refer back to the user stories in your [user needs](User-Needs) +_TIP: Refer back to the user stories in your [user needs](User-Needs) document and to the [use case suite](Use-Case-Suite). -Use them for ideas and make sure that you cover all of them.* +Use them for ideas and make sure that you cover all of them._ ### Features by Release and Priority -*TODO: Select subset of features can be implemented for a given release. +_TODO: Select subset of features can be implemented for a given release. When features are listed in priority order, choosing the features to implement in a release simply becomes a matter of "drawing a line": features below the line must wait for a later release. Make sure to also -consider estimated effort and risk.* +consider estimated effort and risk._ - ::Release 1.0 - ::Essential diff --git a/Features.md b/Features.md index a3c3f11..8c0f835 100644 --- a/Features.md +++ b/Features.md @@ -1,4 +1,4 @@ - + ##### Project ::PROJECT-NAME @@ -20,23 +20,23 @@ **Process impact:** This is a set of detailed feature descriptions. -*TODO: For each feature listed in the [feature set](Feature-Set), +_TODO: For each feature listed in the [feature set](Feature-Set), give a detailed description of the feature here. Describe each feature in enough detail that it could be implemented by any member of the development team (not only someone who already informally knows what to -do).* +do)._ -*TIP: Start with a short textual description of each feature. Then, add +_TIP: Start with a short textual description of each feature. Then, add more formal information as needed to make each description precise and -unambiguous. E.g.,* +unambiguous. E.g.,_ -- *Precisely define valid inputs, and error handling* -- *Specify data structures with UML or logical schema* -- *Specify UI aspects of features with tiny mock-ups* -- *Specify key decisions with decision trees or tables* -- *Specify key algorithms with pseudo-code or flow charts* -- *Specify state-based behavior with state machines or tables* -- *Specify sequences of events with scenario diagrams* +- _Precisely define valid inputs, and error handling_ +- _Specify data structures with UML or logical schema_ +- _Specify UI aspects of features with tiny mock-ups_ +- _Specify key decisions with decision trees or tables_ +- _Specify key algorithms with pseudo-code or flow charts_ +- _Specify state-based behavior with state machines or tables_ +- _Specify sequences of events with scenario diagrams_ --- @@ -116,7 +116,7 @@ Functional area(s): ::WORD, WORD, WORD Use case(s): ::[UC-01](Use-Cases#UC-01) Description: -:: 1-4 PARAGRAPHS. USE BULLETS OR TABLES TO ORGANIZE INFORMATION. LINK TO WORKSHEETS OR ADDITIONAL INFORMATION. +:: 1-4 PARAGRAPHS. USE BULLETS OR TABLES TO ORGANIZE INFORMATION. LINK TO WORKSHEETS OR ADDITIONAL INFORMATION. Precise Details: diff --git a/Glossary-Standard-Terms.md b/Glossary-Standard-Terms.md index 6e43e9b..403ccc5 100644 --- a/Glossary-Standard-Terms.md +++ b/Glossary-Standard-Terms.md @@ -1,4 +1,4 @@ - + **Process impact:** This file as a dictionary of standard terms defined as they are used across projects. Individual projects should not need to edit this file. Writing out the definitions of terms and acronyms here @@ -6,11 +6,12 @@ helps keep other documents more concise and easy to edit. Check the [ReadySET glossary](http://readyset.tigris.org/templates/glossary-std.html) for updates. + Jump to: [General](#general-terms) | [Computer science & technology](#computer-science-and-technology-terms) | [Process](#process-terms) | [Software development tools](#development-tool-terms) | [Requirements](#requirements-terms) | [Design](#design-terms) | [Design goals terms](#desigD-DIAGRAMn-goals-terms) | [QA terms](#qa-terms) | [QA goals terms](#qa-goals-terms) | [Additional terms](#additional-standard-terms)| [Project terms](Glossary) ### General Terms -##### Chipping away +#### Chipping away The process of removing sample text from templates when that text does not apply to the current project. Often some of the sample text @@ -82,9 +83,9 @@ communications such as [SOAP](#soap) messages. ##### ::SOAP -SOAP (Simple Object Access Protocol) is the message format used by -standard web services. It entails sending an XML document to a -server in order to invoke an operation on the server-side. +SOAP (Simple Object Access Protocol) is the message format used by +standard web services. It entails sending an XML document to a +server in order to invoke an operation on the server-side. [More information on SOAP](http://directory.google.com/Top/Computers/Programming/Internet/Web_Services/SOAP/?tc=1). ### Process Terms @@ -138,7 +139,7 @@ than "10.1" or "11". ##### Release Number -The term "release number" by itself refers to an +The term "release number" by itself refers to an [external release number](#external_release_number). Users normally are not aware of the existence of any internal release numbers. @@ -191,7 +192,7 @@ many different ways as part of many different use cases. The main part of a use case is a set of steps that give an example of how an [actor](#actor) can use the product to succeed at -a goal. These steps are called the "Main success scenario", and they +a goal. These steps are called the "Main success scenario", and they include both user intentions and system responses. One use case may show how the actor uses several features to accomplish a goal. @@ -225,7 +226,7 @@ Developers can understand this design and correctly implement it. This design divides the implementation into components or aspects that can correspond to reasonable implementation tasks. -#### Modularity +#### Modularity Concerns are clearly separated so that the impact of most design changes would be limited to only one or a few modules. @@ -323,18 +324,18 @@ this system. #### Bug -*n.* **Deprecated** since 1991. See [defect](#defect). +_n._ **Deprecated** since 1991. See [defect](#defect). #### Error -*v.* A mistaken thought in the developer's mind. Often caused by +_v._ A mistaken thought in the developer's mind. Often caused by miscommunication or bad assumptions. Errors can create [defects](#defect). E.g., a developer might erroneously think that the square root of -4 is -2. #### Defect -*n.* The result of the developer's [error](#error) embodied in the +_n._ The result of the developer's [error](#error) embodied in the product source code, initial data, or documents. E.g., a square root function which allows negative numbers as arguments is defective. Defects can be removed by changing the source code, initial data, @@ -342,7 +343,7 @@ or document. #### Fault -*n.* The execution of defective code. E.g., if a certain input is +_n._ The execution of defective code. E.g., if a certain input is provided to defective code, it may cause an exception, or go into an infinite loop, or store an incorrect value in an internal variable. A fault is not normally visible to users, only the @@ -350,7 +351,7 @@ A fault is not normally visible to users, only the #### Failure -*n.* The user-visible result of a [fault](#fault). E.g., an error +_n._ The user-visible result of a [fault](#fault). E.g., an error message or an incorrect result. This is evidence that can be reported in a defect report. Developers use failure evidence during debugging to eventually find and remove [defects](#defect). @@ -391,6 +392,7 @@ D-DIAGRAM D-DIAGRAM D-DIAGRAM D-DIAGRAM + #### Usability > Understandability and Readability Users need to understand the system to use it. The basic metaphor @@ -447,6 +449,7 @@ D-DIAGRAM in his/her task. #### Usability > Subjective satisfactionD-DIAGRAM + D-DIAGRAM D-DIAGRAM D-DIAGRAM @@ -464,10 +467,12 @@ input should be validated and any malicious input should be rejected. #### Reliability > Consistency under load + D-DIAGRAM D-DIAGRAM D-DIAGRAM D-DIAGRAM + #### Reliability > Consistency under concurrency Systems that allow concurrent access by multiple users, or that use diff --git a/Glossary.md b/Glossary.md index e94b7ae..db480e5 100644 --- a/Glossary.md +++ b/Glossary.md @@ -1,4 +1,5 @@ - + + **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 @@ -13,25 +14,25 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) | ### Project-specific Terms -*TIPs:* +_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. +- _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, + 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 + [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. + 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).* + [GPA](#gpa)._ #### A @@ -47,7 +48,7 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) | - ::Real-world meaning of values: | | | -|-------------|---------------------------------| +| ----------- | ------------------------------- | | ::Freshman | ::Less than 90 units | | ::Sophomore | ::Between 90 and 180 units | | ::Junior | ::Between 180 and 270 units | @@ -59,12 +60,12 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) | ##### ::GEF -::*n.* The [Graph Editing Framework](http://gef.tigris.org/). An open +::_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, +::_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 @@ -74,22 +75,22 @@ academic probation. ##### ::ICS -::*n.* Acronym for the [School of Information and Computer +::_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. +::_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 +::_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 +Years_at_school does not determine senior standing. TODO: how many credits needed? #### T @@ -111,4 +112,4 @@ credits needed? ##### ::Undergraduate -::A type of [student](#student). *TODO: add more detail.* +::A type of [student](#student). _TODO: add more detail._ diff --git a/Home.md b/Home.md index bae5110..0f6eb21 100644 --- a/Home.md +++ b/Home.md @@ -1,10 +1,12 @@ - + + ## Project Overview ### Mission and Scope - -*TODO: Answer these questions in your own words by filling in each* + + +_TODO: Answer these questions in your own words by filling in each_ #### What problem does this project address? @@ -28,9 +30,9 @@ ### Status -*TODO: Briefly describe the status of this project. E.g., what phase are +_TODO: Briefly describe the status of this project. E.g., what phase are you in? And, what is your next major milestone? Detailed project status -is written in the status reports, not here.* +is written in the status reports, not here._ ::We have completed our second beta release and are currently working on adding more of the functionality described in our product @@ -41,8 +43,8 @@ functionality and a wider set of testers. ### Project Documents -|By Activity |Documents | -|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| By Activity | Documents | +| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Inception: | [Home](Home), [Project Proposal](Proposal), [Target Audience and Benefits](Target-and-Benefits), [Statement of User Needs](User-Needs) | | Reference: | [Glossary](Glossary), [Software Development Methodology](SDM), [Document Cross Reference](Document-Cross-Ref), [All-in-one project summary](Summary) | | Elaboration: | [Project Plan](Project-Plan), [Software Requirements Specification](SRS), [Feature Set](Feature-Set), [Use Case Suite](Use-Case-Suite), [Design](Design), [QA Plan](QA-Plan), [Test Suite](Test-Suite) | @@ -50,12 +52,12 @@ functionality and a wider set of testers. | Transition: | [Install / Quick Start](Installation-Guide), [Demo Script](Demo-Script), [Release notes](Release-Notes), [Release checklist](Release-Checklist), [Post Mortem](Post-Mortem) | | Continuous: | [Status Report](Status-Report) | -|By Audience |Documents | -|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| For Everyone: | [Home](Home), [Project Proposal](Proposal), [Target Audience and Benefits](Target-and-Benefits), [Statement of User Needs](User-Needs), [Software Requirements Specification](SRS), [Project Plan](Project-plan), [Release Checklist](Release-Checklist), [Glossary](Glossary) | -| For Management: | [Project Resource Needs](Resource-Needs), [Status Report](Status-Report) | -| For Developers: | [Design](Design), [Review Meeting Notes](Review-Meeting-Notes), [Software Development Methodology](SDM) | -| For QA: | [QA Plan](QA-Plan) | -| For End Users: | [Install / Quick start](Installation-Guide), [User Guide](User-Guide), [Release Notes](Release-Notes) | -| For Support and Ops:| [Implementation Notes](Implementation-Notes), [FAQ / Troubleshooting Guide](FAQ) | -| For Sales/Legal: | [Demo Script](Demo-Script), [Legal Issues](Legal) | +| By Audience | Documents | +| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| For Everyone: | [Home](Home), [Project Proposal](Proposal), [Target Audience and Benefits](Target-and-Benefits), [Statement of User Needs](User-Needs), [Software Requirements Specification](SRS), [Project Plan](Project-plan), [Release Checklist](Release-Checklist), [Glossary](Glossary) | +| For Management: | [Project Resource Needs](Resource-Needs), [Status Report](Status-Report) | +| For Developers: | [Design](Design), [Review Meeting Notes](Review-Meeting-Notes), [Software Development Methodology](SDM) | +| For QA: | [QA Plan](QA-Plan) | +| For End Users: | [Install / Quick start](Installation-Guide), [User Guide](User-Guide), [Release Notes](Release-Notes) | +| For Support and Ops: | [Implementation Notes](Implementation-Notes), [FAQ / Troubleshooting Guide](FAQ) | +| For Sales/Legal: | [Demo Script](Demo-Script), [Legal Issues](Legal) | diff --git a/Implementation-Notes.md b/Implementation-Notes.md index eff4d80..156bf8c 100644 --- a/Implementation-Notes.md +++ b/Implementation-Notes.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -30,9 +31,9 @@ guide". ### Type of Implementation -*TODO: Fill in information that will help other engineers understand this +_TODO: Fill in information that will help other engineers understand this system at-a-glance. Feel free to use relevant technical terms and name -specific technology platforms.* +specific technology platforms._ #### Type of system @@ -75,8 +76,8 @@ specific technology platforms.* ### Runtime Environment -*TODO: List and describe runtime objects that make up a running system. -These objects may be referred to by name in the sections below.* +_TODO: List and describe runtime objects that make up a running system. +These objects may be referred to by name in the sections below._ #### Processes @@ -99,7 +100,7 @@ These objects may be referred to by name in the sections below.* #### Data Files -- ::*.ext: Data files saved by the user on their local hard disk. +- ::\*.ext: Data files saved by the user on their local hard disk. - ::/var/PRODUCT-NAME/upload-XXXX.dat: Files uploaded to the server. #### Temporary Files @@ -115,11 +116,11 @@ These objects may be referred to by name in the sections below.* ### Implementation of Specific Features -*TODO: Write short descriptions of interesting or unexpected algorithms, +_TODO: Write short descriptions of interesting or unexpected algorithms, limiting assumptions, or any other implementation detail that will impact the work of other groups. E.g., long-running operations that must not be interrupted. E.g., start up or shutdown scripts that are -automatically run by the operating system.* +automatically run by the operating system._ - ::Feature name: 1-3 SENTENCE DESCRIPTION - ::Feature name: 1-3 SENTENCE DESCRIPTION @@ -134,8 +135,8 @@ automatically run by the operating system.* ### Operational Procedures -*TODO: Briefly describe procedures that should be followed by operations -engineers when the system is being run in an ASP production environment.* +_TODO: Briefly describe procedures that should be followed by operations +engineers when the system is being run in an ASP production environment._ #### Install @@ -173,8 +174,8 @@ engineers when the system is being run in an ASP production environment.* ### Security -*TODO: Write notes on security to help operations engineers keep the -system secure while it is in operation.* +_TODO: Write notes on security to help operations engineers keep the +system secure while it is in operation._ We take the following precautions to make the system secure @@ -190,8 +191,8 @@ The security of the system depends on the following external factors ### Performance and Scalability -*TODO: Write notes on performance and scalability to help operations -engineers operate the system efficiently.* +_TODO: Write notes on performance and scalability to help operations +engineers operate the system efficiently._ ::NOTES ON PERFORMANCE. diff --git a/Installation-Guide.md b/Installation-Guide.md index 13a8d0c..f580a2c 100644 --- a/Installation-Guide.md +++ b/Installation-Guide.md @@ -1,7 +1,8 @@ - -*TODO: Fill in information about this product. Make sure to use the + + +_TODO: Fill in information about this product. Make sure to use the **product** name and **external** release number, not internal -information.* +information._ ##### Product @@ -34,12 +35,12 @@ PRODUCT-NAME. ### Installation -*TODO: Give detailed installation instructions. Make sure to test these -instructions by doing them yourself on a target machine.* +_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 +_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.* +needed development and bugging tools, e.g., Ant and JUnit._ #### What other software must be installed first? @@ -75,9 +76,9 @@ packages: ### Getting Started -*TODO: Briefly describe how the user would accomplish one or two of the +_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.* +components, include instructions on running unit tests._ #### How can I run post-install unit tests? diff --git a/Interview-Checklist.md b/Interview-Checklist.md index 19d3686..06bfeaf 100644 --- a/Interview-Checklist.md +++ b/Interview-Checklist.md @@ -1,4 +1,5 @@ - + + ##### Related Documents - [User Needs](User-Needs) diff --git a/Interview-Notes.md b/Interview-Notes.md index ff74ac9..47c5cc0 100644 --- a/Interview-Notes.md +++ b/Interview-Notes.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -27,9 +28,9 @@ --- -*TODO: Copy this file once for each interview. Fill in the details. Link +_TODO: Copy this file once for each interview. Fill in the details. Link to this file from the "Notes from Interviews and Brainstorming" section -of user-needs.md.* +of user-needs.md._ **Process impact:** Planning questions for interviews with stakeholders is key to effective requirements gathering. Good requirements are needed @@ -39,9 +40,9 @@ documentation on [user needs](User-Needs) are referred to when the ### Interview Questions and Answers -*TODO: Before the interview, plan the questions you will ask. Afterwords, +_TODO: Before the interview, plan the questions you will ask. Afterwords, type up the answers you received and any additional questions and -answers, and any new follow-up questions.* +answers, and any new follow-up questions._ #### ::How did you learn about the need for this product? @@ -77,8 +78,8 @@ answers, and any new follow-up questions.* ### New Questions and Action Items -*TODO: Often early interviews will raise more questions than they answer. -Note these new questions and what you must do to find the answer.* +_TODO: Often early interviews will raise more questions than they answer. +Note these new questions and what you must do to find the answer._ - ::Can we do X? - ::Do we support Y? @@ -88,11 +89,11 @@ Note these new questions and what you must do to find the answer.* ### Other Interview Notes -*TODO: Note anything else that came out of the interview, either +_TODO: Note anything else that came out of the interview, either explicitly or implicitly. Remember to confirm things that you picked up implicitly if there is any doubt. E.g., make a note if the interviewee uses an unusual meaning for a certain term. Add links to any documents -provided to you by the interviewee.* +provided to you by the interviewee._ - ::NOTE - ::NOTE diff --git a/Legal.md b/Legal.md index 4698876..d81e294 100644 --- a/Legal.md +++ b/Legal.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -30,14 +31,14 @@ this release. Failure to carefully consider these issues may put the development organization at risk for legal action. -*TODO: Fill in the information above and below. Add or remove rows as +_TODO: Fill in the information above and below. Add or remove rows as needed. Use the worksheet to help identify legal issues. Seek -professional counsel for review as needed.* +professional counsel for review as needed._ ### Ownership of Intellectual Property | Component | Owner | License | Status | Comments | -|----------------------------|--------------|----------------------|-----------------------------------------------|----------------------------------------------------------------| +| -------------------------- | ------------ | -------------------- | --------------------------------------------- | -------------------------------------------------------------- | | ::Product name | ::Us | ::Trademark | ::Registration pending | ::We must use "(TM)", not "(R)" | | ::Database | ::VENDOR | ::Commercial license | ::In compliance, paid normal fee | ::Limits us to 2 CPUs/server | | ::Encryption library | ::VENDOR | ::Commercial license | ::In compliance, signed partnership agreement | | @@ -51,7 +52,7 @@ professional counsel for review as needed.* ### Regulatory Compliance | Type | Regulation | Status | Comments | -|--------------------------|---------------------------------------------------|-----------------|-----------------------------------------------------------| +| ------------------------ | ------------------------------------------------- | --------------- | --------------------------------------------------------- | | ::Export | ::Strong encryption exports must be declared | ::In compliance | ::We will not distribute out of country | | ::Privacy | ::Cannot collect personal information from minors | ::In compliance | ::We ask for user age before asking for other information | | ::Industry certification | ::Game industry rating | ::In compliance | ::We follow guidelines for "Everyone" rating | @@ -68,9 +69,9 @@ The goal of this checklist is to help expose legal issues that might otherwise be missed. It does not help with the actual management of legal issues. -*TODO: Answer the questions below. If multiple sample answers are +_TODO: Answer the questions below. If multiple sample answers are provided, delete the ones that do not apply. Edit any provided answers -as needed.* +as needed._ #### Does the development organization hold trademarks on the product name and any other names used in marketing the product? diff --git a/License.md b/License.md index 417553e..5fcaa32 100644 --- a/License.md +++ b/License.md @@ -1,4 +1,5 @@ - + + Do not modify or delete this file. This file describes the license under which you may use the ReadySET templates. @@ -33,8 +34,8 @@ POSSIBILITY OF SUCH DAMAGE. Yes, absolutely. Once you fill in the template with detailed information about a specific project, you are free to do what you -want with them in the context of that project. ***You may even hide the -template copyright statement***: the best way to do that is to edit the +want with them in the context of that project. **_You may even hide the +template copyright statement_**: the best way to do that is to edit the file inst.css. #### Can I modify these templates for use on several projects at my company? @@ -47,7 +48,7 @@ copyright statement clearly visible in each file. If you use the templates and fill in details about a given product, go ahead. If you are thinking of making a product that includes the -templates for use *as templates*, you must retain this file and the +templates for use _as templates_, you must retain this file and the copyright statement in a visible footnote. An enhanced commercial version of these templates, [ReadySETPro](http://www.readysetpro.com/), is already in development diff --git a/Project-Plan.md b/Project-Plan.md index 64c382c..cef548d 100644 --- a/Project-Plan.md +++ b/Project-Plan.md @@ -1,4 +1,5 @@ - + + ##### 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? diff --git a/Proposal.md b/Proposal.md index b7e0435..5fae3a1 100644 --- a/Proposal.md +++ b/Proposal.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -30,10 +31,10 @@ project. ### Background and Motivation -*TODO: Replace the example text below with text that describes your +_TODO: Replace the example text below with text that describes your project. What are the needs or problems that you are trying to address? Why do these needs (still) exist? Why are these problems worth solving? -Who is the customer? Write 2-4 paragraphs.* +Who is the customer? Write 2-4 paragraphs._ #### What is the setting and history behind this project? @@ -137,12 +138,12 @@ allows players to quickly find, evaluate, and join clans. ### Scope -*TODO: Replace the sample text below with a clear statement of the scope +_TODO: Replace the sample text below with a clear statement of the scope of your project. What are the high-level things that you plan to do, and that you will not do? What are your important simplifying assumptions? Try to guard against reasonable misunderstandings that might arise if you did not explain the scope. It can take the form of a paragraph, -bullet list, in/out list, and/or UML context diagram.* +bullet list, in/out list, and/or UML context diagram._ ::We want to focus on the web application itself, and the features of that application that help build a good gaming community. @@ -158,7 +159,7 @@ application that help build a good gaming community. actually integrate with any game software | In Scope | Out of Scope | -|----------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ::Building a web application for use with standard web servers and application servers | ::Building a new web server or application server | | ::Working the most popular browsers (IE6, NN7/Mozilla) | ::Working with uncommon or outdated browsers | | ::Security in the form of user accounts, passwords, and permissions | ::Special security against hackers. Finding or patching security holes in existing software components. | @@ -169,9 +170,9 @@ application that help build a good gaming community. ### Deliverables -*TODO: Briefly list project deliverables. When you are done, what will +_TODO: Briefly list project deliverables. When you are done, what will you deliver to the customer? This can be copied from the draft project -plan and simplified to reduce technical detail.* +plan and simplified to reduce technical detail._ - ::Clan website directory engine - ::Customization guide diff --git a/QA-Plan.md b/QA-Plan.md index 6072c6b..30794ba 100644 --- a/QA-Plan.md +++ b/QA-Plan.md @@ -1,9 +1,7 @@ - - - -*TODO: For each release, update this file by filling in answers to the + +_TODO: For each release, update this file by filling in answers to the questions. In cases where multiple answers are already written, delete -those answers that do not apply.* +those answers that do not apply._ ##### Project @@ -76,7 +74,7 @@ this release. ::There are many quality goals and approaches to assuring them. Since we have limited time and resources for this release, we will focus on the following components and aspects: - + - ::COMPONENT-1 - ::COMPONENT-2 - ::COMPONENT-3 @@ -99,8 +97,8 @@ activities: ### Quality Goals for this Release -*TODO: Add or edit goals to fit your project. Group them by priorities -that make sense for your project on this particular release.* +_TODO: Add or edit goals to fit your project. Group them by priorities +that make sense for your project on this particular release._ - ::Essential - [Functionality > Correctness](Glossary-Standard-Terms#functionality--correctness) @@ -133,18 +131,18 @@ that make sense for your project on this particular release.* ### QA Strategy -*TODO: Consider the activities listed below and delete those that are not +_TODO: Consider the activities listed below and delete those that are not applicable to your project. Edit and add new activities if needed. For each activity, specify the coverage or frequency that you plan to -achieve. If you do not plan to perform an activity, write "N/A".* +achieve. If you do not plan to perform an activity, write "N/A"._ - + | Activity | Coverage or Frequency | Description | -|--------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ::Preconditions |
  • ::Every public method
  • ::Every public method in COMPONENT-NAME
  • ::All public methods that modify data
| ::We will use if-statements at the beginning of public methods to validate each argument value. This helps to document assumptions and catch invalid values before they can cause faults. | | ::Assertions |
  • ::Every private method
  • ::Every private method in COMPONENT-NAME
  • ::All private methods that modify data
| ::Assertions will be used to validate all arguments to private methods. Since these methods are only called from our other methods, arguments passed to them should always be valid, unless our code is defective. Assertions will also be used to test class invariants and some postconditions. | -| ::Static analysis |
  • ::Strict compiler warnings
  • ::Automated style checking
  • ::XML validation
  • Detect common errors
| ::We will use source code analysis tools to automatically detect errors. Style checkers will help make all of our code consistent with our coding standards. XML validation ensures that each XML document conforms to its DTD. Lint-like tools help detect common programming errors. E.g.: [lint](http://www.freebsd.org/cgi/man.cgi?query=lint), [lclint/splint](http://www.splint.org/), [jlint](http://artho.com/jlint/), [checkstyle](http://sourceforge.net/projects/checkstyle/), [Jcsc](http://sourceforge.net/projects/jcsc), [PyLint](https://www.pylint.org/), [PyChecker](http://pychecker.sourceforge.net/), [Tidy](http://www.html-tidy.org/) | +| ::Static analysis |
  • ::Strict compiler warnings
  • ::Automated style checking
  • ::XML validation
  • Detect common errors
| ::We will use source code analysis tools to automatically detect errors. Style checkers will help make all of our code consistent with our coding standards. XML validation ensures that each XML document conforms to its DTD. Lint-like tools help detect common programming errors. E.g.: [lint](http://www.freebsd.org/cgi/man.cgi?query=lint), [lclint/splint](http://www.splint.org/), [jlint](http://artho.com/jlint/), [checkstyle](http://sourceforge.net/projects/checkstyle/), [Jcsc](http://sourceforge.net/projects/jcsc), [PyLint](https://www.pylint.org/), [PyChecker](http://pychecker.sourceforge.net/), [Tidy](http://www.html-tidy.org/) | | ::Buddy review |
  • ::All changes to release branches
  • ::All changes to COMPONENT-NAME
  • ::All changes
| ::Whenever changes must be made to code on a release branch (e.g., to prepare a maintenance release) the change will be reviewed by another developer before it is committed. The goal is to make sure that fixes do not introduce new defects. | | ::Review meetings |
  • ::Weekly
  • ::Once before release
  • ::Every source file
| ::We will hold review meetings where developers will perform formal inspections of selected code or documents. We choose to spend a small, predetermined amount of time and try to maximize the results by selecting review documents carefully. In the review process we will use and maintain a variety of checklists. | | ::Unit testing |
  • ::100% of public methods, and 75% of statements
  • ::100% of public methods
  • ::75% of statements
| ::We will develop and maintain a unit test suite using the JUnit framework. We will consider the boundary conditions for each argument and test both sides of each boundary. Tests must be run and passed before each commit, and they will also be run by the testing team. Each public method will have at least one test. And, the overall test suite will exercise at least 75% of all executable statements in the system. | @@ -155,24 +153,25 @@ achieve. If you do not plan to perform an activity, write "N/A".* | ::Beta testing |
  • ::4 current customers
  • ::40 members of our developers network
  • ::1000 members of the public
| ::We will involve outsiders in a beta test, or early access, program. We will beta testers directions to focus on specific features of the system. We will actively follow up with beta testers to encourage them to report issues. | | ::Instrumentation and monitoring |
  • ::Monitor our ASP servers
  • ::Remotely monitor customer servers
| ::As part of our SLA, we will monitor the behavior of servers to automatically detect service outages or performance degradation. We have policies and procedures in place for failure notification, escalation, and correction. | | ::Field failure reports |
  • ::Prompt users to report failures
  • ::Automatically report failures
| ::We want to understand each post-deployment system failure and actively take steps to correct the defect. The system has built-in capabilities for gathering detailed information from each system failure (e.g., error message, stack traceback, operating system version). This information will be transmitted back to us so that we may analyze it and act on it. | + ### QA Strategy Evaluation -*TODO: Use the following table to evaluate how well your QA Strategy will -assure your QA goals.* +_TODO: Use the following table to evaluate how well your QA Strategy will +assure your QA goals._ -| Goal | Preconditions | Assertions | Buddy review | Review meeting | Unit testing | Manual system testing | Overall assurance | -|-----------------|-----------------|--------------|----------------|------------------|----------------|-------------------------|---------------------| -| Functionality | ::Medium | ::Medium | ::Medium | ::High | ::High | ::High | ::Strong | -| Correctness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong | -| Robustness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong | -| Usability | ::None | ::None | ::None | ::High | ::None | ::Medium | ::Strong | -| Security | ::Medium | ::None | ::Medium | ::High | ::None | ::Medium | ::Strong | -| Reliability | ::None | ::Medium | ::Low | ::Medium | ::Medium | ::Medium | ::Weak | -| Efficiency | ::None | ::None | ::Low | ::Medium | ::None | ::Low | ::At-Risk | -| Scalability | ::None | ::None | ::Low | ::Medium | ::Low | ::Low | ::At-Risk | -| Operability | ::None | ::None | ::None | ::Low | ::None | ::Low | ::At-Risk | -| Maintainability | ::Medium | ::Low | ::Medium | ::High | ::Low | ::None | ::Weak | +| Goal | Preconditions | Assertions | Buddy review | Review meeting | Unit testing | Manual system testing | Overall assurance | +| --------------- | ------------- | ---------- | ------------ | -------------- | ------------ | --------------------- | ----------------- | +| Functionality | ::Medium | ::Medium | ::Medium | ::High | ::High | ::High | ::Strong | +| Correctness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong | +| Robustness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong | +| Usability | ::None | ::None | ::None | ::High | ::None | ::Medium | ::Strong | +| Security | ::Medium | ::None | ::Medium | ::High | ::None | ::Medium | ::Strong | +| Reliability | ::None | ::Medium | ::Low | ::Medium | ::Medium | ::Medium | ::Weak | +| Efficiency | ::None | ::None | ::Low | ::Medium | ::None | ::Low | ::At-Risk | +| Scalability | ::None | ::None | ::Low | ::Medium | ::Low | ::Low | ::At-Risk | +| Operability | ::None | ::None | ::None | ::Low | ::None | ::Low | ::At-Risk | +| Maintainability | ::Medium | ::Low | ::Medium | ::High | ::Low | ::None | ::Weak | Cell values in the table above are subjective estimates of the effectiveness of each activity. This table helps to identify quality @@ -204,12 +203,13 @@ rating. ### Plan of Action -*TODO: Adjust this plan to fit your project.* +_TODO: Adjust this plan to fit your project._ -*TODO: Once the plan is outlined, tasks should be assigned to individuals -and tracked to completion.* +_TODO: Once the plan is outlined, tasks should be assigned to individuals +and tracked to completion._ 1. Preconditions and Assertions + - ::Refine requirements document whenever preconditions are not already determined - ::Create validation functions for use by preconditions and @@ -217,6 +217,7 @@ and tracked to completion.* - ::Write preconditions and assertions in code 2. Review meetings + - ::Assign buddy reviewers whenever a change to a release branch is considered - ::Select an at-risk document or section of code for weekly review @@ -228,6 +229,7 @@ and tracked to completion.* repository and track any issues identified in review meetings 3. Unit tests + - ::Set up infrastructure for easy execution of JUnit tests (this is just an Ant target) - ::Create unit tests for each class when the class is created @@ -241,6 +243,7 @@ and tracked to completion.* - ::Update unit tests whenever requirements change 4. System tests + - ::Design and specify a detailed manual [test suite](Test-Suite). - ::Review the system test suite to make sure that every UI screen and element is covered @@ -266,12 +269,12 @@ and tracked to completion.* #### Do the selected activities in the QA Strategy provide enough assurance that the project will meet it's quality goals? ::Yes, if all activities are carried out as planned, we are confident - that the quality goals will be satisfied. We will, of course, adjust - this plan as needed. +that the quality goals will be satisfied. We will, of course, adjust +this plan as needed. ::No, this plan leaves open several quality risks that have been noted - in the [Risk Management](Project-Plan#Risk-Management) section of the - [Project Plan](Project-Plan). +in the [Risk Management](Project-Plan#Risk-Management) section of the +[Project Plan](Project-Plan). #### Have human resources been allocated to carry out the QA activities? diff --git a/Release-Checklist.md b/Release-Checklist.md index 5a8b5ed..2147b08 100644 --- a/Release-Checklist.md +++ b/Release-Checklist.md @@ -1,7 +1,8 @@ - -*TODO: For each release, copy this file and fill in answers to the + + +_TODO: For each release, copy this file and fill in answers to the questions. In cases where multiple answers are already written, delete -those answers that do not apply.* +those answers that do not apply._ ##### Project @@ -30,16 +31,16 @@ stakeholders of their upcoming responsibilities. Once this checklist has been satisfied, this release may be sent to manufacturing and sold to customers with the full support of the organization. -*TODO: Discuss each item with the relevant stakeholders and update its +_TODO: Discuss each item with the relevant stakeholders and update its status. Add comments as needed to record important decisions or link to resulting documents. Add new items as needed for your particular project or process. Any uncovered problems or tasks should be tracked in the -issue tracker.* +issue tracker._ ### Marketing / Product Management | Item | Status | Comments | -|--------------------------------------------------------------------------|---------|----------| +| ------------------------------------------------------------------------ | ------- | -------- | | ::All new requirements for this release have been tracked | Pending | | | ::All prior defects needing resolution in this release have been tracked | Pending | | | ::All marketing documents have been updated | Pending | | @@ -48,7 +49,7 @@ issue tracker.* ### Development | Item | Status | Comments | -|--------------------------------------------------------|---------|----------| +| ------------------------------------------------------ | ------- | -------- | | ::All needed design work has been completed | Pending | | | ::All needed design work has been reviewed | Pending | | | ::All development work has been completed | Pending | | @@ -61,7 +62,7 @@ issue tracker.* ### Quality Assurance {#quality-assurance} | Item | Status | Comments | -|-------------------------------------------------|---------|----------| +| ----------------------------------------------- | ------- | -------- | | ::The QA plan and test cases have been updated | Pending | | | ::The QA plan has been completely carried out | Pending | | | ::All discovered defects have been tracked | Pending | | @@ -71,7 +72,7 @@ issue tracker.* ### Release Engineering / Configuration Management | Item | Status | Comments | -|----------------------------------------------------------------------------------------------------------------------|---------|----------| +| -------------------------------------------------------------------------------------------------------------------- | ------- | -------- | | ::All components have been properly tagged for release, and the release configuration is clearly defined | Pending | | | ::Change-control practices have been followed, meaning that the released product does not contain unapproved changes | Pending | | | ::The RelEng team is satisfied with this release | Pending | | @@ -79,7 +80,7 @@ issue tracker.* ### User Experience | Item | Status | Comments | -|-----------------------------------------------------------|---------|----------| +| --------------------------------------------------------- | ------- | -------- | | ::Any new or changed functionality is deemed usable | Pending | | | ::On-line and printed user documentation has been updated | Pending | | | ::The UE team is satisfied with this release | Pending | | @@ -87,7 +88,7 @@ issue tracker.* ### Technical Support / Operations | Item | Status | Comments | -|--------------------------------------------------------------------------------------------------------------|---------|----------| +| ------------------------------------------------------------------------------------------------------------ | ------- | -------- | | ::Theory of operations document has been updated | Pending | | | ::Tech support / Operations has successfully installed, upgraded, and used this release | Pending | | | ::Any "Early access" or "Beta" program was conducted successfully and all resulting issues have been tracked | Pending | | @@ -98,7 +99,7 @@ issue tracker.* ### Services / Training | Item | Status | Comments | -|----------------------------------------------------------------------------------|---------|----------| +| -------------------------------------------------------------------------------- | ------- | -------- | | ::Services / Training has had access to this release | Pending | | | ::The impact of any changes on service offerings has been identified and tracked | Pending | | | ::Training materials have been updated | Pending | | @@ -107,7 +108,7 @@ issue tracker.* ### Legal | Item | Status | Comments | -|-------------------------------------------------------------------------------|---------|----------| +| ----------------------------------------------------------------------------- | ------- | -------- | | ::Legal risks associated with this release have been identified and tracked | Pending | | | ::We hold proper licenses for all reused components and intellectual property | Pending | | | ::We conform to all relevant laws and regulations (e.g., export, safety) | Pending | | @@ -122,13 +123,13 @@ issue tracker.* - Done: The stakeholders agree that the item has been satisfied - Failed: This item has forced us to abandon this release -*TIP: If a stakeholder hits difficulties with this release after it goes +_TIP: If a stakeholder hits difficulties with this release after it goes out, add those issues to the checklist template so that everyone knows that they will be explicitly managed on the next release. Conduct a -postmortem review to help expose difficulties rather than repeat them.* +postmortem review to help expose difficulties rather than repeat them._ -*TIP: You might consider some of the following additional stakeholders at +_TIP: You might consider some of the following additional stakeholders at your organization: Other engineering groups (i.e., hardware design), Manufacturing and Shipping, Software Process Improvement, Key customers and partners, External developers, Risk Management, Business -Development, and Upper Management.* +Development, and Upper Management._ diff --git a/Release-Notes.md b/Release-Notes.md index 4ca4c13..9893dfe 100644 --- a/Release-Notes.md +++ b/Release-Notes.md @@ -1,9 +1,10 @@ - -*TODO: For each release, copy this file and fill in the needed -information.* + -*TODO: Make sure to use the **product** name and **external** release -number, not internal information.* +_TODO: For each release, copy this file and fill in the needed +information._ + +_TODO: Make sure to use the **product** name and **external** release +number, not internal information._ ##### Product @@ -32,7 +33,7 @@ The following sections describe the release in detail and provide late-breaking or other information that supplements the main documentation. -*TODO: Consider using one of the following example paragraphs.* +_TODO: Consider using one of the following example paragraphs._ ::This is a developer release for internal evaluation only. Please report any issues via the internal issue tracker. @@ -70,11 +71,11 @@ this release. ### What's New? -*TODO: Briefly list major user-visible enhancements. Or, note that +_TODO: Briefly list major user-visible enhancements. Or, note that nothing major has been added. Technical issues should only be mentioned if this is a reusable software component that will be used to build larger products. Do not include issue numbers. Links to detailed -information can be helpful.* +information can be helpful._ - ::Added 4 new play-back modes - ::Increased play-back speed by as much as 30% @@ -85,16 +86,16 @@ information can be helpful.* ### Installation and Upgrade Notes -*TODO: Fill in these sections. The text here is only an example.* +_TODO: Fill in these sections. The text here is only an example._ #### ::Installation ::See the [installation instructions](Installation-Guide) for full details. - Please note that in this release, ... +Please note that in this release, ... ::IMPORTANT: You must completely uninstall any previous "developer - release" or "early access" version of this product before installing - this release. +release" or "early access" version of this product before installing +this release. #### ::Manifest @@ -142,13 +143,13 @@ updated by using the WaveUpgrade utility. ### Recent Changes -*TODO: Query your public issue tracking system to produce a report of +_TODO: Query your public issue tracking system to produce a report of changes in this release. Include the issue number, type, and one-line summary. Include issues that were highlighted in the "What's New?" section above. You may revise one-line summaries in the issue tracker, prior to generating the report, if you notice that they are incorrect. You may exclude or summarize changes that might give away valuable -proprietary information.* +proprietary information._ - ::FIX [09823](#tbd) Screen frozen when caps-lock is on - ::FIX [09912](#tbd) Static heard while downloading @@ -160,16 +161,16 @@ proprietary information.* ### Known Problems and Workarounds -*TODO: Query your public issue tracking system to produce a report of +_TODO: Query your public issue tracking system to produce a report of defects discovered in this release, or in previous releases that are still not resolved. Include information on workarounds from the issues. -Otherwise, same as above.* +Otherwise, same as above._ - ::DEFECT [07293](#tbd) Player skips on very loud playback. - ::WORKAROUND: Limit volume to settings 1 through 9. - ::DEFECT [10509](#tbd) Cannot switch directly from random play mode to - Internet play-list. + Internet play-list. - ::WORKAROUND: Switch to local play-list first. Click [here](#tbd) for - detailed instructions. + detailed instructions. - ::DEFECT [10589](#tbd) Static heard while booting - ::DEFECT [10944](#tbd) Repeat-mode cannot play more than 999 times diff --git a/Resource-Needs.md b/Resource-Needs.md index dfba3bd..f74d7f0 100644 --- a/Resource-Needs.md +++ b/Resource-Needs.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -26,16 +27,16 @@ this project will need the following resources to meet its goals. If fewer resources are available, the scope of the release should be reconsidered or the process must be changed. -*TODO: Fill in the information above and below. Add or remove rows as +_TODO: Fill in the information above and below. Add or remove rows as needed. Use the worksheet to help identify and scope resource needs. These rows are just examples. The total effort listed in this example may not even match the totals given in other examples of related -documents.* +documents._ ### Human Resource Needs | Need | Resource | Amount | Status | Comments/Responsibilities | -|-------------------------------------------|-----------------------------------------|------------|------------|---------------------------| +| ----------------------------------------- | --------------------------------------- | ---------- | ---------- | ------------------------- | | ::Project Management | ::PERSON-NAME | ::20 hours | ::Pending | | | ::Requirements | ::PERSON-NAME | ::20 hours | ::Assigned | | | ::Requirements | ::PERSON-NAME, PERSON-NAME, PERSON-NAME | ::10 hours | ::Assigned | | @@ -56,7 +57,7 @@ documents.* ### Capital Needs | Need | Resource | Amount | Status | Comments | -|------------------------------------|-------------------------------------------------------|-----------|---------------------------|---------------------------------------------------------------------------------| +| ---------------------------------- | ----------------------------------------------------- | --------- | ------------------------- | ------------------------------------------------------------------------------- | | ::Training materials | ::Book/Course on specific technology | ::1 | ::Allocated | ::Book ordered | | ::Development Workstations | ::800MHz PC, 256MB RAM | ::4 | ::Satisfied | ::Dev group will use existing workstations | | ::Development DB Server | ::Dual CPU 1GHz PC, 512MB RAM: SERVERNAME.company.com | ::1 | ::Allocated | | @@ -89,10 +90,10 @@ The goal of this checklist is to help expose resource needs that might otherwise be missed. It does not help with the actual estimated number of hours needed. Those estimates should be based on the project plan. -*TODO: Answer the questions below. If multiple sample answers are +_TODO: Answer the questions below. If multiple sample answers are provided, [chip away](Glossary-Standard-Terms#chipping-away) the ones that do not apply. Edit any provided answers as needed. Use this exercise to -help you fill in the tables above.* +help you fill in the tables above._ #### Does this project need more than a few days work? @@ -127,7 +128,7 @@ help you fill in the tables above.* #### Does the project plan include complex configuration of existing components? :: Yes. Component expert needed. Also need time to coordinate with - development and operations teams. +development and operations teams. :: No. No component experts are needed @@ -136,19 +137,19 @@ help you fill in the tables above.* :: Yes. No training time needed. :: No. Effort needed for training. Need training materials, courses, or - time with experts or mentors. List specific training - needs individually. +time with experts or mentors. List specific training +needs individually. #### Is the entire development team have an agreed upon software development methodology? :: Yes. No effort needed for defining a methodology. :: Yes. But, effort is needed to refine the methodology to the project - at hand. +at hand. :: No. Effort needed to define and document a methodology and train all - team members. Additional effort needed for refinements throughout - the project. +team members. Additional effort needed for refinements throughout +the project. #### Does the project plan include end-user documentation? @@ -169,131 +170,131 @@ help you fill in the tables above.* :: No, but other developers will need training to reuse this component. :: No. Effort put into producing good technical documentation should - be enough. +be enough. #### Will the product of this project be sold to customers, directly or indirectly? -:: Yes. The full SDM must be followed, including effort by a change - control board and release engineering. +:: Yes. The full SDM must be followed, including effort by a change +control board and release engineering. -:: No, it is for internal use only but it will be used repeatedly to - help build a shipping product. Release engineering and CCB effort is - still needed. +:: No, it is for internal use only but it will be used repeatedly to +help build a shipping product. Release engineering and CCB effort is +still needed. -:: No, it is for internal use only and will only be used once. Release - engineering and CCB effort not needed. +:: No, it is for internal use only and will only be used once. Release +engineering and CCB effort not needed. #### Does the QA plan call for the running of automated unit tests? -:: Yes. Development effort will be needed to implement unit tests. +:: Yes. Development effort will be needed to implement unit tests. -:: No. Additional QA effort will be needed for manual testing. +:: No. Additional QA effort will be needed for manual testing. #### Does the QA plan call for more than the running of automated unit tests? -:: Yes. QA effort will be needed. +:: Yes. QA effort will be needed. -:: No. Unit tests will be enough for this component, full QA can be - done on products that use this component. +:: No. Unit tests will be enough for this component, full QA can be +done on products that use this component. #### How many development workstations will be needed? -:: 1 per developer. +:: 1 per developer. -:: 1 per developer, plus extra for... +:: 1 per developer, plus extra for... #### What development servers are needed? -:: None. +:: None. -:: One for the whole team. +:: One for the whole team. -:: One for the one aspect of development, another for another aspect. +:: One for the one aspect of development, another for another aspect. -:: One for the one branch of development, another for another branch. +:: One for the one branch of development, another for another branch. #### What database servers are needed? -:: None. No database is being used. +:: None. No database is being used. -:: None. Database is integrated into product and does not require a - separate server. +:: None. Database is integrated into product and does not require a +separate server. -:: One for the whole team. +:: One for the whole team. -:: One for the developers, one for QA. +:: One for the developers, one for QA. -:: One for one branch of development, another for another branch. +:: One for one branch of development, another for another branch. -:: One for the developers, one for QA, one for load testing. +:: One for the developers, one for QA, one for load testing. -:: One for each developer or tester, plus one for load testing. +:: One for each developer or tester, plus one for load testing. #### What machines are needed for automated testing? -:: None. Automated testing will not be done. +:: None. Automated testing will not be done. -:: None. Automated testing will be done on workstations. +:: None. Automated testing will be done on workstations. -:: One for all nightly automated tests. +:: One for all nightly automated tests. -:: One for one aspect of nightly automated tests, another for - another aspect. +:: One for one aspect of nightly automated tests, another for +another aspect. -:: One for one branch of development, another for another branch. +:: One for one branch of development, another for another branch. #### What machines are needed for load testing? -:: None. Load testing will not be done. +:: None. Load testing will not be done. -:: None. Load testing will be done on workstations. +:: None. Load testing will be done on workstations. -:: One machine will do all load testing. +:: One machine will do all load testing. -:: Several machines needed to act as clients and servers. +:: Several machines needed to act as clients and servers. -:: One cluster of load testing machines for each branch of development. +:: One cluster of load testing machines for each branch of development. #### What development tools must be licensed for this project? -:: None. Everything is implemented by us. +:: None. Everything is implemented by us. -:: None. All development tools are open source. +:: None. All development tools are open source. -:: Some tools: IDE, database, testing tools. These tools have already - been purchased, installed, and configured. +:: Some tools: IDE, database, testing tools. These tools have already +been purchased, installed, and configured. -:: Some tools: IDE, database, testing tools. Budget must be allocated - to purchase these tools. Effort must be allocated to research and - select tools for purchase, install, and configure them. +:: Some tools: IDE, database, testing tools. Budget must be allocated +to purchase these tools. Effort must be allocated to research and +select tools for purchase, install, and configure them. #### What software components must be licensed for this project? -:: None. Everything is implemented by us. +:: None. Everything is implemented by us. -:: None. All reused components are open source. +:: None. All reused components are open source. -:: Some components: database, server software, libraries. These - components have already been selected, purchased, installed, - and configured. +:: Some components: database, server software, libraries. These +components have already been selected, purchased, installed, +and configured. -:: Some components: database, server software, libraries. Effort must - be allocated to research, select, install and configure - these components. Budget must be allocated to purchase them. +:: Some components: database, server software, libraries. Effort must +be allocated to research, select, install and configure +these components. Budget must be allocated to purchase them. #### Are any of the personnel assignments of capital allocations conditional? -:: Yes. All such conditions are written in the comments column above. - We have a contingency plan that will still achieve (an - acceptable subset) of the project goals. +:: Yes. All such conditions are written in the comments column above. +We have a contingency plan that will still achieve (an +acceptable subset) of the project goals. -:: No. Management has set aside these resources as promised, and the - needs of this project will take priority over any other project that - is likely to need the same resources. +:: No. Management has set aside these resources as promised, and the +needs of this project will take priority over any other project that +is likely to need the same resources. #### Have these resource assignments been communicated to the people being assigned and their managers? -:: Yes, everyone understands. Feedback is welcome. +:: Yes, everyone understands. Feedback is welcome. -:: No, this is a risk that is noted in the [Risk - Management](Project-Plan#Risk-Management) section. +:: No, this is a risk that is noted in the [Risk +Management](Project-Plan#Risk-Management) section. diff --git a/Review-Meeting-Notes.md b/Review-Meeting-Notes.md index aaaebac..a8e6e3f 100644 --- a/Review-Meeting-Notes.md +++ b/Review-Meeting-Notes.md @@ -1,5 +1,5 @@ + - ##### Project ::[PROJECT-NAME](Home) @@ -40,8 +40,8 @@ ### Meeting Minutes -*TODO: Fill in the information above and write a brief summary of what -happened at the meeting. The text below is just a sample.* +_TODO: Fill in the information above and write a brief summary of what +happened at the meeting. The text below is just a sample._ ::We started on time with 3 members and the other team members arrived shortly thereafter. diff --git a/Risks.md b/Risks.md index ee9db06..af6737c 100644 --- a/Risks.md +++ b/Risks.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -38,8 +39,8 @@ 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. -*TODO: You should update these lists regularly. They should be reviewed -by customers and developers from time to time.* +_TODO: You should update these lists regularly. They should be reviewed +by customers and developers from time to time._ ### General contingency plans @@ -74,21 +75,21 @@ delivery date. ### Major risks -| Name | Description | Likelihood | Impact | Plan | Status | Owner | -|-----------------|---------------------------------------------------------------------------------------------------------------------------------|------------|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|-------------------| -| ::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 | -| ::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 | +| Name | Description | Likelihood | Impact | Plan | Status | Owner | +| --------------- | ------------------------------------------------------------------------------------------------------------------------------- | ---------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ----------------- | +| ::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 | +| ::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 | ### Minor risks -*TODO: Review this list regularly, to decide whether the likelihood or -impact of a risk has increased to make it a "major" risk.* +_TODO: Review this list regularly, to decide whether the likelihood or +impact of a risk has increased to make it a "major" risk._ | Name | Description | Likelihood | Impact | Mitigation Strategy | Status | Owner | -|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|----------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|-----------------| +| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------- | --------------- | | ::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 | @@ -97,7 +98,7 @@ impact of a risk has increased to make it a "major" risk.* | ::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 | | ::Maintainability | The system as delivered might be hard to maintain. | Low | Marginal | We will review the code for maintainability. | Green | Lead Developer | -| ::RISK-NAME | 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 | PERSON-NAME | +| ::RISK-NAME | 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 | PERSON-NAME | #### Possible risk status values diff --git a/SDM.md b/SDM.md index 3ff0713..0fda43f 100644 --- a/SDM.md +++ b/SDM.md @@ -1,5 +1,6 @@ - -*TODO: This template is not done yet. Feel free to contribute your ideas.* + + +_TODO: This template is not done yet. Feel free to contribute your ideas._ A Software Development Methodology is always specific to a given company, but the outline of that document could be reused, as could some diff --git a/SRS.md b/SRS.md index aff26c1..4d9e10a 100644 --- a/SRS.md +++ b/SRS.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -30,8 +31,8 @@ and validated by activities outlined in the [QA plan](QA-Plan). ### Introduction -*TODO: Provide a brief overview of this release of the product. You can -copy text from the project proposal, paste it here, and shorten it.* +_TODO: Provide a brief overview of this release of the product. You can +copy text from the project proposal, paste it here, and shorten it._ ::PARAGRAPH @@ -60,8 +61,8 @@ Details: ### Non-Functional Requirements -*TODO: Describe the non-functional requirements for this release. Some -examples are provided below.* +_TODO: Describe the non-functional requirements for this release. Some +examples are provided below._ #### What are the usability requirements? @@ -199,10 +200,10 @@ Details: ### Environmental Requirements -*TODO: Describe the environmental requirements for this release. +_TODO: Describe the environmental requirements for this release. Environmental requirements describe the larger system of hardware, software, and data that this product must work within. Some examples are -provided below.* +provided below._ #### What are the system hardware requirements? diff --git a/Status-Report.md b/Status-Report.md index 4ed5709..ab7be4c 100644 --- a/Status-Report.md +++ b/Status-Report.md @@ -1,10 +1,11 @@ - -*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.* +_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 @@ -89,9 +90,9 @@ release. These issues were selected because ... ### Risk Management -*TODO: List 3-10 of the top project risks that are still outstanding. +_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.* +or a previous status report._ - ::We could face major difficulties with the technology chosen for this project. HOW TO AVOID/MITIGATE? @@ -104,15 +105,15 @@ or a previous status report.* ### Upcoming Activity -*TODO: Provide a few bullets describing what you will do between now and +_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.* +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) + [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 @@ -123,11 +124,11 @@ possible.* ### 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.* +_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 | | | @@ -135,7 +136,7 @@ Add a new column for actual effort spent so far by all team members.* | ::2.2. | ::Requirements specification | ::20h | ::0h | | ::2.3. | ::Requirements validation | ::10h | ::0h | | ::3. | ::Elaboration | | | -| ::3.1. | ::High-level design | ::5h |::0h | +| ::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 | diff --git a/Summary.md b/Summary.md index 14894ca..336be06 100644 --- a/Summary.md +++ b/Summary.md @@ -1,8 +1,9 @@ - + + ### Mission and Scope -*TODO: Answer these questions in your own words. This is condensed -from the project [Home](Home).* +_TODO: Answer these questions in your own words. This is condensed +from the project [Home](Home)._ #### What problem does this project address? @@ -18,7 +19,7 @@ from the project [Home](Home).* ### Status -*TODO: Briefly describe the status of this project. E.g., what phase are you in? And, what is your next major milestone? Detailed project status is written in the status reports, not here.* +_TODO: Briefly describe the status of this project. E.g., what phase are you in? And, what is your next major milestone? Detailed project status is written in the status reports, not here._ ::We have completed our second beta release and are currently working on adding more of the functionality described in our product @@ -35,9 +36,9 @@ functionality and a wider set of testers. ### Resources and schedule -*TODO: Briefly describe the project resources and schedule. This is +_TODO: Briefly describe the project resources and schedule. This is condensed from the [project plan](Project-Plan), [resource needs](Resource-Needs), -and [legal issues](legal.html) documents.* +and [legal issues](legal.html) documents._ #### What are the deadlines for this project? @@ -67,11 +68,11 @@ and [legal issues](legal.html) documents.* ### Requirements -*TODO: Briefly describe the most important system requirements. This is +_TODO: Briefly describe the most important system requirements. This is condensed from the [user needs](User-Needs), [interview notes](interview-notes.html), [SRS](SRS), [use case suite](Use-Case-Suite), -and [feature set](Feature-Set) documents.* +and [feature set](Feature-Set) documents._ #### Who are the project stakeholders? @@ -94,9 +95,9 @@ and [feature set](Feature-Set) documents.* ### Design -*TODO: Briefly describe the most important aspects of the design. This is +_TODO: Briefly describe the most important aspects of the design. This is condensed from the [design](Design) template and associated -worksheets.* +worksheets._ #### What are your ranked design goals? @@ -139,9 +140,9 @@ worksheets.* ### Quality Assurance -*TODO: Briefly describe your quality goals and how you will achieve them. +_TODO: Briefly describe your quality goals and how you will achieve them. This is condensed from the [QA plan](QA-Plan), [test -suite](test-suite), and [test cases](test-cases.html) documents.* +suite](test-suite), and [test cases](test-cases.html) documents._ #### What are your ranked quality goals? @@ -204,9 +205,9 @@ Where is the user documentation? ### Glossary -*TODO: Define any technical terms that you use above, if a new member of +_TODO: Define any technical terms that you use above, if a new member of the team would not already know them. This is condensed from the -[glossary](Glossary) documents.* +[glossary](Glossary) documents._ #### ::TECHNICAL TERM 1 diff --git a/Target-and-Benefits.md b/Target-and-Benefits.md index 8b9c98e..028e7ea 100644 --- a/Target-and-Benefits.md +++ b/Target-and-Benefits.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -23,8 +24,8 @@ cases. ### Target Audience -*TODO: Fill in the information above and below. Provided answers are only -examples. Delete them and answer in your own words.* +_TODO: Fill in the information above and below. Provided answers are only +examples. Delete them and answer in your own words._ #### What market segment is this product in? @@ -66,15 +67,15 @@ about the potential for viruses. ### Benefits to Customers -*TODO: List high-level benefits that this product will provide. For each, +_TODO: List high-level benefits that this product will provide. For each, identify the type of customer or user that will benefit. Each benefit should be in real-world terms, not involving just this product itself. You may want to highlight benefits that are not offered by competing products. Benefits to the development organization should be listed in -[Risks and Rewards](Project-Plan#risk-management).* +[Risks and Rewards](Project-Plan#risk-management)._ -*TIP: If you can rank benefits by value, use numbered lists (the HTML -<ol> tag), otherwise use bullet lists (the HTML <ul> tag).* +_TIP: If you can rank benefits by value, use numbered lists (the HTML +<ol> tag), otherwise use bullet lists (the HTML <ul> tag)._ - ::Increases play-value - ::Many players enjoy games more when they play as a team. @@ -123,9 +124,9 @@ products. Benefits to the development organization should be listed in ### Potential Downside -*TODO: Could anyone be harmed or put at a disadvantage because of your +_TODO: Could anyone be harmed or put at a disadvantage because of your system? List as above. Note, these are not risks to the success of your -implementation, assume that you build the system as specified on time.* +implementation, assume that you build the system as specified on time._ - ::Privacy - ::When players opt into clans, they also opt into receiving @@ -133,7 +134,7 @@ implementation, assume that you build the system as specified on time.* thing if the players are interested, but it can also be annoying. - ::Cheaters will be publicly named as cheaters and blocked from - game servers, thus they lose the ability to play/cheat. + game servers, thus they lose the ability to play/cheat. - ::Type of downside 1. ::Worst downside 2. ::Downside diff --git a/Test-Case-Format.md b/Test-Case-Format.md index 1349130..61e96e1 100644 --- a/Test-Case-Format.md +++ b/Test-Case-Format.md @@ -1,4 +1,5 @@ - + + ##### Related Documents - [QA Plan](QA-Plan) > [Test Suite](Test-Suite) > Test Case Format @@ -29,7 +30,7 @@ Assumptions that must be met before the test case can be run. E.g., "logged **Test Data:** -List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each *combination* of values. These values are written in set notation, one per line. E.g.: +List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each _combination_ of values. These values are written in set notation, one per line. E.g.: - ::loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty} - ::password = {valid, invalid, empty} @@ -123,8 +124,8 @@ the end of the test case. steps of the named test case and then continue on to the next step of this test case. -*Every test case must include a verify step at the end so that the +_Every test case must include a verify step at the end so that the expected output is very clear. A test case can have multiple verify steps in the middle or at the end. Having multiple verify steps can be useful if you want a smaller number of long tests rather than a large -number of short tests.* +number of short tests._ diff --git a/Test-Cases.md b/Test-Cases.md index 1544bdb..c1f572f 100644 --- a/Test-Cases.md +++ b/Test-Cases.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -110,7 +111,7 @@ E.g., "logged in", "guest login allowed", ::List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case -should be performed once for each *combination* of values. These +should be performed once for each _combination_ of values. These values are written in set notation, one per line. E.g.: - loginID = {Valid loginID, invalid loginID, valid email, invalid @@ -156,7 +157,7 @@ E.g., "logged in", "guest login allowed", ::List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case -should be performed once for each *combination* of values. These +should be performed once for each _combination_ of values. These values are written in set notation, one per line. E.g.: - ::loginID = {Valid loginID, invalid loginID, valid email, invalid @@ -202,7 +203,7 @@ E.g., "logged in", "guest login allowed", ::List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case -should be performed once for each *combination* of values. These +should be performed once for each _combination_ of values. These values are written in set notation, one per line. E.g.: - ::loginID = {Valid loginID, invalid loginID, valid email, invalid @@ -248,7 +249,7 @@ E.g., "logged in", "guest login allowed", ::List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case -should be performed once for each *combination* of values. These +should be performed once for each _combination_ of values. These values are written in set notation, one per line. E.g.: - ::loginID = {Valid loginID, invalid loginID, valid email, invalid @@ -294,7 +295,7 @@ E.g., "logged in", "guest login allowed", ::List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case -should be performed once for each *combination* of values. These +should be performed once for each _combination_ of values. These values are written in set notation, one per line. E.g.: - ::loginID = {Valid loginID, invalid loginID, valid email, invalid @@ -339,7 +340,7 @@ E.g., "logged in", "guest login allowed", ::List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case -should be performed once for each *combination* of values. These +should be performed once for each _combination_ of values. These values are written in set notation, one per line. E.g.: - ::loginID = {Valid loginID, invalid loginID, valid email, invalid diff --git a/Test-Run-Suite.md b/Test-Run-Suite.md index 9084128..57f4394 100644 --- a/Test-Run-Suite.md +++ b/Test-Run-Suite.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -23,34 +24,34 @@ have been tested and those that have not. Clearly understanding the degree to which the system has been tested helps to assess progress, assess risk, and focus ongoing testing efforts. -*TODO:* +_TODO:_ -- *Review the [target audience](Target-and-Benefits), +- _Review the [target audience](Target-and-Benefits), [environmental requirements](SRS#environmental), and [possible deployments](Design-Architecture#deployment) to understand the - set of possible system configurations that could be tested.* -- *Use a table or list to describe that set of possible configurations. - Mark each possibility with Pending, N/A, or Waived.* -- *Track each test run with an issue in the issue tracker or an item in - the [test-runs](Test-Runs) document.* -- *Periodically review the set of possible system configurations to - identify any additional needed test runs.* + set of possible system configurations that could be tested._ +- _Use a table or list to describe that set of possible configurations. + Mark each possibility with Pending, N/A, or Waived._ +- _Track each test run with an issue in the issue tracker or an item in + the [test-runs](Test-Runs) document._ +- _Periodically review the set of possible system configurations to + identify any additional needed test runs._ ### ::Test Runs by Operating System and Browser -| OS \ Browser | IE | Firefox | Safari | Chrome | other | -|----------------|------------------------------------------|----------------------------------|----------------------------------|-----------|---------| -| ::Windows | ::[Passed](Test-Runs#TR-01) | ::[Passed](Test-Runs#TR-02) | ::N/A | ::Pending | ::N/A | -| ::Linux | ::N/A | ::[Passed](Test-Runs#TR-03) | ::Pending | ::Pending | ::N/A | -| ::Mac | ::[FAILED](Test-Runs#TR-10) | ::Pending | ::[Passed](Test-Runs#TR-11) | ::Pending | ::N/A | -| ::iOS | ::N/A | ::N/A | ::Pending | ::N/A | ::N/A | -| ::Android | ::N/A | ::N/A | ::Pending | ::Pending | ::N/A | +| OS \ Browser | IE | Firefox | Safari | Chrome | other | +| ------------ | --------------------------- | --------------------------- | --------------------------- | --------- | ----- | +| ::Windows | ::[Passed](Test-Runs#TR-01) | ::[Passed](Test-Runs#TR-02) | ::N/A | ::Pending | ::N/A | +| ::Linux | ::N/A | ::[Passed](Test-Runs#TR-03) | ::Pending | ::Pending | ::N/A | +| ::Mac | ::[FAILED](Test-Runs#TR-10) | ::Pending | ::[Passed](Test-Runs#TR-11) | ::Pending | ::N/A | +| ::iOS | ::N/A | ::N/A | ::Pending | ::N/A | ::N/A | +| ::Android | ::N/A | ::N/A | ::Pending | ::Pending | ::N/A | ### ::Test Runs by Locale -*TIP: Use this outline to guide the testing of internationalized +_TIP: Use this outline to guide the testing of internationalized applications. Each locale indicates a native language as well as formats -for presenting money, dates, times, etc.* +for presenting money, dates, times, etc._ - ::English US: [Passed](Test-Runs#TR-00) - ::English UK: [Passed](Test-Runs#TR-01) @@ -64,10 +65,10 @@ for presenting money, dates, times, etc.* ### ::Test Runs by Hardware Configuration -*TIP: Use this outline for products that depend on specific hardware. +_TIP: Use this outline for products that depend on specific hardware. E.g., a disk crash recovery product would depend on the type of drive, a game might depend on processor speed and graphics cards, other products -might depend on memory or other hardware specs.* +might depend on memory or other hardware specs._ - ::PCs - ::IDE drive: Pending diff --git a/Test-Runs.md b/Test-Runs.md index 8824b4c..7d184ec 100644 --- a/Test-Runs.md +++ b/Test-Runs.md @@ -1,4 +1,5 @@ -##### Project +##### Project + ::[PROJECT-NAME](Home) ##### Internal Release Number @@ -14,8 +15,8 @@ --- -*TODO: Use this file to record the results of each test run. Or, use your -issue tracking tool to plan and track test runs.* +_TODO: Use this file to record the results of each test run. Or, use your +issue tracking tool to plan and track test runs._ ### TR-00: Test Run diff --git a/Test-Suite.md b/Test-Suite.md index 5415850..5bfcff9 100644 --- a/Test-Suite.md +++ b/Test-Suite.md @@ -1,5 +1,6 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -24,51 +25,51 @@ Organizing the suite of test cases by priority, functional area, actor, business object, or release can help identify parts of the system that need additional test cases. -*TODO: Before writing individual test cases, list the test cases that you +_TODO: Before writing individual test cases, list the test cases that you think you will need. Organize them in a way that will purposely leave visible blanks on this page if you are missing use cases. Choose one or -more of the organizations show below.* +more of the organizations show below._ -*TIP: Refer back to your [use cases](Use-Cases) document. Use them +_TIP: Refer back to your [use cases](Use-Cases) document. Use them for ideas and make sure that you cover all of them. Remember that test cases are more precise than use cases, test cases should reference specific details of your implementation, and there may be several test -cases for a given use case.* +cases for a given use case._ -*TIP: The test case suite can be organized into nested lists according to +_TIP: The test case suite can be organized into nested lists according to other coverage criteria, e.g., by actor. Or, it can be organized into tables that consider two aspects at a time, e.g., business objects vs. actor. If a certain section of the tree or table does not need test cases, explicitly mark it "N/A". Otherwise, if a section needs more test cases than you have written yet, mark it "TODO". If one cell or list item contains many tests, break that section out into its own table, as -done for the enrollment feature below.* +done for the enrollment feature below._ ### Test Cases by Business Object and Operation -| BO \ Action | ::add | ::list/browse | ::edit | ::delete | ::search | ::other | -|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------| -| ::Student |
  • ::[student-add-1](Test-Cases#student-add-1)
  • ::[student-add-2](Test-Cases#student-add-2)
  • ::[student-add-3](Test-Cases#student-add-3)
| ::[student-list-1](Test-Cases#student-list-1) |
  • ::[student-edit-1](Test-Cases#student-edit-1)
  • ::[student-edit-2](Test-Cases#student-edit-2)
| ::[student-delete-1](test-casesstudent-delete-1) |
  • ::[student-search-1](Test-Cases#student-search-1)
  • ::[student-search-2](Test-Cases#student-search-2)
| ::[See grid below](#enroll-grid) | -| ::Course |
  • ::[course-add-1](Test-Cases#course-add-1)
  • ::[course-add-2](Test-Cases#course-add-2)
| ::[course-list-1](Test-Cases#course-list-1) |
  • ::[course-edit-1](Test-Cases#course-edit-1)
  • ::[course-move-1](Test-Cases#course-move-1)
  • ::[course-add-prereq-1](Test-Cases#course-add-prereq-1)
| ::[course-cancel-1](Test-Cases#course-cancel-1) | ::[course-search-1](Test-Cases#course-search-1) | ::N/A | -| ::Room |
  • ::[room-add-1](Test-Cases#room-add-1)
  • ::[room-add-2](Test-Cases#room-add-2)
| ::[room-list-1](Test-Cases#room-list-1) | ::TODO | ::TODO | ::TODO | ::N/A | -| ::Instructor | ::[inst-add-1](Test-Cases#inst-add-1) | ::N/A | ::[inst-edit-1](Test-Cases#inst-edit-1) | ::[inst-delete-1](Test-Cases#inst-delete-1) | ::N/A |
  • ::[inst-eval-1](Test-Cases#inst-eval-1)
  • ::[inst-eval-2](Test-Cases#inst-eval-2)
| +| BO \ Action | ::add | ::list/browse | ::edit | ::delete | ::search | ::other | +| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | +| ::Student |
  • ::[student-add-1](Test-Cases#student-add-1)
  • ::[student-add-2](Test-Cases#student-add-2)
  • ::[student-add-3](Test-Cases#student-add-3)
| ::[student-list-1](Test-Cases#student-list-1) |
  • ::[student-edit-1](Test-Cases#student-edit-1)
  • ::[student-edit-2](Test-Cases#student-edit-2)
| ::[student-delete-1](test-casesstudent-delete-1) |
  • ::[student-search-1](Test-Cases#student-search-1)
  • ::[student-search-2](Test-Cases#student-search-2)
| ::[See grid below](#enroll-grid) | +| ::Course |
  • ::[course-add-1](Test-Cases#course-add-1)
  • ::[course-add-2](Test-Cases#course-add-2)
| ::[course-list-1](Test-Cases#course-list-1) |
  • ::[course-edit-1](Test-Cases#course-edit-1)
  • ::[course-move-1](Test-Cases#course-move-1)
  • ::[course-add-prereq-1](Test-Cases#course-add-prereq-1)
| ::[course-cancel-1](Test-Cases#course-cancel-1) | ::[course-search-1](Test-Cases#course-search-1) | ::N/A | +| ::Room |
  • ::[room-add-1](Test-Cases#room-add-1)
  • ::[room-add-2](Test-Cases#room-add-2)
| ::[room-list-1](Test-Cases#room-list-1) | ::TODO | ::TODO | ::TODO | ::N/A | +| ::Instructor | ::[inst-add-1](Test-Cases#inst-add-1) | ::N/A | ::[inst-edit-1](Test-Cases#inst-edit-1) | ::[inst-delete-1](Test-Cases#inst-delete-1) | ::N/A |
  • ::[inst-eval-1](Test-Cases#inst-eval-1)
  • ::[inst-eval-2](Test-Cases#inst-eval-2)
| ### ::Test Cases for Enrolling in Courses | ::Course \ Student | ::New Freshman | ::Senior | ::Any Honors | ::Other | -|--------------------|-----------------------------------------------------|-----------------------------------------------------|-----------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------| +| ------------------ | --------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | ::In Major | [::enroll-priority-2](Test-Cases#enroll-priority-2) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) |
  • [::enroll-1](Test-Cases#enroll-1)
  • [::enroll-2](Test-Cases#enroll-2)
  • [::enroll-3](Test-Cases#enroll-3)
| | ::Non-Major | [::enroll-priority-2](Test-Cases#enroll-priority-2) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) |
  • [::enroll-1](Test-Cases#enroll-1)
  • [::enroll-2](Test-Cases#enroll-2)
  • [::enroll-3](Test-Cases#enroll-3)
| | ::Honors Course | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-restricted-1](Test-Cases#enroll-restricted-1) | ### Test Cases by Feature Priority -*TODO: Use this outline to make sure that high priority features are +_TODO: Use this outline to make sure that high priority features are adequately tested. List features by priority, and then list the test cases for each feature. If a feature needs more test cases, note that -with "TODO".* +with "TODO"._ - Essential - ::[F-01](features#F-01): @@ -97,10 +98,10 @@ with "TODO".* ### Test Cases by Use Case Priority -*TODO: Use this outline to make sure that high priority use cases are +_TODO: Use this outline to make sure that high priority use cases are adequately tested. List use cases by priority, and then list the test cases for each use case. If a use case needs more test cases, note that -with "TODO".* +with "TODO"._ - Essential - ::[UC-01](Use-Cases#UC-01) diff --git a/Use-Case-Format.md b/Use-Case-Format.md index c4294f7..9f3119b 100644 --- a/Use-Case-Format.md +++ b/Use-Case-Format.md @@ -1,4 +1,5 @@ - + + ##### Related Documents - [SRS](SRS) > [Use Case Suite](Use-Case-Suite) > Use Case Format @@ -10,9 +11,9 @@ cases and gives tips on writing use cases. You can copy and paste the sample use case into your [Use Cases](Use-Cases) document. This file itself should not be edited to hold specific use cases. -*TODO: Use this template once in your [Use Cases](Use-Cases) +_TODO: Use this template once in your [Use Cases](Use-Cases) document. Anything you mention here will apply to all use cases in that -file.* +file._ --- @@ -31,9 +32,9 @@ file.* **Prerequisite:** ::Project is set up -*TODO: Copy and paste this use case template as many times as needed in +_TODO: Copy and paste this use case template as many times as needed in your [Use Cases](Use-Cases) document. Only use those fields that -are not the same as the default for all use cases.* +are not the same as the default for all use cases._ --- @@ -74,6 +75,7 @@ are not the same as the default for all use cases.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. diff --git a/Use-Case-Suite.md b/Use-Case-Suite.md index 7d2b712..01891c8 100644 --- a/Use-Case-Suite.md +++ b/Use-Case-Suite.md @@ -1,5 +1,6 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -26,22 +27,22 @@ of use cases by priority, functional area, actor, business object, or release can help identify parts of the system that need additional use cases. -*TODO: Before writing individual use cases, list the use cases that you +_TODO: Before writing individual use cases, list the use cases that you think you will need. Organize them in a way that will purposely leave visible blanks on this page if you are missing use cases. E.g., see "Scalability and availability". Choose one or more of the organizations -show below.* +show below._ -*TIP: Refer back to the user stories in your [user needs](User-Needs) +_TIP: Refer back to the user stories in your [user needs](User-Needs) document. Use them for ideas and make sure that you cover all of them. Remember that use cases are more precise than user stories, and there -may be several use cases for a given user story.* +may be several use cases for a given user story._ -*TIP: The use case suite can be organized into nested lists according to +_TIP: The use case suite can be organized into nested lists according to other coverage criteria, e.g., by actor. Or, it can be organized into tables that consider two aspects at a time, e.g., business objects vs. actor. If a certain section of the tree or table does not need use -cases, explicitly mark it "N/A". Otherwise, mark it "TODO".* +cases, explicitly mark it "N/A". Otherwise, mark it "TODO"._ ### Use Cases by Functional Area @@ -140,8 +141,8 @@ more noticeable. -| BO \ Actor | All | ::Student | ::Instructor | ::Admin | -|--------------------------------|-----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------|-----------------------------------------------------------------------------------------------| -| ::Student record | ::N/A |
  • ::[Register as new user](Use-Cases#uc-01)
  • ::[Request new password](Use-Cases#uc-02)
  • ::[Edit user profile](Use-Cases#uc-03)
| ::[View user profile](Use-Cases#uc-04) | ::N/A | -| ::Course | ::[View catalog description](Use-Cases#uc-11) |
  • ::[Enroll in course](Use-Cases#uc-20)
  • ::[Drop course](Use-Cases#uc-21)
| ::TODO |
  • ::[Create course](Use-Cases#uc-10)
  • ::[Assign room](Use-Cases#uc-31)
| -| ::Room | ::[View room description](Use-Cases#uc-30) | ::N/A | ::N/A | ::[Assign room](Use-Cases#uc-31) | +| BO \ Actor | All | ::Student | ::Instructor | ::Admin | +| ---------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------- | --------------------------------------------------------------------------------------------- | +| ::Student record | ::N/A |
  • ::[Register as new user](Use-Cases#uc-01)
  • ::[Request new password](Use-Cases#uc-02)
  • ::[Edit user profile](Use-Cases#uc-03)
| ::[View user profile](Use-Cases#uc-04) | ::N/A | +| ::Course | ::[View catalog description](Use-Cases#uc-11) |
  • ::[Enroll in course](Use-Cases#uc-20)
  • ::[Drop course](Use-Cases#uc-21)
| ::TODO |
  • ::[Create course](Use-Cases#uc-10)
  • ::[Assign room](Use-Cases#uc-31)
| +| ::Room | ::[View room description](Use-Cases#uc-30) | ::N/A | ::N/A | ::[Assign room](Use-Cases#uc-31) | diff --git a/Use-Cases.md b/Use-Cases.md index 102e9b5..59b4a09 100644 --- a/Use-Cases.md +++ b/Use-Cases.md @@ -1,4 +1,5 @@ - + + ##### Project ::PROJECT-NAME @@ -18,9 +19,9 @@ --- -*TODO: Note any aspects that are common to all use cases here. This helps +_TODO: Note any aspects that are common to all use cases here. This helps keep the use cases themselves short. If any use case is an exception, -note it's specific value to replace or add to the default.* +note it's specific value to replace or add to the default._ ### Default Aspects of All Use Cases @@ -39,17 +40,17 @@ note it's specific value to replace or add to the default.* ::User is logged in -*TODO: For each use case listed in the [use case +_TODO: For each use case listed in the [use case suite](Use-Case-Suite), create an HTML anchor and heading with it's unique ID, then fill in the rows of the table to specify the use case in -detail.* +detail._ -*TIP: It is OK to simply list the names of a lot of use cases without +_TIP: It is OK to simply list the names of a lot of use cases without actually writing the use case in detail. Document the most important use -cases first and come back to less important ones later.* +cases first and come back to less important ones later._ -*TIP: See detailed tips in the -[guidelines for writing use cases](Use-Case-Format#further-information).* +_TIP: See detailed tips in the +[guidelines for writing use cases](Use-Case-Format#further-information)._ --- @@ -88,7 +89,7 @@ cases first and come back to less important ones later.* - ::How will administrators know the right timezone abbreviation? - They would know it if they live in that timezone. Maybe we could - provide a drop-down list of all choices, but each would need some explanation. + provide a drop-down list of all choices, but each would need some explanation. --- @@ -390,6 +391,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -441,6 +443,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -492,6 +495,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -543,6 +547,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -594,6 +599,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -645,6 +651,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -696,6 +703,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -747,6 +755,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -798,6 +807,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -849,6 +859,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -900,6 +911,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -951,6 +963,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -1002,6 +1015,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -1053,6 +1067,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -1104,6 +1119,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -1155,6 +1171,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. @@ -1206,6 +1223,7 @@ cases first and come back to less important ones later.* **Alternative Scenario Extensions:** - ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. - ::If CONDITION, then ALTERNATIVE STEPS. diff --git a/User-Guide.md b/User-Guide.md index 02b0f78..13a9c21 100644 --- a/User-Guide.md +++ b/User-Guide.md @@ -1,7 +1,8 @@ - -*TODO: Fill in information on this product. Make sure to use the + + +_TODO: Fill in information on this product. Make sure to use the **product** name and **external** release number, not internal -information.* +information._ ##### Product @@ -25,11 +26,11 @@ us at ### Table of Contents -*TODO: Fill in the user guide outline below.* +_TODO: Fill in the user guide outline below._ -*TIP: Consider providing both tutorial (step-by-step) and reference +_TIP: Consider providing both tutorial (step-by-step) and reference material. You can organize the user guide by features, by use cases, by -roles, or in other ways.* +roles, or in other ways._ 1. Introduction - ::What is PRODUCT-NAME? diff --git a/User-Needs.md b/User-Needs.md index b50b598..9c59dec 100644 --- a/User-Needs.md +++ b/User-Needs.md @@ -1,4 +1,5 @@ - + + ##### Project ::[PROJECT-NAME](Home) @@ -17,20 +18,20 @@ **Process impact:** The statement of user needs documents and explains the actual desires of stakeholders in roughly their own words. What they -*desire* is never exactly what the product *provides*. Documenting user +_desire_ is never exactly what the product _provides_. Documenting user needs here, independently from the [SRS](SRS), helps to keep the SRS precise and makes the tasks of verification and validation more -effective. This document is *not* an informal draft of the SRS, it is +effective. This document is _not_ an informal draft of the SRS, it is different document with a complementary purpose. ### Agreed Goals -*TODO: Has there been a clear statement of the overall goal of this +_TODO: Has there been a clear statement of the overall goal of this project that the stakeholders agree to? If so, paste it here or add a hyperlink. If not, you should summarize your understanding of the project goals into a brief statement and try to get the stakeholders to agree to it. The text below gives three alternative examples, select -one, or write your own.* +one, or write your own._ ::We were given an [initial project description](LINK) that is agreed to by all stakeholders. @@ -44,10 +45,10 @@ will be hyper-linked from here. ### Environment -*TODO: Briefly describe various aspects of the environment where the +_TODO: Briefly describe various aspects of the environment where the software will be used. Describe the environment as it \*is\* or \*will be\*, not what you would wish it to become. The text below gives a few -examples.* +examples._ #### What is the system's business environment? @@ -70,10 +71,10 @@ co-located data center with 24x7 monitoring, UPS, air-conditioning, etc. Users of this system are typically at their offices. -:: This application runs on hand-held devices that will often be used - while the user is walking from one section of the warehouse - to another. Lighting is good in that environment, but there are many - noises and distractions. +:: This application runs on hand-held devices that will often be used +while the user is walking from one section of the warehouse +to another. Lighting is good in that environment, but there are many +noises and distractions. #### What is the system's technology environment (hardware and software)? @@ -87,25 +88,25 @@ monitors or laptops with 1024x768 resolution are also common. ### Stakeholders / Actors -*TODO: List and describe the stakeholders for this product. These can be +_TODO: List and describe the stakeholders for this product. These can be named individuals or roles that people play. For each stakeholder, list/rank their key needs. Consider the expected technical expertise of the stakeholders and how often they are likely to use the system, as well as key strengths, weaknesses, preferences, or other characteristics. Use a greater-than sign to indicate inheritance among -types of actors.* +types of actors._ -*TIP: To get information on types of users, you can talk to actual users. +_TIP: To get information on types of users, you can talk to actual users. You may also want to talk to user surrogates (people who work with users), such as domain experts, technical trainers, technical support staff, technical writers, supervisors of users, and your own sales and marketing department. You can find clues in manuals and marketing -materials for competing products.* +materials for competing products._ #### ::All -:: All stakeholders share the following key needs: - +:: All stakeholders share the following key needs: + 1. ::Security against abuses by other site visitors 2. ::Convenient access to the site any time over the Internet @@ -120,7 +121,7 @@ users and have high expectations for the functionality and quality of the site, but they may not have much knowledge of computer science. -:: Key needs: +:: Key needs: 1. ::Easily find information about clans 2. ::Keep in touch with members of his/her own clan @@ -148,16 +149,16 @@ more of the game details, now the need to see the "big picture". ::PARAGRAPH #### ::STAKEHOLDER3 - + ::PARAGRAPH ### Notes from Interviews and Brainstorming -*TODO: Keep a log of your requirements gathering. Paste in notes from any +_TODO: Keep a log of your requirements gathering. Paste in notes from any face-to-face or telephone conversations with stakeholders or from brainstorming sessions with members of the development team. If the communication took place via email, link to it in the archive or paste -it here.* +it here._ #### ::DATE, INTERVIEWEE @@ -181,13 +182,13 @@ it here.* ### User Stories -*TODO: Write brief user stories to explain how various actors would +_TODO: Write brief user stories to explain how various actors would interact with the system (directly and indirectly) to accomplish a real-world goal. User stories are \*not\* use cases: user stories are brief (3-5 sentences) paragraphs that describe one specific scenario in concrete terms. In this description of user needs, do not make assumptions about details of the system, instead focus on the users. -Note the source of each user story.* +Note the source of each user story._ #### ::invited-to-join @@ -219,9 +220,9 @@ clan website to find that information. (Source: PERSON-NAME) ### Performance and Capacity Needs -*TODO: Briefly list the stakeholders' desired values for various aspects +_TODO: Briefly list the stakeholders' desired values for various aspects of the system capacity. If you have a good idea about averages or rates -of increase, note that as well.* +of increase, note that as well._ ::By the end of the first year of service, we should to reach the following system capacity: diff --git a/Workflows.md b/Workflows.md index c69ca39..fd8080d 100644 --- a/Workflows.md +++ b/Workflows.md @@ -1,4 +1,5 @@ - + + ### By Activity 1. Project Planning diff --git a/_Footer.md b/_Footer.md index be2d683..e967090 100644 --- a/_Footer.md +++ b/_Footer.md @@ -1,4 +1,4 @@ - + **TODO:** Check for [words of wisdom](Words-of-Wisdom) for additional advice on this template. ::**Your-Organization Proprietary** diff --git a/_Sidebar.md b/_Sidebar.md index d286832..880e5d1 100644 --- a/_Sidebar.md +++ b/_Sidebar.md @@ -1,6 +1,6 @@ - -* [Home](Home) -* [Summary](Summary) -* [Project Plan](Project-Plan) -* [Workflows](Workflows) -* [Words of Wisdom](Words-of-Wisdom) + +- [Home](Home) +- [Summary](Summary) +- [Project Plan](Project-Plan) +- [Workflows](Workflows) +- [Words of Wisdom](Words-of-Wisdom) From cda2dd8a2a58c6c2721b2dd7e9ae645e1b3ac5bb Mon Sep 17 00:00:00 2001 From: William Sandner Date: Fri, 24 Mar 2023 18:01:43 +0100 Subject: [PATCH 2/5] Fix link to std terms glossary --- Glossary.md | 45 +++++++++++++++++++++++---------------------- Home.md | 4 +--- 2 files changed, 24 insertions(+), 25 deletions(-) diff --git a/Glossary.md b/Glossary.md index db480e5..e22a591 100644 --- a/Glossary.md +++ b/Glossary.md @@ -1,18 +1,19 @@ - **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) + +[Standard terms](Glossary-Standard-Terms) -### Project-specific Terms +## Project-specific Terms _TIPs:_ @@ -34,13 +35,13 @@ _TIPs:_ and key attributes. For example, see [student](#student) and [GPA](#gpa)._ -#### A +### A -#### B +### B -#### C +### C -##### ::Class standing +#### ::Class standing - ::Computed attribute of [student](#student) based on number of academic units completed. Used to determine priority in @@ -54,16 +55,16 @@ _TIPs:_ | ::Junior | ::Between 180 and 270 units | | ::Senior | ::More than 270 units completed | -#### D +### D -#### G +### G -##### ::GEF +#### ::GEF ::_n._ The [Graph Editing Framework](http://gef.tigris.org/). An open source library for editing diagrams (boxes and arrows). -##### ::GPA +#### ::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 @@ -71,45 +72,45 @@ course grades in transcript weighted by course units. Used to determine student ranking, and to trigger Dean's List and academic probation. -#### I +### I -##### ::ICS +#### ::ICS ::_n._ Acronym for the [School of Information and Computer Science](http://www.ics.uci.edu/) at [UC Irvine](http://www.uci.edu/). -#### S +### S -##### ::Student +#### ::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 +#### ::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 +### T -##### ::Term1D-DIAGRAM +#### ::Term1D-DIAGRAM ::Definition1 -##### ::Term2 +#### ::Term2 - ::Definition2a - ::Definition2b -##### ::Term3 +#### ::Term3 ::Definition3 -#### U +### U -##### ::Undergraduate +#### ::Undergraduate ::A type of [student](#student). _TODO: add more detail._ diff --git a/Home.md b/Home.md index 0f6eb21..fb3e6d4 100644 --- a/Home.md +++ b/Home.md @@ -1,11 +1,9 @@ - ## Project Overview ### Mission and Scope - _TODO: Answer these questions in your own words by filling in each_ #### What problem does this project address? @@ -22,7 +20,7 @@ _TODO: Answer these questions in your own words by filling in each_ #### What development methodology is being used? -::See our [software development methodology](sdm) document. +::See our [software development methodology](SDM) document. #### Where should a new team member start? From efba347d628e3f8eb58d1b62d314fde178d1ddb1 Mon Sep 17 00:00:00 2001 From: William Sandner Date: Fri, 24 Mar 2023 18:26:30 +0100 Subject: [PATCH 3/5] Adjust headers --- Glossary-Standard-Terms.md | 231 +++++++++++++++++-------------------- 1 file changed, 103 insertions(+), 128 deletions(-) diff --git a/Glossary-Standard-Terms.md b/Glossary-Standard-Terms.md index 403ccc5..d15a88e 100644 --- a/Glossary-Standard-Terms.md +++ b/Glossary-Standard-Terms.md @@ -9,9 +9,9 @@ updates. Jump to: [General](#general-terms) | [Computer science & technology](#computer-science-and-technology-terms) | [Process](#process-terms) | [Software development tools](#development-tool-terms) | [Requirements](#requirements-terms) | [Design](#design-terms) | [Design goals terms](#desigD-DIAGRAMn-goals-terms) | [QA terms](#qa-terms) | [QA goals terms](#qa-goals-terms) | [Additional terms](#additional-standard-terms)| [Project terms](Glossary) -### General Terms +## General Terms -#### Chipping away +### Chipping away The process of removing sample text from templates when that text does not apply to the current project. Often some of the sample text @@ -23,26 +23,25 @@ he carved a marble statue of a horse, he replies "It was easy, I just started with a big block of marble and chipped away everything that did not look like a horse." -##### Attached worksheetD-DIAGRAM +### Attached worksheet -The idea is similar to fillD-DIAGRAMing in an IRS form and using worksheets -to calculate subtotals or mD-DIAGRAMake specific decisions. That is to say, -there is a hierarchy to theD-DIAGRAM templates: there are the main templates, -and then worksheets for speD-DIAGRAMcific topics. We have divided the -information into several fiD-DIAGRAMles so that each file is focused on one -topic, and so that each filD-DIAGRAMe can be worked on by one person in a -reasonable amount of time.D-DIAGRAM -D-DIAGRAM +The idea is similar to filling in an IRS form and using worksheets +to calculate subtotals or make specific decisions. That is to say, +there is a hierarchy to the templates: there are the main templates, +and then worksheets for specific topics. We have divided the +information into several files so that each file is focused on one +topic, and so that each file can be worked on by one person in a +reasonable amount of time. -##### Process impactD-DIAGRAM +### Process impact -The process impact box on eD-DIAGRAMach template explains where the current -template fits into the softD-DIAGRAMware development process. It usually +The process impact box on each template explains where the current +template fits into the software development process. It usually includes a brief comment on who should create the document, and who would be expected to make use of it. You can change the process impact box, but you should not need to. -##### Checklist +### Checklist There are two kinds of checklists: @@ -53,7 +52,7 @@ There are two kinds of checklists: guidelines and checklists that help you identify common errors in those artifacts. -##### Sticky note +### Sticky note The idea is similar to a post-it note attached to a document that tells you do "sign here" or fill in a certain part. There are two @@ -72,25 +71,25 @@ types of sticky notes: After you have done what the sticky note says, you can delete the sticky note. -### Computer Science and Technology Terms +## Computer Science and Technology Terms -##### ::API (Application Programming Interface) +### ::API (Application Programming Interface) An API is a set of functions that one software component makes available to other software components. That allows other programs to "call" this program via direct function calls, or more indirect communications such as [SOAP](#soap) messages. -##### ::SOAP +### ::SOAP SOAP (Simple Object Access Protocol) is the message format used by standard web services. It entails sending an XML document to a server in order to invoke an operation on the server-side. [More information on SOAP](http://directory.google.com/Top/Computers/Programming/Internet/Web_Services/SOAP/?tc=1). -### Process Terms +## Process Terms -##### Change Control Board (CCB) +### Change Control Board (CCB) A group of people who review proposed changes toD-DIAGRAM the project requirements and/or source code to accept or reject changes in each @@ -100,7 +99,7 @@ the need to redo a lot of testing on new code). A CCB is usually composed of managers and representatives of other stakeholders such as the QA group and key customers. -##### Feature Complete +### Feature Complete A release is called "feature complete" when the development team agrees that no new features will be added to this release. New @@ -108,7 +107,7 @@ features may still be suggested for later releases. More development work needs to be done to implement all the features and repair defects. -##### Code Complete +### Code Complete A release is called "code complete" when the development team agrees that no entirely new source code will be added to this release. @@ -117,14 +116,14 @@ still be changes to documentation and data files, and to the code for test cases or utilities. New code may be added in a future release. -##### Internal Release Number +### Internal Release Number An internal release number is the number that the development team gives each release. Internal release numbers typically count up logically, i.e., they do not skip numbers. They may have many parts: e.g., major, minor, patch-level, build number, RC number. -##### External Release Number +### External Release Number External release numbers are the numbers that users see. Often, they will be the same as the internal release number. That is especially @@ -137,49 +136,49 @@ of their client software because their competition had released version 8. Later, the competition used version "10 Optimized" rather than "10.1" or "11". -##### Release Number +### Release Number The term "release number" by itself refers to an [external release number](#external_release_number). Users normally are not aware of the existence of any internal release numbers. -### Development Tool Terms +## Development Tool Terms -#### Version Control System +### Version Control System ::DEFINITION1 -#### Commit Log Message +### Commit Log Message ::DEFINITION1 -#### Issue Tracker +### Issue Tracker ::DEFINITION1 -#### Unit Testing Automation +### Unit Testing Automation ::DEFINITION1 -#### Automated Build System +### Automated Build System ::DEFINITION1 -#### Style Checker +### Style Checker ::DEFINITION1 -#### Source Code Formatter (Pretty Printer) +### Source Code Formatter (Pretty Printer) ::DEFINITION1 -#### System Test Automation +### System Test Automation ::DEFINITION1 -### Requirements Terms +## Requirements Terms -#### Feature specification +### Feature specification A feature specification focuses on one feature of a software product and completely describes how that feature can be used. It includes a @@ -188,7 +187,7 @@ output, and any constraints. Individual bullet items give precise details on all aspects of the feature. One feature may be used in many different ways as part of many different use cases. -#### Use case +### Use case The main part of a use case is a set of steps that give an example of how an [actor](#actor) can use the product to succeed at @@ -196,144 +195,144 @@ a goal. These steps are called the "Main success scenario", and they include both user intentions and system responses. One use case may show how the actor uses several features to accomplish a goal. -#### Actor +### Actor A user or an external system that uses the system being built. -### Design Terms +## Design Terms -#### ::TERM2 +### ::TERM2 ::DEFINITION2 -### Design Goals Terms +## Design Goals Terms -#### Correctness +### Correctness This design correctly matches the given requirements. -#### Feasibility +### Feasibility This design can be implemented and tested with the planned amount of time and effort. -#### Understandability +### Understandability Developers can understand this design and correctly implement it. -#### Implementation phase guidance +### Implementation phase guidance This design divides the implementation into components or aspects that can correspond to reasonable implementation tasks. -#### Modularity +### Modularity Concerns are clearly separated so that the impact of most design changes would be limited to only one or a few modules. -#### Extensibility +### Extensibility New features or components can be easily added later. -#### Testability +### Testability It is easy to test components of this design independently, and information is available to help diagnose defects. -#### Efficiency +### Efficiency The design enables the system to perform functions with an acceptable amount of time, storage space, bandwidth, and other resources. -#### Ease of integration +### Ease of integration The components will work together. -#### Capacity matching +### Capacity matching The architecture deploys components onto machines that provide needed resources with reasonable total expense. -#### Expressiveness +### Expressiveness It allows for storage of all valid values and relationships -#### Ease of access +### Ease of access Application code to access stored data is simple -#### Reliability +### Reliability Stored data cannot easily be corrupted by defective code, concurrent access, or unexpected process termination -#### Data capacity +### Data capacity The system can store the amount of data needed. -#### Data security +### Data security Protection of sensitive user and corporate data from unauthorized access or modification -#### Performance +### Performance Data can be accessed quickly -#### Interoperability +### Interoperability The database or data files can be accessed and updated by other applications -#### Intrusion prevention +### Intrusion prevention Prevent, e.g., hackers opening a command shell on our server. -#### Abuse prevention +### Abuse prevention Prevention of abuse (e.g., using our system to send spam). -#### Auditability +### Auditability All changes can be accounted for later. -#### Understandability and learnability +### Understandability and learnability Users can reasonably be expected to understand the UI at first sight. Users will be able to discover additional features without aid from other users or documentation, and they will be able to recall what they have learned. -#### Task support and efficiency +### Task support and efficiency The UI is well matched to the users' tasks and it can be used with a reasonable number of clicks and keystrokes. -#### Safety +### Safety Users are not likely to accidentally produce an undesired result (e.g., delete data, or send a half-finished email). -#### Consistency and familiarity +### Consistency and familiarity Users can apply their knowledge of similar UIs or UI standards to this system. -### QA Terms +## QA Terms -#### Bug +### Bug _n._ **Deprecated** since 1991. See [defect](#defect). -#### Error +### Error _v._ A mistaken thought in the developer's mind. Often caused by miscommunication or bad assumptions. Errors can create [defects](#defect). E.g., a developer might erroneously think that the square root of -4 is -2. -#### Defect +### Defect _n._ The result of the developer's [error](#error) embodied in the product source code, initial data, or documents. E.g., a square root @@ -341,7 +340,7 @@ function which allows negative numbers as arguments is defective. Defects can be removed by changing the source code, initial data, or document. -#### Fault +### Fault _n._ The execution of defective code. E.g., if a certain input is provided to defective code, it may cause an exception, or go into an @@ -349,42 +348,42 @@ infinite loop, or store an incorrect value in an internal variable. A fault is not normally visible to users, only the [failure](#failure) is visible. -#### Failure +### Failure _n._ The user-visible result of a [fault](#fault). E.g., an error message or an incorrect result. This is evidence that can be reported in a defect report. Developers use failure evidence during debugging to eventually find and remove [defects](#defect). -### QA Goals Terms +## QA Goals Terms -#### Functionality > Correctness +### Functionality > Correctness Correctness is the most basic quality goal. It means that, when valid inputs are given and the system is in a valid state and under reasonable load, the system's behavior and results will be correct. -#### Functionality > Robustness +### Functionality > Robustness Robustness is the system's ability to gracefully handle invalid inputs. It should never be possible for any user input to crash the system or corrupt data, even if that user input is abnormal, unexpected, or malicious. -#### Functionality > Accuracy +### Functionality > Accuracy Accuracy refers to the mathematical precision of calculations done by the system. Any system that does numeric calculations must consider accuracy, e.g., financial or scientific applications. -#### Functionality > Compatibility +### Functionality > Compatibility Systems that claim to follow standards or claim compatibility with existing systems must adhere to the relevant file formats, protocols, and APIs. The relevant standards are linked at the top of this document. -#### Functionality > Factual correctness +### Functionality > Factual correctness Is the data in the system a true representation of the real world? Any system that contains initial data or gathers data about the real @@ -393,7 +392,7 @@ D-DIAGRAM D-DIAGRAM D-DIAGRAM -#### Usability > Understandability and Readability +### Usability > Understandability and Readability Users need to understand the system to use it. The basic metaphor should be understandable and appropriate to user tasks. Some defects @@ -401,7 +400,7 @@ in understandability include unclear metaphors, poor or hard-to-see labels, lack of feedback to confirm the effects of user actions, and missing or inadequate on-line help. -#### Usability > Learnability and Memorability +### Usability > Learnability and Memorability Every user interface contains some details that users will need to learn and remember. E.g., Alt-F to open the "File" menu. UI cues and @@ -409,7 +408,7 @@ rules can make these details easier to learn and remember. E.g., the "F" is underlined and, as a rule, the first letter is usually the accelerator key. -#### Usability > Task support +### Usability > Task support This is the quality of match between user tasks and the system's UI. Task support defects are cases where the system forces the user to @@ -418,7 +417,7 @@ no support for a difficult step in a task. E.g., must the user invent an 8-character filename for their "Christmas card list"? E.g., must users total their own tax deductions? -#### Usability > Efficiency +### Usability > Efficiency Users should be able to accomplish common tasks with reasonable effort. Common tasks should be possible with only one or @@ -426,14 +425,14 @@ two steps. The difficulty of each step should also be considered. E.g., does the user have to remember a long code number or click on a very small button? -#### Usability > Safety +### Usability > Safety Humans are error-prone, but the negative effects of common errors should be limited. E.g., users should realize that a given command will delete data, and be asked to confirm their intent or have the option to undo. -#### Usability > Consistency and Familiarity +### Usability > Consistency and Familiarity Users should be able to apply their past experience from other similar systems. This means that user interface standards should be @@ -442,23 +441,16 @@ Also, UI elements that appear in several parts of the UI should be used consistently, unless another UI quality takes priority. E.g., if most currency entry fields do not require a dollar-sign, then one that does demand it is a consistency defect, unless there is a real -chance that the user is dealing with anoD-DIAGRAM -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM +chance that the user is dealing with another currency on that step in his/her task. -#### Usability > Subjective satisfactionD-DIAGRAM - -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM +### Usability > Subjective satisfaction Users should feel generally satisfied with the UI. This is a subjective quality that sums up the other user interface qualities as well as aesthetics. -#### Security +### Security The system should allow usage only by authorized users, and restrict usage based on permissions. The system should not allow users to @@ -466,48 +458,31 @@ side-step security rule or exploit security holes. E.g., all user input should be validated and any malicious input should be rejected. -#### Reliability > Consistency under load +### Reliability > Consistency under load -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM +Every system has some capacity limits. What happens when those +limits are exceeded? The system should never lose or corrupt data. -#### Reliability > Consistency under concurrency +### Reliability > Consistency under concurrency Systems that allow concurrent access by multiple users, or that use concurrency internally, should be free of race conditions and deadlock. -#### Reliability > Availability under load +### Reliability > Availability under load Every system has some capacity limits. What happens when those limits are exceeded? The system should continue to service those -requests that it is capable of handling. It should not crash or sD-DIAGRAM -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM +requests that it is capable of handling. It should not crash or stop processing all requests. -#### Reliability > Longevity +### Reliability > Longevity -The system should continue to operate as long as it is needed. ItD-DIAGRAM -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM -should not gradually use up a limited resource. Example longevityD-DIAGRAM -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM +The system should continue to operate as long as it is needed. It +should not gradually use up a limited resource. Example longevity defects include memory leaks or filling the disk with log files. -#### Efficiency - -The system's operations should execute quickly, with reasonable use -of machine and network resources. E.g., if one user does one -operation, it should execute efficiently. - -#### Scalability +### Scalability Scalability is a general quality that holds when the system continues to satisfy its requirements when various usage parameters @@ -515,13 +490,13 @@ are increased. E.g., a file server might be scalable to a high number of users, or to very large files or very high capacity disks. Several specific scalability goals are listed below. -#### Scalability > Performance under load +### Scalability > Performance under load This is a specific type of scalability goal dealing with the performance of the system at times when it is servicing many requests from many users. -#### Scalability > Large data volume +### Scalability > Large data volume This is a specific type of scalability goal dealing with the ability for the system to handle large data sets. Operations should continue @@ -529,7 +504,7 @@ to be correct and efficient as data set size increases. Furthermore, the user interface should still be usable as the data presented to users increases in length. -#### Operability +### Operability The long-term needs of system administrators should be reliably supported. E.g., is the system easy to install? Can the @@ -537,16 +512,16 @@ administrator recover from a crash? Is there sufficient log output to diagnose problems in the field? Can the system's data be backed up without downtime? Can the system be upgraded practically? -#### Maintainability > Understandability +### Maintainability > Understandability Will it be easy for (future) developers to understand how the system works? -#### Maintainability > Evolvability +### Maintainability > Evolvability Can the system easily be modified and extended over time? -#### Maintainability > Testability +### Maintainability > Testability Can the system easily be tested? Do the requirements precisely specify possible inputs and the desired results? Can the system be @@ -554,7 +529,7 @@ tested in parts? When failures are observed, can they be traced back to defects in specific components (i.e., debugging)? Is testing practical with the available testing tools? -### Additional Standard Terms +## Additional Standard Terms For additional standard terms, see the following reference sites: From abc255a136f67f393ff6637ff31b3da5bbf71d47 Mon Sep 17 00:00:00 2001 From: William Sandner Date: Fri, 24 Mar 2023 18:30:29 +0100 Subject: [PATCH 4/5] Fix copy paste mistakes --- Glossary-Standard-Terms.md | 11 +++++------ Glossary.md | 2 +- Implementation-Notes.md | 2 +- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/Glossary-Standard-Terms.md b/Glossary-Standard-Terms.md index d15a88e..a613d41 100644 --- a/Glossary-Standard-Terms.md +++ b/Glossary-Standard-Terms.md @@ -7,7 +7,7 @@ helps keep other documents more concise and easy to edit. Check the updates. -Jump to: [General](#general-terms) | [Computer science & technology](#computer-science-and-technology-terms) | [Process](#process-terms) | [Software development tools](#development-tool-terms) | [Requirements](#requirements-terms) | [Design](#design-terms) | [Design goals terms](#desigD-DIAGRAMn-goals-terms) | [QA terms](#qa-terms) | [QA goals terms](#qa-goals-terms) | [Additional terms](#additional-standard-terms)| [Project terms](Glossary) +Jump to: [General](#general-terms) | [Computer science & technology](#computer-science-and-technology-terms) | [Process](#process-terms) | [Software development tools](#development-tool-terms) | [Requirements](#requirements-terms) | [Design](#design-terms) | [Design goals terms](#design-goals-terms) | [QA terms](#qa-terms) | [QA goals terms](#qa-goals-terms) | [Additional terms](#additional-standard-terms)| [Project terms](Glossary) ## General Terms @@ -91,7 +91,7 @@ server in order to invoke an operation on the server-side. ### Change Control Board (CCB) -A group of people who review proposed changes toD-DIAGRAM the project +A group of people who review proposed changes to the project requirements and/or source code to accept or reject changes in each particular release. Proposed changes are usually rejected if they introduce too much risk or would trigger additional effort (e.g., @@ -387,10 +387,9 @@ this document. Is the data in the system a true representation of the real world? Any system that contains initial data or gathers data about the real -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM -D-DIAGRAM +world should be sure that the data is factually correct. E.g., a tax +preparation program should embody correct and up-to-date facts about +tax law. ### Usability > Understandability and Readability diff --git a/Glossary.md b/Glossary.md index e22a591..dfda901 100644 --- a/Glossary.md +++ b/Glossary.md @@ -96,7 +96,7 @@ credits needed? ### T -#### ::Term1D-DIAGRAM +#### ::Term1 ::Definition1 diff --git a/Implementation-Notes.md b/Implementation-Notes.md index 156bf8c..b9d0e93 100644 --- a/Implementation-Notes.md +++ b/Implementation-Notes.md @@ -156,7 +156,7 @@ engineers when the system is being run in an ASP production environment._ 1. ::STEP 1 2. ::STEP 2 -3. ::STEP 3D-DIAGRAM +3. ::STEP 3 #### Reload Config Files From ec229042a24a4abb0d0957b84aaa5f6f0c958514 Mon Sep 17 00:00:00 2001 From: William Sandner Date: Fri, 24 Mar 2023 18:49:28 +0100 Subject: [PATCH 5/5] Link to Internet Archive --- Glossary-Standard-Terms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Glossary-Standard-Terms.md b/Glossary-Standard-Terms.md index a613d41..b78d3c6 100644 --- a/Glossary-Standard-Terms.md +++ b/Glossary-Standard-Terms.md @@ -3,7 +3,7 @@ as they are used across projects. Individual projects should not need to edit this file. Writing out the definitions of terms and acronyms here helps keep other documents more concise and easy to edit. Check the -[ReadySET glossary](http://readyset.tigris.org/templates/glossary-std.html) for +[ReadySET glossary](https://web.archive.org/web/20200702035436/http://readyset.tigris.org/templates/glossary-std.html) for updates.