Packaging Model

Once the physical model defines what will be built and the application architecture defines how it will be organized, this task defines how each independent component will be constructed. For example, a reusable component may be constructed as a DLL, a daemon process, or a dynamically loaded Smalltalk parcel. This task defines what strategy will be used. This task also defines the order that parts of the solution will be developed so that the persons responsible for compiling, packaging and testing know what to package and test, and when.
Risk & Impact:
The solution has to be compiled and packaged in order to be of use. Therefore, this effort has to occur in some form. Since the way a component will be packaged will effect the way it is constructed, it is important for formalize this to eliminate rework in the coding task.
Upstream Tasks:
Downstream Tasks:
Questions Asked
  1. What are the more foundational elements of the solution?
  2. What are the higher level elements of the system? 
  3. Starting from the foundational and going up, what parts can be developed, delivered and tested in an incremental fashion?
Iterates with:
Packaging Model A brief document defining how the source will be combined into packageable groups, the relative schedule of source availability and the testable function it represents.