DART_BusinessProcessGuide_v2.0 1 .docx

DART Business Process Guide

Table of Contents

DART Business Process Guide Introduction The Development and Revision Tool (DART) Business Process Guide is a living document that captures workflows and business rules used to standardize, define, and control the processes associated with learning assets residing in DART. It also defines:

January 11, 2013 DART Business Process Guide v2.0

· roles and responsibilities

· workflows based on revision type

· timelines

· prerequisites

· support

· the review and approval process

· versioning

· tasking

· requirements for deployment

Finalized and approved learning asset changes to the Production environment of the Learning Management System (LMS) – “ATLAS,” are also posted in DART. Included within each workflow are its associated business rules.

Process Roles DART has two types of process roles: 1) Maintenance/Revision and 2) System User. The roles described below are NOT DART-specific System User roles (i.e., Developer, Contributor or Reviewer). The roles below are those involved in the Maintenance/Revision process – most of which align with Directive 709.

Table 1: Maintenance/Revision Process Roles

LMS Administrator (LMS Admin) Loads packages onto the Learning Management System (LMS) and configures appropriate LMS settings.

Individuals assigned to roles for maintenance and development efforts are determined by the PLD for the curriculum area under which the project resides, and the GLTC PM.

DART User Roles The table below defines the DART system user roles: Developer, Contributor, and Reviewer.

Table 2: DART System Roles

· *Create new projects

· Modify the structure of projects

· Open and preview projects

· Make content edits

· Upload media to a project

· Import/export DART project files

· Create and modify tasks

· Create a project blog

· Tag projects, chapters, and pages

· *Publish projects

· Open and preview projects

· Make content edits

· Upload media to a project

· Create and modify tasks

· Tag projects, chapters, and pages

· *Publish projects

The Contributor is NOT permitted to:

· *Create new projects

· Modify the structure of projects

· Import/export DART project files

· Create a project blog

· Open and preview projects

· Create and modify tasks

· Tag projects, chapters, and pages

The Reviewer is NOT permitted to:

· *Create new projects

· Modify the structure of projects

· Import/export DART project files

· Create a project blog

· Make content edits

· Upload media to a project

· *Publish projects

Table 2: DART System Roles (cont.)

DART Coordinator

Full-time resource that oversees the DART system from an end-user perspective. The high-level responsibilities of the Coordinator include exporting/importing DART project files, setting project run-time properties, publishing projects, deleting projects from the system, assigning projects to DART “Groups,” triaging issues, running reports, print file creation, interfacing with the vendor, etc.

* Creation and publishing of projects is performed by the DART Coordinator

Access/Permissions DART may be used by all assigned faculty, Subject Matter Experts (SMEs), and external contractors. The following paragraphs define the steps required to access this system.

Faculty

1. All designated faculty members must be trained prior to gaining access to DART.

2. Designated individuals will be assigned varying roles specific to each project they are involved with.

3. Additional assignments for access/permission will be determined by PLDs and the GLTC Production Manager.

External SMEs/Contractor

1. Individuals send a request for access/permission to the GLTC PM and PLD.

2. The GLTC PM and PLD determines if the external SME/contractor requires training.

3. The GLTC PM contacts the DART Coordinator with all of the information required to give the SME/Contractor access.

4. DART Coordinator assigns access, provides information for training (when necessary), and sends confirmation to GLTC PM/PLD.

Terminology Process Terminology (to align with DAU Directive 709)

· Maintenance: “Maintenance” refers to the general upkeep of the course/module where minor changes are applied within a relatively short period of time. Examples of maintenance changes include simple textual changes, correction to broken links, etc. Maintenance changes should take less than two weeks to complete using an available resource. This does not include time for GLTC review, testing and deployment processes nor does it include the need for additional resources for multimedia modifications.

· Revision: “Revision” refers to significant changes that may take place within the learning asset, requiring an extended amount of time to complete. Examples of revision changes include significant amounts of textual, audio, graphic, or interactivity changes (e.g., broken links, knowledge reviews), but it may also incorporate major changes such as the addition or removal of pages or lessons. Revision changes will likely take longer than two weeks to complete due to the complexity and the number of required changes. This does not include time for GLTC review, testing and deployment processes, nor does it include the need for additional resources for multimedia modifications.

