<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapcontinue="Requirements_Analysis" />
  </query-continue>
  <query>
    <pages>
      <page pageid="253" ns="0" title="Realisation Phase">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">== What ==

&lt;imagemap&gt;Image:RealisationPhase.png|
rect 47 172 129 214 [[Strategy_And_Planning|Strategy And Planning]]
rect 188 93 258 130 [[Analysis|Analysis]]
rect 329 93 399 131 [[Design|Design]]
rect 458 172 535 211 [[Implementation|Implementation]]
rect 322 259 407 296 [[Verification|Verification]]
rect 178 262 268 294 [[Deployment|Deployment]]
#&lt;!-- Created by Online Image Map Editor (http://www.maschek.hu/imagemap/index) --&gt;
desc none
&lt;/imagemap&gt;

== How ==
 
'''The dish'''

Realising a complex project is best done in smaller parts.

By releasing smaller parts, or bites, of the total project, the customer can see progress immediately  and can correct any misunderstandings early.

Furthermore, the developer works under a more constant, and typically lower, pressure with a more steady stress level when delivering small parts of the project more frequently.

For a detailed discussion of timeboxes, see below.


[[Image:Realisation.png|300px]] 

'''''The realisation of the specifications into a product'''''

[[Image:Realisation-bites.png|200px]]

'''''Delivering small bites of the project'''''


'''Ingredients'''

*     All documentation, prototypes and other artefacts produced until the beginning of the phase. 

'''Process''' 

Realisation of the specifications requires involvement of a number of disciplines. 

'''''General planning'''''

Determine the number and length of the timeboxes.

*     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.
*     The implementation timeboxes should normally be of same length.
*     Add one last short timebox to cover issues discovered during the last one or two deployments.
*     Estimate the total number of timeboxes.
*     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. 

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.

'''''Planning in each timebox'''''

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

Plan the test scenario(s). Write down the tests which the product must pass before deployment can be executed.

Review the manning plans and correct accordingly. Remember to coordinate with the rest of the organisation.

'''''Analysis'''''

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.

'''''Design'''''

Perform the recommended design tasks redesigning the general analysis results into implementable results. MW, HW and SW developers mostly work independently during the design process.

'''''Implementation'''''

Implement the design.

'''''Verification'''''

Verify the product using the tests written earlier in Verification Planning. Correct as necessary.

'''''Deployment'''''

In cooperation with the customer, deploy the product either at the customer's site or in-house depending on the possibilities.

'''''PostDeployment'''''

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?

Restart with the next timebox.

== Why ==

'''Introduction'''

The Realisation Phase is typically the longest phase in the development process. During the realisation, the system-to-be is constructed.

'''Timeboxes'''

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:

*     The customer experiences stepwise progress in the development rather than one large delivery at the end of the development. 
*     The frequent delivery enables the customer to try the system before it is completely implemented. As a result, the developer can get feedback early in the process rather than at the end of the development process.
*     The frequent delivery keeps the developers' focus on the development. 
*     The developer will experience a number of well-defined 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.
*     The project management will, like 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. 

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:

[[Image:TimeboxLengthSelection.png|400px]] 

'''''Diagram for timebox length selection'''''



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.



[[Image:RealisationTimeline.png]]

'''''Example of timebox distribution'''''

'''Manning'''

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, although the software developers can start working on parts early by writing stubs that simulates the hardware until its ready. The expected size of the effort to develop the software determines when the software developer starts.

Additional analysis and/or planning may often take place during the first one or two timeboxes requiring less manpower.

'''Planning'''

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.

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.

'''Interruption Shield'''

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.

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 it could be that the product under development may not be of relevance to the customer in its current form any more.

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.

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, s/he may be disappointed when nothing happens until weeks later.

'''Customer Involvement'''

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 installment supplied for each deployment. If the customer does not assign the necessary time to run through the installment, errors or misunderstandings may arise without being discovered until late in the development process, thus requiring greater effort to fix the problem. Feedback from the customer should be acknowledged, but not handled immediately as noted above in ''Interruption Shield''. 

Continue with [[Strategy and Planning]].</rev>
        </revisions>
      </page>
      <page pageid="315" ns="0" title="Requirement analysis">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">== Requirement Analysis ==

=== What ===
Before ending up with a list of requirements, a requirement analysis must be performed.

Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, 
taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.

=== How ===

Requirements Analysis is gathering, understanding, reviewing, and articulating the needs of the stakeholders.

The process can be split into following steps :

*  Analysis  (checking for consistency and completeness)
*  Specification (documenting the requirements) 
*  Validation (making sure the specified requirements are correct)</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>