Information Systems Advisory Committee
Meeting Minutes
May 17, 2010
I. Call to order
Steve Vieira called to order the meeting of the Information Systems Advisory
Committee at 1:00 PM on May 17, 2010 in the IT Conference Room.
Roll call
The following persons were present: Steve Vieira, Michelle O’Brien, Bill
LeBlanc, Jamie Nash and Sharon Picard.
Peter Woodberry, Deb Aiken and Becky Sheldon were absent.
Minutes from last meeting were pre-approved through email exchange earlier.
II. Information Security Council
Steve introduced the idea of developing an information security council which
would create working groups to provide policy, guidelines, best practices and
plans for addressing the growing compliance demands upon CCRI for protecting
personally identifiable information (PII).
Manny Correia, Tom Pitts and Steve have been formulating concepts for an
introductory presentation to the President in order to gain support for beginning
this comprehensive and massive project.
With increasing pressure from bordering state legislature (Massachusetts), credit
card vendors (PCI-DSS and PA-DSS compliance), federal regulations (FERPA
and HIPAA) to comply with various rules and guidelines, CCRI faces a point
where, without documented policies and practices, the liability increases.
Data breaches and information protection are constant security topics that have
been in the news repeatedly for the last five years. The Information Security
Council would be the focal point of the college trying to address awareness
programs, security standards, data handling processes and best practices for
preventing loss of data at CCRI.
III. Production Database Changes
Steve introduced a document (Appendix A) introducing the concept of the
Dynamic Software Development Method (DSDM) to address the issue of how
changes in production systems can be made in appropriate but controlled fashion.
Using two systems combined, the Joint Application Development (JAD) and the
Rapid Application Development, changes to Production systems can be
expedited while maintaining the database integrity.
The text and chart on page three of the Appendix A describes how the system
would function. The changes currently occurring in the production database
must stop. Software development lifecycles are designed to have a requirements
document, a design, user acceptance testing and then implementation in a “live’
environment. Changes that are not considered in this manner could lead to loss
of data, inadvertent elimination of data or worse.
By having a rapid deployment methodology, IT can assure that the requested
work gets resolved quickly while guaranteeing the integrity of the production
system for all our integrated modules and users. This system seeks to answer
those statements that having a more standardized and rigid deployment system
would slow progress and keep people from doing their jobs.
Production systems are not for testing. Any time a modification is made in
Production, everyone should know what impact that change will have before it
occurs. Using the DSDM ensures that we have better control over “untested “
modifications while maintaining a timely delivery of requested operational
adjustments.
Action Item 1: Steve to bring the DSDM, JAD and RAD to BUG and other
users groups to ensure that everyone understands what is being proposed.
IV. Security in Banner Production
Steve discussed his plans to take the model for security and functional positions
delivered to him by SunGard HE and compare that to the current security schema
in place in the Banner Production database.
SunGard HE sent Steve a spreadsheet describing each of the positions normally
occurring on an institution of higher education. Steve also has a current security
schema in place at CCRI. He is going to compare those over this summer to
develop a proposal to modify the existing security schema in use at CCRI.
Steve assures everyone that it is not his intent to take away needed functionality
and that that will be carefully monitored as the proposal is developed. On the
other hand, as part of the overall security picture, an audit of the current security
schema might find some existing privileges and permissions to be exorbitant and
so this is an opportune time to measure how that might be modified.
Action Item 1: Steve to compare security schemas; SunGard HE proposed versus
existing CCRI Banner.
Action Item 2: Steve to work with Tom Pitts on tightening the security classes
available on campus to a wide number of users.
V. Pre-conference Feedback and SunGard HE response
Steve wanted to thank everyone for their feedback concerning the Faculty Load
pre-seminar attended at the last Banner Summit conference. He has been in
negotiations with SunGard HE and has stated that the company is prepared to offer
between 4 and 8 hours of training when we wish to schedule.
Action Item 1: Steve to work with the various user groups to determine a schedule for
the training
VI. Training/Test database Refresh Calendar
The Banner User Group recently announced that they would accept the sixty day
refresh calendar. Though this was announced to start on May 28th, members of the
ISAC committee stated that a refresh had been done on May 10th. The CTRN refresh
occurred on May 10th to accommodate a visit from the USDOE and the
implementation of Banner Workflow.
VII. Report Repository Elements
Steve proposed a document (from Syracuse University) for describing the data
block and reports that would evolve from those structures. In reviewing the document
(included in Appendix B), he asked that everyone concentrate on and contribute to the
list of items that would be potentially included.
By standardizing and using this methodology, it will enable easier long-term
searching, maintenance and change management of data blocks and reports. One
complaint about the existing report environment at CCRI is the lack of an informed
inventory where people can find reports that have already been developed and what
potential data would be included in each.
Members of the committee are asked to ponder the existing model and contribute
other important requirements for logging and documenting the data block and report
inventory over time.
Action Item 1: ISAC team to contribute additional items for the data block and report
inventory.
Action Item 2: Steve to complete a new inventory form for data blocks and reports.
VIII. Flexible Registration and Workflow Updates
Steve stated that SunGard HE is still attempting to schedule resources for flexible
registration.
Steve also stated that SunGard HE has begun the installation of Workflow. As a
result, IT will be visiting individual groups to get specific information customize the
application for use at CCRI. The amount of involvement by functional users will be
minimized as much as possible to limit resource allocation.
Action Item 1: Steve to continue to monitor Workflow implementation
Action Item 1: Steve to continue to work with SunGard HE to schedule the Flexible
Registration implementation.
IX. TouchNet Project Plan
Steve stated that TouchNet is scheduled to do their “move the button”
implementation services starting in June and ending in early August. This will ensure
compliance with credit card handling.
Additionally, TouchNet will be moving all credit card handling off-campus thus
increasing the compliance capabilities for CCRI.
X. Adjournment
Steve Vieira adjourned the meeting at 2:05 PM.
Minutes submitted by: Stephen A. Vieira
Appendix A
Normal Change Processing
The Dynamic Software Development Method
approach
Principles
There are nine underlying principles consisting of four foundations and five
starting-points.









