PARCC TECHNOLOGY ARCHITECTURE ARCHITECTURAL PRINCIPLES AND CONSTRAINTS SUMMARY

Transcription

1 PARCC TECHNOLOGY ARCHITECTURE ARCHITECTURAL PRINCIPLES AND CONSTRAINTS SUMMARY Version 1.1 November 5, 2012

2 Architectural Principles and Constraints Summary REVISION HISTORY The following revision chart defines the version history for this document. Revision Date Released To Description /30/12 PARCC States Initial Release /5/12 PARCC Public Sharepoint Site Released as support material for Assessment Administration RFP (IDOE 13-29) CONTACT Send questions about this document via Prepared by Pacific Metrics and IBM Corporation for the Partnership for Assessment of Readiness for College and Careers. Copyright PARCC All names and products contained herein are the trademarks or registered trademarks of their respective holders.

3 Architectural Principles and Constraints Summary CONTENTS Executive Summary Overview Architectural Principles Design for Evolution and Flexibility... 6 Rationale... 6 Implications... 6 Impacted Functional Areas Componentize Functionality as Services... 7 Rationale... 7 Implications... 7 Impacted Functional Areas Design for Reuse... 7 Rationale... 8 Implications... 8 Impacted Functional Areas Use Common Technology Frameworks... 8 Rationale... 8 Implications... 9 Impacted Functional Areas Use Common Automated Build and Deployment Tools... 9 Rationale... 9 Implications... 9 Impacted Functional Areas Use Continuous Integration Rationale Implications Impacted Functional Areas Architectural Constraints Interoperability Standards Implications Origin Page i

4 Architectural Principles and Constraints Summary Impacted Functional Areas Internet Technologies Implications Origin Impacted Functional Areas Data Security: FERPA, COPPA, and CIPA Regulations Implications Origin Impacted Functional Areas Accessibility Regulations and Policies Implications Origin Impacted Functional Areas Terms and Acronyms Page ii

5 EXECUTIVE SUMMARY This executive summary condenses the key facts and findings of this document into a more concise form. It is intended to provide a shorter form of the PARCC Assessment System architectural principles and constraints that may be read instead of the longer document. However, the executive summary does not necessarily reflect the full view of the architectural principles and constraints summary provided in the full document. It follows the organizational structure of the document and includes references to key tables to help communicate important information. Architectural Principles Architectural principles are fundamental statements of vision, approach, or intent that guide the definition of a system or architecture. Pacific Metrics and IBM, with guidance and direction from the PARCC consortium, have identified these architectural principles and associated benefits and implications for the PARCC Assessment System architecture through prior experience building large- scale assessment systems: Principle Design for evolution and flexibility Componentize functionality as services Benefits and Implications Prepares the system for inevitable future changes. Decreases long- term development time and cost. May increase short- term design time and/or complexity. Identifying areas that require flexibility can be challenging, and there is a risk that the targeted area has been misidentified or is not at the correct scope. Simplified maintenance, packaging and distribution. Provides high degrees of decoupling, reusability, abstraction, and replaceability. Testing integrated services can be complex and difficult. Increased costs for managing the environment where services exchange messages to perform tasks can be challenging. Defining and implementing the appropriate level of security is challenging. Page 1

6 Principle Benefits and Implications Design for reuse Simplifies development efforts. Use common technology frameworks Use common automated build and deployment tools Provides standardized development processes for new components. Increases system quality by minimizing duplicated functionality. May increase time and effort because of the analysis required for quantifying and qualifying the functionality appropriate for reuse. Potentially creates unnecessary complexity by overgeneralizing or over- engineering solutions. Potentially creates a risk of increasing the level of coupling of components if applied incorrectly. Lowers cost by leveraging existing well- tested code. Simplifies the solution by minimizing technology diversity. By its nature, the number of candidate technologies for implementing the solution is limited. If not chosen and implemented carefully, can create lock- in with a particular solution. Improved product quality. Minimizes or eliminates redundant and manual tasks. Captures build and release history. Creates a dependency on the set of tools chosen. Use continuous integration Improves code and system quality. Increases team awareness of quality issues through constant notification. Requires the creation, configuration, and maintenance of an environment to support continuous integration. Requires the creation of a suite of software unit tests with acceptable code coverage. Page 2

