Launch Phase

From EUDP
Revision as of 13:33, 23 October 2010 by Klaus (Talk)

Jump to: navigation, search

What

ContractingTechnical Platform OverviewTechnical Platform OverviewGeneral Architecture DesignGeneral Architecture DesignGeneral Architecture DesignGeneral AnalysisGeneral AnalysisLaunchOverview img.gif
About this image


How

The dish

An initial analysis of the system-to-be in order to estimate price and duration of the final development.

Ingredients

  • Preproject artifacts

Process

Establish an initial Class Diagram by analysing the Problem Domain.

Analyse the Usage Domain and describe the Use Cases.

Analyse and describe the Interfaces to the system.

Compile a list of functions making the data model available to the interfaces.

Throughout the above activities draw Communication or Sequence Diagrams as necessary to understand the dynamics of the system-to-be.

While working with the above activities, write down exact requirements that are revealed.

Iterate the above activities until enough knowledge is available for designing the architecture of the system-to-be.

Finally, decide how the described system should be implemented selecting what goes in hardware and what goes in software.

Having the Analysis Specification, Architecture Specification and the Platform Specification ready, prepare a Development Plan, a Quotation and a Contract.

Activitylevels.png

Why

The Launch Phase is the phase where the developer should analyse and propose a general design for the ideas the customer presented to the developer in the Preproject Phase.

Typically, the Launch Phase is paid by the customer on an hourly basis. We advice to do so because the Launch Phase may be a longer process resulting in a product - the analysis and design documents containing the result of the effort.

One could ask why this phase could not be on a fixed price? The answer to this is: it could, but it is hard to estimate exactly the time needed to perform the analysis and design, hence the developer may add an extra overhead or a security margin to the estimate to ensure that there are enough funds to do the job thoroughly.

By proposing the customer an estimate - maybe even as a maximum price - the customer knows the budget so far. The developer is encouraged not to spend more than the exact necessary hours and therefore the Launch Phase is often performed in shorter time than estimated.

Other reasons not to set a fixed price on this phase is that it might be necessary to build prototypes to test if a suggested solution may be feasible for the particular project. Prototypes or feasibility studies are by nature very difficult to estimate - it is typically rather unknown land the developer should discover.

Another reason for letting the customer pay for this phase is that the result is both a quote for the development and a product - the analysis and design documentation. The customer may invite other tenders for the development.

Some projects may be described with enough details by the customer so that the Preproject Phase is only a matter of estimating the Launch Phase. But be aware that if the customer's description is done using other methods there may be a need to perform some of the activities in the Preproject Phase because the artifacts are needed later on in the Launch Phase.

Having these financial matters aside, it is time to look into what is performed in the Launch Phase. As the name of the phase suggests, it is the launch of a project. It is time to see what is behind the first layers of the onionskin. During the analysis we will peel layer by layer of the onion and describe what we will find.

The goal of the Launch Phase is to get enough knowledge about the system-to-be to be able to estimate the development. It is not a development phase, although some level of design of the system is described as a result of the work. The design is necessary to produce a precise estimate for development.

As mentioned above prototyping can be necessary. Prototypes are used to show if a solution is feasible for the specific project. Prototypes are also often used to show how the user interface can be build. Amongst developers it is well-known that users do have great difficulties dealing with the more theoretical or formal ways developers describe IT-systems. Prototypes showing possible user interfaces can be the best way the developer can involve the customer or user representatives directly in the analysis.

Although prototypes of user interfaces is but the only thing the customer can deal with, we still suggest that the developer tries to describe the problem domain first and postpone the description of the usage domain until later. The reason for this approach is that we find that the data model (the class diagram) which describes the problem domain need to be established before the usage domain is described.

While describing the usage domain the developer may have several iterations back to the problem domain analysis as she or he gains insight in the usage of the system-to-be. These iterations will refine the data model.

Having hardware and software developers working together during the analysis and general architecture design using the same methodology and notation tools (UML), they can rather easily, as one of the very last activities in the Launch Phase, decide which parts should be implemented in hardware and which in software because both parties do have a thorough and common understanding of the system-to-be.