User involvement is the main key in running an efficient and effective project,
where both users and developers share a workplace, so that the decisions can be
made accurately.
The project team must be empowered to make decisions that are important to the
progress of the project without waiting for higher-level approval.
A focus on frequent delivery of products, with assumption that to deliver
something "good enough" earlier is always better than to deliver everything
"perfectly" in the end. By delivering product frequently from an early stage of the
project, the product can be tested and reviewed where the test record and review
document can be taken into account at the next iteration or phase.
The main criteria for acceptance of a "deliverable" is delivering a system that
addresses the current business needs. Delivering a perfect system which addresses
all possible business needs is less important than focusing on critical
functionalities.
Development is iterative and incremental and driven by users’ feedback to
converge on an effective business solution.
All changes during the development are reversible.
The high level scope and requirements should be base-lined before the project
starts.
Testing is carried out throughout the project life-cycle. (See Test-driven
development for comparison).
Communication and cooperation among all project stakeholders is required to be
efficient and effective.
Rapid application development
Joint Application Design (JAD) is a process used in the prototyping life cycle area of
the Dynamic Systems Development Method (DSDM) to collect business requirements
while developing new information systems for the college. "The JAD process also
includes approaches for enhancing user participation, expediting development, and
improving the quality of specifications." It consists of a workshop where “knowledge
workers” and IT specialists meet who will ensure the product provides the needed reports
and information at the end. This acts as “a management process which allows
Information Technology (IT) departments to work more effectively with users in a
shorter time frame.
1. Identify project objectives and limitations
2. Identify critical success factors
3. Define project deliverables
4.
5.
6.
7.
8.
Define the schedule of workshop activities
Select the participants
Prepare the workshop material
Organize workshop activities and exercises
Prepare, inform, educate the workshop participants
Appendix B