Sudfwlfhvehvw eulhi national center for education

File Name: Technical_and_Business_Documentation_Jan2015.pdf

File Size: 673.45 KB

File Type: Application/pdf

Last Modified: 8 years

Status: Available

Last checked: 29 days ago!

This Document Has Been Certified by a Professional

100% customizable

Language: English

We recommend downloading this file onto your computer

Summary

Techni
calandBusi
ness
Documentat
ionforanSL
DS
Bri
ef7
J
anuar
y2015
b
e
p
rs
at
ct
ic
es
b
rie
f
Statew ide
Longitudinal
DataSystems
GrantProgram
SLDS Best Practices Brief
Technical and Business Documentation for an SLDS
Technical and business documentation provide a vital record of the purpose,
design, use, and practices related to a statewide longitudinal data system (SLDS)

Each SLDS team will approach documentation differently depending on the needs
of its system, but there are many documents common to information technology
and data-related projects that can help ensure effective implementation, ongoing Brief 7
maintenance, and sustainability of an SLDS. This publication provides an overview
of documentation processes and deliverables frequently used for SLDSs. January 2015
Why Is Documentation Important? This product of the Institute of
Education Sciences (IES) SLDS
Grant Program was developed
Writing documentation is not always an easy task. However, it is essential to with the help of knowledgeable
capture the details of SLDS development and implementation and to record staff from state education agencies

information about what the tasks, procedures, elements, and uses of the data The content of this brief was
system are, how and why they are carried out, who has responsibility for different derived from a regional meeting
parts of the system, and when the tasks or procedures will be performed. More of SLDS grantees that was held
specifically, documentation will help in May 2014. The views expressed
do not necessarily represent those
• record and preserve internal procedures, decisions, and SLDS knowledge
of the IES SLDS Grant Program

over time and in the event of staff turnover; We thank the following people for
• promote efficiency and consistency through replication of successful their valuable contributions:
processes and products;
• enable continuous improvement of processes and products by tracking Kathy Gosa
SLDS Grant Program,
revisions that build on successes and address issues;
State Support Team
• establish a record of requirements and processes for coordinating across
agencies and with vendors; Robin Taylor
• reduce misunderstandings and confusion by making roles, scope of work, SLDS Grant Program,
and expectations clear to all parties; State Support Team
• create a common language and understanding of the SLDS that fosters
data use and ownership in the system; and
• lay the groundwork for sharing data and collaborating with other agencies For more information on the IES
SLDS Grant Program, additional
or departments by making all parties aware of the work and progress

Best Practices Briefs, or for
support with system development
or use, please visit
http://nces.ed.gov/programs/SLDS

Technical documentation supports the step-by-step
processes associated with the data system and describes
the technical aspects of how a system works

Business documentation relates to how the data
system is used and the business objectives it meets

SLDS Best Practices Brief: Technical and Business Documentation for an SLDS 1
What Are the Different • Workflow diagrams
Types of Documents • Data dictionary or metadata repository: a detailed
and Documentation? description of the data element attributes including
information about the source and ownership of
data for both internal and integrated systems

SLDS documentation will fall into two broad categories: • Project plan: a detailed plan that includes all
technical documentation and business documentation. activities needed to meet intended outcomes

Documents in each of these categories serve different • User manuals: detailed instructions on how to
needs and may be created and used by different use the system

members of the SLDS team. • Data governance manuals and processes:
Technical Documentation detailed documents describing the data
governance policies, processes, and procedures

Technical documentation supports the step-by-step • Data calendar: a description of when data are
processes associated with the system and describes collected, validated, finalized, and reported,
the technical aspects of how a system works. Having including the purpose(s) for each action

this documentation facilitates support, maintenance, • Roles and responsibilities of agency staff: a
upgrades, and enhancements. Technical documentation detailed document describing who is responsible
can include the following types of documents: for what tasks related to the system. This
• Technical specifications and business rules: document is especially important when roles
detailed descriptions of the requirements for and responsibilities for the SLDS span multiple
the data system. agencies, such as when a central IT agency
• Technical architecture: an illustration of the provides hosting and support for the system

