<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-cPtDc656Hgw9PuzWPtV8Iw" name="new_practice,_05YDQGq6EeCHjvXUbVfnOw" guid="-cPtDc656Hgw9PuzWPtV8Iw" changeDate="2012-10-15T15:38:59.355-0700" version="7.5.1">
  <mainDescription>&lt;p>&#xD;
    In almost every case, a product under development needs some amount of documentation for use by those who use its&#xD;
    features and those who are responsible for keeping the system functioning and available. Because neither of these areas&#xD;
    are strengths of the software development community, two new roles have been introduced that take advantage of the&#xD;
    experience and expertise of niche support staff often found in or around an IT organization.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    By playing to the strengths and availability of Technical Writers, Course Developers,&amp;nbsp;and Trainers, a Development&#xD;
    Team does not need to worry about who will write the user documents and train end users - in this case, they can have&#xD;
    the specialists accept those responsibilities. Also, working with these two specialists ultimately will improve the&#xD;
    development team's ability to articulate details of the system that they are building and provide insight into subtle&#xD;
    ways to better comment and document their code.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Virtually all applications that are developed will be used or supported by people. Very often, however, both the&#xD;
    documentation and training aspects of systems implementation are overlooked or not given enough emphasis. Inattention&#xD;
    to these areas can result in a product that does not achieve its full business value because the people who should&#xD;
    benefit from the application are not fully informed or trained.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Although this practice is documented and adopted at the development team level, in some organizations it may be&#xD;
    advantageous to consolidate and integrate all types of documentation and training materials at the program level and&#xD;
    deliver one comprehensive package to stakeholders, end users, and IT operations support personnel for the entire&#xD;
    release across the program.&#xD;
&lt;/p></mainDescription>
  <problem>&lt;p>&#xD;
    The purpose of this practice is to harden the product before a release by documenting key aspects for use by multiple&#xD;
    audiences and by providing training to end users who will take delivery of the product when it is released.&#xD;
&lt;/p></problem>
  <application>&lt;p>&#xD;
    With this practice, basic guidance regarding &lt;em>how&lt;/em> to develop documentation and training, and more importantly&#xD;
    &lt;em>why&lt;/em>, are provided here. The best way to read this practice is to become familiar with its overall structure,&#xD;
    what is in it, and how it is organized.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    There are two related parts to this practice: 1) Documentation, and 2) Training. The documentation activity normally&#xD;
    feeds the training effort. There are three basic types of documentation, each of which is meant for a different&#xD;
    audience, and each has its own purpose.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Product&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        User&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Support&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    A combination of the Product Documentation and User Documentation, with User Stories and Nonfunctional Requirements,&#xD;
    are used in the development of User Training.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Product Documentation, with the Architecture Notebook and any design artifacts, are used to create Support&#xD;
    Documentation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Start with the tasks for creating the different types of documentation. Then, review the work products that result from&#xD;
    those tasks. Next, review the tasks of the training activity. Notice that there is only one task that produces two&#xD;
    different types of training materials (end user and support materials), because the process is the same for both&#xD;
    (unlike the process for developing the three types of documentation). There are two tasks for training delivery because&#xD;
    the end user training often is formal in nature and support training usually is informal.&#xD;
&lt;/p></application>
</org.eclipse.epf.uma:PracticeDescription>
