Skip to main content
photo
 
Limitations of the Prototype Compared to a Production System

As mentioned throughout this report, the Prototype was developed to meet specified service objectives within accepted constraints defined by the scope of the project. As such, the Prototype exhibited limitations that would not be evident or even desirable in a fully functioning production system. Table 8 summarizes some of the Prototype characteristics and constraints and compares them to what would need to be addressed in a production-quality system.

Table 8. Comparison of Prototype Features to Production Requirements

Category / Feature
 
Status in Prototype
 
Status in Production System
Infrastructure
Status in Production System
Infrastructure
Incorporate full application functionality
 
Prototype included functionality within applications that satisfied its scope. For example, it allowed viewing of possible errors on parcel transfers, but not error correction.
 
Full functionality of all applications would be required. For example, would need capability to correct possible errors on parcel transfer, not just view them.
 
Reliability of access
 
Handled on a case-by-case basis within Prototype.
 
Would need to address issues of providing reliable service while running important business tasks over the public Internet.
 
Financial Processing
 
Outside the scope of the Prototype.
 
Necessary part of some transactions.
 
Email Functionality
 
Not available in the Prototype.
 
Would include enhanced email features such as automatic email notification when proposed entries have been addressed.
 
Identity Management
Account management
 
The Prototype used centralized management of user identities and role-based assignments and did not address ongoing issues of people leaving, new arrivals, and transfers.
 
Would require a combination of centralized and decentralized management of identities and role-based assignments, plus a policy, process, and mechanism for handling changes.
 
Data Considerations
One Data Set Shared by All Users
 
Did not address policy issues that might arise such as how to handle dog license transfers when each municipality can see data from others. Prototype had no built-in mechanism to ensure a user could register dogs only in her own municipality.
 
Programming constraints need to be developed that reflect all business rules and policy issues.
 
Data integration from multiple sources
 
One-time data integration from 3 sources, "cleansed" enough to support Prototype applications.
 
Would need to integrate from additional data sources, perform more high-quality data cleansing, and provide for ongoing data management and maintenance.
 
Complete data sets
 
Prototype used a partial data set that was adequate for its scope.
 
Would require complete and up-to-date data sets.
 
Ability to load and unload bulk data in a batch mode
 
Not provided in the Prototype.
 
Would include functionality to upload and download batches of data to and from applications such as the Contact Repository.
 
Data integration into applications and systems outside the Prototype
 
Not addressed in Prototype, which was developed as self-contained within scope of the Prototype applications.
 
Required component to handle key transactions such as licensing fees, state and local fees, that would be integrated with financial systems.
 
Information Policies
Governance
 
The informal Advisory Committee provided governance for development, testing, and evaluation of the Prototype.
 
A formal intergovernmental structure would set direction, adopt policies, etc.
 
Shared code
 
Not addressed in Prototype, which had separate applications running in the Prototype.
 
Would develop ways to enhance re-use of code and collapse common or similar web development tasks into one.
 
Usability
Ease of Use
 
Some usability issues could be tolerated within Prototype environment.
 
User interface would be refined through successive user acceptance testing, field tests, and focus groups until all usability issues are addressed
 
Context-sensitive help
 
Prototype provided only general help screens.
 
Help information would be specific to functions and events within the system so users would find help where and when they need it.
 
Personalization of resources section based on User’s Role
 
Prototype provided a generic Resources sections that was available and identical for all users.
 
Would provide ability for individual users to customize their Resources section based on their role and interests.