Difference between revisions of "Deployment"

From EUDP
Jump to: navigation, search
m (Link to next step)
Line 1: Line 1:
 
== What ==
 
== What ==
 +
<imagemap>
  
[[Image:DeploymentOverview_img.gif]]
+
Image:DeploymentOverview_img.gif
 +
 
 +
poly 55 97 132 97 132 116 55 116 55 97 [[Deployment]]
 +
 
 +
 
 +
</imagemap>
  
 
A series of protype releases to the customer.
 
A series of protype releases to the customer.

Revision as of 15:24, 5 November 2009

What

DeploymentDeploymentOverview img.gif
About this image

A series of protype releases to the customer.

How

The dish

Deployment

Ingredients

  • All artifacts produced in the previous phases.
  • Experiences and metrics from previously performed projects.

Process

As mentioned under "Deployment Planning" in the Realisation Phase, the deployment plan describes which versions of the prototype the customer will get, at what time and with what functionality. The deployment plan should also state how much customer involvement can be expected.

In order to actually deploy the prototype, it is a good idea to assign a "Deployment Manager". Following the deployment plan, the Deployment Manager makes sure that the developers have delivered all necessary input for the prototype deployment and that all parts have been integrated and evaluated according to evaluation specifications.

Subsequently, the Deployment Manager contacts the customer to arrange the time and place for deployment.

The prototype can be a paper prototype, a working sample, an embedded solution simulated on a PC, etc. The important thing is that the customer receives some physical evidence of progress in the development and that he or she can verify the implemented functionality as expected.

After the deployment has taken place, the Deployment Manager prepares a deployment report which shortly describes the customer's feedback of the prototype. The deployment report will be a part of the next Strategy and Planning meeting.

Why

During development of especially IT systems, it is particularly important that the customer gets some physical evidence of the project progress and a chance to verify the the implemented parts as expected.

Many IT-projects have failed in the past, because a customer received a final product which in fact was not what he or she had wanted. In other words, it did not fulfil the customer's wishes.

The performance that the customer can expect of the prototype is found in the deployment plan. The plan gives the customer the possibility of making adjustments to the overall project specifications very early in the project phase. If the prerequisites have changed, it will result in a new plan. As mentioned under "Deployment Planning", the customer will often be happy to pay a higher price for the right product, instead of paying the "right" price for the wrong product.

A positive side effect of frequent deployments is that the developer has deadlines coming up rather frequently in contrast to traditional development plans where deadlines are often sparsely distributed over the project period. The developer keeps the focus on the next delivery which is within a short time frame. Another positive side effect is that the project management has concrete evidence of progress in the project by the application of frequent deployments. Hence, they are not left with spoken or written reports from the developers.

It is essential to follow the time plan and deploy what has been implemented and verified, rather than delay the delivery. If some functionality is not ready for deployment as planned, the functionality should be removed from the deployment and planned for a later deployment. The customer can still see some progress, and the development team will have a feeling of succes and can still gain important feedback from the customer.

After the final deployment the Post Project Phase phase is due.