Extreme Enterprise Event Design: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
Line 11: Line 11:
*Initial Requirement - one page doc, can be pulled in from existing wiki assets and [[OSE Specifications]]
*Initial Requirement - one page doc, can be pulled in from existing wiki assets and [[OSE Specifications]]
*High level functional requirements determined by SMEs
*High level functional requirements determined by SMEs
*Functional units determined through modular decomposition [Modular decomposition strategies to be added soon]
*A “definition of done“ needs to be formulated and agreed to by the SME’s performing the modular decomposition.
*This will help to focus goals and prevent design creep in this planning phase.
*The definition of done for this phase should be a general outline that describes the essential goals the SME’s must achieve to build the design template requirements/constraints.
*The following questions and steps being completed could be the “definition of done”, but this is a flexible item and should be tailored to the needs of the particular design event.
 
 
*Functional units determined through modular decomposition  
**SMEs will answer generalized and product specific questions. The following questions are a good starting point.
***Disclaimer: These questions are not law, they are meant to steer design planning/thinking in a coherent direction. When they are insufficient, they should be added to. When they are ill fitting they should not be used. As better questions are identified they should add to a replace the following.
**What are the sub-units the total product can be broken into such that each maintain a '''''specific and independent function'''''?
*** for a simple example, a hand drill might decompose into the following modules : motor module, power storage/delivery module, driver/chuck and bit module, and a handle module. Each of the above has a function of it's own, however, only when combined together do we see the emergent behavior of a handheld drill.
**Does OSE GVCS have a design that will interface with this product(or module of the product) in the product ecology map?
***If yes, what are the interfaces and performance requirements that will maintain product ecology?
***If no, What are important considerations for how this module will interface with the rest of the system? How much volume can a design occupy? What inputs does it receive? What outputs does it produce? What is the format of these outputs? How well do those outputs generalize across the range of possible recipients?
 
**Does a design pattern exist for the product to be developed?
***If yes, Does the product to be developed replace, modify, or parallel the existing design?
***If it is to parallel the existing design what are the functional/interface differences that necessitate the redesign?
****If there are no clear answers to this question consider using the existing pattern instead of redesigning
***If it is to replace the existing design evaluation should be performed that the new products design requirements fulfill all roles of the design pattern being replaced.
 
 
*Technical team composition will be determined by SME’s for each module proposed based on the skill sets required for development
*Technical team composition will be determined by SME’s for each module proposed based on the skill sets required for development
*How the functions will interface with other modules shall be constrained in this step to assure product ecology is attainable [[Product Ecologies]]
*How the functions will interface with other modules shall be constrained in this step to assure product ecology is attainable [[Product Ecologies]]
*Pattern Diagrams/languages developed for Wiki to track and integrate the products developed
*Pattern Diagrams/languages developed for Wiki to track and integrate the products developed
* '''Goal:''' Producing documentation that describes requirements and constrain critical interfaces for each module to be developed in the XE event. Describe technical skill-sets necessary for dev-team success for  each module. Fully Describe how modules will interface e.g. inputs/outputs, Connectors, Signal/language type, and all known spatial constraints.
* '''Goal:''' Producing documentation that describes requirements and constrain critical interfaces for each module to be developed in the XE event. Describe technical skill-sets necessary for dev-team success for  each module. Fully Describe how modules will interface e.g. inputs/outputs, Connectors, Signal/language type, and all known spatial constraints.
*After the product has been decomposed into module templates consisting of constraints and performance requirements derived from how the module will interface with other product modules the SMEs need to describe the technical backgrounds needed to complete the design. These backgrounds will be the basis for design team make-up during the XE event.
*The workflow of the design process also needs to be considered such that organizational/management skill sets necessary to keep efforts organized can be baked into the team composition.


*Define [[Swarming Strategies]] for all elements of event - ie, how a swarm can divide roles and solve a task rapidly.
*Define [[Swarming Strategies]] for all elements of event - ie, how a swarm can divide roles and solve a task rapidly.

Revision as of 23:36, 13 July 2020

Internet Infrastructure

Role Architecture

edit

