wsnpresentation 18 december, 2003. slide 1 overview of wsn project

64
WSN WSN Presentation Presentation 18 December, 2003 18 December, 2003

Upload: brianna-merritt

Post on 03-Jan-2016

215 views

Category:

Documents


2 download

TRANSCRIPT

WSNWSNPresentationPresentation

18 December, 200318 December, 2003

Slide 2

Overview of WSN Project

Slide 3

Why WSN?

Slide 4

Why WSN?

No Child Left Behind (NCLB) requires extensive new data collection and reporting.

Meeting NCLB report card mandate requires a student level data collection.

Student numbers protect privacy and facilitate student level data collection and reporting.

Slide 5

NCLB requires extensive new data collection and reporting• Outcomes of interest include test results, attendance, graduation,

and dropout rates.

• Outcome data must be disaggregated by gender, race/ethnicity, disability, economic status, migrant status, and English language proficiency

• Disaggregation=2X5X2X2X2X2= 160 distinct combinations/groups for aggregate reporting. 40 groups if you don’t count gender and migrant status. More groups are required to report by grade, primary disability and English language proficiency level.

Slide 6

NCLB requires extensive new data collection and reporting.

• States must report on the acquisition of English proficiency by English language learners.

• Reporting of test results is for students enrolled for a full academic year.

• States and districts must distinguish between dropouts and transfers.

Slide 7

NCLB requires extensive new data collection and reporting.

• Requirements apply to DPI, districts, and schools.

• Wisconsin data fall short of meeting NCLB requirements. DPI and Wisconsin school districts need to modify existing data systems to fill the gaps.

• Meetings were held with selected legislators and staff. Wisconsin hired national experts to help gather input from internal and external groups and to analyze options

Slide 8

Meeting NCLB requires a student level data collection• No Child Left Behind (NCLB) Act requires that we

monitor the movements and progress of students and student groups over time.

• The only efficient way to collect these data is at the student level.

• Wisconsin schools receive over $250,000,000+ annually under NCLB but data requirements must be met.

• All states in the Midwest and almost all states nationwide have already moved or are moving in this direction.

• Wisconsin will design and implement a individual student enrollment system (ISES). The WSN Locator System is the first phase of ISES.

Slide 9

Student numbers protect privacy and facilitate reportingWSNs help protect privacy because

– They can be used in lieu of names in the student level report card data collection (i.e., the individual student enrollment system, also known as ISES).

– WSNs will contain no embedded meaning. – Social Security Numbers will not be used or

collected.– WSNs will be stored in encrypted form in the report

card data base at DPI. Names will not be included in this data base.

– Only authorized persons will have access to this data base.

Slide 10

Student numbers protect privacy and facilitate reporting

WSNs facilitate reporting because

– They can be used to efficiently combine data about a student stored in different collections and over time. Combining data is critical for meeting NCLB requirements.

– It is possible to store student data once and use/submit the data for multiple reporting purposes.

Slide 11

Why WSN?

No Child Left Behind (NCLB) requires extensive new data collection and reporting. Wisconsin gets hundreds of millions of dollars for schools through NCLB.

Meeting NCLB report card mandate indirectly requires a student level data collection. Other states have moved or are moving in this direction. This is a major shift for DPI and for many districts. We are working to design a system that will provide value to schools for school improvement purposes. We will provide multiple options for WSN Locator System use to recognize the variety of local student information systems in place. Training and support will be available through our WSN contractor (TDS) and DPI. Extensive information will be provided on the ESEA report card web page. We are working to minimize the burden, but some time and money will be required for implementation. Vendors are encouraged to begin work now to minimize effort for districts served.

Student numbers protect privacy and facilitate student level data collection and reporting. WSNs may be used locally if treated as confidential. Security and privacy are our number 1 concerns. More will be said about this later in the presentation. Local IDs may continue to be used.

Slide 12

WSN Requirements

Student ID Process

– Student Identifier– Student ID Initial Assignment– Yearly Assignment for Kindergarten Student– Request New WSN Student ID Individually (Via. Web)– Student Locator– Exit Process

Slide 13

WSN Work-Flow Overview

How Schools will use WSN Locator System

– Initial Load– Assign WSN– Locate Students– Resolve Duplicates

Slide 14

WSN Work-Flow Overview (continued)

How to Resolve Duplicates

