This section describes our project methodology, called DIG (Design, Implement, Govern), which was partially developed for this project.

Technical Stages

The DIG methodology defines six different stages: Define, Measure, Analyze, Design, Verify, and Control.

Define

The Define Stage establishes the scope of the problem, clarifies context and maps our current capacities at Costaflores, identifies the desired future state, estimates both human and material resource needs, assesses technical risks, and determines if the desired future state should be pursued.

In other words, during this phase, we evaluate “what do we have today”, in terms of PPP: People, Processes, Products. In doing so, we define our “Operational Baseline”

Measure

The Measure Stage helps articulate the project's functional and systemic requirements and constraints as measurable statements of need.

Here we define the Requirements Definition, “what do we want” both in functional terms (how the project should WORK) and systemic terms (how the project should PERFORM).

The project's functional requirements fall into the following categories:

Base functionalities
Provisioning
Support
Localization
Monitoring metrics
Connectivity and Integration

The project's systemic requirements can be broken down into the following categories:

Performance
Availability
Scalability
Security
Recoverability

Both functional and systemic requirements are documented by individual requirement identifiers, which reference the requirements definition, priority, and additional descriptors.

Analyze

During the Analyze Stage, we develop an architectural design for a solution that attends to our functional and systemic requirements, considering our current capacities (operational baseline).

In other words, were we define the Architecture Specifications for “what are we going to build”.

Design

The Design Stage specifies the Implementation Plan for the architecture specifications.

Here we define component specifications based on the architecture, and also define the strategy for implementing those components.

Simply put, this is the phase where we document “how we are building the solution.”

Verify

The Verify Stage implements the solution and validates that our requirements were met according to a Test Plan. So during this stage, we execute the implementation plan (we build the solution), and we execute the test plan, in order to determine if “we achieved our success criteria?”

Control

Finally, during the Control Stage, we execute our Control Plan, the instructions for operating the solution in production mode.

Documentation Deliverables

The documentation for project deliverables are defined for each phase as follows:

Project Phase	Documentation Deliverables
Define	Operational Baseline
Measure	Requirements Definition
Analyze	Architecture Specifications
Design	Implementation Plan
Verify	Test Plan
Control	Control Plan

Tools

The following tools are used to manage the Openvino project:

All documentation for the project is found on this site
Progress tracking is managed using trello.com

Trello configuration and methodology

If you are working on components of Openvino, you need both a wiki.costaflores.com account and an Openvino team member account for trello.com.

Trello is used to track the status of Openvino module develop and tasks. The primary board in trello is called "Masterplan".

The Masterplan board contains 6 cards:

Operational Baseline	Requirements Definition	Architecture Specification	Implementation Plan	Test Plan	Control Plan
Dashboard
		Websites Migration
					Social Media Plan

The columns define the phase for each deliverable. The color label, defines which of the six silos the deliverable belongs to.

As each deliverable completes a phase, the owner moves it to the next.

The name of the deliverable (i.e. "Website Migration") refers another board of the same name.

Each deliverable board, follows the above color code, and each contains 4 cards, with the following purpose:

Proposed	Documented	Validated	Communicated
Was the change proposal posted to the team?	Was the change documented in the wiki?	Was the change executed and tested?	Was the change resolution communicated to the team?

Every procedure begins in the "Proposed" card, and finalizes within the "Communicated" card. This is simple mechanism of change management.

Individual cards may have different members, checklists, comments, due dates, attachments, as defined in trello by the board and procedure owners:

Work Sequence

The following table defines the steps, from start-to-finsih, for new deliverables.

Step	Phase	Documentation Type	Process
	Define	Operational Baseline
1		Proposed	Create a new deliverable board in Trello. Set the background. Make the board team visible, and add team members. Create 4 lists: "Proposed", "Documented", "Validated", "Communicated". Add cards in the “Proposed” section describing the different aspects of the deliverable. Create a card on the Masterplan board, with the name of the new deliverable board. Add the “Label” according to the Openvino Silo.
2		Documented	Edit the description of each card, with information about the deliverable procedure. Include checklists, due dates, and any relevant attachments. Move the procedure to the “Documented” column.
3		Validated	Have you received feedback (thumbs up) from all deliverable team members indicating all is good to go? Once you have, move the card to the “Validated” list.
4		Communicated	Post a short blog entry on the wiki, including a brief description, and tagging team members involved. “On Thursday, we begin working on the Vineyard IoT sensor data to Sidechain project”. Move the card to the Communicated list.
5			Once ALL the cards are in the Communicated list, move the cards back to the Proposed list Move the Masterplan card to the “Requirements Definition” list.
	Measure	Requirements Definition