7 Architectural Constraints Architectural constraints are any pre- existing standards, guidelines, strategies, or policies that limit architectural choices and put requirements on how the solution may be designed and implemented. These architectural constraints and associated benefits and implications have been identified for the PARCC Assessment System architecture: Constraint Benefits and Implications Interoperability Standards Provides the capability of communicating and interacting with disparate systems. Existing standards may not address all identified needs of the system. May increase complexity and development time. Can introduce inefficiencies depending on the quality and complexity of the standards being used. Increases the cost of maintaining compatibility with existing standards (as well as the standards as they evolve over time). Internet Technologies Minimizes desktop requirements. Data Security: FERPA, COPPA, and CIPA Regulations Easier to manage. Standardizes user interface technologies. Requires a Web browser and multi- tiered, Web- based architecture. Requires securing the client environment using a well- designed desktop and network security policy via operating system features or third- party tools. May require third- party plugins (e.g., Adobe Flash) or newer browser versions with support for HTML5 to enable interactive content. Provides a level of assurance that student data remains private. Increases the cost and complexity of managing access, retention policies, and transfer of sensitive data. Increases complexity and maintenance of the network environment. Currently, states take different approaches to compliance that may require effort to harmonize into a coherent set of PARCC policies and protocols. Page 3

8 Constraint Accessibility Regulations and Policies Benefits and Implications Assures access to the system for people with disabilities. May increase design time and the effort to identify the appropriate universal design guidelines and standards. Increases the cost and effort of implementing universal design guidelines and standards. May require specialized hardware, software, and accessories. May limit client devices that are not fully compliant. Currently, states take different approaches to compliance that may require effort to harmonize into a coherent set of PARCC policies and protocols. Terms and Acronyms This reference section lists the acronyms used in the deliverable along with their definitions. Page 4

9 1. OVERVIEW This document details the architectural principles and constraints that are to be used during the design and development of the PARCC Assessment System and cross- references identified principles and constraints with impacted functional areas of the assessment system defined in PARCC Assessment System High- level Application Architecture. This document focuses specifically on the requirements as defined in Florida Department of Education ITN A.5.C: Architectural Principles and Constraints Summary. The document is composed of these sections: Architectural Principles. Describes the architectural principles that guide the definition of the assessment system, the rationale for choosing the selected principles, the associated implications on the development of the assessment system, and the impacted functional areas. Architectural Constraints. Describes the architectural constraints that limit architectural choices and that put requirements on how the solution may be designed and implemented, the associated implications on the development of the assessment system, the origin of the constraints, and the impacted functional areas. Terms and Acronyms. Lists the acronyms used in the deliverable along with their definitions. Page 5

10 2. ARCHITECTURAL PRINCIPLES Pacific Metrics and IBM, with guidance and direction from PARCC, have identified these architectural principles for the PARCC Assessment System architecture: Design for evolution and flexibility. Componentize functionality as services. Design for reuse. Use common technology frameworks. Use common automated build and deployment tools. Use continuous integration. These principles are further described in this section, including a rationale for the selection of each principle and the implications of the principle on the development of the architecture and implementation of the assessment system. 2.1 DESIGN FOR EVOLUTION AND FLEXIBILITY The process of dealing with change to a system during the system development life cycle is defined by the term evolution. System flexibility should be part of the application design (including incorporating the costs of building in flexibility), because all systems experience unavoidable change after deployment. RATIONALE System evolution and flexibility are important for long- lived and widely used systems. They help prepare the system for future technology enhancements and efficiencies. IMPLICATIONS May increase design time and/or complexity because of the necessary process of identifying and analyzing possible future trends in technology and ultimately incorporating the necessary level of abstraction to realize an evolved and flexible design. Identifying areas that require flexibility can be challenging, and there is a risk that the targeted area has been misidentified or is not at the correct scope. IMPACTED FUNCTIONAL AREAS This is a crosscutting concern that impacts all components of the assessment system. Page 6