– New School Requests Exit Confirmation – Current School Verifies Status of Student– Current School Approves or Declines Exit– Request WSN If Match Not Found

Slide 15

WSN Work-Flow Overview (continued)

Schools Assign/Locate WSNs 4 Ways

– Using a CSV File– Using a XML File– Using a Mass Entry Screen in the WSN Locator

System– Using an Individual Request Screen in the WSN

Locator System

Slide 16

Option 1

Successful

W SN LocatorSystem

Select and subm itthe CSV file to

W SN Locator System

W SN Assignm ent/Duplicate Check Process

*Assignm ent/Duplicate

Check Process

Error

Errors m ust be correctedon the original CSV file.

Re-subm it required.

Generate

XML

Student Load Process Option 1CSV File w ithout a SIS

CSV File

* Assignm ent/Duplicate check process will result in 1 possible result file and 3 possible reports: 1) F ile and report containing successful assignm ent of W SNs 2) Report containing errors 3) Report containing possible duplicate warnings**Exit Acknowledgem ent Solution (EAS) is an autom ated solution within the W SN Locator System to send exit confirm ation and transferacknowledgm ent between districts/schools within the state.

ConvertCSV to XML

Generate

Generate

Report ContainingDuplicateW arnings

File & ReportSuccessful

W SNReport

ContainingErrors

ReportContaining

Errors

Report ContainingDuplicateW arnings

File & ReportSuccessful

W SN

W SN/LS

W SN/LS will create anotherCSV file after duplicates areresolved thru the Duplicate

Review Screen

**EAS

SendConfirm ation

BatchStatus Log

UpdateStatus

Slide 17

Option 2

W SN LocatorSystem

SuccessfulGo to

Mass EntryScreen

Student Load Process - Option 2M ass Student Entry into W SN Locator System

W SN/LS

W SN/LS will create anotherCSV file after duplicates areresolved thru the Duplicate

Review Screen

W SN/LS

Mass Student EntryEnter S tudent Directory Info

W SN Assignm ent/Duplicate Check Process

*Assignm ent/Duplicate

Check Process

Generate

XML

* Assignm ent/Duplicate check process will result in 1 possible result file and 2 possible reports: 1) F ile and report containing successful assignm ent of W SNs 2) Report containing possible duplicate warnings**Exit Acknowledgem ent Solution (EAS) is an autom ated solution within the W SN Locator System to send exitconfirm ation and transfer acknowledgm ent between districts/schools within the state.

CreateXML File

Generate

Report ContainingDuplicateW arnings

File & ReportSuccessful

W SN

Report ContainingDuplicateW arnings

File & ReportSuccessful

W SN

**EAS

SendConfirm ation

BatchStatus Log

UpdateStatus

Slide 18

Option 3

School Inform ation System(SIS)

Successful

W SN LocatorSystem

Select and subm it the CSV or XMLfile

to W SN Locatory System

W SN Assignm ent/Duplicate Check Process

*Assignm ent/Duplicate

Check Process

Error

Errors m ust becorrected

in the S IS .Re-subm it required.

Generate

XML

Student Load Process Option 3XM L or CSV File from a SIS

CSV or XML File

* Assignm ent/Duplicate check process will result in 1 possible result file and 3 possible reports: 1) F ile (XML or CSV) and report containing successful assignm ent of W SNs 2) Report containing errors 3) Report containing possible duplicate warnings**Exit Acknowledgem ent Solution (EAS) is an autom ated solution within the W SN Locator System to send exit confirm ation and transferacknowledgm ent between districts/schools within the state.

ConvertCSV to XML

Generate

Generate

Report ContainingDuplicateW arnings

File (XM L or CSV)& Report

Successful W SN ReportContaining

Errors

ReportContaining

Errors

Report ContainingDuplicateW arnings

File (XM L or CSV)& Report

Successful W SN

W SN/LS

W SN/LS will create anotherCSV or XML file after

duplicates are resolvedthruthe Duplicate Review Screen

**EAS

SendConfirm ation

BatchStatus Log

UpdateStatus

Slide 19

Option 4

W SN LocatorSystem

Successful

Student Load Process - Option 4Individual On-line Entry into W SN Locator System

Request ID Screen

Enter student identifying/directory inform ationDuplicates will decrease as additional field is

enteredNo Match - request W SN

Match is identified - send EAS*confirm ation

