| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription 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="-jWMpCvzhJPOglJcxCiAYjA" name="03_create_update_support_documenation,_nGAhcDHMEeC7j_IRiP-WPQ" guid="-jWMpCvzhJPOglJcxCiAYjA" changeDate="2012-05-30T13:11:48.626-0700" version="7.5.1"> |
| <mainDescription><p>
 |
| Support documentation often is the most overlooked aspect of a documentation effort. Anyone who has had the opportunity
 |
| to provide end user support for a particular application can appreciate how important effective, well-written support
 |
| documentation can be. This documentation very often is technical in nature and differs significantly from user or
 |
| product documentation, which normally is written for the lay person.
 |
| </p>
 |
| <p>
 |
| The development team should do its best to make sure that personnel who perform an IT support role have the right
 |
| amount and the relevant type of information necessary to support the application, whether they provide Tier 1, Tier 2,
 |
| or Tier 3 support. Support documentation often is developed based on these three different support categories. How
 |
| effectively the code base is commented and the ease with which those comments are found and understood contributes to
 |
| the quality and quantity of support documentation.
 |
| </p></mainDescription> |
| <sections xmi:id="_-zfOquB8EeC1y_NExchKwQ" name="Determine support documentation contents" guid="_-zfOquB8EeC1y_NExchKwQ"> |
| <sectionDescription><p>
 |
| This step is often challenging for development teams because they must put themselves in the position of IT support
 |
| personnel to develop the right kind and right amount of useful content. It is advantageous to visit the support
 |
| organization and ask them what types of documentation they would want delivered to them at each Release. You might be
 |
| surprised at what they say, and it could make your documentation tasks easier if you know exactly what type of
 |
| information they want.
 |
| </p>
 |
| <p>
 |
| Because every product is different, and because each program or IT support organization has unique needs, it is
 |
| impossible to list recommended contents for support documentation. However, each program should create support
 |
| documentation standards for the development teams that support its program.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_-zfOq-B8EeC1y_NExchKwQ" name="Leverage available materials" guid="_-zfOq-B8EeC1y_NExchKwQ"> |
| <sectionDescription><p>
 |
| Use the development team's Release Plan as a mechanism to define the scope of the support documentation. Source
 |
| materials that can contribute effectively to support documentation content include:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Component Design Specifications
 |
| </li>
 |
| <li>
 |
| Architecture Notebook
 |
| </li>
 |
| <li>
 |
| User Stories
 |
| </li>
 |
| <li>
 |
| Test Cases
 |
| </li>
 |
| <li>
 |
| Test Scenarios
 |
| </li>
 |
| <li>
 |
| Storyboards and Wireframes
 |
| </li>
 |
| <li>
 |
| Defect Records
 |
| </li>
 |
| <li>
 |
| Lessons Learned
 |
| </li>
 |
| <li>
 |
| Data Dictionary
 |
| </li>
 |
| <li>
 |
| Logical and Physical Data Models
 |
| </li>
 |
| <li>
 |
| Coding Standards
 |
| </li>
 |
| <li>
 |
| Acceptance Tests
 |
| </li>
 |
| <li>
 |
| Test Harness
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_-zfOqeB8EeC1y_NExchKwQ" name="Write support documentation" guid="_-zfOqeB8EeC1y_NExchKwQ"> |
| <sectionDescription>Based on the previous steps, write the support documentation. One way to do this is to assign sections of the
 |
| document%EOL%(determined in the step "Determine Support Documentation Contents" above) to development team members as
 |
| sprint/iteration%EOL%tasks in the release sprint/iteration.</sectionDescription> |
| </sections> |
| <sections xmi:id="_-zfOrOB8EeC1y_NExchKwQ" name="Perform quality review" guid="_-zfOrOB8EeC1y_NExchKwQ"> |
| <sectionDescription>As the support documentation is integrated, plan and conduct a quality review during the release sprint/iteration to
 |
| ensure%EOL%that the documentation is of sufficient quantity and quality. Update and improve the support documentation based
 |
| on the%EOL%results of the quality review.</sectionDescription> |
| </sections> |
| <sections xmi:id="_-zfOqOB8EeC1y_NExchKwQ" name="Deliver support documentation" guid="_-zfOqOB8EeC1y_NExchKwQ"> |
| <sectionDescription>At the end of a release, deliver the completed support documentation to the deployment manager. Ensure that the program has
 |
| a plan for communicating the support documentation to the IT operations support organization in a timely manner.</sectionDescription> |
| </sections> |
| <purpose>The purpose of this task is to ensure that the personnel who are tasked with supporting the system have enough information
 |
| about the product to perform their jobs effectively after the product has been placed into production.</purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
