address comments in PR #20

Author: mariojmdavid

content/03.intro.md

@@ -10,24 +10,24 @@ services, such as their stability or functional suitability.
 
 The meaning of **Service** can be regarded from different perspectives.
 From an IT Service Management (ITSM) standpoint, such as the EOSC Service Management
-System (SMS) process model, a service is devised as a means to "provide value
+System (SMS) process model, a **Service** is devised as a means to "provide value
 to the customer". The same goal is shared by the DevOps paradigm, but in this
 case there is a more pragmatic vision that the customer satisfaction is achieved
-through the continuous delivery of quality-assured services, with a shorter
+through the continuous delivery of quality-assured **Services**, with a shorter
 life cycle, as the final outcome of a comprehensive software development process.
 
-The ITSM model has a broader focus. A service is an "intangible asset" that
+The ITSM model has a broader focus. A **Service** is an "intangible asset" that
 also includes additional activities such as customer engagement and support.
 Consequently, it is a much heavier process that might not be appropriate to
-be applicable for all types of services. The DevOps model, on the other hand,
+be applicable for all types of **Services**. The DevOps model, on the other hand,
 narrows down the scope to meet the user expectations by acting exclusively on
-the quality features of the service, which is seen as an aggregate of software
+the quality features of the **Service**, which is seen as an aggregate of software
 components in operation.
 
 ## Purpose
 
-This document provides an initial approach to Service Quality Assurance,
-meant to be applied in the integration process of the services existing
+This document provides an initial approach to **Service Quality Assurance**,
+meant to be applied in the integration process of the **Services** existing
 under the EOSC-Synergy project, which eventually will be accessible as part
 of the EOSC offerings.
 