*Exit Acknowledgem ent Solution (EAS) is an autom ated solution within the W SN LocatorSystem to send exit confirm ation and transfer acknowledgm ent between districts/schools withinthe state.

XML or CSV FileSuccessful

W SN

Go to Request ID screen

Slide 20

Archiving Student Data at the End of the School Year

Slide 21

Archiving Student Data at the End of the School Year2003-04 Requirements

Any student who was enrolled in the district at any time between the third Friday in September 2003 and July 2004 should be included in the initial WSN file unless the student transferred to another public school district, private school, or state- or district-approved educational program.

This means that the initial file should include the following students:

– students enrolled at the end of the 2003-04 school term, – students who completed high school anytime during the

2003-04 school year, and – students who stopped attending school at any time during

the 2003-04 school year but did not transfer.

Slide 22

Archiving Student Data at the End of the School Year2003-04 Requirements

Any student whose primary educational services are directly supervised by your district should be included in the initial file.

Services may be provided by district employes or by third party public or private contractors.

Examples include technical colleges, community-based organizations, nonprofit-nonsectarian agencies, school to work program providers, etc. if the student is enrolled in your district.

Slide 23

Archiving Student Data at the End of the School Year2003-04 Requirements

– WSNs and ISES-required data for all students in the initial WSN file who are no longer enrolled after the 2003-04 school year must be archived locally.

– These data must be included with 2003-04 ISES high school completion and 2003-04 ISES dropout data in the fall of 2004.

– A list of ISES-required data will be available this spring at the ESEA report card Web page.

Slide 24

Archiving Student Data at the End of the School YearThinking ahead to 2004-05

– Archive WSNs and ISES-required data for all students who were enrolled AT ANY TIME during the 2004-05 school year at least through fall 2005 ISES reporting EVEN IF students transfer out.

– These data will be needed for 2004-05 ISES attendance reporting and more in fall 2005.

– A list of 2004-05 ISES-required data for fall 2005 will be available at the ESEA report card Web page.

Slide 25

Interface Specification forSchools Information Systems

Slide 26

eXtensible Markup Language (XML)

What is XML?

Why do we use it?

Slide 27

Transaction Set Envelope

Student Load Transaction

WSN File Transaction

WSN Transaction Result Report

WSN Student Load Duplicate Report

Interface Specification Sections …

Slide 28

Escaping CharactersThese are characters that cannot appear in their literal

form but can be sent in as Entity References:

Example: Andre’ would be represented as Andre'

Entity Name Name Symbol

&lt; Less than <

&gt; Greater than >

&amp; Ampersand &

&apos; Apostrophe ‘

Slide 29

Document Type Definition (DTD)

DTD is to used define the legal building blocks of an XML document

Defines the document structure with a list of legal elements

The WSN Locator System will utilize an external DTD

Optional Elements are identified with “?”

Multiple Elements are identified with “+”

Slide 30

Testing XML with DTD

XMLcheck.html

Slide 31

No errors found in the XML file

Errors found in the XML file

Slide 32

Comma Separated Value (CSV)

The WSN Locator System accepts three distinct header types: 01 – Header record 02 – Student Detail records 03 – Trailer record.

These header types tell the WSN Locator system what type of data and in what format to expect to find the data in the row

Slide 33

Comma Separated Value (CSV) cont…

Same business rules and edits apply to the CSV transactions

Quoted string values

Example:“02”, “DOE”, “JOHN”, “”, “01/01/1990”

Slide 34

XML vs. CSV

Advantages to using XML

XML format can be easily read by a user

Current with emerging technologies

Increased flexibility in data collection Unlimited occurrences of data like ALIAS and

GUARDIAN Ease of adding / modifying fields

Slide 35

Certification Process

Generating a VALID School Student Load transaction (passing the DTD validity check consistently)

Submitting a VALID School Student Load transaction to the WSN Locator System via FTP to a designated server at DPI

Successfully passing the WSN Locator edit checks and business rules

Loading the assigned WSN Id back into the School’s Student Information System and matching the WSN Id back to the correct student Only do this if you have a TEST database.

Slide 36

Advantages of being Certified Positive publicity in the state that your software can meet the DPI guidelines to participate with the WSN Locator System

Instant notification to your clients that you are certified via the DPI WSN Locator website where the Certification matrix is displayed

Future business opportunities with schoolsthat would be looking for a package