· Overwrite: An “overwrite” does NOT require a completely new version of the course to be loaded to the LMS. Typical courseware changes that would result in an overwrite include fixes to broken links and minor content corrections – changes that would not impact the courseware objectives. The replacement or overwrite of files within courseware or the replacement of an entire course is due to changes that:

· have not caused significant structural change to the courseware,

· were not a result of a policy change, and

· have not impacted the terminal or enabling learning objectives.

System Terminology Common system terminology contains definitions of commonly used DART-specific terms.

· Project: A project is a stand-alone learning asset (e.g., DAU DL or DAU CL) within DART.

· Module: This is not referring to DAU’s Continuous Learning Modules. Module, in this context, is referring to how lessons are grouped within the courseware. A Module is a “container” that groups lessons with a related topic.

· Lesson: This is a series of documents (or pages) that address a specific topic within the project. Related lessons may be grouped together under a Module. For example, a DAU DL will likely contain both modules and lessons. It is unlikely that a DAU CL would contain modules – only lessons.

· Document: Lessons are made up of documents – also called pages, frames, or screens.

· Meta-tag (or “tag”): A word(s) or acronym(s) given to a project, chapter, document or image – providing information about the specific component. The meta-tag or tag is used by the Search function in DART to locate projects, chapters, documents, or images which contain the word(s) defined by the tag.

· Group: A Group is a DART folder or categorization of “like” learning assets (i.e., courseware). For DAU courseware, DART Groups will be aligned with DAU functional areas. For example, there is a DART Group entitled “LOG” and another entitled “ACQ” and another entitled “CON”. For security and access purposes, DART users are also assigned to specific Groups. Therefore, users are only able to gain access or view the projects stored within that DART Group that they have been given access to.

· DART Master Group: The DART Master Group is a secure group containing the most recent version of the courseware (the “project master”). For security purposes, projects contained in the DART Master Group are not accessible to DART users. A copy of the project master is stored in DART Groups for viewing and editing.

Configuration Management It is important to maintain configuration management of DAU courseware. A key aspect to doing so is DAU’s ability to manage the security and access to courseware in DART. This is achieved through the assignment of user roles, as well as the storage of courseware versions and source files within the DART Master Group and the Content Management System (CMS), Blackboard. The following diagram illustrates DAU’s process for maintaining configuration management of courseware in DART.

E. DEPLOY

A Configuration Management Process Update Period DART Master Group

ACQ101

V30.0.0

ACQ Group

ACQ101

V30.0.0 copy

ACQ101

3. Enter Change Requests (CRs)

User.Developer User. Contributor

User.Reviewer

Begin Block Cycle Update Period

5. Make Course Updates

End Block Cycle Update Period

7. Publish Process

- Save as NEW version

- Create Print Files

- Publish SCORM

V30.0.0

6. Remove All User Access

ACQ101

V30.1.0

1. Copy Project to Functional Group

2. Assign Access to Reviewer Role(s)

4. Assign Access to Developer and/or Contributor Role(s)

10. Copy Project to Functional Group & assign access to Reviewer Role(s) copy Review Period A. Conduct Functional Review on DART

ACQ101

V30.1.0

9. Remove previous version and save new version to DART Master Group

GLTC

V30.1.0 B. Load to LMS Production Environment

V30.1.0

V30.1.0

8. Export Source to DAU Blackboard

C. Load Test Bank D. Conduct Functional Review on LMS

User.Reviewer

GLTC

DART Administrator

KEY

Figure 1: DL Configuration Management process Naming Convention(s) and Versioning Naming Conventions For learning assets/projects that will be run on the LMS, the project name incorporates the version of the course (according to the LMS Production environment). If maintenance changes will cause a new version of the course, the new version number will be reflected in the project name.

The naming convention for courseware projects that will run on the LMS adhere to the following format:

Course Prefix + Course #_ + LMS PROD Version #_ + 3-digit version # Table 3: Courseware Naming Convention

