lint formatting fixes

2018-08-23 19:23:45 +02:00
parent bbf98a0dde
commit 7e0a90c44e
43 changed files with 667 additions and 455 deletions
--- a/Glossary-Standard-Terms.md
+++ b/Glossary-Standard-Terms.md
@@ -1,6 +1,6 @@

-
 # Standard Terms Glossary
+
 ---

 **Process impact:** This file as a dictionary of standard terms defined
@@ -10,19 +10,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](#design-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](#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
+
 The process of removing sample text from templates when that text
 does not apply to the current project. Often some of the sample text
 will be kept or revised to fit the current project. Even if the
@@ -33,23 +26,27 @@ 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 worksheet
-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.
+##### Attached worksheetD-DIAGRAM

-##### Process impact
-The process impact box on each template explains where the current
-template fits into the software development process. It usually
+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
+
+##### Process impactD-DIAGRAM
+
+The process impact box on eD-DIAGRAMach template explains where the current
+template fits into the softD-DIAGRAMware 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
+
 There are two kinds of checklists:

 - Many of the templates have a section with questions that help
@@ -60,6 +57,7 @@ There are two kinds of checklists:
  in those artifacts.

 ##### 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
 types of sticky notes:
@@ -80,12 +78,14 @@ sticky note.
 ### Computer Science and Technology Terms

 ##### ::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 (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. 
@@ -94,7 +94,8 @@ server in order to invoke an operation on the server-side.
 ### Process Terms

 ##### Change Control Board (CCB)
-A group of people who review proposed changes to the project
+
+A group of people who review proposed changes toD-DIAGRAM 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.,
@@ -103,6 +104,7 @@ composed of managers and representatives of other stakeholders such
 as the QA group and key customers.

 ##### Feature Complete
+
 A release is called "feature complete" when the development team
 agrees that no new features will be added to this release. New
 features may still be suggested for later releases. More development
@@ -110,6 +112,7 @@ work needs to be done to implement all the features and
 repair defects.

 ##### 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.
 There may still be source code changes to fix defects. There may
@@ -118,12 +121,14 @@ for test cases or utilities. New code may be added in a
 future release.

 ##### 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 numbers are the numbers that users see. Often, they
 will be the same as the internal release number. That is especially
 true if the product being built is a component intended to be reused
@@ -136,6 +141,7 @@ version 8. Later, the competition used version "10 Optimized" rather
 than "10.1" or "11".

 ##### 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.
@@ -143,35 +149,41 @@ of the existence of any internal release numbers.
 ### Development Tool Terms

 #### Version Control System
+
 ::DEFINITION1

 #### Commit Log Message
+
 ::DEFINITION1

 #### Issue Tracker
+
 ::DEFINITION1

 #### Unit Testing Automation
+
 ::DEFINITION1

 #### Automated Build System
-::DEFINITION1

-#### Source Code Analysis Tool
 ::DEFINITION1

 #### Style Checker
+
 ::DEFINITION1

 #### Source Code Formatter (Pretty Printer)
+
 ::DEFINITION1

 #### System Test Automation
+
 ::DEFINITION1

 ### Requirements Terms

 #### 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
 brief description of the purpose of the feature, the input and
@@ -179,8 +191,8 @@ 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
+
 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 
@@ -188,115 +200,144 @@ include both user intentions and system responses. One use case may
 show how the actor uses several features to accomplish a goal.

 #### Actor
+
 A user or an external system that uses the system being built.

 ### Design Terms

 #### ::TERM2
+
 ::DEFINITION2

 ### Design Goals Terms

 #### Correctness
+
 This design correctly matches the given requirements.

 #### Feasibility
+
 This design can be implemented and tested with the planned amount of
 time and effort.

 #### Understandability
+
 Developers can understand this design and correctly implement it.

 #### Implementation phase guidance
+
 This design divides the implementation into components or aspects
 that can correspond to reasonable implementation tasks.

 ####  Modularity
+
 Concerns are clearly separated so that the impact of most design
 changes would be limited to only one or a few modules.

 #### Extensibility
+
 New features or components can be easily added later.

 #### Testability
+
 It is easy to test components of this design independently, and
 information is available to help diagnose defects.

 #### Efficiency
+
 The design enables the system to perform functions with an
 acceptable amount of time, storage space, bandwidth, and
 other resources.

 #### Ease of integration
+
 The components will work together.

 #### Capacity matching
+
 The architecture deploys components onto machines that provide
 needed resources with reasonable total expense.

 #### Expressiveness
+
 It allows for storage of all valid values and relationships

 #### Ease of access
+
 Application code to access stored data is simple

 #### Reliability
+
 Stored data cannot easily be corrupted by defective code, concurrent
 access, or unexpected process termination

 #### Data capacity
+
 The system can store the amount of data needed.

 #### Data security
+
 Protection of sensitive user and corporate data from unauthorized
 access or modification

 #### Performance
+
 Data can be accessed quickly

 #### Interoperability
+
 The database or data files can be accessed and updated by other
 applications

 #### Intrusion prevention
+
 Prevent, e.g., hackers opening a command shell on our server.

 #### Abuse prevention
+
 Prevention of abuse (e.g., using our system to send spam).

 #### Auditability
+
 All changes can be accounted for later.

 #### 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
+
 The UI is well matched to the users' tasks and it can be used with a
 reasonable number of clicks and keystrokes.

 #### Safety
+
 Users are not likely to accidentally produce an undesired result
 (e.g., delete data, or send a half-finished email).

 #### Consistency and familiarity
+
 Users can apply their knowledge of similar UIs or UI standards to
 this system.

 ### QA Terms

 #### Bug
+
 *n.* **Deprecated** since 1991. See [defect](#defect).

 #### 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
+
 *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.
@@ -304,6 +345,7 @@ Defects can be removed by changing the source code, initial data,
 or document.

 #### 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
 infinite loop, or store an incorrect value in an internal variable.
@@ -311,6 +353,7 @@ A fault is not normally visible to users, only the
 [failure](#failure) is visible.

 #### 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
@@ -319,35 +362,41 @@ debugging to eventually find and remove [defects](#defect).
 ### QA Goals Terms

 #### 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
+
 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
+
 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
+
 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
+
 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
-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.
-
+D-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
 #### 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
 in understandability include unclear metaphors, poor or hard-to-see
@@ -355,6 +404,7 @@ labels, lack of feedback to confirm the effects of user actions, and
 missing or inadequate on-line help.

 #### 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
 rules can make these details easier to learn and remember. E.g., the
@@ -362,6 +412,7 @@ rules can make these details easier to learn and remember. E.g., the
 accelerator key.

 #### 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
 take unnatural steps to accomplish a task or where the user is given
@@ -370,6 +421,7 @@ invent an 8-character filename for their "Christmas card list"?
 E.g., must users total their own tax deductions?

 #### Usability > Efficiency
+
 Users should be able to accomplish common tasks with
 reasonable effort. Common tasks should be possible with only one or
 two steps. The difficulty of each step should also be considered.
@@ -377,12 +429,14 @@ E.g., does the user have to remember a long code number or click on
 a very small button?

 #### 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
+
 Users should be able to apply their past experience from other
 similar systems. This means that user interface standards should be
 followed, and common conventions should be used whenever possible.
@@ -390,15 +444,23 @@ 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 another currency on that step
+chance that the user is dealing with anoD-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
 in his/her task.

-#### Usability > Subjective satisfaction
+#### Usability > Subjective satisfactionD-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
+
 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
+
 The system should allow usage only by authorized users, and restrict
 usage based on permissions. The system should not allow users to
 side-step security rule or exploit security holes. E.g., all user
@@ -406,31 +468,46 @@ input should be validated and any malicious input should
 be rejected.

 #### Reliability > Consistency under load
-Every system has some capacity limits. What happens when those
-limits are exceeded? The system should never lose or corrupt data.
-
+D-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
 #### 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
+
 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 stop
+requests that it is capable of handling. It should not crash or sD-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
+D-DIAGRAM
 processing all requests.

 #### Reliability > Longevity
-The system should continue to operate as long as it is needed. It
-should not gradually use up a limited resource. Example 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
 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 is a general quality that holds when the system
 continues to satisfy its requirements when various usage parameters
 are increased. E.g., a file server might be scalable to a high
@@ -438,11 +515,13 @@ number of users, or to very large files or very high capacity disks.
 Several specific scalability goals are listed below.

 #### 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
+
 This is a specific type of scalability goal dealing with the ability
 for the system to handle large data sets. Operations should continue
 to be correct and efficient as data set size increases. Furthermore,
@@ -450,6 +529,7 @@ the user interface should still be usable as the data presented to
 users increases in length.

 #### Operability
+
 The long-term needs of system administrators should be
 reliably supported. E.g., is the system easy to install? Can the
 administrator recover from a crash? Is there sufficient log output
@@ -457,13 +537,16 @@ to diagnose problems in the field? Can the system's data be backed
 up without downtime? Can the system be upgraded practically?

 #### Maintainability > Understandability
+
 Will it be easy for (future) developers to understand how the system
 works?

 #### Maintainability > Evolvability
+
 Can the system easily be modified and extended over time?

 #### Maintainability > Testability
+
 Can the system easily be tested? Do the requirements precisely
 specify possible inputs and the desired results? Can the system be
 tested in parts? When failures are observed, can they be traced back