design for the system and the workflow. • Training documents and modules: detailed
• Data architecture: a picture that shows the data documents or resources that are used to train
structure, including the entity relationships. users of the system

• Data model: a description of the way in which • Communication plan: a plan that describes
the data relate and are collected and stored. all internal and external outreach activities
• Programming code: the actual code that is regarding the system

implemented, with comments. • Release schedule: a plan that specifies what SLDS
• Test plans and test cases: detailed documents data or tools will be available to whom and when

that describe the way in which a system or • Data security: processes and procedures that
application is to be tested. are used to develop and maintain a data security
• Security plan: a detailed description of the program to include consistency with program
privacy and security practices for the system. laws, statutes, and regulations

Business Documentation
Business documentation relates to how the system is
used and the business objectives it meets. It facilitates
communication with users and the program area
regarding the goals and uses of the system. Business
documentation can include the following documents:
• Project charter: a document that describes the
scope, objectives, and stakeholders for a project

• Business needs or requirements: detailed
descriptions of the processes that must be
supported by the system

2 SLDS Best Practices Brief
Documentation Suggestions
Do: Do Not:
Plan the documentation along with the Overdo the documentation

data system

Overlook documentation for vendor-
Follow state standards and requirements, if developed systems and processes

available and applicable

Lose track of document versioning

Take advantage of available resources that
can make the job of documentation easier

Create documentation that is understandable,
easy to use, and written for its
intended audience

Consider options for media used
for documentation

Be sure that documents are reviewed by all
SST Tip: If your state has limited
relevant parties before they are released

documentation to date for its
Ensure documentation is housed in a central, SLDS, a good way to get started
accessible location that is available to all is to identify the most critical
intended users

processes and systems and begin
Have a plan for maintaining and by documenting those

updating documents

Do:
Plan the documentation along with the Follow state standards and requirements, if
data system. available and applicable

Too often, documentation is left for the end of a data If your state has standards or other technical
system project as an afterthought. When resources and requirements, it is important to describe how the
time run short, documentation often does not happen. SLDS effort is aligned to those requirements. It is also
important to note any deviations from state standards
Documentation, in written form, should be a part and requirements and why the deviations are necessary

of every phase of the SLDS effort. When specific
types of documentation are initially created depends Take advantage of available resources that
on the type and stage of the SLDS effort. Some can make the job of documentation easier

types of business documentation, such as project Is there another project that has good documentation
charters and business requirements, should begin that can be a model for the SLDS? Does the agency
during the planning stages of the effort. Technical have a communications director, publication staff,
documentation is often included in later stages of the or other personnel with professional training in
system development process as the SLDS is designed documentation who can help by mentoring others or
and built. reviewing documents?
Technical and Business Documentation for an SLDS 3
Create documentation that is be able to discern how to use the system with little or
understandable, easy to use, and written no help. Information technology staff should be able
for its intended audience. to easily understand how the system was designed and
Much of the information that is documented for data developed and why the system was designed as it was

systems is complex and can be difficult to understand. Consider options for media used
One goal of documentation is to present highly for documentation

technical information in a clear, easy to understand,
and usable way. It is important to consider the In addition to printable documents, documentation
audience for each document as it is written to ensure might be created effectively using video or audio
that it will be accessible for readers. End users should recordings, interactive modules, or other formats

Kansas: Creating Standardized Documentation for IT Projects
The Kansas State Department of Education (KSDE) has established a robust
suite of documentation to supports its software development lifecycle, and
standard templates have been developed for each of the documents. At
the beginning of each initiative or project, a Project Start Checklist is used
to determine the scope of documentation that is needed for the project

Simple, low-risk updates to an existing system require less documentation
than development and implementation of a new, complex system. Further,
the practice of peer review and requiring appropriate individuals to sign off on the document help ensure
the quality and usability of each document. The Project Plan, Roles and Responsibilities document, and
Communication Matrix further describe what is expected in terms of documentation, by whom, and when

Kansas’s Documentation Templates in the Public Domain Clearinghouse (login required):
• Project Start Checklist: This template allows the project management team to plan for appropriate
documentation based on the complexity and risk associated with the project

