Difference between revisions of "Launch Phase"

From EUDP
Jump to: navigation, search
(Why)
(How)
Line 12: Line 12:
 
'''The dish'''
 
'''The dish'''
  
An initial analysis of the system-to-be in order to estimate price and duration of the final development  
+
An initial analysis of the system-to-be in order to estimate price and duration of the final development.
  
 
'''Ingredients'''
 
'''Ingredients'''
Line 20: Line 20:
 
'''Process'''  
 
'''Process'''  
  
During these activities, it is vital to identify all requirements. Requirements can be developed based on [[User Needs]], but also on the basis of the analysis and the initial designs as well as the specification of the technical platform. Some requirements are sub-requirements to others refining the requirement. Every time there is a requirement, it shall immediately be addressed.
+
During these activities, it is vital to identify all requirements. Requirements can be developed based on [[User Needs]], but also on the basis of the analysis and the initial designs as well as the specification of the technical platform. Some requirements are sub-requirements to others; i.e. a sub-requirement refines a requirement. Every time there is a requirement, it shall immediately be addressed.
  
It is likewise important to define a basic architecture for the system-to-be. The architecture describes an overall layout of the system. The architecture diagram consists of functional blocks with a short description. The architecture diagram will change and evolve during most of the Launch Phase as analysis and design reveal more and more details. Note that a decision about what to implement in HW and what to implement in SW should be postponed to the last possible moment, typically when defining the [[Technical Platform]]. By having an open mind, the number of solutions that can fulfil a requirement is larger.  
+
It is likewise important to define a basic architecture for the system-to-be. The architecture describes an overall layout of the system. The architecture diagram consists of functional blocks with a short description. The architecture diagram will change and evolve during most of the Launch Phase as analysis and design reveal more and more details. Note that a decision about what to implement in HW and SW, respectively, should be postponed to the last possible moment, typically when defining the [[Technical Platform]]. By having an open mind, the number of solutions that can fulfil a requirement is larger.  
  
 
There are several ways of capturing the requirements. First, perform a [[Problem Domain Analysis]] and second, perform a [[Usage Domain Analysis]]. For some type of systems, the order may be the opposite.
 
There are several ways of capturing the requirements. First, perform a [[Problem Domain Analysis]] and second, perform a [[Usage Domain Analysis]]. For some type of systems, the order may be the opposite.
  
Having captured all requirements and defined the general architecture, the time has come to decide on how to implement the system-to-be. Decisions about what parts should be implemented in HW and SW respectively will reflect the [[Technical Platform]].
+
Having captured all requirements and defined the general architecture, the time has come to decide on how to implement the system-to-be. Decisions about what parts should be implemented in HW and SW will reflect the [[Technical Platform]].
  
Finally, after having defined the Requirements, the Architecture and the Technical Platform, prepare a Development Plan, a Quotation and a Contract. The [[Contracting]].
+
Finally, after having defined the requirements, the architecture and the technical platform, prepare a development plan, a quotation and a contract. The [[Contracting]].
  
  

Revision as of 09:37, 23 April 2015

What

General AnalysisGeneral Architecture DesignContractingLaunchPhase.png

How

The dish

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

Ingredients

  • Preproject artefacts

Process

During these activities, it is vital to identify all requirements. Requirements can be developed based on User Needs, but also on the basis of the analysis and the initial designs as well as the specification of the technical platform. Some requirements are sub-requirements to others; i.e. a sub-requirement refines a requirement. Every time there is a requirement, it shall immediately be addressed.

It is likewise important to define a basic architecture for the system-to-be. The architecture describes an overall layout of the system. The architecture diagram consists of functional blocks with a short description. The architecture diagram will change and evolve during most of the Launch Phase as analysis and design reveal more and more details. Note that a decision about what to implement in HW and SW, respectively, should be postponed to the last possible moment, typically when defining the Technical Platform. By having an open mind, the number of solutions that can fulfil a requirement is larger.

There are several ways of capturing the requirements. First, perform a Problem Domain Analysis and second, perform a Usage Domain Analysis. For some type of systems, the order may be the opposite.

Having captured all requirements and defined the general architecture, the time has come to decide on how to implement the system-to-be. Decisions about what parts should be implemented in HW and SW will reflect the Technical Platform.

Finally, after having defined the requirements, the architecture and the technical platform, prepare a development plan, a quotation and a contract. The Contracting.


Activitylevels.png

Why

At first, the project context should be explored - i.e. a Problem Domain Analysis. By viewing the system-to-be as a black box that cannot be looked into, exploration of the environment can reveal what should be represented in the system-to-be and how it is to interact with the environment in order to monitor, control or administer the parts of the environment with which the system-to-be shall interact. The analysis results in the initial block/class diagram and the initial use cases.

Further ahead, the black box will be opened and the requirements gathered in the initial analysis will be transformed into requirements for the system-to-be. When the User Needs for the system are known, they can be transformed into requirements for the system-to-be and, if fulfilled, the system-to-be will then satisfy the needs.

Business and Financial Arguments

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

Typically, the Launch Phase is paid by the customer on an hourly basis. We advise 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 is not paid on a fixed price basis. The answer to this is: It is possible, but it is difficult 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 is feasible for the particular project. Prototypes or feasibility studies are by nature very difficult to estimate - it is typically a rather unknown land which 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 - i.e. 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.

Goals

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

Prototyping may be necessary. Prototypes are used to illustrate 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 have great difficulty in dealing with the more theoretical or formal ways in which developers describe IT systems. Prototypes showing possible user interfaces can be the best way to involve the customer or user representatives directly in the analysis.

Although prototypes of user interfaces are 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, needs 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 s/he gains insight into the usage of the system-to-be. These iterations will refine the data model.

Having HW and SW 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 HW and which in SW because both parties have a thorough and common understanding of the system-to-be.

Example

This example report contains examples from the earlier version of EUDP.