EXAMPLE: BCF103_v1.0.0 Versioning Tracking different versions of the same project can be accomplished by manually duplicating the version number and adding a corresponding version description within DART. These are entered in two places by the DART developer or coordinator: 1) Help “popup” and 2) DART Project Manager. (See Figure 2 and 3) The same version number and description are added to the project via the DART Project Manager.Click the “Help” button.

The Help popup will contain the standard help text, along with the course version information. The developer would add this information manually.

Figure 2: Version information within “HELP”

Figure 3: Version information in the “METADATA”

DART also includes the current version number and description within the project’s metadata. The metadata.xml file within the SCORM package contains the version information found in the Project Manager Dialog box. (See Figure 4)Description and Version number within the Project Manager.

figure 4: Version information within the “PROJECT MANAGER”

Table 4: Naming Convention(s) and Versioning Workflow

EXAMPLE 1: Request that Will Require a New Version on LMS Production Server

EXAMPLE:

CURRENT VERSION in the DART Master Group: ACQ101_v20.1.15 NEW PROJECT/VERSION: ACQ101_v21.0.0 DART Coordinator

EXAMPLE 2: Request that Will NOT Require a New Version on LMS Production Server

EXAMPLE:

CURRENT VERSION in the DART Master Group: ACQ101_ v21.0.0 NEW PROJECT/VERSION: ACQ101_v21.0.1 DART Coordinator

EXAMPLE 3: New Development Request (no existing course or module)

EXAMPLE:

NEW PROJECT name: BCF220_v1.0.0 DART Coordinator

Requirements Approval Process The Requirements Approval Process is established and managed by DAU’s Requirements Board; the Board is responsible for establishing requirements for new learning assets (as defined by DAU Directive 709), revisions to learning assets and hosted learning assets.

Maintenance and Revision Requests All DART related maintenance and revision requests will follow the block cycles defined in the Maintenance and Revision section of this document. (See Page 10) New Development Requests There is no change in the Requirement and Approval process. New development will continue to follow the current Requirement and Approval process.

Maintenance and Revision Schedule To ensure efficiency of courseware updates to the LMS, DAU will implement a schedule for courseware updates. The purpose of the schedule is to:

· Provide structure to the maintenance and revision process – promote easier tracking of courseware updates and versions within DART

· Enable stakeholders to better manage resources Distance Learning (DL) Courses Block Cycle Update The Block Cycle Update process aligns with the fiscal year which runs from October (current year) to September (following year). In this option, courseware owners are given specific windows of time in which they can make modifications to their learning asset within DART and therefore know when they may expect their course or module to be deployed. The table below depicts an example of the Block Cycle Update process.

Table 5: DL Block Update Cycle

Sept 1st–30th.

New FY begins Oct 1st.

*Note: Minor changes to a DL may result in a quicker development cycle than depicted.

Update Period – The Update Period is the span of time in which the courseware owner makes approved changes to the learning asset within DART. During this period, updates are being made both to the content to the test bank document. Internal SME reviews of the changes also take place during this time. EXAMPLE – The courseware owner determines that approved changes will be made during first quarter of the fiscal year: October, November, and December, with a deployment some time before the end of February.

Test Bank

1. Course changes are reviewed to determine if changes will impact the test bank. *Note: The current document will be stored with the course/module in DART.

2. The current test bank document is reviewed and the designated ISD(s) notified.

3. All revisions (e.g., deletions, additions) are sent to the designated ISD(s) for review and feedback.

4. The ISD and DART Coordinator will upload the revised test bank document to:

· DART – will be stored as a “hidden” resource

· Deployed folder – “Restricted” Update Complete – Updates for the quarter will be completed by a specific date. At this juncture the course or module is turned over to GLTC and the DART Coordinator for quality reviews and packaging. EXAMPLE – Using the example above, the changes made in the first quarter of the fiscal year will need to be completed by the first day of the following month, January 1st. If changes were being made in the third quarter of the fiscal year, they would need to be completed by the first day of the following month, July 1st.

Review Period – The Review Period is the period of time in which GLTC conducts the required quality reviews of the learning asset on the learning management system (LMS) – ATLAS Production. The newest versions of the test banks are also loaded during this period.