@@ -37,29 +37,30 @@ conventions. To this end, the criteria herein compiled builds on the DevOps
 culture already established in the preceding Software Quality Assurance baseline
 document [@url:https://digital.csic.es/handle/10261/160086] to outline the set
 of good practices that seek the usability and
-reliability of services, and meet the user expectations in terms of functional
+reliability of **Services**, and meet the user expectations in terms of functional
 requirements.
 
 ## Contextualization of a Service
 
 As a result, a **Service**, as conceived in this document, represents the following:
 
-* **Web service** [WS] [@url:https://techterms.com/definition/web_service]:
-    * A web service is an application or data source that is accessible via
+* **Web Service** [@url:https://techterms.com/definition/web_service]:
+    * A **Web Service** is an application or data source that is accessible via
     a standard web protocol (HTTP or HTTPS).
-    * Web services are designed to communicate with other programs,
+    * **Web Services** are designed to communicate with other programs,
     rather than directly with users.
-    * Most web services provide an API, or a set of functions and commands,
+    * Most **Web Services** provide an API, or a set of functions and commands,
     that can be used to access the data.
 
-* **Web application** [WApp] [@url:https://techterms.com/definition/web_application]:
-    * A web application or "web app" is a software program that is delivered over
+* **Web Application** [@url:https://techterms.com/definition/web_application]:
+    * A **Web Application** or "Web App" is a software program that is delivered over
     the Internet and is accessed through a web browser.
 
-* **Platform** or **Service Composition** [Plat]
+* **Platform** or **Service Composition**
 [@url:https://csrc.nist.gov/glossary/term/Service_Composition]:
-    * Aggregation of multiple small services into larger services.
-    * An integrated set of Web services, Web applications and software components.
+    * Aggregation of multiple small services into larger services,
+    according to a service-oriented (SOA) and/or microservices architecture.
+    * An integrated set of **Web Services**, **Web Applications** and software components.
 
 Examples are: Web portals, Scientific portals and gateways, data repositories.
 

content/06.quality_criteria.md

@@ -229,7 +229,7 @@ good practices.
   for this task.
 
 * **[SvcQC.Sec07]** IaC testing, from [SvcQC.Aud02] criterion, MUST cover the
-security auditing of the IaC templates (aka _Security as Code_ or _SaC_) in
+security auditing of the IaC templates (_SaC_) in
 order to assure the deployment of secured **Services**. For all the third-party
 dependencies used in the IaC templates (including all kind of software artefacts,
 such as Linux packages or container-based images):
@@ -246,14 +246,14 @@ such as Linux packages or container-based images):
 
 ### Policies [SvcQC.Pol]
 
-Policy documents describe what are the users expected behaviour when using the
+Policy documents describe what are the user's expected behaviour when using the
 **Service**, how they can access it and what they can expect regarding privacy
 of their data.
 
 * **[SvcQC.Pol01]** The **Service** MUST include the following policy documents:
   * **[SvcQC.Pol01.1]** Acceptable Usage Policy (AUP): Is a set of rules applied
-  by the owner, creator or administrator of a network, website, or service, that
-  restrict the ways in which the network, website or system may be used and sets
+  by the owner, creator or administrator of a network, **Service** or system, that
+  restrict the ways in which the network, **Service** or system may be used and sets
   guidelines as to how it should be used. The AUP can also be referred to as: Acceptable
   Use Policy or Fair Use Policy.
   * **[SvcQC.Pol01.2]** Access Policy or Terms of Use: represent a binding legal
@@ -285,11 +285,36 @@ Level Agreement (OLA) with the infrastructure where it is integrated.
 * **[SvcQC.Sup04]** The **Service** MAY include Service Level
 Agreement (SLA) with user communities.
 
+### Automated Deployment [SvcQC.Aud]
+
+The automated deployment of **Services** implies the use of code to install and
+configure them in the target infrastructures. Infrastructure as Code (IaC)
+templates allow operations teams to treat service provisioning and deployment in
+a similar fashion as developers manage the software code.
+
+Consequently, IaC enables the paradigm of immutable infrastructure deployment
+and maintenance, where **Services** are never updated, but deprovisioned and
+redeployed. An immutable infrastructure simplifies maintenance and enhances
+repeatability and reliability.
+
+* **[SvcQC.Aud01]** A production-ready **Service** SHOULD be deployed as a
+workable system with the minimal user or system administrator interaction
+leveraging IaC templates.
+
+* **[SvcQC.Aud02]** Any future change to a deployed **Service** SHOULD be
+  done in the form of a new deployment, in order to preserve immutable
+  infrastructures.
+
+* **[SvcQC.Aud03]** IaC SHOULD be validated by specific (unit) testing
+frameworks for every change being done.
+  * **[SvcQC.Aud03.1]** IaC (unit) tests MUST be idempotent.
+
 ### Monitoring [SvcQC.Mon]
 
 Monitoring is a periodic testing of the **Service**. It requires a monitoring
 service from where tests are executed or sent and results of those tests are shown.
-The tests can be the same, in part or in total of the Functional tests.
+The tests can be the same, in part or in total of the Functional, Security and
+Infrastructure tests.
 The technology used for the monitoring is left to the developers of the underlying
 software to decide eventually with input from the infrastructure(s),
 where the **Service** is foreseen to be integrated.
@@ -315,30 +340,6 @@ where the **Service** is foreseen to be integrated.
   * **[SvcQC.Mon03.1]** IaC (unit) tests [SvcQC.Aud02] SHOULD be reused as
   monitoring tests, thus avoiding duplication.
 
-### Automated Deployment [SvcQC.Aud]
-
-The automated deployment of **Services** implies the use of code to install and
-configure them in the target infrastructures. Infrastructure as Code (IaC)
-templates allow operations teams to treat service provisioning and deployment in
-a similar fashion as developers manage the software code.
-
-Consequently, IaC enables the paradigm of immutable infrastructure deployment
-and maintenance, where **Services** are never updated, but deprovisioned and
-redeployed. An immutable infrastructure simplifies maintenance and enhances
-repeatability and reliability.
-
-* **[SvcQC.Aud01]** A production-ready **Service** SHOULD be deployed as a
-workable system with the minimal user or system administrator interaction
-leveraging IaC templates.
-
-* **[SvcQC.Aud02]** Any future change to a deployed **Service** SHOULD be
-  done in the form of a new deployment, in order to preserve immutable
-  infrastructures.
-
-* **[SvcQC.Aud03]** IaC SHOULD be validated by specific (unit) testing
-frameworks for every change being done.
-  * **[SvcQC.Aud03.1]** IaC (unit) tests MUST be idempotent.
-
 ### Metrics [SvcQC.Met]
 
 A metric is a quantifiable measure that is used to track and assess

content/07.glossary.md

@@ -21,6 +21,10 @@ __GDPR__
 __IaC__
 : Infrastructure as Code
 
+__ITSM__
+
+: IT Service Management
+
 __NIST__
 : National Institute of Standards and Technology
 
@@ -48,5 +52,11 @@ __SDLC__
 __SLA__
 : Service Level Agreement
 
+__SMS__
+: Service Management System
+
+__SOA__
+: Service Oriented Architecture
+
 __VCS__
 : Version Control System