Development Approach - Revision history

Marcin: /* Protocol */

2013-10-05T14:31:42Z

Protocol

← Older revision		Revision as of 14:31, 5 October 2013
Line 10:		Line 10:

	=Protocol=		=Protocol=

	#Embed a Critical Path Diagram in the wiki - with as much detail as possible		#Embed a Critical Path Diagram in the wiki - with as much detail as possible
	#Show Tech Choices from Tech Tree of Choices		#Show Tech Choices from Tech Tree of Choices
	#Link to any salient results.		#Link to any salient results.

Marcin at 02:32, 16 September 2013

2013-09-16T02:32:37Z

@@ Line 1: / Line 1: @@
 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.
@@ Line 5: / Line 11: @@
 =Protocol=
 #Embed a Critical Path Diagram in the wiki - with as much detail as possible

Marcin at 00:44, 9 August 2013

2013-08-09T00:44:44Z

← Older revision		Revision as of 00:44, 9 August 2013
Line 2:		Line 2:

	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]].		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=
			#Embed a Critical Path Diagram in the wiki - with as much detail as possible

Marcin at 03:47, 2 August 2013

2013-08-02T03:47:01Z

← Older revision		Revision as of 03:47, 2 August 2013
Line 1:		Line 1:
	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 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]].

Marcin at 01:20, 2 August 2013

2013-08-02T01:20:46Z

← Older revision		Revision as of 01:20, 2 August 2013
Line 1:		Line 1:
	The Development Approach is a strategic 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 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.

Marcin at 01:20, 2 August 2013

2013-08-02T01:20:16Z

← Older revision	Revision as of 01:20, 2 August 2013
Line 1:	Line 1:
		The Development Approach is a strategic 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.

Marcin: Blanked the page

2013-08-02T00:40:32Z

Blanked the page

← Older revision		Revision as of 00:40, 2 August 2013
Line 1:		Line 1:
	~~#REDIRECT [[Development Guide]]~~

YK: Redirected page to Development Guide

2012-12-13T09:30:36Z

Redirected page to Development Guide

← Older revision		Revision as of 09:30, 13 December 2012
Line 1:		Line 1:
	~~=Steps to Success - Hardware=~~		#REDIRECT [[Development Guide]]

	~~'''On Development'''~~

	~~It's either figuring out a new concept, setting dimensions/details for a new technology, or pondering how to make something.~~

	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.

	~~Before you start a project, intend to finish it. Prepare well so that each step is straightforward.~~

	~~'''On~~ [[~~Collaboration Resources]]'''~~

	~~Working with others? Set up the communication channels, work out the finances, be clear and detailed to avoid misunderstandings.~~

	~~'''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 [[Suppliers]]'''~~

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

	~~Make a hyperlink list of reliable suppliers that stock well and ship fast. Be sure to categorize the list for easy navigation.~~

	~~Get tool and material sourcing to a pow-pow-done straightforwardness.~~

	~~'''On [[Action Resources]]'''~~

	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 [[Documentation Resources~~]]~~'''~~

	~~For documentation, keep things clear and concise. Avoid long strings of hyperlinks. Make navigation simple.~~

	~~'''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.

YK at 08:12, 13 December 2012

2012-12-13T08:12:28Z

← Older revision		Revision as of 08:12, 13 December 2012
Line 8:		Line 8:

	Before you start a project, intend to finish it. Prepare well so that each step is straightforward.		Before you start a project, intend to finish it. Prepare well so that each step is straightforward.

			'''On [[Collaboration Resources]]'''

			Working with others? Set up the communication channels, work out the finances, be clear and detailed to avoid misunderstandings.

	'''On [[Design Resources]]'''		'''On [[Design Resources]]'''

YK at 08:07, 13 December 2012

2012-12-13T08:07:57Z

← Older revision		Revision as of 08:07, 13 December 2012
Line 14:		Line 14:

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

	~~For documentation, keep things clear and concise. Avoid long strings of hyperlinks. Make navigation simple.~~

	'''On [[Suppliers]]'''		'''On [[Suppliers]]'''
Line 30:		Line 28:

	Using any part of the workshop should eventually become pow-pow-done straightforward.		Using any part of the workshop should eventually become pow-pow-done straightforward.

			'''On [[Documentation Resources]]'''

			For documentation, keep things clear and concise. Avoid long strings of hyperlinks. Make navigation simple.

	'''On Concept into Details into Execution'''		'''On Concept into Details into Execution'''