http://eudp.net/api.php?action=feedcontributions&user=Ellyk&feedformat=atomEUDP - User contributions [en]2024-03-29T15:43:49ZUser contributionsMediaWiki 1.23.13http://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-06T11:15:13Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
poly 129 163 186 163 186 181 129 181 129 163 [[Human Processes]]<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
poly 136 243 181 243 181 261 136 261 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 [[Review Techniques]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Pre_AnalysisPre Analysis2009-11-06T11:12:24Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:PreAnalysisOverview_img.gif<br />
<br />
poly 70 349 143 349 143 367 70 367 [[Preliminary Use Cases]] <br />
poly 77 367 136 367 136 385 77 385 77 367 [[Preliminary Use Cases]] <br />
poly 85 524 129 524 129 542 85 542 85 524 [[System Definition]] <br />
poly 77 542 136 542 136 560 77 560 77 542 [[System Definition]] <br />
poly 71 437 142 437 142 455 71 455 71 437 [[Stakeholder Analysis]] <br />
poly 80 455 133 455 133 473 80 473 80 455 [[Stakeholder Analysis]] <br />
poly 74 270 140 270 140 288 74 288 74 270 [[Storycard]]s <br />
poly 71 183 142 183 142 201 71 201 71 183 [[Storytelling]] <br />
poly 70 95 143 95 143 113 70 113 70 95 [[Rich Picture]] <br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/RoadmapRoadmap2009-11-06T09:07:29Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
image:ProjectPhasesOverview_img.gif<br />
poly 715 413 715 266 738 266 738 413 715 413 [[Common Activities]]<br />
poly 604 573 690 573 690 596 604 596 604 573 [[Post Project Phase]]<br />
poly 604 376 690 376 690 399 604 399 604 376 [[Realisation Phase]]<br />
poly 604 187 661 187 661 210 604 210 604 187 [[The Launch Phase]]<br />
poly 604 77 682 77 682 100 604 100 604 77 [[PreProject]]<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Strategy_And_PlanningStrategy And Planning2009-11-06T08:57:22Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:StrategyAndPlanningOverview_img.gif<br />
<br />
<br />
poly 27 354 110 354 110 373 27 373 27 354 [[Deployment Planning]]<br />
poly 39 373 98 373 98 392 39 392 39 373 [[Deployment Planning]]<br />
poly 32 179 104 179 104 198 32 198 32 179 [[Verification Planning]]<br />
poly 39 198 98 198 98 217 39 217 39 198 [[Verification Planning]]<br />
poly 27 88 110 88 110 107 27 107 27 88 [[Development Strategy]]<br />
poly 42 107 95 107 95 126 42 126 42 107 [[Development Strategy]]<br />
poly 30 269 107 269 107 288 30 288 30 269 [[Development Planning Realisation]]<br />
poly 39 288 98 288 98 307 39 307 39 288 [[Development Planning Realisation]]<br />
<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/ContractingContracting2009-11-06T08:57:08Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:LaunchContractingOverview_img.gif<br />
<br />
<br />
poly 49 276 100 276 100 295 49 295 49 276 [[Product Acceptance]]<br />
poly 43 295 43 295 43 314 43 314 43 295 [[Product Acceptance]]<br />
poly 43 295 105 295 105 314 43 314 43 295 [[Product Acceptance]]<br />
poly 41 197 107 197 107 216 41 216 41 197 [[Quotation]]<br />
poly 33 100 116 100 116 119 33 119 33 100 [[Development Plan]]<br />
poly 60 119 89 119 89 138 60 138 60 119 [[Development Plan]]<br />
<br />
<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Technical_PlatformTechnical Platform2009-11-06T08:56:54Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:TechnicalPlatformOverview_img.gif<br />
<br />
<br />
poly 27 98 146 98 146 117 27 117 27 98 [[Technical Platform]]<br />
<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/General_Architecture_DesignGeneral Architecture Design2009-11-06T08:56:24Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:ArchitectureDesignOverview_img.gif<br />
<br />
<br />
poly 45 253 103 253 103 272 45 272 45 253 [[Architecture Dynamics]]<br />
poly 43 272 104 272 104 291 43 291 43 272 [[Architecture Dynamics]]<br />
poly 37 167 112 167 112 186 37 186 37 167 [[Subsystem Design]]<br />
poly 52 186 96 186 96 205 52 205 52 186 [[Subsystem Design]]<br />
poly 52 82 96 82 96 101 52 101 52 82 [[Design Criteria]]<br />
poly 50 101 98 101 98 120 50 120 50 101 [[Design Criteria]]<br />
<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Realisation_PhaseRealisation Phase2009-11-06T08:55:32Z<p>Ellyk: </p>
<hr />
<div>== What ==<br />
<br />
<imagemap><br />
<br />
Image:Realisation_Overview_img.gif<br />
<br />
<br />
poly 202 134 250 134 250 151 202 151 202 134 [[Analysis]]<br />
poly 50 217 110 217 110 234 50 234 50 217 [[Strategy and Planning]]<br />
poly 56 234 104 234 104 251 56 251 56 234 [[Strategy and Planning]]<br />
poly 356 134 395 134 395 151 356 151 356 134 [[Design]]<br />
poly 488 211 546 211 546 228 488 228 488 211 [[Implementation]]<br />
poly 546 211 550 211 550 228 546 228 546 211 [[Implementation]]<br />
poly 503 228 503 228 503 245 503 245 503 228 [[Implementation]]<br />
poly 503 228 535 228 535 245 503 245 503 228 [[Implementation]]<br />
poly 340 315 405 315 405 332 340 332 340 315 [[Verification]]<br />
poly 190 315 259 315 259 332 190 332 190 315 [[Deployment]]<br />
<br />
</imagemap><br />
<br />
<br />
<br />
== How ==<br />
<br />
'''The dish'''<br />
<br />
Realisation Phase. <br />
<br />
'''Ingredients'''<br />
<br />
* All documentation and products produced until the beginning of the phase. <br />
<br />
'''Process''' <br />
<br />
'''''General planning'''''<br />
<br />
Determine the number and length of the timeboxes.<br />
<br />
* The first one or two timeboxes may be of different length if further planning, analysis or other activities have to be carried out before the actual development can begin.<br />
* The implementation timeboxes should normally be of same length.<br />
* Add one last short timebox to cover issues discovered during the last one or two deployments.<br />
* Estimate the total number of timeboxes.<br />
* Assign the interruption shield (see below) to a developer if there is no formal project manager in the project. Inform the customer about the interruption shield and the procedure about handling inquiries. <br />
<br />
Make a rough selection of which parts will be developed in which timeboxes - '''the development strategy'''. From the rough selection, plan the manning of each timebox. Coordinate the plan with the project organisation.<br />
<br />
'''''Planning in each timebox'''''<br />
<br />
At the beginning of each timebox, review the strategy, i.e. the selected parts that should be developed during the timebox. Often adjustments may be necessary due to knowledge gained during the past timeboxes. Some parts may be postponed and others may be advanced.<br />
<br />
Plan the deployment with the customer. Encourage the customer to participate as much as s/he can in the deployment. Write down the deployment plan.<br />
<br />
Plan the test scenario(s). Write down the tests that the product has to pass before deployment can be executed.<br />
<br />
Review the manning plans and correct accordingly. Remember to coordinate with the rest of the organisation.<br />
<br />
'''''Analysis'''''<br />
<br />
Do the necessary analysis to gain enough insight and details to design and develop the selected parts. The MW, HW and SW developers work together during the analysis.<br />
<br />
'''''Design'''''<br />
<br />
Perform the recommended design tasks redesigning the general analysis results into implementable results. MW, HW and SW developers mostly work independently during design.<br />
<br />
'''''Implementation'''''<br />
<br />
Implement the design.<br />
<br />
'''''Verification'''''<br />
<br />
Verify the product using the tests written earlier in Verification Planning . Correct as necessary.<br />
<br />
'''''Deployment'''''<br />
<br />
In cooperation with the customer, deploy the product either at the customers site or in-house depending on the possibilities.<br />
<br />
'''''Post deployment'''''<br />
<br />
Spend a short time evaluating the just-closed timebox. What went well? Why did it go well? What caused problems? Can they be prevented in the future? And how can they be prevented?<br />
<br />
Restart with the next timebox. <br />
<br />
== Why ==<br />
<br />
'''Introduction'''<br />
<br />
The Realisation Phase is typically the longest phase in the development. During the realisation, the system-to-be is constructed.<br />
<br />
'''Timeboxes'''<br />
<br />
It is our recommendation that the development is divided into smaller parts - timeboxes - rather than having one long development process covering all the activities. The timeboxes give a number of advantages over the long run such as:<br />
<br />
* The customer experiences stepwise progress in the development rather than one large delivery at the end of the development. <br />
<br />
* The frequent delivery enables the customer to try the system before it is totally implemented. As a result, the developer can get feedback early in the process rather than at the end of the development process.<br />
* It keeps the developers focus on the development by having the developer deliver to the customer frequently. <br />
<br />
* The developer will experience a number of welldefined tasks including verification planning, analysis, design, test specification and implementation which are repeated frequently. Consequently, focus will be on the quality of delivery in each deployment rather than postponing the verification and test activities until just before delivery of the final product.<br />
* The project management will, as the customer, experience stepwise identifiable progress in the development rather than progress based on the developer's feedback. In this way, the project management will have more detailed follow-ups available. <br />
<br />
The timeboxes should normally be of two to six weeks in length depending of the expected total project length, the number of developers involved, the type of project, etc. As a rule of thumb, the following chart may be used to specify the length of each timebox:<br />
<br />
[[Image:Tx_oodocs_2f7e5214e0.gif]] <br />
<br />
It is recommended to have at least one short timebox at the scheduled end of the project to fix any minor bugs or misunderstandings found in the last one or two deployments.<br />
<br />
[[Image:Timebox.gif]]<br />
<br />
'''Manning'''<br />
<br />
During the development, the manning of the timeboxes may vary. Hardware, for instance, is typically developed during the first timeboxes leaving the software developers realising their part during the later timeboxes. Additional analysis and/or planning may often take place during the first one or two timeboxes requiring less manpower.<br />
<br />
'''Planning'''<br />
<br />
At the beginning of each timebox, it is essential to perform the planning thoroughly. The planning should mainly be done by the participating developers, thereby ensuring personal commitment to the plans leading to a high degree of self management. Consequently, less general project management is required.<br />
<br />
It is recommended that the planning and specification of the verification is done before the actual implementation. For instance, it is essential that the test specifications are written based on the requirements rather than on what was actually implemented during the realisation.<br />
<br />
'''Interruption Shield'''<br />
<br />
The project management must provide a shield against interruption from the outside. The project team should concentrate on the main issue: developing the selected parts in the timebox. The project management should acknowledge the interruptions, but postpone the handling and decision process until the next planning activity is due.<br />
<br />
Only very important interruptions should be allowed when passing through to the developers. Important interruptions could be of financial character introducing major changes for the project economy, or the product under development may not be of relevance to the customer in its current form any more.<br />
<br />
If, for instance, a small organisation does not have a formal project management, one of the developers should be assigned the task of being a shield against outside interruptions.<br />
<br />
The customer and other external stakeholders should be informed about and accept the practice of shielding the developers during a realisation timebox. If the customer, not knowing the working practice, expects immediate reaction from the developer, he may be disappointed when nothing happens until weeks later.<br />
<br />
'''Customer Involvement'''<br />
<br />
Another issue worth spending some effort on is to inform the customer about the expected involvement in each deployment. The customer should assign enough time to try and test the instalment supplied at each deployment. If the customer does not assign the necessary time to run through the instalment, errors or misunderstandings may arise without being discovered until late in the development process, thus requiring greater effort fixing the problem. Feedback from the customer should be acknowledged, but not handled immediately as noted above in ''Interruption Shield''. <br />
<br />
Continue with [[Strategy and Planning]]</div>Ellykhttp://eudp.net/index.php/Pre_AnalysisPre Analysis2009-11-05T15:37:37Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:PreAnalysisOverview_img.gif<br />
<br />
poly 70 349 143 349 143 367 70 367 70 349 [[Preliminary Use Cases]] <br />
poly 77 367 136 367 136 385 77 385 77 367 [[Preliminary Use Cases]] <br />
poly 85 524 129 524 129 542 85 542 85 524 [[System Definition]] <br />
poly 77 542 136 542 136 560 77 560 77 542 [[System Definition]] <br />
poly 71 437 142 437 142 455 71 455 71 437 [[Stakeholder Analysis]] <br />
poly 80 455 133 455 133 473 80 473 80 455 [[Stakeholder Analysis]] <br />
poly 74 270 140 270 140 288 74 288 74 270 [[Storycard]]s <br />
poly 71 183 142 183 142 201 71 201 71 183 [[Storytelling]] <br />
poly 70 95 143 95 143 113 70 113 70 95 [[Rich Picture]] <br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/PreProject_PhasePreProject Phase2009-11-05T15:37:27Z<p>Ellyk: </p>
<hr />
<div>== What ==<br />
<br />
<imagemap><br />
Image:PreProjectOverview_img.gif<br />
<br />
<br />
poly 186 36 262 36 262 54 186 54 186 36 [[Pre Analysis]]<br />
poly 365 27 386 27 386 46 365 46 365 27 [[Pre Contracting]]<br />
poly 337 46 414 46 414 65 337 65 337 46 [[Pre Contracting]]<br />
<br />
</imagemap><br />
<br />
== How ==<br />
<br />
'''The dish'''<br />
<br />
A lightweight analysis of the system-to-be <br />
<br />
'''Ingredients'''<br />
<br />
* All information available from the customer <br />
<br />
'''Process''' <br />
<br />
At the first meeting with the customer schedule a number of future meetings with the customer - and if possible also with a specified user representative. The number of meetings depend on the size of the project, smaller projects may only require three meetings whereas large projects may require several meetings.<br />
<br />
Gather information about the stakeholders at all the meetings.<br />
<br />
Draw Rich Pictures when necessary.<br />
<br />
Evaluate if the customer can write stories describing the system-to-be in a casual manner. Show examples of storytelling and storycards or previously written stories/storycard(s) to inspire the customer. If the customer is capable of and willing to write the stories, it is an excellent idea to let him/her do so. Otherwise, the developer should gather enough information from customer interviews/meetings in order to write a short novel or storycard(s) which express the system-to-be.<br />
<br />
Determine if there are Use Cases that need further analysis. If so select the usage situations that need further analysis and prepare Preliminary Use Cases by writing a more detailed usage description.<br />
<br />
Prepare a stakeholder analysis by using the information gathered at previous meetings.<br />
<br />
Write a System Definition based on the information gathered so far.<br />
<br />
Prepare a Development Plan for the Launch Phase.<br />
<br />
Prepare a Quote based on the Development Plan.<br />
<br />
Write a contract for the Launch Phase by including the necessary artifacts produced during the Preproject Phase. <br />
<br />
== Why ==<br />
<br />
The Preproject Phase is a very lightweight early analysis of a new project. Use the Preproject Phase to learn just enough about a customer's idea to estimate the cost of a more general analysis.<br />
<br />
The Preproject Phase is conducted in close cooperation with the customer - it is the customer who has the knowledge about the system-to-be. Consequently, there will be quite a large number of meetings where the customer and / or representatives of future users and developers meet to discuss, do brainstorming and knowledge transfer to the developer.<br />
<br />
Expect that the work will be highly iterative, i.e. the activities performed will be repeated a number of times refining the understanding of the system-to-be in every iteration.<br />
<br />
The developer is expected to add his or hers experience, but not to think in solutions, i.e. how to implement this or that. The developer should be open-minded and listen carefully to the customer's requirements and wishes. It is difficult to avoid thinking in solutions. However, if the developer does think in solutions, there is a risk that he/she delivers a product which is easy to grasp, but also a product that does not fulfil the customer's demands in full. With an open mind new hitherto unrevealed ideas may arise and thereby the outcome will be a much better solution for the customer (and in the end for the developer as well). How to implement the new ideas is left to solve rather late in the development process. And through a thorough analysis and design process, it very often appears that what might have looked impossible to solve in the initial stages of the project can in fact be solved in a rather simple and elegant manner.<br />
<br />
The goal is to deliver products that solve customers' problems most efficiently and adapt to the current way of working rather than require reorganisation or changing the way a task is done. Therefore, the developer should be careful not to suggest solutions that limit the future users ability to do their work properly.<br />
<br />
The more experienced developer may suggest that working routines should be considered changed if he or she experiences that there is something wrong in the way the current work is organised or performed at the customer's organisation. The Rich Picture, for instance, can be used as a very efficient tool to show how the work-flow is organised. Suggesting changes by drawing a new Rich Picture which shows a more efficient work-flow can be presented to the customer. But the developer should leave it to the customer's own organisation or other external consultants within the organisational branch to implement the changes. The developer should focus on developing well-designed IT-systems that solve the customer's needs. The developer should, though, be aware that not even a perfect IT-system can solve conflicts or mis-organised work-flows. Consequently, the developer should back-off if he or she discovers that the customer tries to "buy" problem-solving though the introduction of a new IT-system rather than focusing on the real problem. History has shown that neither the developer nor the customer nor the end-users will be satisfied, and the developer would face a long dark period in his attempt to fix all kinds of problems that by nature originate in organisational problems. <br />
<br />
== Example ==<br />
<br />
An example will be presented later. Please return to this page later.</div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:35:54Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
poly 129 163 186 163 186 181 129 181 129 163 [[Human Processes]]<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
poly 136 243 181 243 181 261 136 261 136 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 125 [[Review Techniques]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:35:31Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
poly 129 163 186 163 186 181 129 181 129 163 [[Human Processes]]<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:35:05Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
poly 129 163 186 163 186 181 129 181 129 163 [[Human Processes]]<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:34:52Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
poly 129 163 186 163 186 181 129 181 129 163 [[Human Processes]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:34:33Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:34:22Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:33:57Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:33:25Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:33:19Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:33:05Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:32:35Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:32:22Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Common_ActivitiesCommon Activities2009-11-05T15:31:00Z<p>Ellyk: </p>
<hr />
<div>[[Roadmap]]<br />
<br />
<imagemap><br />
<br />
Image:Common_Activities_img.gif<br />
<br />
poly 147 438 173 438 173 456 147 456 147 438 [[Risk Management]]<br />
poly 121 456 199 456 199 474 121 474 121 456 [[Risk Management]]<br />
poly 135 145 180 145 180 163 135 163 135 145 [[Human Processes]]<br />
poly 129 163 186 163 186 181 129 181 129 163 [[Human Processes]]<br />
poly 123 349 194 349 194 367 123 367 123 349 [[Verification - common]]<br />
poly 136 243 181 243 181 261 136 261 136 [[Review Techniques]]<br />
poly 125 261 192 261 192 279 125 279 125 [[Review Techniques]]<br />
poly 127 36 189 36 189 54 127 54 127 36 [[Hardware Development]]<br />
poly 131 54 184 54 184 72 131 72 131 54 [[Hardware Development]]<br />
poly 142 72 142 72 142 90 142 90 142 72 [[Hardware Development]]<br />
poly 142 72 173 72 173 90 142 90 142 72 [[Hardware Development]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/PostProject_PhasePostProject Phase2009-11-05T15:28:37Z<p>Ellyk: </p>
<hr />
<div>== What ==<br />
<br />
<imagemap><br />
<br />
Image:Postproject_img.gif<br />
<br />
poly 497 118 539 118 539 136 497 136 497 118 [[Project Evaluation]]<br />
poly 486 136 551 136 551 154 486 154 486 136 [[Project Evaluation]]<br />
poly 350 117 398 117 398 135 350 135 350 117 [[Product Evaluation]]<br />
poly 341 135 406 135 406 153 341 153 341 135 [[Product Evaluation]]<br />
poly 201 117 249 117 249 135 201 135 201 117 [[Product Accept]]<br />
poly 205 135 246 135 246 153 205 153 205 135 [[Product Accept]]<br />
<br />
<br />
<br />
</imagemap><br />
<br />
== How ==<br />
<br />
'''The dish'''<br />
<br />
Postproject<br />
<br />
'''Ingredients'''<br />
<br />
* The realised system - the former system-to-be<br />
* The customer<br />
* The developer <br />
<br />
'''Process''' <br />
<br />
The final stages of the project should be carried out with great enthusiasm and at the same level of engagement as shown during the development. This is important in order to conclude the project with a satisfied customer and developer as well a satisfactory product.<br />
<br />
In the Product Accept phase, arrange a formal meeting with the customer where the product is officially handed over to the customer. Conduct the Product Accept as the last formal task as described in the Product Accept Specification, which is based on the requirements agreed upon with the customer in the "Launch phase".<br />
<br />
After the formal product accept, it is time to evaluate the delivered product as well as the entire project. This evaluation is more informal and gives the customer a possibility to declare how satisfied he or she has been cooperating with the developer. It is particularly worth spending some time on possible improvements that can be introduced in a possible next project.<br />
<br />
Finally, the developer conducts an internal project evaluation in order to highlight any possible process improvements in the development phases. <br />
<br />
== Why ==<br />
<br />
Just as important as the developer's first meeting at the customer's site is done in a professional and effective way, so should the exit also be in order to keep the door open for the next project. The customer should leave the developer with a positive experience in mind having received the expected product within the expected timeframe and to the agreed price. Therefore, a formal Product Accept should be signed by both parties and an informal Product and Project Evaluation should be conducted in order to clear out any misunderstandings and to improve the development process. This will leave the customer with an impression of an even more professional performance in relation to future projects.</div>Ellykhttp://eudp.net/index.php/DeploymentDeployment2009-11-05T15:24:09Z<p>Ellyk: </p>
<hr />
<div>== What ==<br />
<imagemap><br />
<br />
Image:DeploymentOverview_img.gif<br />
<br />
poly 55 97 132 97 132 116 55 116 55 97 [[Deployment]]<br />
<br />
<br />
</imagemap><br />
<br />
A series of protype releases to the customer.<br />
<br />
== How ==<br />
<br />
'''The dish'''<br />
<br />
Deployment<br />
<br />
'''Ingredients'''<br />
<br />
* All artifacts produced in the previous phases. <br />
* Experiences and metrics from previously performed projects. <br />
<br />
'''Process''' <br />
<br />
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.<br />
<br />
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.<br />
<br />
Subsequently, the Deployment Manager contacts the customer to arrange the time and place for deployment.<br />
<br />
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.<br />
<br />
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. <br />
<br />
== Why ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
After the final deployment the [[Post Project Phase]] phase is due.</div>Ellykhttp://eudp.net/index.php/VerificationVerification2009-11-05T15:22:00Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:VerificationOverview_img.gif<br />
<br />
poly 57 88 129 88 129 107 57 107 57 88 [[Verification Recommendations]]<br />
poly 36 107 36 107 36 126 36 126 36 107 [[Verification Recommendations]]<br />
poly 36 107 151 107 151 126 36 126 36 107 [[Verification Recommendations]]<br />
<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/ImplementationImplementation2009-11-05T15:20:11Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:ImplementationOverview_img.gif<br />
<br />
poly 57 287 129 287 129 306 57 306 57 287 [[Integration]]<br />
poly 77 182 110 182 110 201 77 201 77 182 [[Class Implementation]]<br />
poly 46 201 46 201 46 220 46 220 46 201 [[Class Implementation]]<br />
poly 46 201 141 201 141 220 46 220 46 201 [[Class Implementation]]<br />
poly 44 88 144 88 144 107 44 107 44 88 [[Implementation Recommendations]]<br />
poly 36 107 36 107 36 126 36 126 36 107 [[Implementation Recommendations]]<br />
poly 36 107 152 107 152 126 36 126 36 107 [[Implementation Recommendations]]<br />
<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/DesignDesign2009-11-05T15:18:25Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:DesignOverview_img.gif<br />
<br />
poly 28 399 102 399 102 418 28 418 28 399 [[HW Design]]<br />
poly 48 299 83 299 83 318 48 318 48 299 [[Block Diagram]]<br />
poly 38 318 93 318 93 337 38 337 38 318 [[Block Diagram]]<br />
poly 37 209 95 209 95 228 37 228 37 209 [[Use Case Scenarios]]<br />
poly 35 228 96 228 96 247 35 247 35 228 [[Use Case Scenarios]]<br />
poly 25 102 106 102 106 121 25 121 25 102 [[Class Design]]<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/AnalysisAnalysis2009-11-05T15:16:33Z<p>Ellyk: </p>
<hr />
<div><br />
<imagemap><br />
<br />
Image:AnalysisOverview_img.gif<br />
<br />
poly 21 452 111 452 111 471 21 471 21 452 [[Dimensioning]]<br />
poly 39 355 93 355 93 374 39 374 39 355 [[Interface Analysis - realisation]]<br />
poly 38 374 93 374 93 393 38 393 38 374 [[Interface Analysis - realisation]]<br />
poly 22 266 109 266 109 285 22 285 22 266 [[User Interface Analysis - realisation]]<br />
poly 38 285 93 285 93 304 38 304 38 285 [[User Interface Analysis - realisation]]<br />
poly 38 178 94 178 94 197 38 197 38 178 [[Use Case Analysis - realisation]]<br />
poly 38 197 93 197 93 216 38 216 38 197 [[Use Case Analysis - realisation]]<br />
poly 49 89 82 89 82 108 49 108 49 89 [[Class Analysis - realisation]]<br />
poly 38 108 93 108 93 127 38 127 38 108 [[Class Analysis - realisation]]<br />
<br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/Strategy_And_PlanningStrategy And Planning2009-11-05T15:13:41Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:StrategyAndPlanningOverview_img.gif<br />
<br />
<br />
poly 27 354 110 354 110 373 27 373 27 354 [[Deployment Planning]]<br />
poly 39 373 98 373 98 392 39 392 39 373 [[Deployment Planning]]<br />
poly 32 179 104 179 104 198 32 198 32 179 [[Verification Planning]]<br />
poly 39 198 98 198 98 217 39 217 39 198 [[Verification Planning]]<br />
poly 27 88 110 88 110 107 27 107 27 88 [[Development Strategy]]<br />
poly 42 107 95 107 95 126 42 126 42 107 [[Development Strategy]]<br />
poly 30 269 107 269 107 288 30 288 30 269 [[Development Planning Realisation]]<br />
poly 39 288 98 288 98 307 39 307 39 288 [[Development Planning Realisation]]<br />
<br />
<br />
</imagemap><br />
<br />
<br />
[[Development Strategy]]<br />
<br />
[[Verification Planning]]<br />
<br />
[[Deployment Planning]]<br />
<br />
[[Development Planning Realisation]]</div>Ellykhttp://eudp.net/index.php/Realisation_PhaseRealisation Phase2009-11-05T15:11:32Z<p>Ellyk: </p>
<hr />
<div>== What ==<br />
<br />
<imagemap><br />
<br />
Image:Realisation_Overview_img.gif<br />
<br />
<br />
poly 202 134 250 134 250 151 202 151 202 134 [[Analysis]]<br />
poly 50 217 110 217 110 234 50 234 50 217 [[Strategy and Planning]]<br />
poly 56 234 104 234 104 251 56 251 56 234 [[Strategy and Planning]]<br />
poly 356 134 395 134 395 151 356 151 356 134 [[Design]]<br />
poly 488 211 546 211 546 228 488 228 488 211 [[Implementation]]<br />
poly 546 211 550 211 550 228 546 228 546 211 [[Implementation]]<br />
poly 503 228 503 228 503 245 503 245 503 228 [[Implementation]]<br />
poly 503 228 535 228 535 245 503 245 503 228 [[Implementation]]<br />
poly 340 315 405 315 405 332 340 332 340 315 [[Verification]]<br />
poly 190 315 259 315 259 332 190 332 190 315 [[Deployment]]<br />
<br />
</imagemap><br />
<br />
[[Strategy and Planning]]<br />
<br />
[[Analysis]]<br />
<br />
[[Design]]<br />
<br />
[[Implementation]]<br />
<br />
[[Verification]]<br />
<br />
[[Deployment]]<br />
<br />
<br />
== How ==<br />
<br />
'''The dish'''<br />
<br />
Realisation Phase. <br />
<br />
'''Ingredients'''<br />
<br />
* All documentation and products produced until the beginning of the phase. <br />
<br />
'''Process''' <br />
<br />
'''''General planning'''''<br />
<br />
Determine the number and length of the timeboxes.<br />
<br />
* The first one or two timeboxes may be of different length if further planning, analysis or other activities have to be carried out before the actual development can begin.<br />
* The implementation timeboxes should normally be of same length.<br />
* Add one last short timebox to cover issues discovered during the last one or two deployments.<br />
* Estimate the total number of timeboxes.<br />
* Assign the interruption shield (see below) to a developer if there is no formal project manager in the project. Inform the customer about the interruption shield and the procedure about handling inquiries. <br />
<br />
Make a rough selection of which parts will be developed in which timeboxes - '''the development strategy'''. From the rough selection, plan the manning of each timebox. Coordinate the plan with the project organisation.<br />
<br />
'''''Planning in each timebox'''''<br />
<br />
At the beginning of each timebox, review the strategy, i.e. the selected parts that should be developed during the timebox. Often adjustments may be necessary due to knowledge gained during the past timeboxes. Some parts may be postponed and others may be advanced.<br />
<br />
Plan the deployment with the customer. Encourage the customer to participate as much as s/he can in the deployment. Write down the deployment plan.<br />
<br />
Plan the test scenario(s). Write down the tests that the product has to pass before deployment can be executed.<br />
<br />
Review the manning plans and correct accordingly. Remember to coordinate with the rest of the organisation.<br />
<br />
'''''Analysis'''''<br />
<br />
Do the necessary analysis to gain enough insight and details to design and develop the selected parts. The MW, HW and SW developers work together during the analysis.<br />
<br />
'''''Design'''''<br />
<br />
Perform the recommended design tasks redesigning the general analysis results into implementable results. MW, HW and SW developers mostly work independently during design.<br />
<br />
'''''Implementation'''''<br />
<br />
Implement the design.<br />
<br />
'''''Verification'''''<br />
<br />
Verify the product using the tests written earlier in Verification Planning . Correct as necessary.<br />
<br />
'''''Deployment'''''<br />
<br />
In cooperation with the customer, deploy the product either at the customers site or in-house depending on the possibilities.<br />
<br />
'''''Post deployment'''''<br />
<br />
Spend a short time evaluating the just-closed timebox. What went well? Why did it go well? What caused problems? Can they be prevented in the future? And how can they be prevented?<br />
<br />
Restart with the next timebox. <br />
<br />
== Why ==<br />
<br />
'''Introduction'''<br />
<br />
The Realisation Phase is typically the longest phase in the development. During the realisation, the system-to-be is constructed.<br />
<br />
'''Timeboxes'''<br />
<br />
It is our recommendation that the development is divided into smaller parts - timeboxes - rather than having one long development process covering all the activities. The timeboxes give a number of advantages over the long run such as:<br />
<br />
* The customer experiences stepwise progress in the development rather than one large delivery at the end of the development. <br />
<br />
* The frequent delivery enables the customer to try the system before it is totally implemented. As a result, the developer can get feedback early in the process rather than at the end of the development process.<br />
* It keeps the developers focus on the development by having the developer deliver to the customer frequently. <br />
<br />
* The developer will experience a number of welldefined tasks including verification planning, analysis, design, test specification and implementation which are repeated frequently. Consequently, focus will be on the quality of delivery in each deployment rather than postponing the verification and test activities until just before delivery of the final product.<br />
* The project management will, as the customer, experience stepwise identifiable progress in the development rather than progress based on the developer's feedback. In this way, the project management will have more detailed follow-ups available. <br />
<br />
The timeboxes should normally be of two to six weeks in length depending of the expected total project length, the number of developers involved, the type of project, etc. As a rule of thumb, the following chart may be used to specify the length of each timebox:<br />
<br />
[[Image:Tx_oodocs_2f7e5214e0.gif]] <br />
<br />
It is recommended to have at least one short timebox at the scheduled end of the project to fix any minor bugs or misunderstandings found in the last one or two deployments.<br />
<br />
[[Image:Timebox.gif]]<br />
<br />
'''Manning'''<br />
<br />
During the development, the manning of the timeboxes may vary. Hardware, for instance, is typically developed during the first timeboxes leaving the software developers realising their part during the later timeboxes. Additional analysis and/or planning may often take place during the first one or two timeboxes requiring less manpower.<br />
<br />
'''Planning'''<br />
<br />
At the beginning of each timebox, it is essential to perform the planning thoroughly. The planning should mainly be done by the participating developers, thereby ensuring personal commitment to the plans leading to a high degree of self management. Consequently, less general project management is required.<br />
<br />
It is recommended that the planning and specification of the verification is done before the actual implementation. For instance, it is essential that the test specifications are written based on the requirements rather than on what was actually implemented during the realisation.<br />
<br />
'''Interruption Shield'''<br />
<br />
The project management must provide a shield against interruption from the outside. The project team should concentrate on the main issue: developing the selected parts in the timebox. The project management should acknowledge the interruptions, but postpone the handling and decision process until the next planning activity is due.<br />
<br />
Only very important interruptions should be allowed when passing through to the developers. Important interruptions could be of financial character introducing major changes for the project economy, or the product under development may not be of relevance to the customer in its current form any more.<br />
<br />
If, for instance, a small organisation does not have a formal project management, one of the developers should be assigned the task of being a shield against outside interruptions.<br />
<br />
The customer and other external stakeholders should be informed about and accept the practice of shielding the developers during a realisation timebox. If the customer, not knowing the working practice, expects immediate reaction from the developer, he may be disappointed when nothing happens until weeks later.<br />
<br />
'''Customer Involvement'''<br />
<br />
Another issue worth spending some effort on is to inform the customer about the expected involvement in each deployment. The customer should assign enough time to try and test the instalment supplied at each deployment. If the customer does not assign the necessary time to run through the instalment, errors or misunderstandings may arise without being discovered until late in the development process, thus requiring greater effort fixing the problem. Feedback from the customer should be acknowledged, but not handled immediately as noted above in ''Interruption Shield''. <br />
<br />
Continue with [[Strategy and Planning]]</div>Ellykhttp://eudp.net/index.php/ContractingContracting2009-11-05T15:07:56Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:LaunchContractingOverview_img.gif<br />
<br />
<br />
poly 49 276 100 276 100 295 49 295 49 276 [[Product Acceptance]]<br />
poly 43 295 43 295 43 314 43 314 43 295 [[Product Acceptance]]<br />
poly 43 295 105 295 105 314 43 314 43 295 [[Product Acceptance]]<br />
poly 41 197 107 197 107 216 41 216 41 197 [[Quotation]]<br />
poly 33 100 116 100 116 119 33 119 33 100 [[Development Plan]]<br />
poly 60 119 89 119 89 138 60 138 60 119 [[Development Plan]]<br />
<br />
<br />
<br />
</imagemap><br />
<br />
[[Development Plan]]<br />
<br />
[[Quotation]]<br />
<br />
[[Product Acceptance]]<br />
<br />
[[Contracting]]</div>Ellykhttp://eudp.net/index.php/Technical_PlatformTechnical Platform2009-11-05T15:05:43Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:TechnicalPlatformOverview_img.gif<br />
<br />
<br />
poly 27 98 146 98 146 117 27 117 27 98 [[Technical Platform]]<br />
<br />
<br />
</imagemap><br />
<br />
[[Technical Platform]]</div>Ellykhttp://eudp.net/index.php/General_Architecture_DesignGeneral Architecture Design2009-11-05T15:04:02Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:ArchitectureDesignOverview_img.gif<br />
<br />
<br />
poly 45 253 103 253 103 272 45 272 45 253 [[Architecture Dynamics]]<br />
poly 43 272 104 272 104 291 43 291 43 272 [[Architecture Dynamics]]<br />
poly 37 167 112 167 112 186 37 186 37 167 [[Subsystem Design]]<br />
poly 52 186 96 186 96 205 52 205 52 186 [[Subsystem Design]]<br />
poly 52 82 96 82 96 101 52 101 52 82 [[Design Criteria]]<br />
poly 50 101 98 101 98 120 50 120 50 101 [[Design Criteria]]<br />
<br />
<br />
</imagemap><br />
<br />
[[Design Criteria]]<br />
<br />
[[Subsystem Design]]<br />
<br />
[[Architecture Dynamics]]</div>Ellykhttp://eudp.net/index.php/Requirements_AnalysisRequirements Analysis2009-11-05T15:01:26Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:RequirementAnalysisOverview_img.gif<br />
<br />
<br />
poly 47 89 127 89 127 108 47 108 47 89 [[Exact Requirements]]<br />
poly 60 108 115 108 115 127 60 127 60 108 [[Exact Requirements]]<br />
<br />
<br />
</imagemap><br />
<br />
<br />
<br />
[[Exact Requirements]]</div>Ellykhttp://eudp.net/index.php/Requirements_AnalysisRequirements Analysis2009-11-05T15:01:00Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:RequirementAnalysisOverview_img.gif<br />
<br />
<br />
poly 47 89 127 89 127 108 47 108 47 89 [[Exact Requirements]]<br />
poly 60 108 115 108 115 127 60 127 60 108 [[Exact Requirements]]<br />
<br />
<br />
</imagemap><br />
<br />
<br />
[[Requirements Analysis]]<br />
<br />
[[Exact Requirements]]</div>Ellykhttp://eudp.net/index.php/System_DynamicsSystem Dynamics2009-11-05T14:59:06Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:System_Dynamics.gif<br />
<br />
<br />
poly 49 172 107 172 107 191 49 191 49 172 [[Sequence Diagrams]]<br />
poly 47 191 108 191 108 210 47 210 47 191 [[Sequence Diagrams]]<br />
poly 26 87 129 87 129 106 26 106 26 87 [[Communication Diagrams]]<br />
poly 47 106 108 106 108 125 47 125 47 106 [[Communication Diagrams]]<br />
<br />
<br />
<br />
<br />
</imagemap><br />
<br />
[[Communication Diagrams]]<br />
<br />
[[Sequence Diagrams]]</div>Ellykhttp://eudp.net/index.php/Function_AnalysisFunction Analysis2009-11-05T14:57:20Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:Function_Analysis.gif<br />
<br />
<br />
poly 26 181 149 181 149 200 26 200 26 181 [[Functions Analysis]]<br />
poly 58 89 116 89 116 108 58 108 58 89 [[Function Candidates Analysis]]<br />
poly 22 108 151 108 151 127 22 127 22 108 [[Function Candidates Analysis]]<br />
<br />
<br />
<br />
</imagemap><br />
<br />
<br />
[[Function Candidates Analysis]]<br />
<br />
[[Functions Analysis]]</div>Ellykhttp://eudp.net/index.php/Function_AnalysisFunction Analysis2009-11-05T14:56:50Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:Function_Analysis.gif<br />
<br />
<br />
poly 26 181 149 181 149 200 26 200 26 181 [[Functions Analysis]]<br />
poly 58 89 116 89 116 108 58 108 58 89 <br />
[[Function Candidates Analysis]]<br />
poly 22 108 151 108 151 127 22 127 22 108 <br />
[[Function Candidates Analysis]]<br />
<br />
<br />
<br />
</imagemap><br />
<br />
<br />
<br />
[[Function Candidates Analysis]]<br />
<br />
[[Functions Analysis]]</div>Ellykhttp://eudp.net/index.php/Interface_AnalysisInterface Analysis2009-11-05T14:54:21Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:Interface_Analysis.gif<br />
<br />
<br />
poly 34 172 137 172 137 191 34 191 34 172 [[System Interface Analysis]] <br />
poly 58 191 113 191 113 210 58 210 58 191 [[System Interface Analysis]]<br />
poly 41 87 128 87 128 106 41 106 41 87 [[User Interface Analysis]] <br />
poly 57 106 112 106 112 125 57 125 57 106 [[User Interface Analysis]] <br />
<br />
<br />
</imagemap><br />
<br />
<br />
[[User Interface Analysis]]<br />
<br />
[[System Interface Analysis]]</div>Ellykhttp://eudp.net/index.php/Interface_AnalysisInterface Analysis2009-11-05T14:54:06Z<p>Ellyk: </p>
<hr />
<div><imagemap <br />
<br />
Image:Interface_Analysis.gif<br />
<br />
<br />
poly 34 172 137 172 137 191 34 191 34 172 [[System Interface Analysis]] <br />
poly 58 191 113 191 113 210 58 210 58 191 [[System Interface Analysis]]<br />
poly 41 87 128 87 128 106 41 106 41 87 [[User Interface Analysis]] <br />
poly 57 106 112 106 112 125 57 125 57 106 [[User Interface Analysis]] <br />
<br />
<br />
</imagemap <br />
<br />
<br />
[[User Interface Analysis]]<br />
<br />
[[System Interface Analysis]]</div>Ellykhttp://eudp.net/index.php/Use_Case_AnalysisUse Case Analysis2009-11-05T14:51:24Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
<br />
Image:Use_Case_Analysis.gif<br />
<br />
<br />
poly 43 278 105 278 105 297 43 297 43 278 [[Use Cases]] <br />
poly 56 184 92 184 92 203 56 203 56 184 [[Actor Candidates]] <br />
poly 39 203 109 203 109 222 39 222 39 203 [[Actor Candidates]] <br />
poly 46 99 102 99 102 118 46 118 46 99 [[Use Case Candidates]]<br />
poly 39 118 109 118 109 137 39 137 39 118 [[Use Case Candidates]] <br />
<br />
</imagemap><br />
<br />
[[Use Case Candidates]]<br />
<br />
[[Actor Candidates]]<br />
<br />
[[Use Cases]]</div>Ellykhttp://eudp.net/index.php/Use_Case_AnalysisUse Case Analysis2009-11-05T14:51:02Z<p>Ellyk: </p>
<hr />
<div><imagemap <br />
<br />
Image:Use_Case_Analysis.gif<br />
<br />
<br />
poly 43 278 105 278 105 297 43 297 43 278 [[Use Cases]] <br />
poly 56 184 92 184 92 203 56 203 56 184 [[Actor Candidates]] <br />
poly 39 203 109 203 109 222 39 222 39 203 [[Actor Candidates]] <br />
poly 46 99 102 99 102 118 46 118 46 99 [[Use Case Candidates]]<br />
poly 39 118 109 118 109 137 39 137 39 118 [[Use Case Candidates]] <br />
<br />
</imagemap <br />
<br />
[[Use Case Candidates]]<br />
<br />
[[Actor Candidates]]<br />
<br />
[[Use Cases]]</div>Ellykhttp://eudp.net/index.php/Use_Case_AnalysisUse Case Analysis2009-11-05T14:50:30Z<p>Ellyk: </p>
<hr />
<div> <imagemap <br />
<br />
Image:Use_Case_Analysis.gif<br />
<br />
<br />
poly 43 278 105 278 105 297 43 297 43 278 [[Use Cases]] <br />
poly 56 184 92 184 92 203 56 203 56 184 [[Actor Candidates]] <br />
poly 39 203 109 203 109 222 39 222 39 203 [[Actor Candidates]] <br />
poly 46 99 102 99 102 118 46 118 46 99 [[Use Case Candidates]]<br />
poly 39 118 109 118 109 137 39 137 39 118 [[Use Case Candidates]] <br />
<br />
</imagemap <br />
<br />
[[Use Case Candidates]]<br />
<br />
[[Actor Candidates]]<br />
<br />
[[Use Cases]]</div>Ellykhttp://eudp.net/index.php/Class_AnalysisClass Analysis2009-11-05T14:47:28Z<p>Ellyk: </p>
<hr />
<div> <imagemap><br />
<br />
image:ClassAnalysisOverview.gif<br />
<br />
<br />
<br />
<br />
<br />
poly 26 420 115 420 115 439 26 439 26 420 [[State Machine Diagrams]] <br />
poly 40 439 101 439 101 458 40 458 40 439 [[State Machine Diagrams]] <br />
poly 54 335 87 335 87 354 54 354 54 335 [[Class Diagram]] <br />
poly 43 354 98 354 98 373 43 373 43 354 [[Class Diagram]]<br />
poly 34 249 108 249 108 268 34 268 34 249 [[Class Event Table]]<br />
poly 54 268 88 268 88 287 54 287 54 268 [[Class Event Table]] <br />
poly 52 165 89 165 89 184 52 184 52 165 [[Event Candidates]] <br />
poly 36 184 106 184 106 203 36 203 36 184 [[Event Candidates]]<br />
poly 54 80 87 80 87 99 54 99 54 80 [[Class Candidates]] <br />
poly 36 99 106 99 106 118 36 118 36 99 [[Class Candidates]]<br />
<br />
<br />
</imagemap><br />
<br />
<br />
[[Class Candidates]]<br />
<br />
[[Event Candidates]]<br />
<br />
[[Class Event Table]]<br />
<br />
[[Class Diagram]]<br />
<br />
[[State Machine Diagrams]]</div>Ellykhttp://eudp.net/index.php/General_AnalysisGeneral Analysis2009-10-22T08:51:44Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
Image:GeneralAnalysisOverview.gif<br />
<br />
poly 29 532 115 532 115 551 29 551 29 532 [[Requirements Analysis]] <br />
poly 44 551 99 551 99 570 44 570 44 551 [[Requirements Analysis]] <br />
poly 49 445 94 445 94 464 49 464 49 445 [[System Dynamics]]<br />
poly 40 464 103 464 103 483 40 483 40 464 [[System Dynamics]]<br />
poly 43 359 101 359 101 378 43 378 43 359 [[Function Analysis]] <br />
poly 44 378 99 378 99 397 44 397 44 378 [[Function Analysis]]<br />
poly 45 272 99 272 99 291 45 291 45 272 [[Interface Analysis]]<br />
poly 44 291 99 291 99 310 44 310 44 291 [[Interface Analysis]] <br />
poly 44 186 100 186 100 205 44 205 44 186 [[Use Case Analysis]] <br />
poly 44 205 99 205 99 224 44 224 44 205 [[Use Case Analysis]]<br />
poly 55 99 88 99 88 118 55 118 55 99 [[Class Analysis]] <br />
poly 44 118 99 118 99 137 44 137 44 118 [[Class Analysis]] <br />
<br />
</imagemap></div>Ellykhttp://eudp.net/index.php/General_AnalysisGeneral Analysis2009-10-22T08:51:23Z<p>Ellyk: </p>
<hr />
<div><imagemap><br />
Image:GeneralAnalysisOverview.gif<br />
<br />
poly 29 532 115 532 115 551 29 551 29 532 [[Requirements Analysis]] <br />
poly 44 551 99 551 99 570 44 570 44 551 [[Requirements Analysis]] <br />
poly 49 445 94 445 94 464 49 464 49 445 [[System Dynamics]]<br />
poly 40 464 103 464 103 483 40 483 40 464 [[System Dynamics]]<br />
poly 43 359 101 359 101 378 43 378 43 359 [[Function Analysis]] <br />
poly 44 378 99 378 99 397 44 397 44 378 [[Function Analysis]]<br />
poly 45 272 99 272 99 291 45 291 45 272 [[Interface Analysis]]<br />
poly 44 291 99 291 99 310 44 310 44 291 [[Interface Analysis]] <br />
poly 44 186 100 186 100 205 44 205 44 186 [[Use Case Analysis]] <br />
poly 44 205 99 205 99 224 44 224 44 205 [[Use Case Analysis]]<br />
poly 55 99 88 99 88 118 55 118 55 99 [[Class Analysis]] <br />
poly 44 118 99 118 99 137 44 137 44 118 [[Class Analysis]] <br />
<br />
</imagemap><br />
<br />
[[Class Analysis]]<br />
<br />
[[Use Case Analysis]]<br />
<br />
[[Interface Analysis]]<br />
<br />
[[Function Analysis]]<br />
<br />
[[System Dynamics]]<br />
<br />
[[Requirements Analysis]]</div>Ellykhttp://eudp.net/index.php/Launch_PhaseLaunch Phase2009-10-22T08:45:29Z<p>Ellyk: </p>
<hr />
<div>== What ==<br />
<imagemap><br />
Image:LaunchOverview_img.gif<br />
<br />
poly 43 126 115 126 115 144 43 144 43 126 [[Contracting]]<br />
poly 196 117 253 117 253 135 196 135 196 117 [[Technical Platform Overview]] <br />
poly 198 135 251 135 251 153 198 153 198 135 [[Technical Platform Overview]] <br />
poly 351 108 398 108 398 126 351 126 351 108 [[General Architecture Design]]<br />
poly 336 126 412 126 412 144 336 144 336 126 [[General Architecture Design]] <br />
poly 354 144 394 144 394 162 354 162 354 144 [[General Architecture Design]]<br />
poly 496 117 543 117 543 135 496 135 496 117 [[General Analysis]]<br />
poly 493 135 546 135 546 153 493 153 493 135 [[General Analysis]]<br />
<br />
</imagemap><br />
<br />
<br />
== How ==<br />
<br />
'''The dish'''<br />
<br />
An initial analysis of the system-to-be in order to estimate price and duration of the final development. <br />
<br />
'''Ingredients'''<br />
<br />
* Preproject artifacts <br />
<br />
'''Process''' <br />
<br />
Establish an initial Class Diagram by analysing the Problem Domain.<br />
<br />
Analyse the Usage Domain and describe the Use Cases.<br />
<br />
Analyse and describe the Interfaces to the system.<br />
<br />
Compile a list of functions making the data model available to the interfaces.<br />
<br />
Throughout the above activities draw Communication or Sequence Diagrams as necessary to understand the dynamics of the system-to-be.<br />
<br />
While working with the above activities, write down exact requirements that are revealed.<br />
<br />
Iterate the above activities until enough knowledge is available for designing the architecture of the system-to-be.<br />
<br />
Finally, decide how the described system should be implemented selecting what goes in hardware and what goes in software.<br />
<br />
Having the Analysis Specification, Architecture Specification and the Platform Specification ready, prepare a Development Plan, a Quotation and a Contract.<br />
<br />
== Why ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.</div>Ellykhttp://eudp.net/index.php/Launch_PhaseLaunch Phase2009-10-22T08:45:06Z<p>Ellyk: </p>
<hr />
<div>== What ==<br />
<imagemap><br />
Image:LaunchOverview_img.gif<br />
<br />
poly 43 126 115 126 115 144 43 144 43 126 [[Contracting]]<br />
poly 196 117 253 117 253 135 196 135 196 117 [[Technical Platform Overview]] <br />
poly 198 135 251 135 251 153 198 153 198 135 [[Technical Platform Overview]] <br />
poly 351 108 398 108 398 126 351 126 351 108 [[General Architecture Design]]<br />
poly 336 126 412 126 412 144 336 144 336 126 [[General Architecture Design]] <br />
poly 354 144 394 144 394 162 354 162 354 144 [[General Architecture Design]]<br />
poly 496 117 543 117 543 135 496 135 496 117 [[General Analysis]]<br />
poly 493 135 546 135 546 153 493 153 493 135 [[General Analysis]]<br />
<br />
</imagemap><br />
[[General Analysis]]<br />
<br />
[[General Architecture Design]]<br />
<br />
[[Technical Platform Overview]] <br />
<br />
[[Contracting]]<br />
<br />
== How ==<br />
<br />
'''The dish'''<br />
<br />
An initial analysis of the system-to-be in order to estimate price and duration of the final development. <br />
<br />
'''Ingredients'''<br />
<br />
* Preproject artifacts <br />
<br />
'''Process''' <br />
<br />
Establish an initial Class Diagram by analysing the Problem Domain.<br />
<br />
Analyse the Usage Domain and describe the Use Cases.<br />
<br />
Analyse and describe the Interfaces to the system.<br />
<br />
Compile a list of functions making the data model available to the interfaces.<br />
<br />
Throughout the above activities draw Communication or Sequence Diagrams as necessary to understand the dynamics of the system-to-be.<br />
<br />
While working with the above activities, write down exact requirements that are revealed.<br />
<br />
Iterate the above activities until enough knowledge is available for designing the architecture of the system-to-be.<br />
<br />
Finally, decide how the described system should be implemented selecting what goes in hardware and what goes in software.<br />
<br />
Having the Analysis Specification, Architecture Specification and the Platform Specification ready, prepare a Development Plan, a Quotation and a Contract.<br />
<br />
== Why ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.</div>Ellykhttp://eudp.net/index.php/PreContractingPreContracting2009-10-22T08:30:18Z<p>Ellyk: </p>
<hr />
<div><br />
<imagemap><br />
Image:PreContractingOverview_img.gif<br />
<br />
<br />
poly 53 255 126 255 126 273 53 273 53 255 [[Preliminary Contract]]<br />
poly 63 273 116 273 116 291 63 291 63 273 [[Preliminary Contract]]<br />
poly 72 175 108 175 108 193 72 193 72 175 [[Quote]]<br />
poly 49 78 128 78 128 96 49 96 49 78 [[Development Planning]]<br />
poly 62 96 116 96 116 114 62 114 62 96 [[Development Planning]]<br />
<br />
</imagemap></div>Ellyk