Deployment – Once the reviews and test bank loads are complete, the course/module is deployed. EXAMPLE – For changes and reviews completed in the first quarter of the fiscal year, the courseware would deploy within or by the following month, February.

Change Over – During the month of the fiscal year change over, system updates will be conducted. During this period of time, the system may be unavailable for use. This change over period provides a clean break between the current fiscal year and the next fiscal year.

Allowance If courseware changes are not complex, are completed earlier than expected or complete early in the next fiscal quarter, and GLTC resources are available to conduct GLTC review and testing, the course/module may be able to deploy sooner than anticipated. EXAMPLE – If courseware changes made in December (FY1) are completed in January (FY2), and GLTC is available to conduct reviews and testing, the course may deploy well before the FY2 deployment window (May).

Continuous Learning (CL) Module Updates Unlike the Block Cycle Update process instituted for DL courses, the process for updating CL modules is manageable. The table below depicts an example of Update Cycle for CL modules (minor changes to a CL may result in a quicker deployment than depicted).

Table 6: CL Update Cycle

*Note: Minor changes to a CL may result in a quicker deployment than depicted.

Maintenance/Update Timeline Sample The graphic below depicts the typical high-level timeline of the learning asset development and maintenance/revision process, from the Development or Maintenance/Update Period through the GLTC processes in the Review Period. Timing may vary depending on the complexity and size of the effort.

Conduct Functional Review on DART

(2 DAYS)

Create or Modify Print File(s)

(2 DAYS)

Publish Project and Export to Blackboard

(1 DAY)

Load to LMS PROD

(1 DAY)

Load Test Bank (if applicable)

(2 DAYS)

Conduct Functional Review on LMS PROD

(2 DAYS)

DEPLOY

DART Request Approved

Development / Modifications Complete Maintenance/Revision Update Period Review Period

Figure 5: GLTC Learning Asset Review Period Sample

Maintenance and Revision Process Certain information will be obtained from the DAU Learning Asset Requirements Submission Form along with additional DART-related information submitted by the requestor in the DART Maintenance and Revisions Request Form. This form will be submitted by the requester via the DART website (https://daunet.dau.mil/sites/eLTC/dart/default.aspx) on DAUNet, and include information such as:

· Name of Learning Asset: (i.e., ACQ 201A – Intermediate Systems Acquisition)

· Current version on LMS PRODUCTION: For existing learning assets on the LMS

· New version on PROD?: Yes /No, new version # (if applicable)

· Estimated Time to Complete: This is the anticipated period of time users will need access to the project within DART. This information will help GLTC manage resources and create a “master” schedule to manage the reviews and testing of courseware on the LMS. It will also give the requestor an indication of when this learning asset may be deployed on the LMS (assuming resources are available).

· Users Needing Access: List of users/names needing access to the project in DART

· Project Tags: Initial listing of tags to apply at the Project Level within DART

· If the Request Type is “Maintenance/Revision,” the following information is requested/required:

· MAINTENANCE/REVISION: To better manage workflows, the requested change should be assigned a priority: Routine or Urgent.

· Routine: this change that does not negatively impact the ability of the workforce to perform their job or impede the learner’s ability to complete required courses. Routine changes will follow the block-update schedule. The following are examples of routine changes:

· misspellings

· awkward or ambiguous wording

· modifications to graphics

· modifications to page layout

· Urgent: denotes a required change such as a newly implemented policy that significantly impacts the target workforce and contradicts information in the lesson. The PLD/SME will work with the GLTC PM to deploy this change.

· MAINTENANCE/REVISION – Type(s) of Change: Identify the changes that are needed. Detailed requests will help GLTC determine if additional resources are required based on the level of effort (LOE) and if a unique skill-set is required for the change.

· content edits

· course structure

· graphic, audio, video, games, simulation The types of complex requirements that may require additional resources or funding include:

· creating graphics

· simulations

· audio narration, podcasts, animations

· MAINTENANCE/REVISION – Change Requests (CRs): SMEs are required to enter change requests into the DART CR tool and submit an electronic export of the CRs via an attachment. Hard copy change requests will not be accepted.

· Sign-off: PLD/CM acknowledgement that he/she is aware of the maintenance changes and approves of the information supplied.

· GLTC Sign-off: GLTC Program Manager signs-off and indicates when the request was received and reviewed, and when relevant will include where the learning asset will fall within the Maintenance Cycle/Schedule. The PLD and CM are also informed.

Users Needing Access:

REQUEST TYPE:

☐Maintenance ☐Revision

CHANGE REQUESTS (CRS) INPUT INTO TOOL:

☐Yes If Yes, Select Date Provided CLICK HERE TO ENTER A DATE.

☐No

Do You Need Support for the Following Development Activities? Note: Additional funding may be required:

☐Creating Graphics ☐Revising Graphics ☐Audio Narration ☐Podcasts ☐Videos ☐Animations ☐Games ☐Simulations

Comments: Click here to enter text.

PLD Name:Click here to enter text.

PLD Signature: ____________________________ Date: Click here to enter a date.

GLTC Name:Click here to enter text.

GLTC Signature: __________________________ Date: Click here to enter a date.

Maintenance/Revision Workflow The workflow below correlates with the Maintenance/Revision Timeline. (See Figure 5) Table 7: Maintenance/Revision Workflow Revision Cycle

Update Period

The courseware test bank document will be stored with the course/module in DART as a “hidden” resource (will not publish with the project).

A standard DART Task will be added to each project to 1) review project Test Bank and 2) document if Test Bank changes are necessary (Y/N).