Pre-Preparation

  • Initial Requirement - one page doc, can be pulled in from existing wiki assets and OSE Specifications
  • High level functional requirements determined by SMEs
  • A “definition of done“ needs to be formulated and agreed to by the SME’s performing the modular decomposition.
  • This will help to focus goals and prevent design creep in this planning phase.
  • The definition of done for this phase should be a general outline that describes the essential goals the SME’s must achieve to build the design template requirements/constraints.
  • The following questions and steps being completed could be the “definition of done”, but this is a flexible item and should be tailored to the needs of the particular design event.


  • Functional units determined through modular decomposition
    • SMEs will answer generalized and product specific questions. The following questions are a good starting point.
      • Disclaimer: These questions are not law, they are meant to steer design planning/thinking in a coherent direction. When they are insufficient, they should be added to. When they are ill fitting they should not be used. As better questions are identified they should add to a replace the following.
    • What are the sub-units the total product can be broken into such that each maintain a specific and independent function?
      • for a simple example, a hand drill might decompose into the following modules : motor module, power storage/delivery module, driver/chuck and bit module, and a handle module. Each of the above has a function of it's own, however, only when combined together do we see the emergent behavior of a handheld drill.
    • Does OSE GVCS have a design that will interface with this product(or module of the product) in the product ecology map?
      • If yes, what are the interfaces and performance requirements that will maintain product ecology?
      • If no, What are important considerations for how this module will interface with the rest of the system? How much volume can a design occupy? What inputs does it receive? What outputs does it produce? What is the format of these outputs? How well do those outputs generalize across the range of possible recipients?
    • Does a design pattern exist for the product to be developed?
      • If yes, Does the product to be developed replace, modify, or parallel the existing design?
      • If it is to parallel the existing design what are the functional/interface differences that necessitate the redesign?
        • If there are no clear answers to this question consider using the existing pattern instead of redesigning
      • If it is to replace the existing design evaluation should be performed that the new products design requirements fulfill all roles of the design pattern being replaced.


  • Technical team composition will be determined by SME’s for each module proposed based on the skill sets required for development
  • How the functions will interface with other modules shall be constrained in this step to assure product ecology is attainable Product Ecologies
  • Pattern Diagrams/languages developed for Wiki to track and integrate the products developed
  • Goal: Producing documentation that describes requirements and constrain critical interfaces for each module to be developed in the XE event. Describe technical skill-sets necessary for dev-team success for each module. Fully Describe how modules will interface e.g. inputs/outputs, Connectors, Signal/language type, and all known spatial constraints.
  • After the product has been decomposed into module templates consisting of constraints and performance requirements derived from how the module will interface with other product modules the SMEs need to describe the technical backgrounds needed to complete the design. These backgrounds will be the basis for design team make-up during the XE event.
  • The workflow of the design process also needs to be considered such that organizational/management skill sets necessary to keep efforts organized can be baked into the team composition.


Before

  1. Reach out to candidates with a short, inspiring intro email. See if they are 'interested'.
  2. Prepare a Media Kit on OSE, and specifically on Extreme Enterprise - to include FMI. Build upon existing Media Kits
  3. For people that respond positively, send a second email with much deeper intro describing what will be required to pull this off. This determines if they are not only 'interested' in the idea, but can commit to the 24 hours, and the 1 prep meeting beforehand - and one team meeting with entire group prior to event.

During

  1. Do a Kickstarter campaign to focus enterprise assets, and do other campaigns depending on the time allotted.
  2. Do video, such as Kickstarter and other promos
  3. Crowdfund
  4. Have a 24-7 access video room.
  5. Have ancillary lessons on content from SMEs.
  6. Publish website for MOOC on the content

...

After

Governance

  1. All assets generated on design and enterprise are open source
  2. Anything can be edited mercilessly by anyone, with due respect.
  3. Some assets belong to OSE.
  4. We do escrow account for funding disbursement - if we don't get enough presales, we simply give it back. In a conditional sale, this is not an issue.
  5. Whoever creates something can start a business, but they must publish all assets.
  6. ALL assets are published on the wiki

Links