Slide 37

WSN Standards

Three code tables will be used during the validation edits in the XML/CSV code and the application code

Gender Code table Race Code table State Code table

Slide 38

WSN Standards continued…File Naming Conventions

Six data elements and a file extension Send or Receive Tag – 1 character District Code – 4 characters School Code – 4 characters Transaction Date – 2 month, 2 day, 4 year values Transaction Type – 3 characters Sequence Number – 5 digit number File extension (XML, CSV, or HTML)

SendReceiveTag_DistrictNumber_SchoolNumber_MMDDYYYY_Type_SeqNumber.csv

S_0001_0002_01012004_SST_00001.csv

Slide 39

Where to BEGIN…..

1. Update your Student Information Systems to contain the DPI Code tables

2. Apply the WSN Locator System business rules to your software

3. Generate the XML/CSV School Student Load transaction

4. Run the stand-alone Document Type Definition test using the xmlcheck.html

5. FTP the Pilot Student Load transaction to the FTP folder

6. If WSN IDs were assigned, update SIS with WSN IDs Only if you have a Test database

7. If WSN IDs were not assigned, check the results reports, correct the data, and resubmit

8. Inform your clients when you have been certified and distribute software changes/patches

Slide 40

Security for the Exchange of Electronic Data

Privacy (Follow State & Federal Law)

Managing access to data

Managing user “identities” or accounts

Slide 41

Security Solutions inDPI’s WSN Locator System

Privacy

To keep the conversation private and confidential between the State’s server and the WSN Locator client at a school or district office, the standard mechanism of strongly encrypted SSL shall be employed.

All modern, popular web browsers are capable of conducting conversations over strongly encrypted SSL.

Slide 42

Security Solutions inDPI’s WSN Locator System (Continued)Managing access to data

To ensure that only authorized users may access the WSN Locator System and its data, the State’s Web Access Management System (WAMS) will be employed.

When granting or denying access to a web browser’s request, WAMS bases its decisions on

1. proof that the user holds an authentic account and

2. membership of the user in an appropriate “role”.

Slide 43

Security Solutions inDPI’s WSN Locator System (Continued)

Managing user accounts

To facilitate the creation and maintenance of user accounts and the assignment of users to roles, WAMS consists of production-proven tools and procedures that shall be employed.

A carefully engineered and supported WAMS infrastructure was implemented in 2001, which includes web applications for users to manage accounts. For role assignments, strict procedures are followed from the school level and on to the State level.

Slide 44

Further Information aboutManaging Access

When the WSN Locator System responds to a web browser’s request, it does so within the context of the user’s account information. In having the WSN Locator System utilize WAMS, the user’s account information is added to security audit trails. These security audit trails help prove that the WSN Locator System is used in a secured manner by only those persons with the authority to do so.

Slide 45

Managing Access

When someone submits a web request of the WSN Locator System, WAMS will always perform two steps:

1. Authentication

2. Authorization

Slide 46

Managing Access (Continued)

Authentication

When a user has not yet proven the possession of authentic user account information, WAMS will interrupt the request by prompting the user for a userID and password. Upon successfully authenticating the supplied information, the user is not interrupted again for subsequent requests. This is accomplished through use of an in-memory (a.k.a. transient or “session-based”) cookie in the user’s browser: one of the few browser requirements for using the WSN Locator System.

Slide 47

Managing Access (Continued)

Authorization

For every user request of the WSN Locator System, WAMS will seek out the necessary membership for that user in a role that has been entitled to that request. To illustrate, here is an example only.

Slide 48

An enrollment officer is entitled to upload a file of person data while an administrator is not so entitled. Assume the user Jim is a member of the administrator role and Renee is a member of the enrollment officer role. Upon requests to upload a data file, Jim is denied access, and Renee is granted access.

Managing Access - Example

IS MEMBER OF

IS MEMBER OF

Renee

Jim

ADMINISTRATORS

ENROLLMENT OFFICERS FILE

UPLOAD

Slide 49

Managing User Accounts

Creation and Maintenance of User Accounts

The following series of screen shots illustrate some of the web applications in the WAMS toolset that allow individuals to manage their own account information.

Slide 50

Slide 51

Slide 52

Slide 53

Slide 54

Slide 55

Managing User Accounts

Role Assignment

