An initial analysis of the system-to-be in order to estimate price and duration of the final development.
- Preproject artefacts
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).
First, the project context should be explored (Problem Domain Analysis). By viewing the system-to-be as a black box into which you cannot look, 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.
In other words: Imagine a box from where you are looking out at the environment. Which parts of the environment do you need to have a representation of in the system-to-be in order to accomplish the tasks requested. A representation is something the can be sensed and converted to digital format for handling in an electronic and/or computer system. A representation can also be an object in the environment that you want to interact with through an actuator.
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 a shorter time than estimated.
Other reasons not to set a fixed price here is that it may 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; they are typically 'unknown land' left for the developer to 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 might be a need to perform some of the activities in the Preproject Phase, since the artefacts are needed later on in the Launch Phase.
Once the financial matters have been settled, 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 onion skin. During the analysis, we will peel the onion, layer by layer, and describe what we find.
The goal of the Launch Phase is to obtain 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 postpones the description of the usage domain until later. The reason for this approach is that the data model (the class diagram), which describes the problem domain, needs to be created 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 work together during the analysis and general architecture design using the same methodology and notation tools (SysML and 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.
This example report contains examples from the earlier version of EUDP.