https://slds.grads360.org/#communities/pdc/documents/2699
• Communication Matrix Template: This template enables the project team to specify the multiple
methods of communication that will be used for the project including a description, purpose, author,
audience, frequency, and the preferred method for updates/communication

https://slds.grads360.org/#communities/pdc/documents/2698
• High Level Project Outline Template: This template allows the project management team to
document a high-level outline of the categories and timeline for expected project activities. This is
done as a big-picture planning tool, but it does not replace a detailed project plan

https://slds.grads360.org/#communities/pdc/documents/2697
• Project Charter Template: This template allows the project team to gain consensus regarding the
goals and constraints of the project, including general project information, project contacts, the
business need for the project, an official statement of work, specific project outcomes, project risks and
success factors, and other background information related to the project. The template can also be
used to record revisions to the original project charter

https://slds.grads360.org/#communities/pdc/documents/2700
• Roles and Responsibilities Template: This template can be customized to create a detailed list of
project responsibilities and to designate the individuals responsible for specific tasks

https://slds.grads360.org/#communities/pdc/documents/2701
• Project Implementation Checklist: This template can be customized to create a checklist of activities
related to project implementation, ensuring that the technical and business teams are on the same
page regarding the timing and responsibilities for implementation tasks

https://slds.grads360.org/#communities/pdc/documents/2702
4 SLDS Best Practices Brief
Be sure that documents are reviewed by all
relevant parties before they are released. International Standards for Software
Processes, Lifecycles, and Documentation
Review by appropriate experts and stakeholders is
particularly important for publicly released documents. The International Organization for
Standardization (ISO) publishes standards for
Ensure documentation is housed in many types of processes, including software
a central, accessible location that is development. ISO 12207 describes stages in the
available to all intended users. software development lifecycle and the principal
deliverables associated with each stage

Documentation should be easy to find on a state’s
website, which may include links to the document in • Acquisition stage
» Initiation documents
multiple places. It is also important to have at least one
» Request for proposal
hard copy of documents housed in a central location » Contract (and contract updates)
within the agency. » Supplier monitor report
» Acquisition report
Have a plan for maintaining and
updating documents. • Supply stage
» Project management plan
Specify roles and timing for maintaining documents
• Development stage
that will need to be reviewed and updated periodically,
» Functional requirements
as well as how version control will be managed and
» High-level design
how updates will be communicated. It is important » Module design
to reconsider the audience (who), the purpose of » Code
the documentation (why), the contents (what), and » Module test report
accessibility (where the document is located). As » Integration test report
projects mature, documentation must be updated » System test report
to reflect the current and historical perspectives. In • Operation stage
addition, the audience for the document may broaden » User manuals/training materials
over time. • Maintenance stage
» Enhancement plans
Do Not: » Known issues
Overdo the documentation. time, the vendor will turn over the SLDS to the state,
Although it is hard to imagine, it is possible to have and the responsibility for maintaining and enhancing
too much documentation. Carefully consider what is the system becomes that of the state. Clearly define
needed to effectively support the SLDS. Make those the expected types and standards of documentation
documentation tasks a priority, and plan for time and in contracts with the vendor to ensure that essential
human resources accordingly. aspects of the system’s development and operation are
recorded as needed

Overlook documentation for
vendor-developed systems and processes. Lose track of document versioning

All systems should be documented whether they Versioning is critical. SLDS leaders need to ensure that
are developed by vendors or in-house by an agency. the latest documentation can be easily identified and
It is essential that vendor-developed systems and that staff members are not using different versions of
processes be clearly documented; at some point in the same document