After a person has created an account in WAMS by using the Self-Registration web site, a responsible and authorized officer or agent of the school or district must request that the new user account be made a member of the appropriate WSN Locator System role. The identity of the school or district must also accompany the request so that the user may work on behalf of that organization. Only the data for that organization will then be available within the WSN Locator System to the user.

Slide 56

WAMS User Acceptance Agreement

• Your User ID and password are your keys to the State of Wisconsin over the Internet; they should be considered as important as your signature.

• Do not share your User ID and password with anyone.

• It is your obligation to protect it by keeping it confidential.

• Your user account must have a unique e-mail address. Your user account must have a unique e-mail address.

•Etc.Etc.

Slide 57

Browser Requirements

• Must accept a valid State of Wisconsin certificate (X.509) (X.509)

• Must accept session cookies Must accept session cookies

• If a proxy server is used, it must pass cookies to your If a proxy server is used, it must pass cookies to your browser browser

• Some applications may require enabling JavaScript and Some applications may require enabling JavaScript and Pop-up WindowsPop-up Windows

Slide 58

Implementation Timeline?

• Report Card Data must be publicly disseminated by 2002-03. We’re late.

• Good-faith effort must be made to meet all the requirements at the earliest possible date

Slide 59

WSN TimelineID Task Name Start Finish

1 Contract Start Date (TDS) Mon 11/3/03 Fri 1/13/062 Start contract Mon 11/3/03 Mon 11/3/03

3 WSN Locator System Design/Development Tue 11/4/03 Wed 3/31/044 Requirement Phase Tue 11/4/03 Mon 12/1/035 WSN Requirements Review Tue 11/4/03 Mon 12/1/03

6 Design Phase Mon 11/17/03 Fri 1/30/047 WSN Design Mon 11/17/03 Fri 1/30/04

8 Review XML/CSV requirements/design with Vendors & DPI Staff Mon 11/17/03 Fri 1/30/04

9 Security WAMS Mon 11/17/03 Fri 1/30/04

10 WSN Screens/Reports Prototypes Mon 11/17/03 Fri 1/30/04

11 WSN Database Mon 11/17/03 Fri 1/30/04

12 WSN Development Phase Mon 1/5/04 Wed 3/31/0413 WSN XML/CSV Mon 1/5/04 Wed 3/31/04

14 WSN Manual Mon 1/5/04 Wed 3/31/04

15 WSN Screens Mon 1/5/04 Wed 3/31/04

16 WSN Reports Mon 1/5/04 Wed 3/31/04

17 Pilot WSN Locator System Schools/Districts Thu 4/1/04 Fri 4/30/0418 Work with SIS for Certrification Thu 4/1/04 Fri 4/30/04

19 Work with School/District Pilot (Manual Process) Thu 4/1/04 Fri 4/30/04

20 Training Schools / Districts Personnel Mon 5/3/04 Wed 6/30/0421 Training of School/District personnel Mon 5/3/04 Wed 6/30/04

22 Initial Assignment of WSN for the 426 School District Mon 5/10/04 Thu 7/1/0423 Assignment of WSN Mon 5/10/04 Thu 7/1/04

24 Full Implementation Tue 6/1/04 Fri 9/17/0425 WSN Deployment Tue 6/1/04 Fri 9/17/04

26 On-site at DPI Post-implementation Support Mon 8/2/04 Fri 1/14/0527 On-site Support Mon 8/2/04 Fri 1/14/05

28 Telephone Support Mon 8/2/04 Fri 1/13/06

M T W T F S 2, '03

Slide 60

To Make WSN a RealityNext Steps School/District Vendors

• Commit to the Project• Check email, web• DPI/TDS Vendor support• Start an Approved process for SIS Vendor(s)

assignment of WSN• Vendor Training for School/District personnel• Vendor deploy new software with WSN enhancement• Address any issues of Hardware Connectivity to State

LAN• Review Policy and Procedure changes for WSN

process

Slide 61

To Make WSN a Reality

Final Steps

• Develop• Deploy• Train• Support

Slide 62

Risk Management

WSN Risk Areas

– User Buy-In and Ownership– School Information System Packages (Vendors)– Network Infrastructure– Security– Integration of Other Systems

Others?

Slide 63

For More Information

DPI’s NCLB Report Card Web site

http://www.dpi.state.wi.us/dpi/dltcl/lbstat/eseadata.html

Slide 64

Open for Discussion