11 2.2 COMPONENTIZE FUNCTIONALITY AS SERVICES Componentizing services into loosely coupled units of functionality provides many of the characteristics of a service- oriented architecture, including simplifying the maintenance, packaging, and distribution of that functionality. The architecture should expose functionality of identified components as interoperable services. RATIONALE Componentized functionality provides high degrees of decoupling, reusability, and abstraction for the implemented solution that enable the interoperability and replaceability characteristics that PARCC desires for system components. IMPLICATIONS Testing integrated services can be complex and difficult because of their distributed and decoupled nature, especially for services between two different implementation organizations and/or teams. Increased costs for managing the necessary, and possibly complex, environment along with defining where and how services exchange messages to perform tasks can be challenging. Defining and implementing the appropriate level of security can be challenging. Access control and authorization are also areas that need to be maintained. IMPACTED FUNCTIONAL AREAS See the descriptions of these functional areas and edge use cases in High- level Application Architecture: 004 Content Movement 006 Registration 010 Scoring Distribution 016 Resource Center Edge Case 001 Transient Student Edge Case 003 State Assessments Edge Case 004 District Formative Assessments 2.3 DESIGN FOR REUSE Designing for reuse can simplify development efforts for components of the architecture and provide standardized development processes for new components of the system that may be Page 7

12 necessary. The system should be designed in a manner such that the solution logic is independent of any particular business process or technology. RATIONALE Reuse relates to when the service is used to automate multiple functional or business processes, which eliminates the need for creating new services and allows the building of new processes by assembling pre- existing services. This approach can decrease development costs because functionality is already created and leveraged. It can also increase the quality and reliability of the software because the pieces will be more thoroughly tested in multiple contexts (i.e., rather than just one). IMPLICATIONS May increase time and effort because of the analysis required for quantifying and qualifying the functionality appropriate for reuse. This implies a larger and more intricate design phase, especially when compared to lighter, more agile methodologies like Emergent Design. Potentially creates unnecessary complexity by overgeneralizing or over- engineering solutions. This condition occurs when system components are created through too many layers of abstraction, making it difficult to identify and add functionality in the appropriate component. It also complicates maintenance adding impediments for tracking and fixing discovered issues. Potentially creates a risk of increasing the level of coupling of components if applied incorrectly. Because several layers of abstraction can occur, care must be taken to avoid creating inter- dependencies between components leading to high levels of coupling between them. IMPACTED FUNCTIONAL AREAS This is a crosscutting concern that impacts all components of the assessment system. 2.4 USE COMMON TECHNOLOGY FRAMEWORKS Utilizing common technology frameworks implies implementing a homogenous system, wherein the same technologies can be utilized and leveraged for a more integrated and cohesive system. The architecture should be implemented with common technology frameworks, where possible, for encapsulating component functionality. RATIONALE Using common technologies results in lower costs, and the code will be easier to maintain and integrate. It also minimizes diversity and, therefore, simplifies the solution. It standardizes development, QA, and operational environments for lower cost of ownership. The use of Page 8

13 common frameworks also increases the opportunities for integrating PARCC systems with other state infrastructures and other multi- state initiatives. IMPLICATIONS By its nature, the number of candidate technologies for implementing the solution is limited. Deciding on using a technology framework involves an analysis and assessment phase where candidate technologies are compared with each other over various characteristics, specifically functionality provided and mind share in the technology industry. If not chosen and implemented carefully, can create lock- in with a particular solution. An example would include utilizing the Hibernate object- relational mapping (ORM) framework and not creating an abstraction layer, making it difficult to replace Hibernate with another ORM framework. IMPACTED FUNCTIONAL AREAS This is a crosscutting concern that impacts all components of the assessment system. 2.5 USE COMMON AUTOMATED BUILD AND DEPLOYMENT TOOLS The ability to automate the build and deployment of system components is a prerequisite for continuous integration. It offers several advantages, such as improved product quality, the elimination of redundant and manual tasks, and the capture of build and release history, and results in saved time and money. Implementing teams should utilize the same build and deployment tools throughout system development. RATIONALE Utilizing common build and deployment tools simplifies development and IT support and delivers standardization and consistency in the development process. Most importantly, these build and deployment tools enable continuous integration. IMPLICATIONS Creates a dependency on the set of tools chosen. Because there are only de- facto standards in this area and not industry standards, any work done will likely only apply to the set of tools being used in the project, making it difficult to transition to another set of tools. IMPACTED FUNCTIONAL AREAS This is a crosscutting concern that impacts all components of the assessment system. Page 9