Project SME

If extended team members, who do not have access to the project in DART, need to validate changes to the course, the GLTC PM will send to them the Tasks Report printed from DART. These members would access the project from an accessible location outside of DART (i.e., the LMS) as “Reviewers,” to review and validate changes.

GLTC PM

· New development

· Maintenance/revisions resulting in structural changes

· New interactive components added to courseware GLTC Resource or ISD

For learning assets/projects that will be run within the LMS, ensure project name incorporates the version of the course (according to LMS Production environment). If the maintenance changes will cause a new version of the course, the new version # should be reflected in the project name within the Master Group and within the exported project file.

Naming convention for courseware projects to adhere to the following format: Course Prefix + Course Number + 3-digit version # EXAMPLE: ACQ101_v20.0.1

SEE APPPENDIX A

DART Coordinator

Deployment

Summary of Business Rules for Maintenance/Revision Efforts

· Step 11:

· The courseware test bank document will be stored with the course/module in DART as a “hidden” resource (will not publish with the project).

· A standard DART Task will be added to each project to 1) review project Test Bank and 2) document if Test Bank changes are necessary (Y/N).

FIGURE 6: EXAmPLE of DL MODULE EXAM SCO

The Exam SCO link In the DART Preview mode will result in “The page cannot be found.” However, in the LMS the exam will display and function as designed.

FIGURE 7: exam sco in DART preview mode

· Step 13:

· If extended team members, who do not have access to the project in DART, need to validate changes to the course, the GLTC PM will send to them the Tasks Report printed from DART. These members would access the project from an accessible location outside of DART (i.e., the LMS) as “Reviewers,” to review and validate changes

· Step 17:

· For learning assets/projects that will be run within the LMS, ensure project name incorporates the version of the course (according to LMS Production environment). If the maintenance changes will cause a new version of the course, the new version # should be reflected in the project name within the Master Group and within the exported project file. An “About Me” file may also be created to incorporate the version information.

· Naming conventions for courseware projects to adhere to the following format: Course Prefix + Course Number + 3-Digit version # (EXAMPLE: ACQ101_v20.0.1). In this example, version 20 of ACQ101 has completed its first round of maintenance revisions in DART. When the same version undergoes a second round of maintenance revisions the new project name would be ACQ101_v20.0.2.

Figure 8: Maintenance revision workflow image2.png image3.png image4.png image5.png image6.png image7.png image8.png image9.png image10.png image11.png image7.tmp image13.png image8.tmp image9.tmp image16.png image17.png image10.tmp image19.png image12.png image14.png image15.png image18.png image1.png image20.png image21.emf oleObject1.bin Title

Function

Phase