0.1 Purpose

In my nomenclature, this document is the ``A'' specification including definition of original function and user documenation for the generic package.

The higher goal of the XASP project is to provide a Commodity Software alternative to Microsoft's ``Active Server Pages''. This long-range goal applies to cycles of development of the generic software package. The shorter term goal is to use the software developed in those cycles in customizations for specific business purposes. These customization may in turn result in iterative cycles of divergent development. These processes are intended to operate in parallel.

In this context, the XASP development process model is as follows:

1. I initiate the process by iteratively developing full scale Initial Operating Capabilities (IOC) of the generic package suitable for customizations.
2. The features of the customization are then determined. Two kinds of approaches are suggested for this. In the first, a NASA style [1], Statement of Work is written detailing the work to be performed in the customization. This method is most appropriate where a single entity that can arbitrarily decide features/functions is involved. The second approach is to negotiate features/functions of the customization with all concerned parties using the WinWin [2] methodology and it's system. In WinWin these parties are called stakeholders.
3. What happens next depends on the owning organizations development processes. At a minimum the results of the previous step are recorded in an instance of this document. At a maximum, the system requirements are translated into refinements on the object-oriented requirements objects in the current generic system baseline using a development process modeling and requirements analysis tool called ToFS [3] and it's accompanying methodology O4S, which is basically a vacuous but hygenic and complete object pass thru to standards such as CMM, ISO 9000, etc. Alternatively, if the commissioning entity is using other tools, (eg: Rational's) then those could be used with the logical translations from the ToFS CIs.

   Some organizations prefer not to pay the cost of more involved processes, or to do so after an initial proof of concept cycle. In these cases, the developed code and the customization of this document (essentially the documentation of the work performed in the Statement of Work) are the complete deliverables and this is the end of an abbreviated process. The customizing organization can still make a commitment to more process at a later time.

4. In the terminology of O4S, this document, which I call the ``A'' spec, is the ``originating'' one for the XASP system. In organization committed to full-scale processes, it and the Tofs models constitute the functional requirements and high level design specification of the system. However, our variation on O4S is that this document is neither logically prior nor a consequence of the ToFS model and, the rendering of the downstream elements is in general external to ToFS/O4S.
5. Depending on the owning organizations development process as decided in step 2 above, this then either becomes the sole document or the object model implicit in the succesful completion of the previous steps is realized as the core exhibit of a second document, the ``B'' spec., which is a detailed design of the system objects of the ``A'' document. For this the generic system uses an extensible object modeling tool ``UML Studio'', formerly ``Pragmatica'' though others can be used as stated in step 2 above.
6. Test cases and other elements of the quality plan in the B Spec are executed to get a closure on a phase of the development process which can then either freeze or restart with step 1 above. Various reviews, and other process elements have not been mentioned in this sketch as they can drop out if the buying organization decides to pursue a minimum process in step 2 above.

This document is archived for baseline review purposes at major milestones in the systems development process with other work product.

The version available with the evaluation downloads contains only the guide for installation and use and stubs for development of the customization elements of the document mentioned in step 2 above.