Project Bootstrapping

SWOT Analysis

  ────────────────────────────────────────────────────────────
                    INTERNAL FACTORS
  ──────────────────────────┬─────────────────────────────────
    (S)TRENGTHS             │   (W)EAKNESS
    ───────────             │   ──────────
    characteristics of the  │   characteristics that place
    action/solution/product │   the action/solution/product
    that give to it an      │   at a disadvantge relative to
    advantage over others.  │   others.
  ────────────────────────────────────────────────────────────
                    EXTERNAL FACTORS
  ──────────────────────────┬─────────────────────────────────
    (O)PORTUNITIES          │   (T)HREATS
    ──────────────          │   ─────────
    elements that the       │   environment elements 
    action bears and        │   that could cause trouble
    could exploit to        │   for the implementation.
    its advantage.          │
  ──────────────────────────┴─────────────────────────────────








        


Behavior Driven Dev. (BDD)
@[https://en.wikipedia.org/wiki/Behavior-driven_development]

BDD suggests that unit test names be whole sentences starting with a 
conditional verb ("should" in English for example) and should be 
written in order of business value.

Acceptance tests should be written using the standard agile 
framework of a user story:
   """
Oº Being a [role/actor/stakeholder] º
Oº I want a [feature/capability]    º
Oº yielding a [benefit]             º

User Story classification: Classify project stories according detailing what is provided by the solution in terms of: [template] - Operational Efficiency - Current Problems solved - savings: - proffits: - Time - Resources: - Staff: - Others: - Automation gain - Security gain - Simplification gain - Adaptation to current context - Information gain: - trust-gain - transparency-gain - Risk-reduction - Resilience
Work Package
Work package:
- sub-project grouping the smallest-set-of-related-task
  that a project can be split into.

   PROJECT:
   ───────────┬───────────────────┬──────────
     PHASE    │     TASK          │ WORK 
              │                   │ PACKAGE
   ───────────┼───────────────────┼──────────
     Phase 1  │ Deliverable 1.1 ┐ │ WP_1
              │ Deliverable 1.2 │ │ WP_1
              │ Other tasks     ┘ │ WP_1
              │ Deliverable 1.3 ┐ │ WP_2
              │ Deliverable 1.4 │ │ WP_2
              │ Other tasks     ┘ │ WP_2
   ───────────┼───────────────────┼──────────
     Phase 2  │ Deliverable 2.1 ┐ │ WP_3
              │ Deliverable 2.2 │ │ WP_3
              │ Deliverable 2.3 ┘ │ WP_3
   ───────────┼───────────────────┼──────────
     Phase 3  │ Deliverable 3.1 ┐ │ WP_4
           3  │ QA Testing      │ │ WP_4
           3  │ Marketing tasks ┘ │ WP_4
   ───────────┴───────────────────┴──────────
     └─────┘    └──────┬──────┘     └┬─┘ 
                       └───────┬─────┘ 
     Ordered       Tasks grouped in WP by:
     in time        - knowledge/discipline.
                    - time needed
                    - Shared resouces
                      - geographical area.
                      - Shared knowledge.
                      - ...
Describing/Modeling systems
- Describe system as a graph.
  Nodes are components/actors then:
  - graph 1: Arrows are relations. 
  - graph 2: Arrows are data flows. (map to sequence diagrams).

- Describe actors (components, users, roles..) and the frequent task
  each actor will be in charge of. 


- Classify entities in model according to:
  -ºactive entitiesº: entities that initiate a new work flow that acts as
     "beeings with own will". In software those entities are related to human 
     users, IoT devices, ... 
     In general, they must registrer and authenticate "shomehow" to the 
     system, have a set of assigned secrets/signature keys/... and represent
     natural/legal entities. Ex:
  -ºreactive-entitiesº: entities that react to external orders/requests.
     The mostly corresponds to software modules like daemons, 
     modules exposing REST APIs, ...
  -ºdata entitiesº: persistence data representing the status of the software model.
    They can be subdivided in:
    - Business entities: entities modeling the "Happy path" in a business workflow.
    
    - Error control : entities modeling the "Non-Happy path" when workflow
                      is stuck pending some data/event or must rollback due to
                      some non-contemplated/non-fixable error/condition.
      They can be subdivided in:
      - Error origin     : Explain where or why the error originated
      - Error destination: Explains who must fix the error.
      - Error metadata   : Extra information about the error that can
                           help to fix/audit/trace the error.
Choosing a Tech. Stack
REF: @[https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb]

""" 
   Next time you find yourself Googling some cool new technology to 
   (re)build your architecture around, I urge you to stop and follow 
  ºUNPHATºinstead:

  - Don't even start considering solutions until you Understand the 
    problem. Your goal should be to "solve" the problem mostly within the 
    problem domain, not the solution domain.
  - eNumerate multiple candidate solutions. Don't just start prodding 
    at your favorite!
  - Consider a candidate solution, then read the Paper if there is 
    one.
  - Determine the Historical context in which the candidate solution 
    was designed or developed.
  - Weigh Advantages against disadvantages. Determine what was 
    de-prioritized to achieve what was prioritized.
  - Think! Soberly and humbly ponder how well this solution fits your 
    problem. What fact would need to be different for you to change your 
    mind? For instance, how much smaller would the data need to be before 
    youd elect not to use Hadoop?
"""
Agile
MoSCoW Task Prioritization
  MoSCoW method  is  one  of  the  most  used  prioritization  
techniques  in  the  project  management  and software development 
and for this reason it was selected in the current deliverable. 

  Its primary role is to define a common baseline with partners on how 
they evaluate (e.g. most important/important/least important/etc.) 
each defined requirement. 

The acronym, MoSCoW, stands for 4 categories of prioritizations:
• "Must  have" requirements are considered vital/critical for the partner in order 
  to obtain a successful  outcome.  As  a  result,  these  are  
  considered  non-negotiable  and  mandatory. Furthermore,  any 
  solution delivered withouta requirement tagged as a must is not 
  considered viable.  If a workaround can be found for a requirement, 
  then this is not considered as “Musthave”. 

• "Should have" requirements:
  This  type comprises   all requirements that are not considered vital 
  but are important for the partner. The solution is considered viable 
  even if the requirement is not met. A workaround can be employed and 
  the solution will remain viable.

• "Could have" :
  contains all the  desired  features  that  could improve  the  
  functionality/work  experience  of the  solution  but  do  not  
  affect  the  result.  These  requirements have a minimum impact on 
  the end goal and are usually firstlyremoved in case of limited 
  timeframes.  

• "Won’t have" : (this time)
  requirements that are not needed at the current time or which do not 
  bring any addition to the value of the desired solution. Such 
  requirements do not have priority at the current moment of time. 

BºAccording  to  literature,  this prioritization  method  is        º
Bºefficient  and  offers  better  results  when  compared  to simplerº
Bºprioritizations approaches like high/medium/low prioritization or  º
Bºsequential prioritization.                                         º
Use case diagram    Diagram representing the actors outside of a system 
                    capable of interacting with the system itself. It represents the highest 
                    level view of a system.  
                    Shows the system as a whole and its input and output to and from external elements.

Vertical industry   Sybase
diagrams            
                    AADL     : Soft. Architecute Analysis and Design Language
                               (Memory, Processor, Thread, Data, Bus, System, Subprogram,
                                Thread Group, Device, Package)
                    BPMN     : Business Process Model and Notation
                               Start Event Message, Timer, Rule, Link, Multiple,
                               Intermediate Event, ,,,
                    ChemEng
                    Chronogram
                    Circuit
                    Civil
                    Cybernetics
                    Database
                    Electric
                    ER        : Entity  Relantionship
                    Flowchart
                    FS
                    Gane and Sarson
                    GRAFCET
                    Jigsaw
                    Ladder
                    Lights
                    Logic
                    Map,Isometric
                    MES
                    Network (Cisco Network)
                    Pneumatic/Hydraulic
                    RE-i*
                    RE-Jackson
                    RE-KAOS
                    SADT/IDEF0
                    SDL

Graph Diagrams      (Hyper)relational models.
                    Show entities as "circles" connected by arrows representing
                    relationships among them.

Diagram Software
           
- UML: sequence diagrams, components, state-machine, ...
  - https://mermaid-js.github.io/mermaid-live-editor/
    - Diagrams: Sequence, ER,Class, State, Flow Chart, User Journey,
    - Charts  : Gantt Charts, Pie Charts.
    - Syntax: 
      https://mermaid-js.github.io/mermaid/#/
  - https://www.planttext.com/
    -  allows ASCII art output (C⅋P as text, git friendly, ...)
  - https://www.websequencediagrams.com/
    - Better styling but no support for ASCII output 
  - PlantUML:
    - Offline Desktop java application.
    - Supports ASCII art output

- GNU Dia:
  Complete, light, easy to use, Windows/Linux/Mac. Can export to web format standards
  like Scalable Vector Graphics (SVG),  png, gif, ...
  - Extensions can be created through Python scripts:
    Example extensions include:
    https://github.com/amotzg/dia-postgresql : convert diagrams to PostgreSQL SQL syntax.
    https://github.com/chebizarro/postdia    : Convert PostgreSQL diagram to/from  (tedia2sql) UML dia diagram
    https://launchpad.net/diascla/           : Launch a customizable list of shell script from Dia
    - Define a list of scripts that will be launched from a dialog in 
      Dia. Scripts will be executed as typed in a shell; full output and 
      standard error of execution will be printed in dialog. It is possible 
      to choose the directory where to execute the script.
    - Scripts can use some template strings that will be raplaced 
      with active diagram full path, or active layer name or number, or 
      space separated list of ids of selected objects in diagram (id values 
      as in Dia xml file for objects. es. O1 O3 O92 ...).
    - Can prepend or append additional parameters to each script 
      (template string expansion will be done on these additional 
      parameters too).

- https://www.lucidchart.com/
  Online professional Diagram software. Free for individual use.
  (some menus views indicate it could be "inspired/based" in GNU Dia?)
  Supports BPMN 

- http://asciiflow.com/: 
  Extremely simple but very power editor to include text-based diagrams
  in mail, chats, working documentaion, ...
 
- http://www.umldesigner.org/
  Graph. tool to edit/visualize UML models based on Eclipse Sirius.
i
- Gliffy  : General Purpose on-line (web). Non-free for commercial use.
Agile concepts, Nomenclature
@[http://www.dummies.com/how-to/content/agile-project-management-for-dummies-cheat-sheet.html]
@[ttp://www.agilemanifesto.org]
@[http://www.scrummanager.net/files/sm_proyecto.pdf]
@[http://www.jandwyer.com/wp-content/uploads/2012/09/Lean-Primer-Article.pdf]
@[https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2]
@[http://www.scrumprimer.org/]
@[https://www.infoq.com/minibooks/kanban-scrum-minibook]
@[http://leankanban.com/wp-content/uploads/2016/06/Essential-Kanban-Condensed.pdf]

- Projects takes too much (1 year taking requirements, 10 months
  developping,...)

- Agile applies to project, people relationships,...
  prioritization of tasks, ...  better visibility,
  better prioritization, less downtime between tasks,
  Improved teamwork

- What's a task:
  A case study / promo-video / market-research /... ? NO. Too long.
  A task in agile is something that takes more than 30 minutes and less 
  than 3 days.

- How to estimate the time?
  Estimating is hard.
  Use story points (vs hours):
      1, 2, 4, 8, 16, 32, 48
      This could map (not necesarely) to:
      30min, 1hour, 2hours, 4hours, 1day, 2days, 3days.

SCRUM vs KANBAN: 
  Both are subsets of Agile.
  SCRUM targets dead-lines. (fixed dates)
   * Releases are more important that "what's in".
   * Delay release or drop feature?
   * Uses a PLAN MODE

  Kanban:
   * Service team. new tickets  always comming in.
   * Prioritazing the tickets (tasks) and doing in the right order
     is more important than how many are done in a week.
   * No Plan mode, no Sprints. 
     PLAN MODE:
   * Do NOT uses a PLAN MODE
Why I hate Scrum
https://dzone.com/articles/why-i-hate-scrum?edition=618291
By Gerhard Beck

I’ll define Scrum as the methodology developed by Ken Schwaber and Jeff Sutherland and documented in “The Scrum Guide.”

opinion: Scrum is not agile and, in practice, not very flexible. 

- Let’s take a look at the basic terminology:
  - "daily scrum"
    (less sporty and a lot less aggressive: a daily standup)
    - what you did.
    - what you are going to do
    - blockers. 
  - "sprints": management metaphor  to pressure to work un-paid hours.
    - 2 hours "sprints": "Put more pressure"

  - "Done" Scrum meaning.
     It starts with requiring those “performing the work and those inspecting
     the resulting increment must share a common definition of ‘Done’."
     - Problem: "done" depends:
                - on the task to be accomplished. 
                - on customer acceptance.
                -Dificult to figure out.
     - going to "done" must NOT be "insane"
     - ‘Done’ increment required at the Sprint Review. (just another way
       to put more preassure).

  - Time box: (2 weeks)
    Idea   : fit everything into "time box" so we all finish together.
    Reality: some things go faster, some others go slower.
           - Scrum is not agile, it’s a two-week waterfall from hell.

  - Scrum Master:
    Idea   : servant-leader for the Scrum Team.
    Reality: project manager stripped of the ability to manage the project.
     - "something needs to be done and a project manager can make the changes
        and get it done".
     - Scrum Master has to meekly explain to leadership that the next
       opportunity to save the ship will come in a week-and-a-half at
       the next sprint review
  
  - four formal events defined:
    - Sprint Planning
    - Daily Scrum:  replace with daily standup
    - Sprint Review
    - Sprint Retrospective: Do when needed, not at sprint plans.

    Reality: Waste of time for non-productive meeting. 

  - "team": 
     well-performing team members covering for poor performing team members
     is a guarantee that those will performing team members will soon be 
     working for a different company and you will have self-selected
     poor-quality team members. 
     Theory: 1-vote-per-team member:
     Reality: seasoned expert with thirty years of experience 
              outvoted by the novices.

  Conclusion:
  Perhaps as an industry we should work more on what a good leader looks like
  than trying to invent methodologies that deliberately remove leaders and 
  leadership as a quality. To me it seems entirely rudderless. 
  Scrum is Not a Team Player 

  Scrum is based around dropping working software every two weeks. 
  For some projects (web front ends) a short identical cadence works 
  well. For other projects (avionics) it doesn’t work at all.


Avoid "Product Owner" role - product owner role: proxy in between people doing the work and people needing the job done, and this causes delays, misunderstandings and bloat in our software engineering process. Poppendieck, author of many books on Lean in Software - there is an emerging theme in the literature, namely that the original balance of scrum master, product owner and team roles are being adapted, conflated, and possibly corrupted, to suit the needs of Bºorganizations transitioning from waterfall...º - Summarising ... as we scale Agile and its usage becomes the norm, the product owner role may not be such an obvious need or an obvious fit to the situation.
JIRA Summary
Features:
- Jira Issues and Dashboards
- Agile concepts
- Jira Agile Plan, Work, Track

JIRA WORKFLOW SUMMARIZED:
  - We have a team of developers than pass the work to the QA Team that
  pass the work back to the developers or forwards it to the client,...
  - There can be "millions" of different workflows.


JIRA ISSUES and DASHBOARDS:
   - Dashboards allows for example to follow  others people work.

JIRA E-R Diagram
REF: @[https://www.communardo.de/wp─content/blogs.dir/2/files/2012/04/JIRA_Concepts.pdf]

                             ┌──────────┐
                             │Issue Type│←────┐
                             │__________│     │
                             │Standard  │     │
                             │Sub─task  │     │
                             └──────────┘     │
   ┌──────────┐                  ^            │
   │Workflow  │                  │       ┌───────────┐              ┌───────┐
   │transition│                  │       │Issue Type │┌─────────────┼Context│
   └──────────┘←─♦┌────────┐  ┌────────┐ │Screen Sch.││             └───────┘
                  │Workflow│←─│Workflow│ └───┴───────┘│                 ^
   ┌────────┐←───♦└────────┘  │Scheme  │   │          │                 │
   │Workflow│                 └────────┘   │          │                 │
   │Step    │                  ^           │          │                 │
   └────────┘                  │           │          v          ┌─────────────────┐
       │                       ┌─────────────────────┐           │Global Context   │
    ┌──v──┐                    │ Project             │           │(in all projects)│
    │State│                    │                     │           └─────────────────┘
    └─^───┘                    │                     │                                     ┌─────────┐
      │                        │                     │        ┌──────────────────────┐     │Security │
      │                        │                     │───────→│Issue Security Scheme │────→│Level    │
      │                        │                     │        └──────────────────────┘     └─────────┘
      │                        │                     │
      │                        ┼─────────────────────┘────────────────┐             ┌────────────────┐
      │                        1♦   ♦1         │   │                  │             │User/Groups/    │
      │                   ┌─────┘   │          │   │                  │             │Proj.Roles      │
      │                  N│         │N         │   │   ┌────────┐   ┌─v────────┐───→│───────────     │
      │               ┌───────┐   ┌─────────┐  │   └──→│Project │   │Permission│    │Reporter        │
      │               │Version│   │Component│  │       │Category│   │Scheme    │    │Group           │
      │               └───────┘   └─────────┘  │       └────────┘   └──────────┘    │Single User     │
      │                ^           ^           │                        │           │Project Lead    │
      │                │     ┌─────┘           │                   ┌──────────┐     │Current Assignee│
      │                │     │                 │                   │Permission│     │User custom     │
      │                └┌──────┐───────────────┘                   └──────────┘     │Prj. Role       │
      └─────────────────│Issue │N                                       │           └────────────────┘
                        │      │           ┌───────┐                    │                    │
                        └──────┘←─────────→│ Issue │                    │                    │
                         │    │            │ Link  │                    │    ┌─────────┐     │
                         v    v            └───────┘                    │    │ Project │     │
                   ┌──────────┐    ┌──────────┐                         └───→│ Role    │←────┘
                   │Resolution│    │ Priority │                              └─────────┘
                   └──────────┘    └──────────┘


E-R:  REF @[https://dac-lf.prod.atl-paas.net/server/jira/platform/attachments/4227160/45525621.pdf]
PROJECT        ISSUE                  RESOLUTION
-------        --------------------   ----------
ID             ID                     ID
PNAME          PKEY                   SEQUENCE
URL            ISSUENUM               PNAME
LEAD           PROJECT                DESCRIPTION
DESCRIPTION    REPORTER               ICONURL
PKEY           ASSIGNEE
PCOUNTER       CREATEOR
ASSIGNEETYPE   ISSUETYPE
AVATAR         SUMMARY
ORIGINALKEY    DESCRIPTION
PROJECTTYPE    ENVIRONMENT
               PRIORITY
               RESOLUTION                   
               ISSUESTATUS                  
COMPONENT      CREATED                      
---------      UPDATED                      
ID             DUEDATE                      
PROJECT        RESOLUTIONDATE               
CNAME          VOTES                        
DESCRIPTION    WATCHES
URL            TIMEORIGINALESTIMATE
LEAD           TIMEESTIMATE
ASSIGNEETYPE   TIMESPENT
               WORKFLOW_id
               SECURITY

SCRUM FullJourney
ºPRE-SETUP (Initially and on-demand) )º
- CreateºCOMPONENTSº

- CreateºEpicsº

NOTE: ºCOMPONENT vs EPICº
┌──────────────────────────────────────────────────────────────────────────────┐
│COMPONENT:                                │ EPIC:                             │
│ - COMPONENT = ºproduct categoryº         │  - EPIC = ºgroupings for storiesº.│
│ - single project, timeless and kind of   │  - can go cross project           │
│   endless in scope and can be divided in │  - should have an end in time.    │
│   in "sub─products".                     │                                   │
└──────────────────────────────────────────────────────────────────────────────┘
@[https://www.linkedin.com/pulse/stories-vs-epics-components-modelling-product-jira-piotr/]


- CreateºIssue listº ← STEP 1 - organize via EPICs. ← Optional - Move list to backlog ("future TODO list") ← STEP 2 (TODOs planned, some of them can start two years from now) - Decide if we need EPICs. (Team of work/tasks) ← STEP 3 - Create newºSPRINTº(batch of tasks) and decide ← STEP 4 which tasks to move from the backlog to the SPRINT TODO (ussually two weeks dead-line). For every sprint we can decide to move forward one or more epics. - create versions. ← STEP 5 Optional
BURNDOWN CHART - chart showing the progress for the sprint. linear progress vs real progress
Xray for Jira
- Manage Tests as Jira issues
- Plan, Execute and Integrate
- Reports and Requirement Coverage
- Manage manual and automated tests as Jira issues, customize 
  screens, fields and workflows.
- Specify tests in cucumber language and integrate with test 
  automation frameworks.
- Organize tests in folders and test sets.
- Create test plans for tracking a set of tests and planned or ad hoc 
  test executions.
- Execute tests on different environments and consolidate results.
- Use your CI tool to report test results using the included REST API. 
CalVer.org
- CalVer is a versioning convention based on your project's release 
  calendar, instead of arbitrary numbers.

_ Versioning gets better with time.

- For maintainers, versioning allows us to specify precise dependencies 
  within an ever-expanding ecosystem. For sellers and promoters, a 
  project's version is a dynamic part of a brand. For all of us, 
  versioning lets us reference the past while upgrading to the future.

- Different projects use different systems for versioning, but common 
  practices have emerged. For instance, point-separated numbers (e.g., 
  3.1.4) are all but given. Another common versioning pattern 
  incorporates a time-based element, usually part of the release date.

- This date-based approach has come to be called Calendar Versioning, 
  or CalVer for short.
Documentation
Diagram Types
Term                Meaning
Functional diagram  Structured representation of the functions (activities,
                    actions, processes, operations) within the system or one of its parts.
                    The model aims at facilitating the identification of 
                    information needs and helping to recognize opportunities.
                    Amongst other funct. diagrams include:
                    - Data Flow Diagram
                    - Sequence  Diagram

Component diagram   Diagram which has the purpose of representing the 
                    internal structure of the software system modeled in terms of its main 
                    components and the relationships between them. 
                    A component is a software unit with a distinct 
                    identity, as well as a distinct responsibility and 
                    well-defined interfaces.

Deployment diagram  Diagram which describes a system in terms of hardware 
                    resources, nodes, and relationships between them.
                    Often there is a diagram showing how the software 
                    components are distributed in the available hardware resources on the system.
                    In essence, it shows the physical location (deployment) of components of the architecture

Activity diagram    The process view is a way of showing what the system does at a high level 
                    from a process prospective, explaining how the small 
                    steps within the process fit together, in terms of 
                    order and information flow.

Use case diagram    Diagram representing the actors outside of a system 
                    capable of interacting with the system itself. It represents the highest 
                    level view of a system.  
                    Shows the system as a whole and its input and output to and from external elements.

Vertical industry   Sybase
diagrams            
                    AADL     : Soft. Architecute Analysis and Design Language
                               (Memory, Processor, Thread, Data, Bus, System, Subprogram,
                                Thread Group, Device, Package)
                    BPMN     : Business Process Model and Notation
                               Start Event Message, Timer, Rule, Link, Multiple,
                               Intermediate Event, ,,,
                    ChemEng
                    Chronogram
                    Circuit
                    Civil
                    Cybernetics
                    Database
                    Electric
                    ER        : Entity  Relantionship
                    Flowchart
                    FS
                    Gane and Sarson
                    GRAFCET
                    Jigsaw
                    Ladder
                    Lights
                    Logic
                    Map,Isometric
                    MES
                    Network (Cisco Network)
                    Pneumatic/Hydraulic
                    RE-i*
                    RE-Jackson
                    RE-KAOS
                    SADT/IDEF0
                    SDL

Tools for Diagram design
- PlantUML : text to UML (a Local Java version exists, as well as online
             - zero install versions -)
              To generate text diagram (Asci-art) use the flag -txt or -utxt in the
              local plantuml or one online version with text output support. For
              example @[https://www.planttext.com/]

             Quickly generate sequence diagrams from text. 
             Ex: (Using  https://www.planttext.com/)

             ──────────────────  -→  ─────────────────────────────
             INPUT                           OUTPUT 
             ──────────────────  -→  ─────────────────────────────
                                     ┌─┐          ┌─┐          ┌─┐
             @startuml           -→  │A│          │B│          │C│
                                     └┬┘          └┬┘          └┬┘
             participant A       -→   │ message 1  │            │ 
             participant B            │───────────→│            │ 
             participant C       -→   │            │            │ 
                                      │            │ message 1  │ 
             A -→ B: message 1   -→   │            │───────────→│ 
             B -→ C: message 1        │            │            │ 
             C -→ B: reply 1     -→   │            │  reply 1   │ 
             B -→ A: reply 1          │            │←───────────│ 
                                 -→   │            │            │ 
             @enduml                  │  reply 1   │            │ 
                                 -→   │←───────────│            │ 
                                     ┌┴┐          ┌┴┐          ┌┴┐
                                 -→  │A│          │B│          │C│
                                     └─┘          └─┘          └─┘

- GNU Dia: Complete, light, easy to use, Windows/Linux/Mac. Can export to web format standards
           like Scalable Vector Graphics (SVG),  png, gif, ...

- AscciFlow: Extremely simple but very power editor to include text-based diagrams
            in mail, chats, working documentaion, ...
            http://asciiflow.com/

- Web Sequence Diagram: On-line, free.

- http://www.umldesigner.org/
  Graph. tool to edit/visualize UML models based on Eclipse Sirius.

- Gliffy  : General Purpose on-line (web). Non-free for commercial use.
Reference Classification
- Next generic categorization can be use to label content in CMS
 (See section in Confluence), JIRA, Git/Git-Commits, email and of cours in
 single page book projects.

  CLASSIFICATION   labels ("Coordinates in dimension)                         
  DIMMENSION                                                                  

  Generic          gen.TODO
                   gen.important

  - soft_arch:     soft_arch.AAA
                   soft_arch.API
                   soft_arch.secrets
                   soft_arch.performance
                   soft_arch.scalability
                   soft_arch.standards
                   soft_arch.security
                   soft_arch.devops
                   soft_arch.infrastructure.
    
  
  QA) qa.unitests , qa.functionalTests, qa.IntegrationTest

  Life─cycle      0) Governance
                  1) planing        
                  2) Tools          
                  3) documentation  
                  4) development     
                  5) debugging      
                  6) deployment                            
                  7) monitorization                        
                  8) ticketing
                  9) deprecation                           
                 10) close
                 11) alerting

  Environment     DEV, INT, ACC/PRE, PRO                                          

  Component       component1, 2,...

  Service          diploma , notarization , essif                              
  (Solution/Product)

  Tool            Jira, SonarQube, Jenkins, npm, swagger, ...                 


  documentType:  dataflow, deliverable, analysis,
                 functional, must-read, tutorial, dataflow, configuration, procedure, 
                 minutes, reference,  comparative, code_snippet,
                 software, news, report,  trace(log), code, apendix, diagram
                 template, draft, 
                 meeting.input, meeting.output
                 Others: ( budget, gant, ...)                                
                 diagram     : functional,component,deployment,activity,use_case

   audience   : (what-roll this-document is intended for) developer, stackholder, ...
   Roll       : (What roll is related to this document) PROGRAMADOR, ANALISTA, ... ?

  Programming : javascript, typescript, ruby, shell, ...                    
  Language                                                                    

  difficulty  : level0 → ... → level10                                      
                (Reader-expected-expertise)

  Intended    :   developer, business_analist, operator, stackholder, ...     
  audience

  Lecture Time:   7min → 15min → 30min → 1h → 4h → 1d → 1w → 1m               

  PM            - PM.stackholder
 (Project       - PM.funding
  Management):  - PM.planning
                - PM.estimate
                - PM.TODO
                - PM.TODO.DEADLINE
                - PM.DONE
                - PM.sprint
                - PM.WorkPackage
                - PM.urgent
                - PM.blocking
                - PM.task
                - PM.task.state
                  → PM.task.state.backlog
                  → PM.task.state.in_progess
                   → PM.task.state.review
                    → PM.task.state.aproved
                     → PM.task.state.published     (doc related)
                      → PM.task.state.closed
                      → PM.task.state.deprecated   (doc related, Outdated/Deprecated/Replaced)

  HHRR (Human Resources)
  - HHRR.expenses
  - HHRR.Teleworking
  - HHRR.timelabor
  - HHRR.TimeLavor
  - HHRR.travel
  - HHRR.who_is_how
  - HHRR.WhoIsWho
  - HHRR.bill
  - HHRR.delivery_note


keyword ontology @[https://www.google.com/search?q=keywords+categories+ontologies+database] - Using software terminology keywords can be: - namespaces grouping related content. - Constructors or factories of many other words - module name for words in such "module". - From @[https://biznology.com/2018/02/what-is-a-keyword-ontology/] - A keyword ontology is a knowledge graph describing relationships between the keywords your target audiences frequently use in search queries and the products and services you sell. - It can include other relationships as well, such as taxonomies, information architectures, social listening queries, competitors, etc. - Not that your audience always comes to the content that sells your products through search. But a large of enough sample of them do that the keywords they use tell you a lot about the information they need to ultimately buy your products. A keyword ontology helps you understand which words tend to go with which products, and how you can out think your competition to deliver the content your prospects need. - bold claim: "Keywords are the life’s blood of your marketing enterprise." it is not just about choosing the right search words for your paid search campaigns. They can serve as a foundation for external organic search, internal search, navigation, and social listening. Q: If keyword research is so important, why do so few companies do it well? A: Because it’s really hard... Done well, keyword research is typically a manual process of checking each search result on the top page in Google for each keyword. Bº...primary benefits of a keyword ontology are scale, collaboration, and automation...º - From @[https://www.aclweb.org/anthology/2020.lrec-1.278.pdf] Ontology learning Layer (Buitelaar et al., 2005) ( applied_to(x,y), similar_to (y,z) → applied_to(x,z) ) For all x,y,x ┌────────────────────────────────────────── │ AXIOMS and RULES ┌───┴────────────────────────────────────────── represents (dom:LAWYE, range:CLIENT) │ (Other) Relations (dom:LAWYER, range:CLIENT) ························································································ ┌─┴────────────────────────────────────────────── IS_a │ Taxonomy/Concept Hierchies (LAWYER, PERSON) ┌─┴──────────────────────────────────────────────── │ Concepts (LAWYER, PERSON, ...) ┌─┴────────────────────────────────────────────────── │ Synonyms (crime, infraction, ... ┌─┴──────────────────────────────────────────────────── │ Terms (case, crime, infraction,..) └────────────────────────────────────────────────────── The field that focuses only on the creation ofthese triples is named Open Information Extraction (OpenIE).
Confluence Notes

Advanced Search (CQL) @[https://developer.atlassian.com/server/confluence/advanced-searching-using-cql/#cql-operators] CQL stands for Confluence Query Language (CQL) Simple CQL: $field $operator (value|function)1+ Ex.: space = "TEST" ← find all content in "TEST" space. Rº:It is not possible to compare two fieldsº Content API REST Resource Ex: AAA="-u username:password" curl $AAA "$BASE_URL/rest/api/content/search?cql=space=TEST" ← Simple query COMPLEX_QUERY="" COMPLEX_QUERY="$COMPLEX_QUERY cql=(type=page and space=DEV) OR" COMPLEX_QUERY="$COMPLEX_QUERY (creator=admin and type=blogpost)" curl $AAA -G "$BASE_URL/context/rest/api/content/search" \ ← Complex query --data-urlencode "$COMPLEX_QUERY" \ | python -m json.tool Operators CONTAINS: UsesºLucene's text-searchingº on fields: - title - text - space.title AND|NOT: combine multiple clauses Exs: type = "blogpost" and ← page|blogspot|attachment label = "performance" and creator = currentUser() and space = DEV and not( lastModified ˂ startOfYear() ) order by created desc, title mention IN (alice,bob) and ºtextº~ "http win* api" └───────↑──┘ ^ ┌──────────────┘ = ··· EQUALS │ != NOT EQUALS │ ˃ GREATER THAN │ ˃= GREATER THAN OR EQUALS │ ˂ LESS THAN │ ˂= LESS THAN OR EQUALS │ IN │ NOT IN ← equivalent to multiple "!=" statements, │ but shorter. That │ title|text ~ ········ CONTAINS ← exact/ºfuzzyº match │ title|text !~ DOES NOT CONTAINS ← Ex: │ ~ run matches running,ran | Field is one of: - Ancestor - ID - Space -ºTextº ("document content") - Container - Label - " category - Title - Content - Last modified - " key - Type - Created - Macro - " title - Watcher - Creator - Mention - " type - Contributor - Parent - Favourite favorite Dates: results will be relative to configured time zone (default to Confluence server time zone). Ex Dates: yyyy/MM/dd HH:mm yyyy-MM-dd HH:mm yyyy/MM/dd yyyy-MM-dd now("-4w") endOfDay() endOfMonth() endOfWeek() endOfYear() startOfDay() startOfMonth() startOfWeek() startOfYear() Ex: macro = jira ← Find content that has the JIRA issue macro. macro in (jira, toc, widget) ← content that hash JIRA-issue macro or Table-of-content macro or widget macro. Space category space.category in (planning, development) space.key in (MKT, OPS, DEV) space.title ~ "Development Team" space.type = personal ← Find personal spaces space.type = global ← Find site / global spaces
Confluence, Using lables @[https://confluence.atlassian.com/doc/add-remove-and-search-for-labels-136419.html] - Labels can be used to create content classification in N dimensions, versus 1-dimensional folder classification. labelText:'tutorial' AND labelText:'componentes? - Visually: root ·············· │ class2 │ │ label2.4┼ ├ folder1_1 ······ │ x1 │ │ │ │ label2.3┼ │ ├ folder1_1_1 ·· │ x2 │ │ │ │ │ label2.2┼ Bºdoc2º │ │ └ Gºdoc1º····· ┼ x3 │ · │ │ │ label2.1┼···Gºdoc1º· │ └ folder1_1_2 ·· │ x4 │ · · │ │ └──────┴───·─────┴──... class1 ├ folder1_2 ······ │ x5 ╱ label1.1 · ·label1.2 │ │ ╱ · · ├ folder1_3 ······ │ x6 ╱ · · │ │ │ ╱ ·· │ └ Bºdoc2º····· ┼ x7 ╳················ · · ╱ label3.1 · · ╱ ^ . 1-Dimension class 3
List existing labels ${CONFLUENCE_BASE_URL}/labels/listlabels-alphaview.action?key=${SPACE} ← All labels ${CONFLUENCE_BASE_URL}/labels/listlabels-heatmap.action?key=${SPACE} ← Hot labels
Error Management
- Define generic "messages" to indicate "throws".
- Classify errors by:
  - Retry now   (weird conditions,...).
  - Retry later.
  - Do not retry.
- Classify errors by:
  - Internal to be fixed by Admins
  - Internal to be developers ("asserts in code")
  - External (to be fixed by users -or software-) sending 
    the input. In this case, most probably retry doesn't
    makes sense until client fixes its issues.
Taxonomy/Research methodology
Extraced from "A systematic literature review of blockchain-based
applications:Currentstatus,classification and open issues"
Fran Casinoa, ThomasK. Dasaklisb,Constantinos Patsakisa,

To provide a transparent, reproducible and scientific literature 
review of blockchain-based applications, the process suggested by 
Briner and Denyer (2012)as well as some features of the PRISMA 
statement (Moher et al., 2009) have been adopted. 
The overall methodological approach includes the following steps:
1. Identify the need for the review, prepare aproposal for the review, and develop the review protocol.
2. Identify the research, select the studies, assess the quality, take notes and extract data, synthesise the data.
3. Report the results of there view.
3.1. Locating studies 
  To address our primary research question, a systematic literature search 
  was carried out during January 2018 without time frame restrictions 
  and the results were subsequently updated during April 2018.
     Scopus was used as the main scientific database in which the term 
  “blockchain” was searched in all articles’titles. Additional 
  searches using the referenced works of relevant articles were also 
  conducted (snowball effect). Relevant “grey literature”, 
  including unpublished research commissioned by governments or 
  private/public institutions was also identified through electronic 
  searches. To identify the published grey literature, we evaluated the 
  first 200 hits from Google. Alternate terms for “blockchain” and 
  “application” were used during the search. The hand-search 
  reference list in several reports resulted in additional grey 
  literature, particularly research and committee reports or policy 
  briefs from both private and public sector 
  institutions/organizations. A flowchart of the strategy implemented 
  is presented inFig. 2. In addition, several refinement features of 
  Scopus were extensively used (multiple refinements of results  
  following the context of specific articles,related documents search, 
  etc.). When the abstract of a particular study was not available, the 
  full article was retrieved and assessed for relevance.All potentially 
  relevant articles were retrieved in fulltext.

3.2. Study selection and evaluation
      The eligibility of the retrieved literature was evaluated  
   independently by the authors based on a set of 
      predefined exclusion and inclusion criteria (seeTable 2). Some 
   exclusion criteria were used before introducing the literature in the 
   bibliographic manager(language, subject area and document type 
   restrictions). Initially, the abstracts of all research papers and 
   introductory sections of grey literature were assessed. Articles 
   meeting one of the exclusion criteria were excluded and sorted by 
   reason of exclusion. Afterwards,a full-text review also took place, 
   and some additional articles were excluded from the study documenting 
   the reasons for exclusion. Any discrepancy with respect to the 
   relevance of reviewed articles was resolved through discussion until 
   consensus was reached. Overall, several studies were excluded because 
   they were focused primarily on the technical aspects of blockchain 
   tech-nology and/or blockchain architecture. Articles not fitting the 
   inclusion criteria were set aside and consequently used in the 
   in-troduction of this article.
   

   3.3. Analysis and synthesis
   All articles and reports meeting the inclusion criteria were 
entered into a qualitative analysis software (MAXQDA11), and data 
were analysed in emerging themes. The reviewers independently carried 
out the thematic content analysis. Afterwards, the three clusters of 
coded segments were compared(rate of consensus was approximately 
75%), agreed upon for all articles and summarised in one set of 
themes and sub-themes

                      Bibliographic database search                                     +       Grey Literature
                                                                                        |
+------------+    +------------------------------+                                      |
|            |    |Records retreived. (568)      |                                      |     +-----------+
|Identifi-   |    |                              |                                      |     |Records    |
|cation      |    |Additional articles included  |       +----------------+             |     |retrieved  |
|            |    |through bibliographic trail   |       |Exclusion of NOn|             |     |from other |
|            |    |search and reference list (37)+-----˃ |English language|             |     |source(170)|
+------------+    +------------------------------+       |literature(39)  |             |     +-----------+
                                                         +----------------+             |
                                                                                        |
+------------+    +-------------------------------+     +----------------------+        |
|Screening   |    |Records imported into          +----˃+ Duplicates removed(9)|        |     +-------------+      +--------------+
|            |    |citation manager (566)         |     +----------------------+        |     |Records      |      |Records       |
|            |    +------------+------------------+                                     |     |screened with+-----˃+excluded based|
|            |                 |                        +------------------------+      |     |check-list 2 |      |on ...(116)   |
|            |                 v                    --˃ | Articles excluded based|      |     |(170)        |      +--------------+
|            |    +------------+-----------------+  |   | on Title(22)           |      |     +-------------+
+------------+    |Title and Abstract screening  +--+   +------------------------+      |
                  |(557)                         |      +-------------------------+     |
                  |                              +-----˃+ Articles excluded based |     |
                  +------------------------------+      | on Abstract(42)         |     |
                                                        +-------------------------+     |
+------------+    +-------------------------------+                                     |
|Eligibility |    |Full-text articles             |     +-------------------+           |
|            |    |assesed for eligibility        |     | Full-text articles|           |     +------------------------------+
|            |    |(292)                          +----˃+ exclude(32)       |           |     |Number of reports included(54)|
+------------+    +-------------------------------+     +-------------------+           |     +--+---------------------------+
                                                                                        |        |
 Inclusion                                                                              |        |
                  +-------------------------------+                                     |        |
                  |Number of articles included    |                                     +        |
                  |(260)                          |                                              |
                  +------------+------------------+                                              |
                               |                                                                 |
                               |                                                                 |
                               v                                                                 v
                     +---------+-----------------------------------------------------------------+----+
                     |Total records included in qualitative analysis (314): 260 articles and 54 report|
                     +--------------------------------------------------------------------------------+

˂  ˃

* MAXQDA is a world-leading software package for qualitative and 
mixed methods research. Analyze all kinds of data – from texts to 
images and audio/video files, websites, tweets, focus group 
discussions, survey responses, and much more. Developed by and for 
researchers, MAXQDA is at once powerful and easy-to-use, innovative 
and user-friendly, as well as the only leading QDA software that is 
100% 

Qualitative Data Analysis Soft (QDAS)
@[https://en.wikipedia.org/wiki/Computer-assisted_qualitative_data_analysis_software]
- Computer-assisted (or aided) qualitative data analysis software 
  (CAQDAS) offers tools that assist with qualitative research such as 
  transcription analysis, coding and text interpretation, recursive 
  abstraction, content analysis, discourse analysis,[1] grounded theory 
  methodology, etc. 

- CAQDAS is used in psychology, marketing research, ethnography, public 
  health and other social sciences. The CAQDAS networking project[2] 
  lists the following tools a CAQDAS program should have:
  - Content searching tools
  - Coding tools
  - Linking tools
  - Mapping or networking tools
  - Query tools
  - Writing and annotation tools
56% of information lost in 1 hour
@[https://www.cell.com/neuron/fulltext/S0896-6273(17)30365-3?_returnURL=https%3A%2F%2Flinkinghub.elsevier.com%2Fretrieve%2Fpii%2FS0896627317303653%3Fshowall%3Dtrue]
56% of information is lost in 1 hour if there is no link with previous knowledge.

- Studies point to the importance of forgetting (or transience)
  as a critical component of a healthy mnemonic system.

Templates
Project Management Template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
  1    IDENTIFICATION    1
  1.1    Document overview  
  1.2    Abbreviations and Glossary
  1.2.1    Abbreviations 
  1.2.2    Glossary  
  1.3    References   
  1.3.1    Project References
  1.3.2    Standard and regulatory References
  1.4    Conventions   
  2    Project Management   
  2.1    Team,  responsibilities   
  2.2    Work breakdown structure, tasks, planning   
  2.2.1    Task n 
  2.3    Resource identification   
  2.4    Relationships with project stakeholders
  2.4.1    Customer or end-user involvement
  2.4.2    Subcontractor management   
  2.4.3    Relationships with other teams
  2.5    Communication 
  2.5.1    Meetings 
  2.5.2    Reviews  
  2.6    Training   
  3    System requirements and project input data
  4    Configuration management    
  4.1    Software configuration management  
  4.2    Documentation configuration management
  5    Software development management
  5.1    Software development process 
  5.2    Software development tools    
  5.2.1    Tools    
  5.2.2    Obsolescence management    
  5.3    Software development rules and standards    
  6    Tests phases management
  6.1    Integration tests   
  6.2    Verification tests  
  6.2.1    Phase 1   
  6.2.2    Phase 2    
  7    Problems resolution    

1 IDENTIFICATION
1.1 Document overview
This document contains the project management plan of software XXX.

1.2 Abbreviations and Glossary
1.2.1 Abbreviations
Add here abbreviations

1.2.2 Glossary
Add here words definitions
1.3 References
1.3.1 Project References

#   Document Identifier  Document Title  [R1]IDdd your documents references.
One line per document     
1.3.2 Standard and regulatory References

#      Document Identifier   Document Title
[STD1] ISO 13485:2003        Medical devices - Quality management systems 
                             - Requirements for regulatory purposes
[STD2] ISO 14971:2007        Medical devices - Application of risk management ...
[STD3] IEC/TR 80002-1:2009   Medical device software ... 
[STD4] ISO 62304:2006        Medical Devices - Software life cycle processes     


1.4 Conventions
  - Typographical convention.
  - Any other convention.

2 Project Management
 [the section describes the organizational structure of the XXX 
  project, the corresponding responsibilities and the flows of internal 
  information.]
  2.1 Team,  responsibilities
  The organizational structure is:  Describe the team,  if necessary

  Title            Name         Responsibilities     
  Project Manager  John Smith   Manages costs, quality, schedule of the project, 
                                manages relationship with end users.
  ...

  2.2 Work breakdown structure, tasks, planning
  The tasks of the project are described in the table below.
  Insert a table or list or diagram describing the tasks.
  The Working Breakdown Structure (WBS) of the XXX project identifies all the tasks to the development of XXX product. If necessary, add a WBS codification. 
  
  The planning below contains all tasks of the project and the links between tasks.
  Insert a table or list or diagram describing the planning.
  Remark: for small projects, a gantt diagram is enough for this section!
  Important, list the deliverables and reviews of each phase of the project

    2.2.1 Task n (Example)
    Optional, add a sub-section for each task with:
    - Inputs of the task
    - Content of the task
    - Outputs of the task
    - Task reviews (in, if necessary, and out).
    Verification tasks are described more precisely in "verification tests" section.
    If you instantiate the "software development plan" document, you may add a
    reference to that doc and remove these sub-sections.

   2.3 Resource identification
   If specific resources are need for the project such as a 
   calibrated measurement tool or a simulator, they shall be identified, 
   referenced and managed in configuration.

   2.4 Relationships with project stakeholders

   2.4.1 Customer or end-user involvement
   Describe how the customer or end-user is involved in the software 
   development: meetings, reviews, and presentations of intermediate 
   versions

   2.4.2 Subcontractor management 
   Describe how subcontractors are managed: statement of work, 
   reviews, validation, verification 

   2.4.3 Relationships with other teams (Optionnal)
   Describe relationships with other teams of your company, like the 
   team in charge of the system design.

  2.5 Communication
  2.5.1 Meetings
    Describe what kinds of meetings are organized during the project 
  and what happens in these meeting. This may be described in your 
  quality management system. In this case, this section is not 
  necessary.
  2.5.2 Reviews
    Describe what kinds of reviews are organized during the project: 
  launch review, design reviews, tests reviews and what happens in 
  these reviews. This may be described in your quality management 
  system. In this case, this section is not necessary.

  2.6 Training
  Describe training of people involved in the project, if necessary.

3 System requirements and project input data
Reference here the input data from your project , non limited list :
- Intended use
- End user requirements (they may be very unstructured ! like meeting reports)
- Statement of work of your customer
- System requirements
- Risk analysis
- Legacy system documentation
- Any other input data 

  And how you manage their possible modification.

4 Configuration management
    If you instantiate the software configuration management plan 
  document, you may add a reference to that doc and leave this section 
  and subsections blank.

  4.1 Software configuration management
  The management of the software configuration may be included in this 
  section: what kind of SCM tool is used, when branches are made etc...
  How is the scm database saved or archived, when and where
  How a version is extracted and delivered, for verification phases, 
  for final delivery, for patches and service packs …
  It may be also described either in your quality management system 
  procedures or in a software configuration management plan.

  4.2 Documentation configuration management
    This section present the documentation management rules for all 
  documents sent or received during the XXX project.  It may be also 
  described in your quality management system procedures. In this case, 
  this section is not useful.

5 Software development management
  If you instantiate the "software development plan" document, you may 
  add a reference to that doc and leave this section and subsections 
  blank.

  5.1 Software development process
    The software development process chosen for the project is the 
  waterfall/SCRUM/Extreme programming model (choose yours).  The 
  waterfall/SCRUM/Extreme programming model was chosen for the reasons 
  below: add justification.

  5.2 Software development tools
  5.2.1 Tools
  Describe the IDE, the SCM tools, any tool used to write and manage 
  requirements, code and configuration. Don’t forget their versions. 
  SCM tools are described more precisely in « configuration management »
  Examples
  - Eclipse + list of plugins or VS2010 + list of plugins
  - Purify, boundschecker,
  - Git, redmine, Hudson,
  - Clearcase,
  - Rational Rose, Together J,
  - Doors (erk !),
  - Bugzilla,
  - Any Open source product
  - Willy Waller 2006
  - And so on 

  5.2.2 Obsolescence management
  Describe how you manage the obsolescence of software development tools :
  - Either you update them when a new version comes up
  - Or you stick to a version during the developpement and maintenance.
    Explain you choice.

  5.3 Software development rules and standards
    Describe here the standards and rules used for software 
  development, like modelling (UML), data modelling, coding rules,

  6 Tests phases management
    If you instantiate the “software development plan” document and 
  describe phases in that doc, you may add a reference to that doc and 
  leave this section and subsections blank.

  6.1 Integration tests (Optional)
    Describe how integration is managed Phases, reviews, documentation 
  Even if this may be described in your quality management system, I 
  recommend you to describe what is forecasted.

  6.2 Verification tests
    Describe how verification tests are managed. Phases, reviews, 
  documentation … Even if this may be described in your quality 
  management system, I recommend you to describe what is forecasted.

    Tests is often the weak link of soft development. Thinking about 
  tests at the beginning of the project is worth the effort.

  Example:
  Tests are split in four phases:
  * Alpha 1 tests: in this phase, V0.1 of software will be tested. 
    Testers will be the software development team. Each member tests a 
    portion of software developed by another member. Software will be 
    directly tested on the development platform
  * Alpha 2 tests: in this phase, V0.5 of software will be tested. 
    Tester will be the software integrator. Software will be installed on 
    the integration and test platform.
  * Beta 1 tests: in this phase, V0.8 of software will be tested. 
    Tester will be the software integrator and selected end-users. 
    Software will be installed on the integration and test platform.
  * Beta 2 tests: in this phase, V0.9 of software will be tested. 
    Testers will be selected end-users. Software will be installed on the 
    pilot platform in.
  Tests phases are described in the software tests plan OR below:
  6.2.1 Phase 1
  Describe the verification phase:
  - In: what is verified (version Vx.y.z)
  - Tasks: how it is verified (tests are done according to software test description doc XXX)
  - Out: the test report
  - Acceptation criteria: how the tests are passed or failed.
  
  Example of acceptation criteria, with bugs levels ratios (dummy but very effective):
  - Alpha tests: all blocking bugs are fixed
  - Beta tests:  all major bugs found in alpha tests are fixed and less than 20% of remaining bugs are major
  - Final version: all major bugs are fixed and 90% of minor bugs are fixed.
  
  Example of acceptation criteria, with rationale about requirements:
  - Alpha tests: tests about critical requirements (like those from 
    risk analysis) are passed and requirements about system-software 
    interfaces are passed
  - Beta tests:  tests on previous requirements and tests on 
    requirements about main use cases are passed
  - Final version: all tests are passed
  6.2.2 Phase 2
  Repeat the pattern for each phase
  Describe the verification phase:
  - In: what is verified (version Vx.y.z)
  - Task: how it is verified (tests are done according to software 
    test description doc XXX)
  - Out: the test report
  - Acceptation criteria: how the tests are passed or failed.

7 Problems resolution
  Describe here how bugs, requests, questions anything coming from 
  anyone outside the software development team. Especially for bugs, 
  how they are recorded, tracked, fixed.
  It may be also described in your quality management system 
  procedures. In this case, this section is not useful.

    Remark: there is no risk management section in this document. This 
  is voluntary, the risk management plan is an important document and 
  cannot be a section of project management.
Risk Management Plan template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]

  TABLE OF CONTENTS
  1    Introduction    2
  1.1    Document overview    2
  1.2    References    2
  1.2.1    Project References    2
  1.2.2    Standard and regulatory References    3
  2    Risk management during software development    3
  2.1    Organization and Responsibilities    3
  2.2    Qualification of personnel    3
  2.3    Objective of risk management activities    3
  2.4    Tasks, Planning    4
  2.4.1    Task n    4
  2.4.2    Risk analysis initialization    4
  2.4.3    Risk analysis update    5
  2.5    Criteria for Acceptability of Risk    5
  2.6    Verification and Risk traceability matrix    5
  2.7    Approvals    5
  2.8    Location of Risk Management File    5
  3    Risk management after software development    5
  3.1    Organization and Responsibilities    5
  3.2    Qualification of personnel    6
  3.3    Production and maintenance information    6
  3.4    Annual Audit    6
  4    Ranking System for Risk Analysis    6
  4.1    Probability of Occurrence    6
  4.2    Consequences of Hazard    7
  4.3    Add your other criteria    7
  4.4    Determination of risk priority number    7
  4.5    Criteria for acceptability    8

1 Introduction
1.1 Document overview
    This document covers the risk management plan of XXX device, designed in XXX software development project.

It contains:
- The risk management organization and process during the software 
  development project,
- The risk management organization and process during maintenance, 
  after final delivery of the software development project.

Note: most of times, risk management organization is very different 
before and after design. You may split the risk management plan in 
two documents, the first one before end of design, the second one 
after the end of design.


1.2 References
1.2.1 Project References

     Document Identifier  Document Title
[R1] ID                   Add your documents references.
                          One line per document


1.2.2 Standard and regulatory References

#       Document Identifier  Document Title
[STD1]                       Add your documents references.
                             One line per document

Add the standard references to the table above. 

  2 Risk management during software development
    This chapter covers the risk management process and organization 
    during the software development.

  2.1 Organization and Responsibilities
    Describe the organization of the team responsible for risk 
  management during design. You may add an organization chart or add a 
  reference to your project management plan, where the organization of 
  the project should be already described.
  
  Person          Responsibility 
  Project Manager * Overall management process responsibility
                  * Risk Management Plan development
                  * Creation and update of Risk Analysis Table
                  * Creation and update of Risk traceability matrix
                  * Creation and update Risk Analysis Report
  
  Quality Manager * Independent review of Risk Management File

  2.2 Qualification of personnel
    Describe the qualification of personnel responsible for the risk 
  management and risk analysis activities. Example:
  The personnel who participates to the risk analysis is composed of:
  - Experienced staff who was involved in the design process of similar products
  - The expert praticians who participate to the design process

  2.3 Objective of risk management activities
  The objective of risk management activities is to deliver a risk 
  analysis report, which contains:
  - The device characteristics that could impact on safety (ISO 14971),
  - The software safety classification (IEC 62304),
  - The risk analysis table,
  - The risk traceability matrix with design requirements,
  - The overall assessment of residual risk.

  The risk analysis table and risk traceability matrix will be created 
  and updated as necessary during software development, according to 
  tasks described in §2.4.

  Data on the risk analysis table includes:
  - List the columns, according to your risk analysis table in your risk analysis report,
  Data on the risk analysis table includes:
  - List the columns, according to your risk traceability matrix in 
  your risk analysis report,

  See the risk analysis report template for columns samples.
  Note: The Risk analysis may be performed with the help of the table 
  B.1 in IEC/TR 80002-1.

   The risk analysis report will summarize whether identified and 
  mitigated risks meet the acceptable values defined in this plan. It 
  will also include a statement indicating whether all known hazards 
  have been identified.
  
  The Risk Management File gathers this document and all documents quoted above.

   2.4 Tasks, Planning
  Describe how the risk management activities are planned during the project.
  The planning of risk activities shall be coherent with the planning 
  of the project found in §2.2 of the project management plan.
  Insert a table or list or diagram describing the planning.
  Important, list the deliverables and reviews of each phase of the project

  2.4.1 Task n
  Optional, add a sub-section for each task with:
  - Inputs of the task
  - Content of the task
  - Outputs of the task
  - Task reviews (in, if necessary, and out)
  - Relationship with development planning.
  Note: The tasks may group sets of activities found in §4 to §7 of ISO14971.
  Examples of tasks below:

  2.4.2 Risk analysis initialization
    During this phase, the following activities are performed: 
  identification of intended use, identification of characteristics 
  affecting the safety, assignation of safety class (see §2.5.1) 
  identification of hazards, evaluation of hazards, and identification 
  of foreseeable mitigation actions.
  - Inputs: publications, clinical data, any information prior to design phase
  - Two meetings with clinicians involved in the design process
  - Outputs: intended use, safety characteristics and hazards, 
    creation of risk analysis
  - Relationship with development planning: Output data of this task 
    is input data for specification
  - End of Task review: review of risk analysis in draft version.

  2.4.3 Risk analysis update
    During this phase, the following activities are performed: 
  identification of mitigation actions, evaluation of hazards after 
  mitigation and analysis of risk/patient outcome ratio.
  - Inputs: publications, clinical data, any information prior to design phase
  - Two meetings with clinicians involved in the design process and system architect
  - Outputs: Update of risk analysis
  - Relationship with development planning: this task is performed during specifications
  - End of Task review: review of risk analysis in first revision.

  2.5 Criteria for Acceptability of Risk
    Warning: I recommend you to read carefully §3.4 of IEC 80002-1 to 
  understand how probability of occurrence is determined for software 
  failure.

  Risks will be evaluated in accordance with Risk Management Procedures for:
  - Probability of occurrence
  - Consequence of hazard
  - Any other criteria of your choice, like probability of detection 
    Based on the risk priority number, for each hazard analyzed for 
  XXXX , the Residual Risk will be considered Acceptable if the risk 
  priority number value is less than .

    Based on the risk priority numbers, the Overall Residual Risk for a 
  device will be considered acceptable if the following conditions are 
  satisfied:
  1. None of the identified hazards leads to an unacceptable risk 
     (i.e., no risk priority number above  is 
     identified); and
  2. Another quantitative criterion of your choice
  3. Another one 
      Any risk priority numbers above these values need to have actions 
    taken to reduce the risk.

  2.6 Verification and Risk traceability matrix
   Verification testing activities will be cross-referenced in the 
  risk traceability matrix, as applicable.

  2.7 Approvals
    The Risk Management Plan must be reviewed and approved by XXXX prior 
  to the start of the risk assessment process.
    The Risk Analysis Report will be reviewed and approved by XXXX to 
  ensure completeness and conformance to this Risk Management Plan.

  2.8 Location of Risk Management File
   The Risk Management File is located in XXX (for example a document 
  management tool defined in the software development plan or project 
  management plan). This file contains all the documents related to the 
  management of risk for the device and is kept for the life of the 
  product.

  3 Risk management after software development
  3.1 Organization and Responsibilities
    Describe the organization of the team responsible for risk 
  management after software development. You may add an organization 
  chart.
  Discard if unchanged and during and after software development

  Maintenance Manager    * Overall management process responsibility
                         * Annual Risk Management File Review
                         * Update of Risk Analysis Table
                         * Update of Risk traceability matrix
                         * Update Risk Analysis Report
                         * Independent review of Risk Management File

  3.2 Qualification of personnel
    Describe the qualification of personnel responsible for the risk 
  management and risk analysis activities.
    Discard if unchanged and during and after software development.

  3.3 Production and maintenance information
    The Risk Management File is systematically reviewed and updated in 
  the maintenance of the device, especially when:
  * The product is modified (software patch, minor updates),
  * Analysis of data of post marketing surveillance triggers a 
    reevaluation (internal defects, customer requests, maintenance, 
    vigilance bulletins, of field information from any source),

  3.4 Annual Audit
    Reviews and updates to the Risk Management File will be done 
  annually (choose your periodicity) 
    Reviews and updates to any risk related document will be 
  documented, approved, and included within the Risk Management File.

  4 Ranking System for Risk Analysis
    This section describes how the risk priority number is deduced from 
  the characteristics of the risk:
  * List the criteria defined in §2.2.
  Describe in sub sections how you quantify your criteria, like these:

  4.1 Probability of Occurrence
  Use quantitative criteria. Here is an example.

  Ranking   Definition              Frequency (F)
  ----------------------------------------------------------------------
  5         Every month             Frequent (very high probability)
  ----------------------------------------------------------------------
  4         Once every year         Probable (high probability)
  ----------------------------------------------------------------------
  3         Once in last 5 years    Occasional (moderate probability)
  ----------------------------------------------------------------------
  2         Once in last 10 years   Unlikely (low probability)
  ----------------------------------------------------------------------
  1         Zero occurrence in the  Very Unlikely (very low probability)
            past 10 years with      
            similar products        
  ----------------------------------------------------------------------

  4.2 Consequences of Hazard
  Use criteria based on damages on patient and/or user
  Ranking   Definition    Clinical and Process End Effects
  5         Catastrophic  Serious injury (irreversible) or death of the patient or user
  4         Critical      Serious injury (reversible) to the patient or user.
                          New treatment required.
  3         Moderate      Moderate injury to the patient or user. Longer treatment
                          time or new minor treatment required.
  2         Minor         Minor injury to the patient. Longer treatment time
  1         Negligible/   No injury to the patient or user.
              Cosmetic

  4.3 Add your other criteria
  Your definition


  4.4 Determination of risk priority number
      A rule of your choice, like.
      Risk priority number =   criterion 1
                             x criterion 2
                             ...
                             x criterion n


       Example of cross-table of RPN with two criteria:

       CROSS TABLE OF RISK PRIORITY NUMBER

Frequent     5          10         15        20         25
  5
Probable     4           8         12        16         20
  4
Occasional   3           6          9        12         15
  3
Unlikely     2           4          6         8         10
  2
Very Unlik.  1           2          3         4          5
  1
          Negligible    Minor    Important  Critical   Catastrophic
             1            2        3          4          5


  4.5 Criteria for acceptability
  Acceptability per risk priority number is: (choose your own)
  * If the risk priority number is 1 to xx the risk is acceptable - 
    No recommended actions are required. 
  * If the risk priority number is xx to yy the risk is tolerable - 
    Some actions may be used, where possible, to lower the level. 
  * If risk priority number is above yy the risk is unacceptable. 
    Mitigation action must be implemented to lower the level. 

Soft. Requirement Specs template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]

TABLE OF CONTENTS
1    INTRODUCTION    3
1.1    Document overview    3
1.2    Abbreviations and Glossary    3
1.2.1    Abbreviations    3
1.2.2    Glossary    3
1.3    References    3
1.3.1    Project References    3
1.3.2    Standard and regulatory References    3
1.4    Conventions    3
2    REQUIREMENTS    5
2.1    States    5
2.2    Functionalities and Performance    5
2.3    Safety, security, and privacy protection    6
2.4    User maintenance    6
2.5    Usability and human-factors engineering    6
2.5.1    Man machine interface layout    6
2.5.2    Help    7
2.6    Regulatory requirements    7
2.7    System environment    7
2.8    External interfaces    7
2.8.1    Hardware interfaces    8
2.8.2    Network interfaces    8
2.8.3    Data exchange    8
2.9    Resources    8
2.9.1    Hardware resources    8
2.9.2    Software resources    8
2.10    Internal data    8
2.11    Adaptation    8
2.12    Verification    8
2.13    Personnel and training    9
2.14    Packaging and installation    9
3    VERIFICATION METHODS    10
4    REQUIREMENTS TRACEABILITY    12
5    CRITICAL REQUIREMENTS    13

1    INTRODUCTION
1.1    Document overview
    This document presents the software requirements 
    specifications of XXX software development project.
    It describes:
    * Requirements of functionalities, performances, interfaces, environment ...
    * Tests principles and definitions of validation methods of requirements,
    * The compliance of requirements to customer needs,
    * The relative importance and precedence of requirements
1.2    Abbreviations and Glossary
1.2.1 Abbreviations
      Add here abbreviations

1.2.2 Glossary
      Add here words definitions

1.3    References
1.3.1    Project References

#     Document Identifier  Document Title
[R1]  ID                   Add your documents references.
                           One line per document
                           For example a statement of work, 
                           a user interface mock-up ...

1.3.2 Standard and regulatory References

#        Document Identifier     Document Title      
[STD1]                           Add your documents references.
                                 One line per document
                                 For example: ISO 13485, ...

1.4    Conventions
    Requirements listed in this document are constructed according to 
    the following structure:

Requirement ID        SRS-XXX-000
Title                 Title of XXX-000 requirement
Description           Description of XXX-000 requirement
Version               Version of XXX-000 requirement

Example:

Requirement ID        SRS-GUI-010
Title                 Main Window Background Color
Description           The background color of the main window is grey RGB(192,192,192)
Version               V1.0


2    REQUIREMENTS
Note : have a look at  http://en.wikipedia.org/wiki/Requirement, 
       article in wikipedia. It's well written and the links at the bottom 
       are useful.

2.1    States
FOO software works in three states:
*    Starting: the software loads its components;
*    In use: all the functionalities of the software are available to the users;
*    Stopping: the software is being stopped.
*    Maintenance: the software is in maintenance mode
*    And so on ...
Add a diagram with states and transitions if necessary

2.2    Functionalities and Performance
    This is the core of your SRS. It contains the purpose of your 
    software expressed in technical requirements

    You may organize this part in sub-sections like:
    * Module 1
      o  Function 1.1
         o Sub-Function 1.1
         o Sub-Function 1.2
         o ...
      o    Function 1.2
         o Sub-Function 1.1
         o Sub-Function 1.2
         o ...
      o    ...
    * Module 2
      o    ...
    ...
    Choose your own structure which best fits your needs.

    Requirements shall not be vague. They shall be understandable and testable.
    Ask yourself "How am I going to test this?" when you write a requirement

    Examples of requirement:
    Requirement ID   SRS-XXX-010 SAMPLE
    Title            Sample requirement about a function
    Description      FOO software shall compute the zzz parameters with the 
                     a, , c and d input parameter, with the use of the XXX algorithm.
    Version           V1.0

    Requirement ID   SRS-XXX-020 SAMPLE
    ...

2.3 Safety, security, and privacy protection
This section is about software features like confidentiality, integrity control, reliability, and availability. You can add subsections on:
    · Confidentiality, security, integrity,
    · Virus, malware protection
    · Operational security

    See CyberSecurity requirements of FDA
    See also 2016/679 GPDR in Europe if necessary of data privacy
    Requirement ID  SRS-XXX-030 SAMPLE
    Title           Patient data 
    Description     XXX stores patient data with a checksum to ensure their integrity.
    Version         V1.0

    Requirement ID  SRS-XXX-030 SAMPLE
    Title           Password protected functions
    Description     The following functions are protected by password:
                    * Configuration
                    * Firmware update
    Version         V1.0


2.4 Personal Data
This section is about management of personal data to be compliant with regulations.
See HIPAA requirements, See also 2016/679 GPDR in Europe, especially articles 15 to 22
Requirement ID      SRS-XXX-130 SAMPLE
Title               Right to forget
Description         XXX software has a function to delete all patient data. 
                    The deletion is permanent and not reversible
Version             V1.0

2.5 User maintenance
Maintenance functions accessible by users or by administrators. Do sub-sections if there are different types of users.
Requirement ID     SRS-XXX-040 SAMPLE
Title              Application logs
Description        XXX generates a log file containing:
                   * The state of the application and the steps performed to reach 
                     that state,
                   * The possible error logs, if any.
Version            V1.0

2.6 Usability and human-factors engineering
The requirements here may have traceability with the results of 62366 standard 
implementation
2.6.1    Man machine interface layout
The layout of XXX is ....
Instead of a dozen of text requirements, a mock-up of the software 
GUI is very appreciated
Add only requirements for which a description of layout/behaviour is necessary and/or 
requested by a user.
Requirement ID   SRS-XXX-050 SAMPLE
Title            Menu items and other widgets
Description      XXX software has the following items:
                 * Menu file ...
                 * Widgets in the main window (slider, button, radiobutton, textfield).
                 * ...   
Version          V1.0

2.6.2 Help
The user guide is always very important for medical devices. It 
may be online, in this case add requirements here about the online 
help ....
Requirement ID   SRS-XXX-060 SAMPLE
Title            Online user guide
Description      XXX contains an online user guide
Version          V1.0

2.7 Regulatory requirements
Regulations can have an impact on software design. For example, 
this is the case with the future Unique Device Identification of FDA.
An about window is a good way to identify software version and provide a UDI....

Requirement ID  SRS-XXX-070 SAMPLE
Title           About XXX
Description     XXX shall display an "About..." window. This window displays the current 
                version of the application.
Version         V1.0
...


2.8 System environment
If software is integrated in a specific system, describe briefly 
the system and add specific requirements for the integration of your 
software in this system

Warning : for PEMS/Electro-medical Devices with a big system architecture, a system 
architecture document is necessary to describe the system/software architecture.

2.9 External interfaces
  This section describes hardware and software interfaces of the software in the system 

2.9.1 Hardware interfaces
      For PEMS/Electro-medical Devices, add requirements about 
      integration of software and hardware.

2.9.2 Network interfaces
Also add here communication and networks stuff, like IP, wireless, Bluetooth ...

2.9.3 Data exchange
      If XXX software is in interface with other software, describe here 
      the requirements on data exchanges.

2.10  Resources
2.10.1 Hardware resources
Requirement ID   SRS-XXX-080 SAMPLE
Title            Hardware configuration
Description      XXX shall run with the expected response times on a PC with the 
                 following minimal configuration:
                 *    2 Go RAM
                 *    ...
Version          V1.0

2.10.2 Software resources
Requirement ID  SRS-XXX-090 SAMPLE
Title           Software configuration
Description     XXX runs in the following software environment:
                * (describe OS version),
Version         V1.0

2.11 Internal data
     If specific requirements for internal data, like databases, binary files, xml ...
     It can be necessary to specify internal data if their design mitigates a risk
2.12 Configuration or Adaptation
     If specific requirements adaptability or configuration of software
2.13 Verification
     Special functions to test the software, if necessary. For example 
     a hidden function to activate a log file during beta tests. But not a 
     backdoor or a security hole!!!

2.14 Personnel and training
     Requirements about the capabilities/knowledge of users, the 
     training they shall have before using software

     Requirement ID   SRS-XXX-USR-010 SAMPLE
     Title            E-learning
     Description      XXX is delivered with e-learning module.
     Version          V1.0

2.15 Packaging and installation
     Requirement ID   SRS-XXX-PAK-010 SAMPLE
     Title            Packaging
     Description      XXX shall be delivered on zzz media.
     Version          V1.0

     Requirement ID   SRS-XXX-PAK-010 SAMPLE
     Title            Install-shield
     Description      XXX shall be installed with the use of an install shield.
     Version          V1.0

3 VERIFICATION METHODS
  Discard this section if you don't want to have verification 
  methods attached to your requirements.

The verification methods of the requirements are defined below:
• Inspection (I): control or visual verification
  o Control of the physical implementation or the installation of 
    a component. The control verifies that the implementation or the 
    installation of a component is compliant with the requirements of 
    diagrams.
  o Control of the documentation describing a component. The control verifies that 
    the documentation is compliant with the requirements.
• Analysis (A): verification based upon analytical evidences
  o Verification of a functionality, performance or technical solution of a component 
    by analyzing the data collected by tests in real conditions, by simulation of real 
    conditions or by a analysis report.
  o Analysis of test data or of design data is used as appropriate to verify 
    requirements.
  o The verification is based upon analytical evidences obtained by calculations, like 
    modeling, simulation and forecasting.
  o Analysis is used when an acceptable level of confidence cannot be established by 
    other methods or if analysis is the most cost-effective solution.
• Demonstration (D): verification of operational characteristics, without quantitative 
  measurement
  o Verifying a requirement by demonstration implies that the 
    required functionality specified by a requirement is complete.
  o Demonstration is used when quantitative measurement is not required for 
    verification of the requirements
  o Demonstration includes the control of the technical solutions specified by the 
    non-functional requirements.
• Test (T): verification of quantitative characteristics with quantitative measurement
  o Verifying a functionality, performance or technical solution of a component by 
    executing testing scenarios in predefined, controlled and traceable testing 
    conditions.
  o Tests require the use of special equipment, instrumentation, simulation 
    techniques, or the application of established principles and procedures,
  o Data produced during tests is used to evaluate quantitative results and compare 
    them with requirements.

For each requirement of the SRS, a verification method is defined. 
Method is abbreviated I, A, D or T.

Requirement ID  Requirement Title                          Method
REQ-001         Verify that the speed is displayed in rpm  D
REQ-001         Verify background color  is blue           I

Note: do not mistake the two meanings of the word "test" in this document:
• The method of verification, named Test and abbreviated (T), as defined above.
• A test, or test case, is a sequence of actions to verify a 
  requirement. Tests are defined in the software test plan.

Examples of tests methods:
Inspection:
• Verify that the color of background is blue,
• Verify that the user manual has the CE mark on its cover
• Verify that the PC has 4Gb memory
• Verify that firmware version on electronic card is 1.0.1

Demonstration
• Verify that when the user closes the window, a confirmation message appears
• Verify that the file is saved in the output directory
• Verify that the result is shown
• Verify that if a value is out of range, a warning is displayed

Analysis:
• Verify that the statistical distribution of results of xxx 
  algorithm is a Gaussian with mean=x and stdev=y, when input
  data are blah blah
• Verify that the linear regression of results of xxx algorithm 
  is a line which value is 1 on the y-axis, at zero on the x-axis, 

Test:
• Verify that a file of 1Gb is processed in less than 3s
• Verify that the response time of the server is 15ms with 20 simultaneous requests

Rule of thumb for software, 80% of requirements are verified by 
demonstration, 15% by inspection and 5% by analysis or test methods.

4 REQUIREMENTS TRACEABILITY
  Add a table with traceability of software requirements of this 
  document with user or system requirements.

  Example
SRS Req.    Req Title          Functional Req.  Req. Title
SRS-REQ-001 Reading ECG values FUN-REQ-00A      ECG post treatment
SRS-REQ-002 Writing results    FUN-REQ-00A      ECG post treatment

5 CRITICAL REQUIREMENTS
If necessary, add a list of critical requirements, or a list of reference to requirements in previous sections.
This list may be the result of risk analysis (ISO 14971).

Examples
Requirement ID  Requirement Title                Origin
REQ-001         Alarm when value out of range    Risk Analysis
REQ-002         Do not open file if no patient   Risk Analysis
                name
REQ-003         Display negative values in red   Human factor engineering
                color

System Architecture Template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
1	Introduction	2
1.1	Document overview	2
1.2	Abbreviations and Glossary	2
1.2.1	Abbreviations	2
1.2.2	Glossary	2
1.3	References	2
1.3.1	Project References	2
1.3.2	Standard and regulatory References	2
1.4	Conventions	2
2	Architecture	3
2.1	Architecture overview	3
2.2	Logical architecture overview	3
2.2.1	Software Component 1 description	3
2.2.2	Software Component 2 description	3
2.2.3	Software Component 3 description	3
2.3	Physical architecture overview	3
2.3.1	Hardware Component 1 description	3
2.3.2	Hardware Component 2 description	4
2.3.3	Hardware Component 3 description	4
2.4	Software COTS	4
3	Dynamic behaviour of architecture	5
3.1	Workflow / Sequence 1	5
3.2	Workflow / Sequence 2	5
4	Justification of architecture	6
4.1	System architecture capabilities	6
4.2	Network architecture capabilities	6
4.3	Risk analysis outputs	6
4.4	Human factors engineering outputs	6
5	Requirements traceability	7

1	Introduction
1.1	Document overview
This document describes the architecture of XXX system.

It describes:
* A general description of the system
* The logical architecture of software, the layers and top-level components
* The physical architecture of the hardware on which runs the software
* The justification of technical choices made
* The traceability between the architecture and the system requirements.
1.2	Abbreviations and Glossary
1.2.1	Abbreviations
Add here abbreviations
COTS: Components Off the Shelf (software industry acronym)
OTSS: Off The Shelf Software (FDA acronym)
SOUP: Software Of Unknown Provenance (IEC 62304 acronym)

1.2.2 Glossary
      Add here words definitions
1.3	References
1.3.1 Project References
#    Document Identifier     Document Title
[R1] ID                      Add your documents references.
                             One line per document

1.3.2 Standard and regulatory References

#      Document Identifier     Document Title
[STD1] ID                      Add your documents references.
                               One line per document

1.4	Conventions
Add here conventions
For example for diagrams.

COTS, OTSS and SOUP refer to the same concept, i.e. software delivered by 3rd party that wasn't 
developed with a regulatory and/or normative compliant development process.
We deliberately use the term "SOUP", to focus on IEC 62304 compliance.

2	Architecture 
2.1	Architecture overview
Give a general description of the system, from the point of view of the user:
• In what environment it works (home, near patient bed, operating room ...)
• Who the users are
• What it is for,
• The main functions,
• The main interfaces, inputs and outputs.

If your software is integrated in a larger system, you may reference a document that describes 
this system.

2.2	Physical architecture overview
    Describe the hardware components on which software runs and their interactions/relationships
    Use components diagrams, deployment diagrams, network diagrams, interface diagrams...
2.2.1	Hardware Component 1 description
Describe the content of each hardware component in the architecture
Optional, you may not do it if your software is not class C according to IEC 62304
The description shall contain:
• Its identification
• The purpose of the component
• The software component it receives
• Its technical characteristics: type of machine, CPU, RAM, disk and so on.
• Its network hardware interfaces

2.2.2 Hardware Component 2 description
      Repeat the pattern for each top-level component.
2.2.3 Hardware Component 3 description
      Repeat the pattern for each top-level component.

2.3	Logical architecture overview
    Describe the top level software components and their interactions/relationships.
    Use UML package diagrams and/or layer diagrams and/or interface diagrams.
    Describe also the operating systems on which the software runs.
2.3.1 Software Component 1 description
    Describe the content of each top-level software component in the architecture
    Optional, you may not do it for 2 rationales:
    1. Either your software is not class C according to IEC 62304
    2. Or you describe each top level component in a SDD.

The description should contain:
• Its identification
• The purpose of the component,
• Its interfaces with other components,
• Its network interfaces,
• The hardware resources it uses, for example: average RAM usage, peak RAM usage and 
  peak frequency and duration, disk space for permanent data, disk space for cache data, 
  average CPU usage, peak CPU usage and peak frequency and duration ...
2.3.2 Software Component 2 description
      Repeat the pattern for each top-level component.
2.3.3 Software Component 3 description
      Repeat the pattern for each top-level component.
2.4	Software SOUP
    If you use SOUP (Software Of Unknown Provenance), list them here.
For each SOUP, describe:
• Its identification and version
• Its purpose
• Where it comes from: manufacturer, vendor, university ...
• Wether it is maintained by a third party or not
• If this is an executable,
  o What are the hardware / sotfware resources it uses
  o Wether it is insulated in the architecture and why
• Its interfaces and data flows
• Which SOUP functions the software uses
• How the SOUP is integrated in the software
• What hardware/software resources it requires for proper use

Note: have a look at FDA Guidance " Off-The-Shelf Software Use in Medical Devices " to 
determine if you need specific or special documentation for your COTS.

If there is a list of known bugs on your COTS, you may add here this list with a review of their 
consequences in terms of software failure and patient safety. If there are concerns about known 
bugs, they should be treated by the risk analysis process.

3	Dynamic behavior of architecture
The architecture was designed to answer to functional requirements.
For each main function of the system, add a description of the sequences / data flow that occur.
Use sequence diagrams, collaboration diagrams

3.1	Workflow / Sequence 1
    Describe here the workflow / sequence of a main function 
    For example, the user queries data, what happens, from his terminal to the database.
3.2	Workflow / Sequence 2
    Repeat the patern for each main function of the system
4	Justification of architecture
4.1	System architecture capabilities
    Describe here the rationale of the hardware / software architecture in terms of capabilities:
• Performances (for example response time, user mobility, data storage, or any functional 
  performance which has an impact on architecture)
• User / patient safety (see §4.3 and §4.4)
• Protection against misuse (see 4.4)
• Maintenance (cold maintenance or hot maintenance),
• Adaptability, flexibility
• Scalability, availability
• Backup and restore
• Hardware and Software security : fault tolerance, redondancy, emergency stop, recovery 
  after crash ...
• Administration,
• Monitoring, audit
• Internationalization

4.2	Network architecture capabilities
  If the medical device uses/has a network, describe here the rationale of the hardware / network 
  architecture:
• Bandwidth
• Network failures
• Loss of data
• Inconsistent data
• Inconsistent timing of data
• Cyber security (see FDA Guidance on Cyber Security of networked medical devices)

4.3	Risk analysis outputs
    If the results of risk analysis have an impact on the architecture, describe here for each risk 
    analysis output what has been done to mitigate the risk in the architecture.
    Use diagrams if necessary, like architecture before risk mitigation and architecture after risk 
    mitigation, to explain the choices.

4.4	Human factors engineering outputs
    If (by any chance) the results of human factors analysis have an impact on the architecture, 
    describe here for each risk output what has been done to mitigate the risk in the architecture.

4.5	Regulation on personal data
    If HIPAA or EU Regulation 2016/679 (GDPR) are applicable, describe here how the architecture 
    is compliant to these regulations. For GDPR, see articles 25 and 32.

4.6	SOUP integration
    If the software architecture has a particular structure dedicated to SOUP integration, it can be 
    described here. For example a wrapper of the SOUP, or an external process + a socket 
    communication, ...


5 Requirements traceability
  Add a table with traceability of components of this document with functional requirements.

Requirement   Component                 Comment
REQ-001       The device shall do foo   COMPO-001: foo maker
                                        COMP-001 does foo.
                                        COMP-002 also does 
                                        verification of foo result.

This may be a difficult job. A high level function is usually handled by many components. In this 
case, quote only the component(s) which has(have) the major role.
Soft.Detailed Design template
This Template is the property of Cyrille Michaud @[http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5]
License terms : see @[http://blog.cm-dm.com/post/2011/11/04/License]
Source: @[https://blog.cm-dm.com/pages/Software-Development-Process-templates]
TABLE OF CONTENTS
1    Introduction    2
1.1    Document overview    2
1.2    References    2
1.2.1    Project References    2
1.2.2    Standard and regulatory References    2
2    Software Architecture overview    3
3    Software design description    3
3.1    Component 1    3
3.1.1    Component interfaces    3
3.1.2    Component design description    3
3.1.3    Workflows and algorithms    4
3.1.4    Software requirements mapping    4
3.2    Component 2    4
3.3    Component 3    4
4    SOUP identification    4
5    Critical Requirements    4

1    Introduction
You may have all the description of the design of your software:
* Either in a single instance of this document
* Or have the design of each component/package/element in many instances of this document.
  This is your choice, which depends on the size of your software.

1.1    Document overview
    This document describes the design of XXX 
    component/package/element of XXX device, part of XXX software 
    development project.
1.2    References
1.2.1    Project References
#     Document Identifier  Document Title
[R1]  ID                   Add your documents references.
                           One line per document

1.2.2    Standard and regulatory References
#       Document Identifier  Document Title
[STD1]  ID                   Add your documents references.
                             One line per document

Add your documents references.
One line per document

Add the standard references to the table above. It may include ISO/IEC...


Software Architecture overview
  Describe here the top-level software components and their interactions/relationships.
  Use UML package diagrams and/or layer diagrams and/or interface diagrams.
  Describe also the operating systems on which the software runs.
   You may reference the system architecture document, if you have 
  one in your project, which already explains the software architecture.


3 Software design description
  If you have a single design document, describe each top-level 
  package/component of your software, and if necessary 
  sub-components/sub packages.
* Single instance of design document
  o Top-level-component #1 --> described in section 3.1
    - Sub-component #1 --> described in section 3.1.1
    - Sub-component #2 --> described in section 3.1.2
    - And so on...
  o Top-level-component #2 --> described in section 3.2
    - ...
  o Top-level-component #1 --> described in section 3.3
    - ...
  
If you decide to have one design document for each top-level 
package/component, describe the content (sub components, sub 
packages) of each top-level package/component.

The top-level components shall then be described in the system architecture document
* Top-level-component #1 --> described in instance #1 of SDD document
  o Sub-component #1 --> described in section 3.1
  o Sub-component #2 --> described in section 3.2
  o And so on...
* Top-level-component #2 --> described in instance #2 of SDD document
  o ...
* Top-level-component #3 --> described in instance #3 of SDD document
  o ...

Use Class diagrams, Collaboration / sequence diagrams, Deployment 
diagrams to illustrate your description.

3.1 Component 1
    Describe the component with the structuration relevant to the technology you use.
    Below are examples of sub-sections to describe components.
    If you're in class C, have a look at 5.5.4 of IEC 62304.
3.1.1 Component interfaces
  Describe the interfaces of the component and input output data
3.1.2 Component design description
    Describe the design of the component, Use package diagrams 
  and/or class diagrams to show the links between 
  sub-components/sub-packages and or classes inside the component.
3.1.3 Workflows and algorithms
  Use collaboration diagrams and/or sequence diagrams to show the 
  workflows of components/packages/classes inside the component.  
  Describe algorithms, if possible. An algorithm may be described 
  outside this document, in this case, add the reference to that 
  document.
3.1.4 Software requirements mapping
    Class C software only, list the SRS requirements handled by this component
3.2 Component 2
    Repeat the pattern for each component.
3.3 Component 3
    Repeat the pattern for each component.
4 SOUP identification
  Add the list of SOUP used in software. Example:
  SOUP libraries used in XXX are the following:
  * foo.jar/foo.so/foo.dll, version id, download URL, License 
    type, requirements traceability
  * bar.jar/bar.so/bar.dll, version id, download URL, License type, 
    requirements traceability

Caution: if SRS requirements are handled by SOUP, then 
traceability between SOUP and SRS requirements shall be described 
here.

5 Critical Requirements
If requirement were tagged as critical in the SRS, add here the 
traceability between these requirements and the components described 
in this document. Critical requirements may be those added after risk 
analysis.

Requirement ID   Requirement title      Component      Comment
REQ-001          Software shall have    Main window    Widget added in the 
                 an abort button                       window layout
                                        ----------- 
                                        Main window    Controller aborts the 
                                        controller     operation
Meeting report Template
- Date 
- Title     
- Atendees:
  - Atendee 1
  - Atendee 2
  - ...

- Discusion Points:
  - Topic 1.
  - Topic 2.
  - ...

- Agreed Actions:
  - Action 1: ...        Deadline: YYYY/mm/dd 
  - Action 2: ...    First Review: YYYY/mm/dd
  - ...
Peer to peer Review template
┌─────────────────────────────────────────────────────────────────────
│ Introduction:
│ 
│  Peer Review process for its internal quality assurance for 
│ deliverables to assure consistency and high standard for documented 
│ project results.
│ 
│ - Instructions:
│     The Peer Review is processed individually by selected reviewers. 
│   The allocated time for the review is about two weeks. The author of 
│   the document has the final responsibility to collect the comments and 
│   suggestions from the Peer Reviewers and decide what changes to the 
│   document and actions are to be undertaken.
│   Reviewers:
│ 
│ - [Mr./Ms. NAME] – [ORGANISATION]
│ 
│ 
│ - Overall Peer Review Result:
│   - Deliverable is:
│     o Fully accepted
│     o Accepted with reservation
│     o Rejected unless modified as suggested
│     o Fully rejected
│   
│   - Please give an overall rating of this deliverable in a scale from 
│     (1: very poor to 5: very good) : _______
│ 
│ - Suggested actions:
│   1. The following changes should be implemented ...
│   2. Specify missing chapters / subjects ...
│   3. Required changes on deliverable essence and contents ...
│   4. Further relevant required improvements ...
│ ===========================================================
│ - Comments of Mr/Ms X
│   - GENERAL COMMENT 
│     These refer to:
│     • Deliverable contents thoroughness
│     • Innovation level
│     • Correspondence to project and programme objectives
│ 
│     (...comments...)
│   - SPECIFIC COMMENTS
│ 
│     - Topic A: Relevance
│       - Reviewer comment
│         ...
│       - Author response
│         ...
│     - Topic B: Relevance
│       - Reviewer comment
│         ...
│       - Author response
│         ...
│     - Topic C: Methodological framework soundness
│       - Reviewer comment
│         ...
│       - Author response
│         ...
│     - Topic D: Quality of achievements
│       - Reviewer comment
│         ...
│       - Author response
│         ...
│     - Topic E: Quality of presentation of achievements
│       - Reviewer comment
│         ...
│       - Author response
│         ...
│     - Topic F: Deliverable Layout / Spelling / Format
│       - Reviewer comment
│         ...
│       - Author response
│         ...
└─────────────────────────────────────────────────────────────────────
Risk Management Plan template
It's an important to adhere to ISO 14971.


Soft.Dev. Validation Plan template - (optional) contains elements to help validating software development tools. Software Tests Plan template
(Sofware Component Spec Template)
Category   : front-end | back-end | Middleware | Service | ...

Description: List of Main responsibilies (features) of this component

Constrains : The list of consraints applying to this component:

Composition: This component reuses/integrates the following building
             blocks / products:
             - Commercial Product Name, including version
             - Open Source project name, including version

Licensing  : "Enumerate licensing options for building blocks/ libs:
             - Commercial/Open-source; Needed to assess if any OOSS
               license prohibtis commercialization of final product

Inputs     : - Raw data files (e,g CSV, DBF,...)
             - Online data streams (e.g, Twitter API)
             - Structured data (JSON, XML, protobuff,...)
             - ...

Outputs    : - Structured data (e.g, JSON, XML,...)
             - Unstructured data (Doc, image, pdf,...)
             - ...

Interactions: [Enumerate expected interactions with other components]
              Ex:
              - Receive stream of events from Kafka hub
              - Store "XXX" data in DDBB

Sofware     : Ex: this components requires the following base-software
Requirements      to operate:
              - GNU/Linux AMD64 ....
              - Docker/Swarn (min.version)

Hardware    : - Recomented: 16 Gb RAM, ...
Requirements
              - Minimal:     2 GB RAM ,...
Meeting Output template:
Meeting title: Status and progress meeting
Meeting date: ....
Meeting type: INternal.
Meeting location: Videoconference.
Meeting coordinator: Dnaiel Arosa, 
Issue Date: ...

Attendee Name      Initials    Organisation/Email
...


Meeting Agenda:
1.- ...
2.- Project progress..
3,. Next stesps

Meeting Output Summary:
- Project report:
  - Task 1:
  - Task 2:
  - Task 3:
  ...

Risk and changes:
  - ....

Next steps:
  -...

 Actions table:
 
 ID     Creation date      Description             Status       Target Resolution     Owner
 ...    ...                ....                    ...          ...                   ...   

Soft.Development Estimation Template
                                     │ estimated  │
                                     │ Hours/Days │ Risks(Rº*1 WARN, WARN,  WARN:º)
                                     │────────────│ ─────────────
  Functional Analysis ·············· │            │
  └ User Stores / Sequence Diagrams· │            │
  └ GUI definition ················· │            │
  └ Privacy/Security Definition ···· │            │
                                     │            │
  Module 1: Middleware API           │            │
  └ API Swagger Definition ········· │            │
  └ Implementation                   │            │
    └ Core REST API Server ········· │            │
      └ Logic ······················ │            │
      └ Error Control, filters ····· │            │
  └ Documentation ·················· │            │
                                     │            │
  Module 2: Front-End:               │            │
  └ Control cli Shell ·············· │            │
  └ Async notification system ······ │            │
  └ Documentation ·················· │            │
                                     │            │
  Module 3: BackEnd                  │            │
  └ Development                      │            │
    └ Functional Analysis ·········· │            │
    └ Functional Tests    ·········· │            │
    └ Java Development ············· │            │
  └ Documentation ·················· │            │
                                     │            │
  Infrastructure:                    │            │
  └ CI Environment ················· │            │
    └ Git ·························· │            │
    └ Build Pipelines ·············· │            │
    └ Backups ······················ │            │
    └ Basic Monitoring ············· │            │
  └ Cloud Environment ·············· │            │
    └ Admin tasks ·················· │            │
    └ Deployment Module 1 ·········· │            │
    └ Deployment Module 2 ·········· │            │
      ...                            │            │
  └ Documentation ·················· │            │

Rº*1 WARN, WARN,  WARN:º
  NOTE that the Risk column can weight more than the Estimation column
  in context with high uncertainty as we switch from industrialized
  (automated repetitive tasks) to development of new Software Solutions
  with non-scoped definition about Use-stories, technology stack,...
  Since software is easy to industrialize, many projects fall under the
  second alternative and so Risks must be taken as reference over
  estimations.
94 Google Docs templates
Source: @[https://www.xataka.com/basics/plantillas-google-docs-para-organizarlo-todo]

- Board Member Accountability Form by The Management Center.

- Business Plan, por Smartsheets. to planify a business model, 
  describing the company to be created, and anything related.
- Business Plan, by Google. based on text (vs squares). Very
  detailed.

- Business Plan with Social Impact Statement. 

- Certificate of appreciation, by GooDocs.

- Communication Plan, by ProjectManater.

- Community meeting minutes.

- Company Invoice, by GooDocs.

- Press release:

- Formal Meeting Agenda.

- Invoice professional 

- Meeting agenda:  
    
- Receipt template

- Red Blocks Business (Visit) Card. 
Business Management
Business Research sources
- Gartner
- Forrester
- Oxford Economics
- Euromonitor International
- IDC
- Everest Group Research, ...
- Google Scholar (academic articles). 
- ...
H2020 Expected Project Results
https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/support/glossary

H2020 Result: Communication / Dissemination / Explotation
European Commision Project Results
                                   ^
                                  / \
                                 /   \
      │Research   │             Research          │  MS, EU     │
      │Communities│             Roadmaps          │policiymakers│
                                 │   │                
                  Data           │   │          Policy
                     ┌───────────┘   └─────────┐recommendations   
                     │                         │
                     │                         │
              Publications                     │  Reports
                     │                         │
                     │                         │
     ┌───────────────┘                         └───────────────┐
    { Software                          (Collaboration)platforms}
     \───────────────┐                         ┌───────────────/
                     │                         │
                     │                         │
              Prototypes                    Skills,
                     │                      Knowledge
                     │                         │
                     └───────────┐    ┌────────┘
                   Pre─standards │    │     Educational
                                 │    │      Materials
      │Industry, │               Code Of         │Civic society,│
      │innovators│               Conduct         │ citizens     │
                                 \   /
                                  \ /
                                   v

- Exploitation: The utilisation of results in further research activities 
  other than those covered by the action concerned, or in developing, 
  creating and marketing a product or process, or in creating and 
  providing a service, or in standardisation activities.*

  - But why does Dissemination/Explotation not always happen? 
    or barriers to effective D&E in projects
    o Perceiving dissemination and exploitation as "tick boxes", not 
      important for the "real work" of the project
    o Confusion between communication, dissemination, 
      exploitation. Focusing on implementing and validating technical 
      objectives instead of aligning work with the needs of users and 
      stakeholders.
    o Limited considerations of what can be valuable key results of 
      the project.
    o Lack of skills (or interest) to effectively consider the value 
      and possible benefits of the key results outside "typical" 
      community.
    o Lack of knowledge of dissemination and exploitation risks and 
      opportunities, alternative channels and routes, stakeholders, 
      competing solutions.
    o Lack of reflection and joint discussions within the consortia
EazyBI
- Easy Business Intelligence for Project Teams
- eazyBI cloud
- eazyBI for Jira
- eazyBI for Confluence
- Private eazyBI
Decision Model and Notation
@[https://en.wikipedia.org/wiki/Decision_Model_and_Notation]

See also Goldman Sach implementation in Java:
@[https://github.com/goldmansachs/jdmn]

- Decision Model and Notation (DMN) is a standard published by the 
  Object Management Group.[1] It is a standard approach for describing 
  and modeling repeatable decisions within organizations to ensure that 
  decision models are interchangeable across organizations.

- The DMN standard provides the industry with a modeling notation for 
  decisions that will support decision management and business rules. 
  The notation is designed to be readable by business and IT users 
  alike. This enables various groups to effectively collaborate in 
  defining a decision model:

- the business people who manage and monitor the decisions
- the business analysts or functional analysts who document the 
  initial decision requirements and specify the detailed decision 
  models and decision logic,
- the technical developers responsible for the automation of systems 
  that make the decisions.

- The DMN standard can be effectively used standalone but it is also 
  complementary to the BPMN and CMMN standards. BPMN defines a special 
  kind of activity, the Business Rule Task, which "provides a mechanism 
  for the process to provide input to a business rule engine and to get 
  the output of calculations that the business rule engine might 
  provide"[2][3] that can be used to show where in a BPMN process a 
  decision defined using DMN should be used.

- DMN has been made a standard for Business Analysis according to BABOK v3.[4][5] 
Bitergia (Dev.Analysis)
Bitergia helps you in your understanding, reporting, and decision 
making process regarding community health, project sustainability, 
development efficiency, talent retention and acquisition, content 
creation, developer audience analysis, and more. 
Team tools
MatterMost/Discourse
- Used by CERN as replacement for Facebook Workplace, ...

- https://mattermost.com/
  - OpenSource.
  - Collaborate securely and privately, enterprise-wide
  - Used by many of the world’s leading privacy-conscious enterprises work 
  - connecting people, tools, and automation to increase collaboration.
  - Flexible deployment model: Self-hosted or SaaS
    - Enterprise-grade security and privacy for full control of data
    - Works seamlessly with enterprise security, identity, and compliance systems

- https://github.com/discourse/discourse
  https://discourse.org
  - 100% open source discussion platform.
    - mailing list
    - discussion forum
    - long-form chat room

  - "Civilized discussion for your community"
  - Integrates with slack, wordpress, zendesk, patreon, GitHub, Google Analytics.
  - Over 4.2 million posts / 428 million page views in March 2021.


Twake: OOSS Kanban Prj Mgn
@[https://itsfoss.com/twake-app/]
- focus on Kanban project management methodology.
- Can be used on-line or hosted on premise.
Online Suvey Tools
- SurveyGizmo: 
- Doodle     :
Zeit.io
- Time Tracking:
  Collaborative time tracking for freelancers and agencies.
- Expenses:
  Book not only times but also expenses for a project
- Turn on Approval process for times/expenses per project and/or freelancer.

- Contract Management:
  - Manage contracts with your employees in one central place.
  - Visible for everyone involved.

- Budget controlling.

- Customer management.

- Invoicing

- BºREST API!!!º
Availability: Scheduling Meetings
@[https://app.greenhouse.io/availability]
Dealing with Psychopaths and Narcissists during Agile Change
https://www.infoq.com/articles/psychopats-narcissists-agile-change/ 
Quality Assurance
ISO 9001,20000-1 families
https://en.wikipedia.org/wiki/ISO_9000
- quality management systems (QMS) set of standards 
- Aim: Help organizations ensure they meet customer and 
  other stakeholder needs within statutory and regulatory requirements 
  related to a product or service.
- ISO 9000:  fundamentals of quality management systems
  7 quality management principles:

- ISO 9001:  requirements that organizations need to fulfil.
  (certified by 3rd parties)
RºCritics about usefulness exists.º
OOSS ←→Standard Setting Relationship
Bibliografy:
- “The Relationship Between Open Source Software and Standard Setting,” 
  by Knut Blind, Mirko Boehm, JRC Science Policy Report, Publications Office
  of the European Union, Luxembourg, 2019


Non classified