Development Approach: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
No edit summary
 
(15 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=Steps to Success - Hardware=


'''On Development'''


It's either figuring out a new concept, setting dimensions/details for a new technology, or pondering how to make something.
=Problem Statement and Development Approach=


Order your projects well- do you have the right tools? Get some first to avoid transition losses due to "darn, we need to order that". Do you have the right software? Set it up so that you avoid timesinking into learning it half-way through a project.  
This is a constantly updated short description of a problem that is currently being worked on that provides a further description for involving developers.


Before you start a project, intend to finish it. Prepare well so that each step is straightforward.  
The Development Approach is a strategic, emergent, agile approach towards building a certain prototype determined by the product owner. Depending on the available resources, scheduling, timelines, dogfooding needs, development of other prototypes, product ecologies, features of OSE Specifications, and other situational factors, a certain approach is favored over another.


'''On [[Suppliers]]'''
The development approach should include decisions on the types of components used and a specific implementation pathway - to be tested according to [[Test-Driven Design]].


Avoid spending too much time with broad search bars. There's a finite number of great suppliers applicable to your area- find them to focus your navigation scope.
=Protocol=


Make a hyperlink list of reliable suppliers that stock well and ship fast. Be sure to categorize the list for easy navigation.
#Embed a Critical Path Diagram in the wiki - with as much detail as possible
 
#Show Tech Choices from Tech Tree of Choices
Get tool and material sourcing to a pow-pow-done straightforwardness.
#Link to any salient results.
 
'''On [[Design Resources]]'''
 
Designs frequently use the same concepts over and over again. Record these concepts and make them easy to navigate, then attach info about design considerations and associated mathematics.
 
Getting and using great design software can be a hassle. If possible, try using software that is accessible to others for the collaborative access boost.
 
'''On Use of Tools and Materials'''
 
From design to execution. So the workshop has a bunch of tools and a bunch of materials all organized in some way. Now, how to make the design? Safety first- accessible equipment and warnings! Then proper signs, effective organization, instructionals and especially first-hand experience.
 
Using any part of the workshop should eventually become pow-pow-done straightforward.
 
'''On Concept into Details into Execution'''
 
Grasping the concept of a cup is easy enough. But try adding dimensions and you'll need math equations about human hand ergonomics. Even past dimensions, how to get the right tools and materials and how to know the exact techniques for actually doing it... crippling.
 
Fortunately, a lot of tools should already be in the workshop and the material supplier list should easily handle the rest of the sourcing. Excellent design resources will handle the itty-bitty details. Finally, a well-developed, well-maintained workshop with accessible use information will handle the rest. Everything will become ridiculously simple- eventually.

Latest revision as of 14:31, 5 October 2013


Problem Statement and Development Approach

This is a constantly updated short description of a problem that is currently being worked on that provides a further description for involving developers.

The Development Approach is a strategic, emergent, agile approach towards building a certain prototype determined by the product owner. Depending on the available resources, scheduling, timelines, dogfooding needs, development of other prototypes, product ecologies, features of OSE Specifications, and other situational factors, a certain approach is favored over another.

The development approach should include decisions on the types of components used and a specific implementation pathway - to be tested according to Test-Driven Design.

Protocol

  1. Embed a Critical Path Diagram in the wiki - with as much detail as possible
  2. Show Tech Choices from Tech Tree of Choices
  3. Link to any salient results.
Retrieved from "https://wiki.opensourceecology.org/index.php?title=Development_Approach&oldid=108561"