Page tree
Skip to end of metadata
Go to start of metadata

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 PhaseDocumentation DeliverablesGrowing the GrapesManaging and Delivering the WineManaging the Business

Wine-backed Cryptocurrency

You Drink It, You Own ItTelling Our Story
DefineOperational Baseline





MeasureRequirements Definition





AnalyzeArchitecture Specifications





DesignImplementation Plan





Verify

Test Plan







ControlControl Plan





Tools

The following tools are used to manage the Openvino project:

  • All documentation for the project is found on this wiki 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 BaselineRequirements DefinitionArchitecture SpecificationImplementation PlanTest PlanControl 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:

ProposedDocumentedValidatedCommunicated
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.

StepPhaseDocumentation Type
Process

DefineOperational Baseline

1
Proposed
  1. Create a new deliverable board in Trello.
  2. Set the background.
  3. Make the board team visible, and add team members.
  4. Create 4 lists: "Proposed", "Documented", "Validated", "Communicated".
  5. Add cards in the “Proposed” section describing the different aspects of the deliverable.
  6. Create a card on the Masterplan board, with the name of the new deliverable board.
  7. Add the “Label” according to the Openvino Silo.
2
Documented
  1. Edit the description of each card, with information about the deliverable procedure. Include checklists, due dates, and any relevant attachments.
  2. 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
  1. 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”.
  2. Move the card to the Communicated list.
5


  1. Once ALL the cards are in the Communicated list, move the cards back to the Proposed list
  2. Move the Masterplan card to the “Requirements Definition” list.

MeasureRequirements Definition

6
Proposed
  1. 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.
  2. Assign responsibilites to team members.
7
Documented
  1. 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.
  2. 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


  1. Once ALL the cards are in the Communicated list, move the cards back to the Proposed list.
  2. Move the Masterplan card to the “Architecture Specifications” list.

AnalyzeArchitecture 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.

DesignImplementation 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.

VerifyTest 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.

ControlControl 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.



  • No labels
Write a comment…