Commit 19e144ca authored by AIFORSE Community's avatar AIFORSE Community

Merge branch 'vgrigoryevskiy' into 'master'

Principles for all 4 AIFORSE Frameworks

See merge request !4
parents 15d751b8 43183ac1
# Application Framework Principles
The list of principles which drive AIFORSE Application Framework approaches to software engineering applications ("APPLICATION") development and usage is provided below.
## Principles
APPLICATION must be:
* **[DEFINED-BY-PROCESS](#defined-by-process)**
* **[DATA-FLOW-ORIENTED](#data-flow-oriented)**
## Explanations and Examples
### **DEFINED-BY-PROCESS**
An APPLICATION shall provide a Solution for a particular PROCESS (or/and their parts), defined in the [Process Framework](../Process%20Framework (AIFORSE_procF)/), and hence, shall realize all the [Process Framework Principles](../Process%20Framework (AIFORSE_procF)/Process%20Framework%20Principles.md).
### **DATA-FLOW-ORIENTED**
An APPLICATION shall identify a complete set of ARTIFACTs - which are used (read) as an *input* to an APPLICATION and which are affected (created/updated/deleted) as an *output* of an APPLICATION - defined in the [Information Framework](../Information%20Framework (AIFORSE_infoF)/), and hence, shall realize all the [Information Framework Principles](../Information%20Framework (AIFORSE_infoF)/Information%20Framework%20Principles.md).
\ No newline at end of file
# Information Framework Principles
The list of principles which drive AIFORSE Information Framework approaches to software engineering artifacts ("ARTIFACT") management is provided below.
## Principles
ARTIFACT must be:
- **[TOOL-AGNOSTIC](#tool-agnostic)**
- **[IDENTIFIABLE](#identifiable)**
- **[COMPARABLE](#comparable)**
- **[VERSIONABLE](#versionable)**
- **[SEARCHABLE](#searchable)**
- **[ACCESSIBLE](#accessible)**
## Explanations and Examples
### **TOOL-AGNOSTIC**
All the forthcoming principles must be realized on the ARTIFACT Source Data Level, but not on the level of an Application, which manages this ARTIFACT.
* **DOs**:
* Source Code - in general, can be stored in any VCS (version control system) and can be managed by any IDE (integrated development environment) or even without it.
* **DON'Ts**:
* Technical Design, stored in MS Word format, is finally stored as a binary file, which cannot be opened without MS Word application.
### **IDENTIFIABLE**
Each ARTIFACT (and event its specific parts) shall be treated as Asset, which can be tracked, referenced and located by its unique identifier (not necessarily globally unique).
And such identifier shall be available not on the Application level, but on the Data level, to enforce the TOOL-AGNOSTIC Principle.
* **DOs:**
* JIRA Ticket - has a human-readable unique identifier within its Project.
* JAVA Method - has a unique name within its Interface/Class.
* **DON'Ts:**
* User Story, captured in a spreadsheet as just its name without any artificial identifier.
### **COMPARABLE**
It shall be possible to compare two different ARTIFACTs in order to identify how each of them differs from another one and what the common part is.
And such comparison shall be able to be done not only on the Application level, but also on the Data level, to enforce the TOOL-AGNOSTIC Principle.
* **DOs:**
* Test Cases, written in Gherkin language, compared by any Diff Tool.
* **DON'Ts:**
* Software Diagrams (e.g. Activity Flow Diagram) stored as MS Visio Files.
* Configuration File, stored as Excel Spreadsheet.
### **VERSIONABLE**
It shall be possible to version an ARTIFACTs in order to identify *which changes* are done, *when* and *by whom*.
And such versioning shall be able to be done not only on the Application level, but also on the Data level, to enforce the TOOL-AGNOSTIC Principle.
- **DOs:**
- Configuration File, stored in the YAML Format, versioned in any VCS.
- **DON'Ts:**
- User Interface Prototypes, created in Axure RP or Marvel App.
### **SEARCHABLE**
It shall be possible to text-search within a content of an ARTIFACTs in order to find needed information or locate some of its parts.
And such search shall be able to be done not only on the Application level, but also on the Data level, to enforce the TOOL-AGNOSTIC Principle.
- **DOs:**
- Configuration File, stored in the YAML Format, versioned in any VCS.
- **DON'Ts:**
- Software Diagrams (e.g. Activity Flow Diagram) stored as pictures.
### **ACCESSIBLE**
It shall be possible to save, store and retrieve an ARTIFACT through a commonly available interface in order to find needed information.
And such access shall be able to be done not only on the Application level, but also on the Data level, to enforce the TOOL-AGNOSTIC Principle.
- **DOs:**
- Centralized Document Server with configured Authentication and Authorization Privileges.
- **DON'Ts:**
- ARTIFACTS stores as pictures and attachments in mailboxes.
\ No newline at end of file
# Integration Framework Principles
The list of principles which define AIFORSE Integration Framework is provided below.
## Principles
The Principles are:
- [OPEN API](#open-api) [^1]
- [OPEN ESB](#open-esb) [^2]
## Explanations and Examples
### **OPEN API**
Each of the Application, defined in the Application Framework, must provide Public API, which can be used to integrate this Application into the End-to-End Software Engineering Process.
* **DOs**:
* Git Command Line Instructions - can be easily managed with Automated Scrips.
* JIRA REST API - can be used to automatically report a new Ticket, resolve existing one etc.
* **DON'Ts**:
* Invision - it doesn't provide API, which makes the Programmatic Access to Design Information captured in Invision files impossible.
### **OPEN ESB**
Each of the Application, defined in the Application Framework, should avoid Point-to-Point Integration with all other Applications, defined in the Application Framework, but instead provide an Adaptor to a single Bus, which shall be owned and maintained by a community (free and open-source).
- **DOs**:
- Elastic Stack & Apache Kafka - provides a configurable toolbox, which can be embedded into existing architecture, independent on already existing parts of it, to log software-related operations.
- **DON'Ts**:
- Slack - it provides integration adapters to different tools (e.g. JIRA, Asana, Jenkins CI etc.), but this approach couples systems together tightly and creates excessive dependencies.
------
[^1]: Not to be confused with [OpenAPI](https://www.openapis.org).
[^2]: Not to be confused with [OpenESB](http://www.open-esb.net).
\ No newline at end of file
# Process Framework Principles
> *If you can't describe what you are doing as a process, you don't know what you are doing.*
>
> -W. Edwards Deming
The list of principles which drive AIFORSE Process Framework approaches to software engineering processes ("PROCESS") management is provided below.
## Principles
PROCESS must be:
* **[DOCUMENTED](#documented)**
* **[DATA-FLOW-RELATED](#data-flow-related)**
* **[SEQUENTIAL](#sequential)**
* **[ASSIGNABLE](#assignable)**
* **[VERIFIABLE](#verifiable)**
* **[MEASURABLE](#measurable)**
* **[TRACEABLE](#traceable)**
* **[SCALABLE](#scalable)**
## Explanations and Examples
### **DOCUMENTED**
A PROCESS shall be documented in order to enable its execution analysis and all the forthcoming principles.
To make this information usable, a PROCESS shall be documented following the [Information Framework Principles](../Information%20Framework (AIFORSE_infoF)/Information%20Framework%20Principles.md).
### **DATA-FLOW-RELATED**
A PROCESS shall consist of atomic PARTs (steps), each of which shall have:
- identified a complete set of ARTIFACTs - which are used (read) as an *input* to this PART and which are affected (created/updated/deleted) as an *output* of this PART - defined in the [Information Framework](../Information%20Framework (AIFORSE_infoF)/).
### **SEQUENTIAL**
A PROCESS shall consist of atomic PARTs (steps), each of which shall have:
* identified DEPENDENCIES on other PROCESSes and/or PARTs.
### **ASSIGNABLE**
A PROCESS shall consist of atomic PARTs (steps), each of which shall have:
- identified ACTOR (individual/system), responsible for this PART.
### **VERIFIABLE**
A PROCESS shall consist of atomic PARTs (steps), each of which shall have:
- DEFINITION OF DONE
### **MEASURABLE**
A PROCESS shall consist of atomic PARTs (steps), each of which shall have:
- quantifiable METRICs which describe this PART.
### **TRACEABLE**
It shall be possible at any moment of the time to identify on which PART(-s) a particular PROCESS instance is.
### **SCALABLE**
A PROCESS and each of its atomic PARTs (steps) shall be able to be scaled.
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment