Difference between revisions of "Launch Phase"

From EUDP
Jump to: navigation, search
(How)
(Goals)
 
(24 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== What ==
 
== What ==
 
<imagemap>Image:LaunchPhase.png|
 
<imagemap>Image:LaunchPhase.png|
rect 159 21 254 76 [[General_Analysis|General_Analysis]]
+
rect 156 5 231 59 [[General_Analysis|General Analysis]]
rect 156 115 254 172 [[General_Architecture_Design|General Architecture Design]]
+
rect 154 99 231 155 [[General_Architecture_Design|General Architecture Design]]
rect 159 208 256 266 [[Technical_Platform|Technical Platform]]
+
rect 153 193 231 247 [[Contracting|Contracting]]
rect 157 309 257 366 [[Contracting|Contracting]]
+
 
#<!-- Created by Online Image Map Editor (http://www.maschek.hu/imagemap/index) -->
 
#<!-- Created by Online Image Map Editor (http://www.maschek.hu/imagemap/index) -->
 
desc none
 
desc none
Line 17: Line 16:
 
'''Ingredients'''
 
'''Ingredients'''
  
*    Preproject artifacts
+
*    Preproject artefacts
  
 
'''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. Note that a decision about what to implement in HW and what to implement in SW has to be postponed to the last possible moment. By having an open mind the number of solutions that can fulfil a requirement are 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.  
  
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 shall be implemented in HW and what parts in SW will reflect the technical platform.
+
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 defined the Requirements, Architecture and Technical Platform, prepare a Development Plan, a Quotation and a Contract.
+
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]].
  
TODO: Edit below to suit new thoughts
+
Finally, after having defined the requirements, the architecture and the technical platform, prepare a development plan, a quotation and a contract (the [[Contracting]]).
 
+
TODO MOJ: Perhaps we could use chapter 2 "System Design Methodologies" from "Embedded Systems Design" (book from HW/SW codesign used for the course in Aarhus).
+
Mention
+
* bottom-up methodology
+
* top-down methodology
+
* meet-in-the-middle methodology
+
* platform methodology
+
* FPGA methodology
+
Perhaps exemplify a few.
+
  
  
Line 45: Line 35:
 
== Why ==
 
== Why ==
  
At first, the project context should be explored - 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 shall 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 class diagram and the initial use cases.
+
[[File:Box with eyes.svg.png|right]]
 +
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.
  
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.  
+
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.
  
===Business and Economical arguments===
+
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.
 
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 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.
+
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 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.
+
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.
+
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 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.
+
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 - the analysis and design documentation. The customer may invite other tenders for the development.
+
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.
+
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.
  
 
===Goals===
 
===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.
+
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 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.
+
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.
  
As mentioned above, prototyping may 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 that 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.
+
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.
+
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.
 
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 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 have a thorough and common understanding of the system-to-be.
+
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.
 +
 
 +
==Example==
 +
 
 +
[[Media:TeamH2-exampleReport.tar.gz| This]] example report contains examples from the earlier version of EUDP.

Latest revision as of 09:47, 26 January 2021

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

Box with eyes.svg.png

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.

Goals

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.

Example

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