| |
| "CBD-Process" of the Physical Products |
|
|
Any unique custom physical CBD-product can be designed and build by designing, building and assembling custom-components having custom interfaces (and component-hierarchies as in FIG-2 of section-2). The process for designing and building any large physical CBD-product can be divided into 3 stages/steps, which are briefly summarized in the following numbered steps/stages:
|
|
| 1 |
Design & Development stage/step: Designing of a large CBD-product begins by partitioning it into components, where each large component is partitioned into sub-components (and so on), which results in creating component-hierarchy (e.g. As illustrated for the CBD-structure, the top-level components are identified as in FIG-1. Then subcomponents are identified for each of the top-level components. Sub-subcomponents are identified for each subcomponent, and so on, which results in a
CBD-structure or a component-hierarchy as in FIG-2). Independently design and build each of the prototype-(sub)components and test each of the prototype-components/sub-components individually. Assemble all the components to build working prototypes for the product-model and test the prototype. Fix any problems (e.g. functional, design or shortcomings etc.) by redesigning/refining or replacing each of the components/subcomponents in the component-hierarchy and test. Repeat ‘refine/fix-and-test cycle’ until building a satisfactory product-prototype, which is final ‘golden’ reference model/version for manufacturing:
|
|
|
| 2 |
Mass production stage/step: Using the ‘golden’ as a reference to define engineering tolerances for each of the components and its coupling interfaces (e.g. for assembling and to allow proper collaboration between the components) to mass-produce ‘interchangeable components’. Then set up an assembly line to mass-produce identical CBD-products. Although coupling interfaces of components are often changed in step-1/step-3, but discouraged in step-2 (e.g. internality functionality or features within components may be changed/refined in step-2, without changing coupling interfaces of each component that could affect other components relying on the coupling interfaces).
|
|
|
| 3 |
Maintenance/evolution step: Every few years, each of the successful product-model (e.g. Camry or Accord) is substantially redesigned for upgrading to a new model. Any physical CBD-product is evolved by evolving each of its components (e.g. by using the blueprints of each of the components & sub-components). The CBD-structure or components-hierarchy is also adjusted or redesigned. It often needs redesigning most large core components/sub-components to improve each of them based on factors such as new-innovations, expertise/wisdom gained from previous designs and customer feedbacks etc. Also fix any shortcomings or problems (e.g. design/functional) by refining/replacing each of the components and test. Repeat the ‘fix/refine-and-test cycle’ until satisfied with each component or sub-components, and the product-prototype, which is ‘golden’ reference model for manufacturing/mass-production (then go to step-2 for mass production). |
|
|
| In case of a software product, mass production is nothing but making copies on CDs or host on a web-server for the world to use or download the software product. So obviously stage-2 (i.e. mass-production) applies neither to one-of-a-kind physical (or ‘golden’ or prototype) product nor to most of the software products. But stage-1 & 3 certainly can be employed for building software applications, if one wish to design and built using an ideal CBD, CBSE (Component-Based Software Engineering) and real software components that are equivalent to the physical components for achieving a CBD-structure. |
|
| For prototype in step-1 or 3: The total cost of either (i) initial assembling or (ii) disassembling/reassembling the resultant prototype (by disassembling one component at a time), would be less than 10% of the total cost of designing, building and refining the first set of components for the ‘golden’ model. In case of Swiss analog-watch, cost of components includes designing the components for the first prototype-model (or cost of refining most components for next successive models). |
|
| Either complexity or uniqueness of a one-of-a-kind product (e.g. prototypes of spacecraft or new kind of nuclear powered rail engine or even analog-watch) can't prevent designers from satisfying an important rule referred to as the 20% CBD-rule. Likewise, any software CBSE-application built using true software-components must satisfy the 10% CBD rule. |
|
|
Engineering historian Dr. Henry Petroski illustrated in his 1992 book "The Evolution of Useful Things" that: (i) Continual refinement is the usual rule and (ii) Engineers constantly find shortcomings in their designs and fix/refine them
little-by-little (In step-1&3 above).
|
|
| Each physical product (e.g. cars or computers) is evolved by improving/refining each of its components little-by-little autonomously (over many decades). For example, designer of the car-engine refines the engine little by little autonomously away from the car. It is not practical today in software to refine and test each of the equivalent larger components (having many sub-components) outside its product. For example, this ability to disassemble and refine each component independently outside of the product and also test independently outside of the product, must had helped Wright brothers immensely not only in building the 1st functional Airplane that had taken 1st successfully flight but also to improve the airplane few more iterations or models. |
|
|
Mankind already invented countless CBD-products such as automobiles, computers or airplanes and still working on inventing countless new CBD-products. It is essential to gain insights into the process of inventing and building a new product. It is not hard to find, why and how software products are different from products from mature or crowded product families. But there is no valid reason, why design of a new innovative software product different from the design of a new innovative physical CBD-product, such as design of first Airplane by Wright brothers or many new products invented each year such as designing and building new artificial kidney (http://www.youtube.com/watch?v=hc5e5cYdshI).
|
|
|
Please kindly pay attention to 15 seconds bit starting at 1 minute 55 seconds. Let me paraphrase the 15 seconds bit, as I understood it: Essential purpose of the real component-based engineering is ability to look, feel and test each component independently to optimize individually for making each component as best as it can be. Then bring the components together periodically to make sure that (a) each of them properly collaborating with other parts (e.g. in step-1), and (b) all the components are fulfilling their respective roles as intended. This is what the ‘fix-and-test’ cycles in step-1 and step-3 of CBD-process presented my paper.
|
|
|
The City_GIS presents a software application created by using CBD-process (that achieved the CBD-structure), where each component is built and tested independently and each component allow optimizing individually for making each component as best as it can be.
This architecture allows 'versioning' & 'sandboxing' of source code of each of the real components in step-1 and throughout the evolutionary life of the product (in each of the future iterations of step-3).
|
|
|
Most experts overlook an obvious fact that it is often impossible to create a perfect component in the first attempt. So it is essential to eliminate all overhead costs to iteratively redesign
to improve little-by-little
and test individually (outside of the product)
for each of the components of a product in its component-hierarchy (i.e. CBD-structure)
to make it as best as it can be before assembling all the components (in above step-1).
Even a best product likely would become irrelevant sooner rather than later, if it can’t be improved or
it is very complex to improve, for example, by iteratively redesigning each of its components in its
CBD-structure. So it is essential to eliminate all overhead costs to iteratively redesign and test each of the components individually (outside of the product) to make any component in its CBD-structure as
best as it can be throughout the life of the product (in step-3). So componentization
is the most efficient & effective method for addressing any complex problem.
|
|
|
Almost every product we use today was poorly designed and barely functioned when it was first invented. For example, look at airplanes built by Wright brothers, automobiles a century ago or small brick size cell-phones attached to small suitcase. But they were continuously refined little-by-little over the decades. This is also true for software products, for example, MS-word, OS, editors and compilers. But in case of the physical CBD-products, over
90% of each product’s functionality is implemented in a collection of self-contained components and the products are evolved by redesigning and testing each of the self-contained components
individually. That is, to redesign a component of a product it is not necessary for the designer to see internal design (i.e. so to speak source code) of any other component of the product. Why is it not possible to achieve this kind of modularity for software products? For example, why programmers are forced to see internal code of many other component of
City_GIS application to redesign or to replace a component such as
City_LandMarks?
|
|