6		Proposed	Create the template in the wiki where these deliverable procedures will be documented, and communicate to the team. At this stage both the “Requirements Definition” template, and the “Test Plan” template should be created. Assign responsibilites to team members.
7		Documented	Have team members fill in the “Requirements Definition template AND “Test Plan” template, creating and assigning individual CTQ (critical-to-quality) entries for every functional and systemic requirement. Move the card to the Documented list.
8		Validated	Have you received feedback (thumbs up) from all deliverable team members indicating all is good to go? Once you have, move the card to the “Validated” list.
9		Communicated	When a card has been validated by all team members, send a short message to team members informing that this card is closed, and move it to the “Communicated list”.
10			Once ALL the cards are in the Communicated list, move the cards back to the Proposed list. Move the Masterplan card to the “Architecture Specifications” list.
	Analyze	Architecture Specifications
11		Proposed	Create the template in the wiki where the Architecture components (hardware, software, networking, identities, etc.) for the deliverable procedures will be documented, and communicate to the team. Assign responsibilites to team members.
12		Documented	Team members create the necessary documentation of servers, operating systems, applications, network configurations, directory services, etc. that underpin the deliverable. Move the card to the Documented list.
13		Validated	Have you received feedback (thumbs up) from all deliverable team members indicating all is good to go? Once you have, move the card to the “Validated” list.
14		Communicated	When a card has been validated by all team members, send a short message to team members informing that this card is closed, and move it to the “Communicated list”.
15			Once ALL the cards are in the Communicated list, move the cards back to the Proposed list, and move the Masterplan card to the “Implementation Plan” list.
	Design	Implementation Plan
16		Proposed	Create the template in the wiki where the “Implementation Plan” for the deliverable procedures will be documented, and communicate to the team. Assign responsibilites to team members.
17		Documented	Team members implement AND document the necessary components for the procedure. THIS IS WHERE THE ACTUAL WORK GETS DONE. When work AND documentation is complete, move the card to the Documented list.
18		Validated	Have you received feedback (thumbs up) from all deliverable team members indicating all is good to go? Once you have, move the card to the “Validated” list.
19		Communicated	When a card has been validated by all team members, send a short message to team members informing that this card is closed, and move it to the “Communicated list”.
20			Once ALL the cards are in the Communicated list, move the cards back to the Proposed list, and move the Masterplan card to the “Test Plan” list.
	Verify	Test Plan
21		Proposed	Review the Test Plan created in step 6. Assign testing responsibilities to team members.
22		Documented	Execute the test plan, and make any necessary updates or changes.. When this is complete, move the card to the “Documented” list.
23		Validated	Have you received feedback (thumbs up) from all deliverable team members indicating all is good to go? Once you have, move the card to the “Validated” list.
24		Communicated	When a card has been validated by all team members, create a short message to the team, entry indicating that the testing phase has finished successfully.
25			Once ALL the cards are in the Communicated list, move the cards back to the Proposed list, and move the Masterplan card to the “Test Plan” list.
	Control	Control Plan
26		Proposed	Create the template in the wiki where the “Control Plan” for the deliverable procedures will be documented, and communicate to the team. Assign responsibilites to team members.
27		Documented	Team members create the necessary documentation for operating the deliverable service, including daily, weekly, monthly, and periodic mantenance tasks. This should also include monitoring variables and thresholds, and security constraints. Once this is finished, move the card to the “Documented” list.
28		Validated	Have you received feedback (thumbs up) from all deliverable team members indicating all is good to go? Once you have, move the card to the “Validated” list.
29		Communicated	When a card has been validated by all team members, create a short BLOG entry indicating that the deliverable has gone into production. Congratulations! You have finished.
30			The board entry can be archived.

OpenVino

DIG Project Methodology