Technical and Business Documentation for an SLDS 5
State Examples of Documentation
Items from the SLDS Public Domain Clearinghouse (https://slds.grads360.org) may require a login

Project Plans and Overview Documents
• P-20 Program Baseline – Washington State (2012)
This document identifies the baseline scope, schedule, budget, and benefits of the P-20 Program. The
program will be measured against these baselines throughout the remainder of the program’s timeframe

https://slds.grads360.org/#communities/pdc/documents/2661
• Process Definition Template and Activity Table – Tennessee (2007)
A blank template for documenting relevant information about SLDS processes

https://slds.grads360.org/#communities/pdc/documents/2948
Business and Technical Requirements
• EEM-SDS Business-Technical Requirements – Michigan (2007)
A four-document archive of finalized business and technical requirements for the EEM-SDS systems

https://slds.grads360.org/#communities/pdc/documents/2960
• Longitudinal Data System (LDS) Grant Project Business Requirements – Minnesota (2006–2007)
This item documents the business requirements for Minnesota’s Longitudinal Data System Grant Project

https://slds.grads360.org/#communities/pdc/documents/2961
• Requirements Document: DSR01285 – SLDS Design and Construction Programming – Texas (2010)
This document describes the requirements for the new elements being added to the current Student
Longitudinal Data System (SLDS)

https://slds.grads360.org/#communities/pdc/documents/2788
Business Rules
• CEDARS Quick Tip Sheet: Understanding the “As of Date” – Washington State (2010)
This document is part of the training materials for the Comprehensive Education Data and Research
System (CEDARS) outlining business rules for a specific data element

http://www.k12.wa.us/CEDARS/TrainingMaterials/UnderstandingtheAsofDate.pdf
• Definitions of Selected Terms – Colorado
This webpage lists common questions and answers related to terms used in the Colorado Department
of Education’s data system, including how school dropout and graduation rates are determined

http://www.cde.state.co.us/cdereval/rvdefine
• Business Rules for Standardizing Name Fields – Washington State (2012)
A set of business rules for standardizing name fields prior to performing identity matching

https://slds.grads360.org/#communities/pdc/documents/2672
• Guidelines to Facilitate Consistent Analysis of NSC Data Across Agencies in Connecticut – Connecticut (2010)
Guidelines created to analyze the National Student Clearinghouse data in a consistent manner across
state agencies to support common outcomes as much as possible

https://slds.grads360.org/#communities/pdc/documents/2786
• Statistical Process Control – Maryland (2007)
This document describes a process added to the state’s education data collection system to ensure the
logical nature of the aggregates published for state and federal compliance reporting

https://slds.grads360.org/#communities/pdc/documents/2964
• Alaska Unity Project: Phase II Data Warehouse: Business Requirements and Analysis – Alaska (2006)
This document describes the business requirements gathered during interview sessions with
representatives of the program sections involved in the UNITY Data Warehouse project

https://slds.grads360.org/#communities/pdc/documents/3140
6 SLDS Best Practices Brief
System Models
• Data Flow Chart — Minnesota (2014)
A conceptual/technical diagram of the data flow process for Minnesota’s P-20W SLDS

https://slds.grads360.org/#communities/pdc/documents/5150
Data Dictionaries
• Education Insight Data Dictionary – Delaware (2012)
Data standards for the Education Insight data warehouse and performance management dashboards

http://dedoe.schoolwires.net/cms/lib09/DE01922744/Centricity/Domain/167/EdFiDictionary.pdf
• Data Definitions and Explanations – Montana
Definitions and explanations for all terms used in Montana’s Growth and Enhancement of Montana
Students (GEMS) data system. Use the Export button (disk icon) to download the dictionary in a
variety of file formats

http://gems.opi.mt.gov/TrainingCenter/Pages/DataDefinitions.aspx
• Student Information System Data Elements, Approved Codes, and Indicators – Illinois (2015)
Definitions of data elements included in Illinois’s student information system

http://www.isbe.net/sis/html/data_elements.htm
• South Carolina LDS Project: Data Dictionary-Data Model – South Carolina (2006)
This document illustrates South Carolina’s longitudinal data system’s data dictionary and data model

https://slds.grads360.org/#communities/pdc/documents/3134
• Agency-Wide Data Dictionary Planning Project – Wisconsin (2007)
This document details the two projects related to the Wisconsin Department of Public Instruction’s
Agency-wide Data Dictionary: a planning project and an implementation project

https://slds.grads360.org/#communities/pdc/documents/2956
Data Collection Calendars
• Colorado Department of Education Data Collection Calendar – Colorado (2014–2015)
This calendar, created with the cooperation of the departments at Colorado’s state education agency,
lists the data collections required from CDE and school districts by state and federal statutes

http://www.cde.state.co.us/cdereval/collectioncalender
• Collections, Deadlines, Notices, and Data Verification Calendar – Montana (2015)
Use the Export button (disk icon) to download the calendar in a variety of file formats

http://gems.opi.mt.gov/ReportsAndData/Pages/OPIDataCollectionsDueDates.aspx
• Tennessee Data Collection Calendar – Tennessee (2005)
A sample data collection calendar from Tennessee

https://slds.grads360.org/#communities/pdc/documents/3152
Data Manuals, User Manuals, and Training Materials
• Texas Data Standards for Data Collection – Texas (2009–2015)
A set of documents including roles and responsibilities, specifications for data submissions, a data
dictionary, and codes for multiple years

http://tea.texas.gov/Reports_and_Data/Data_Submission/PEIMS/PEIMS_Data_Standards/PEIMS_Data_Standards/
• CEDARS Data Manual – Washington State (2014–2015)
A data manual for Washington’s Comprehensive Education Data and Research System (CEDARS)

http://www.k12.wa.us/CEDARS/Manuals.aspx
• CEDARS Reporting Guidance – Washington State (2014–2015)
A manual for users submitting data to the Comprehensive Education Data and Research System (CEDARS)

http://www.k12.wa.us/CEDARS/ReportingGuidance.aspx
Technical and Business Documentation for an SLDS 7
• CEDARS Training Materials – Washington State
Training presentations, checklists, guides, and other documents related to the Comprehensive
Education Data and Research System (CEDARS)

http://www.k12.wa.us/CEDARS/Training.aspx
• Statewide Information System Portal – Arkansas (2014–2015)
An online data system portal with links to data manuals and cycle documentation, including a calendar

https://adedata.arkansas.gov/sis/Default.aspx
• ZoomWV User Guide – West Virginia (2014)
A guide with information about the ZoomWV system for educators, parents, policymakers, and the public

http://static.k12.wv.us/zoomwv/user-guide.pdf
• Maine Education Data Warehouse User Guide – Maine
Detailed guidance for processes related to Maine’s data tools

http://dw.education.maine.gov/DirectoryManager/web/MaineEDWHelp/indexDMAT.htm
• GEMS Web Portal End User Manual – Montana
A training manual developed to enable users to effectively use the tools and functions in the Growth
and Enhancements of Montana Students (GEMS) website

http://gems.opi.mt.gov/TrainingCenter/Documents/GEMS_User_Manual.pdf
• Student Information System User Manual – Illinois (2013)
A manual introducing users to the student information system and providing instruction to enable
each user to utilize the system effectively in a short period of time

http://www.isbe.net/sis/html/user_manual.htm
• Employment Data Handbook – Washington State (2012)
A guide for incorporating employment information from a state Unemployment Insurance (UI)
program into a P-20 longitudinal data system

https://slds.grads360.org/#communities/pdc/documents/2668
• Data Collection Manual – South Carolina (2006–2007)
A manual listing the data elements collected from the School Administrative Student Information
System using the SWEET tool, as well as information about how the data were used the previous year

https://slds.grads360.org/#communities/pdc/documents/2965
• Data Sharing Matrix – Washington State (2012)
A matrix detailing who is able and not able to obtain Washington’s personally identifiable data by
sector organization type

https://slds.grads360.org/#communities/pdc/documents/2663
Additional Resources
International Organization for Standardization (ISO) Software Resources
http://www.iso.org/iso/home/store/catalogue_ics/catalogue_ics_browse.htm?ICS1=35&ICS2=080&developme
nt=on
Kansas State Department of Education
http://www.ksde.org/
SLDS Best Practices Brief: Vendor Engagement: Tips from the States
http://nces.ed.gov/programs/slds/pdf/brief3.pdf
SLDS Issue Brief: Effective Project Planning and Managing Change
http://nces.ed.gov/programs/slds/pdf/managing_change.pdf
8 SLDS Best Practices Brief

Types of business documentation, such as project charters and business requirements, should begin during the planning stages of the effort. Technical documentation is often included in …