14 2.6 USE CONTINUOUS INTEGRATION Continuous integration improves the quality of software by repeatedly applying quality control measures while building and testing the software. Implementing teams should create unit tests and utilize a continuous integration process while developing the system. RATIONALE Iterative regression testing improves code and system quality by continually confirming that the software works as expected. IMPLICATIONS Requires the creation, configuration, and maintenance of an environment to support continuous integration. Typical continuous integration environments include a source code control server for maintaining and tracking software changes and a continuous integration server that watches for changes in software and kicks off the build process, which should include code formatting/styling rules, unit and integration test suites, and notification rules for build breakage. Requires the creation of a suite of software unit tests with acceptable code coverage. This adds to implementation time, as good tests with appropriate coverage area need to be developed in parallel with the software development effort. IMPACTED FUNCTIONAL AREAS This is a crosscutting concern that impacts all components of the assessment system. Page 10

15 3. ARCHITECTURAL CONSTRAINTS These architectural constraints have been identified for the PARCC Assessment System architecture: Interoperability Standards Internet Technologies Data security: FERPA, COPPA, and CIPA Regulations Accessibility Regulations and Policies These constraints are described below, including the implications that each constraint has on the architecture as well as the identified origin of the constraint. 3.1 INTEROPERABILITY STANDARDS The architecture needs to specify the ability to communicate with a variety of disparate systems. Therefore, it must support interoperability standards for the successful transfer of various data elements via well- known methods. However, adhering to interoperability standards can increase complexity and inefficiency because the standards are likely to cover multiple uses outside of the immediate needs of the assessment system, making the standards harder to understand and implement. IMPLICATIONS Existing standards may not address all identified needs of the system. May increase complexity and development time. Can introduce inefficiencies in the software code itself, depending on the quality and complexity of the standards being used. Increases the cost of maintaining compatibility with existing standards (as well as the standards as they evolve over time). ORIGIN ITN , page 23. Key Priorities (#3): Interoperability with Existing State and District Systems ITN , page 24. Key Priorities (#9): Item Interoperability. Page 11

16 IMPACTED FUNCTIONAL AREAS See the descriptions of these functional areas and edge use cases in High- level Application Architecture: 001 Test Specification Management 002 Test Management 003 Item Management 004 Content Movement 006 Registration 008 Student Delivery 014 Data Export 016 Resource Center Edge Case 003 State Assessments Edge Case 004 District Formative Assessments 3.2 INTERNET TECHNOLOGIES The architecture requires the use of Internet technologies because the PARCC Assessment System is expected to be accessible through an Internet Web browser. This approach enforces a browser solution with many benefits including fewer desktop requirements, easier management, and standardized user interface technologies. However, it also has disadvantages such as difficulty securing the environment, limitations in transport and protocol options, and limitations in performance and content interactivity. Advances in Internet technologies like HTML5 have narrowed the gap. IMPLICATIONS Requires a web browser and multi- tiered, Web- based architecture. Requires securing the client environment using a well- designed desktop and network security policy via operating system features or third- party software or tools for locking down the desktop. May require third- party plugins or newer browser versions with support for HTML5 to enable interactive content. ORIGIN PARCC USDOE Application, page 232. The only local technology requirements will be an Internet connection and standard Web browser. Page 12

17 IMPACTED FUNCTIONAL AREAS This is a crosscutting concern that impacts all components of the assessment system. 3.3 DATA SECURITY: FERPA, COPPA, AND CIPA REGULATIONS The architecture needs to adhere to strict data security standards, including federal regulations such as the Family Educational Rights and Privacy Act (FERPA), the Children s Online Privacy Protection Act (COPPA), and the Children s Internet Protection Act (CIPA). While the PARCC Assessment System must adhere to these data security and legal regulations, adherence creates costly and complex data requirements on the architecture and implemented systems. IMPLICATIONS Increases the cost and complexity of managing access, retention policies, and transfer of sensitive data. Increases the complexity and maintenance of the network environment due to required hardware or software being installed and accurately configured. Currently, states take different approaches to compliance that may require effort to harmonize into a coherent set of PARCC policies and protocols. ORIGIN ITN , page 26. Key Assessment System Technology Capabilities (#4): The technical architecture should use standard security protocols with state- of- the- art security methods for encryption of test and personal data. The strict security protocols of encrypted databases will protect the security and confidentiality of student information in adherence to Family Educational Rights and Privacy Act (FERPA) and Children s Online Privacy Protection Act (COPPA) regulations. Personal level data will be compliant with identity management standards and FERPA regulations and agreed to by states in PARCC. These agreements will be captured in a PARCC- wide security protocols document. IMPACTED FUNCTIONAL AREAS See the descriptions of these functional areas and edge use cases in High- level Application Architecture: 006 Registration 007 Scheduling and Assignment 008 Student Delivery Page 13

18 013 Test Analysis 014 Data Export 015 Report Generation Edge Case 001 Transient Student Edge Case 002 Student Test Results Challenge Edge Case 003 State Assessments Edge Case 004 District Formative Assessments 3.4 ACCESSIBILITY REGULATIONS AND POLICIES In order to promote access to the system for all users, the architecture needs to require that the implemented user interfaces adhere to universal design principals, software and hardware embedded supports, and that they are compliant with Section 508 of the Rehabilitation Act of 1973, as amended in the Workforce Reinvestment Act of IMPLICATIONS May increase design time and the effort to identify the appropriate universal design guidelines and standards that include the following principles: Equitable use for people with diverse abilities. Flexibility in use to accommodate a wide range of abilities. Simple and intuitive use so it is easy to understand. Perceptible information regardless of sensory or physical abilities. Tolerance for error that minimizes accidents or unintended actions. Low physical effort so it can be used comfortably with minimum fatigue. Size and space for approach and use regardless of body size, posture, or mobility. Increases the cost and effort of implementing universal design guidelines and standards. May require specialized space, hardware, software, and accessories. May limit client devices that are not fully compliant. Currently, states take different approaches to compliance that may require effort to harmonize into a coherent set of PARCC policies and protocols. ORIGIN ITN , page 24. Key Priorities (#10): Accessibility. Page 14

19 IMPACTED FUNCTIONAL AREAS See the descriptions of these functional areas and edge use cases in High- level Application Architecture: 001 Test Specification Management 002 Test Management 003 Item Management 008 Student Delivery 009 Test Administration 015 Report Generation 016 Resource Center Edge Case 003 State Assessments Edge Case 004 District Formative Assessments Page 15

20 4. TERMS AND ACRONYMS Table 1 Definitions of Terms and Acronyms provides definitions for the terms and acronyms used in this document. Table 1 Definitions of Terms and Acronyms Term/Acronym Definition Description CIPA COPPA FERPA HTML5 Children s Internet Protection Act Children s Online Privacy Protection Act Family Educational Rights and Privacy Act HyperText Markup Language Revision 5 A U.S. federal law that requires technology protection measures that prevent access to offensive content over the Internet on school and library computers. A U.S. federal law that places parents in control of what information is collected online from children under 13 years of age. A U.S. federal law that protects the privacy of student education records. The 5 th revision of the HTML standard, still under development, which aims to provide more standard and streamlined support for multi- media and complex Web applications across a variety of platforms and devices. ORM Object- relational Mapping Framework for handling the translation of data calls on software objects to relational database tables and fields. Section 508 Section 508 of the Rehabilitation Act of 1973, as amended in the Workforce Reinvestment Act of 1998 Addresses legal compliance and has technical standards that require electronic and information technology accessible to people with disabilities. Page 16