Standards for Developing and Implementing
Administrative Systems at UC Davis
Introduction
The purpose of this document is to describe Standards for Developing and Implementing Administrative Systems at UC Davis. The degree to which this document is followed is dependent on the complexity and constituency of the system as represented by the figure below (adapted from the Gartner Group). Therefore, for mission critical applications, as defined in Policy and Procedure 200-45, compliance with these standards are mandatory.
The reader should also be aware that the University of California Office of the President has drafted a comprehensive and flexible standard for developing administrative systems. These standards are in compliance with the UCOP standard. See http://www.ucop.edu/ucophome/policies/bfb/is10.pdf for this document.
1.0 Planning Phase
When initiating an administrative computing system project, develop a project scope document which address the following issues.
1.1 Determine if you need to develop or buy an administrative system. Address these high-level issues:
what is the business problem or opportunity to be addressed if there is an existing system in place, where does it fall short, what
are its strengths
what benefits would a new business system bring and what procedural improvements might occur
are there other systems on campus that may be doing similar functions or processing similar data
is it possible to salvage parts of an old system
what are the critical success factors for the department's business and how does the proposed system relate to these factors. 1.2 Identify the primary stakeholders.
Identify the primary stakeholders in the proposed system development: who would be likely to fund a project
who are the secondary users
will University policy be affected by the proposed project who are the business experts who will define the business rules what departments and external entities will be impacted by the
proposed system.
1.3 Begin to define the scope of the system.
Document the scope of the system including the constraints of the system and plan to refine this definition as the project progresses:
business problem to be solved business functions to be included
business functions that will not be included opportunities for re-engineering
security requirements
required time-frame to implementation estimated resources requirements estimated budget
risks (include obstacles to implementing a new system) mitigating actions
cost/benefit analysis
preliminary project plan with time estimates and resource requirements.
1.4 Identify a sponsor for the project. The sponsor will be responsible for:
approving the scope of the system development project securing the requested budget
acting as a liaison to external staff/departments providing resources as required for success defining the governance of the project. 1.5 Identify the project team.
Members of the team should include the following roles. The team can be augmented by consultants if core-competencies are not available (for example re-engineering expertise).
project manager to manage the core team
business experts to provide the business requirements and rules, test the system as it is developed, define training requirements
system architect to provide technical oversight
quality assurance to ensure quality throughout the project software developers to analyze, design, build the system consultants as appropriate.
Develop an initial project plan which accurately reflects critical milestones, resource plan and budget constraints.
2.0 Analysis Phase
During the analysis phase, gather your department's business requirements and environmental considerations. At the end of this phase, decide whether you will build or buy your proposed system.
2.1 Capture and analyze your requirements and identify critical issues.
The analysis should include consideration of the following: business functions to be developed
all data required for these business functions
business rules determining data behavior, constraints, limits, relationships, life-cycle
business function flow
related business systems on campus and off campus
interfaces with other external and internal business systems existing data that may have to be converted
opportunities for re-engineering preliminary transition plan security requirements
campus and departmental technical environment and standards (includes: security, network, hardware, database, desktop tools, middleware, and application software delivery issues)
technical architectures which maximize opportunities for appropriate sharing of information across the campus community
critical success factors (up-time, business response time, etc.) architectural issues such as network and systems capacity planning campus policy affected
contingency planning.
2.2 Decide whether to build or buy the proposed business system. The following are factors in deciding to buy or build a business system:
survey of the marketplace which indicate availability of products that would address the majority of your business problems product compatibility with campus technical environment and
standards (includes: security, network, hardware, database, desktop tools, middleware, and application software delivery issues) full life-cycle cost of a buy versus build decision, including
customization cost
availability of internal resources to build a system
availability of contract resources to augment staff to build a system consideration of the time-frame of buy versus build.
2.3 Initiate Operations Planning
Start to address the following operational issues, and plan to refine this plan throughout the project:
determine how the application will be deployed
determine how technical and functional upgrades be accomplished determine desktop and server hardware and need to upgrade or
change end-user desktop computers
determine timing and strategy for backing up data initiate disaster planning
determine resources to support ongoing operations addressing application and hardware maintenance
develop a communication plan.
2.4 Produce an analysis summary of high level conclusions.
The analysis summary should include an assessment of the following: acceptable approaches
acceptable technologies and general architectures unacceptable approaches
unacceptable technologies and general architectures risks
opportunities for re-engineering
refinement of resource needs (people, money, environment).
3.0 Prototype Phase
Develop a prototype if there are candidate technologies or approaches which require further investigation for viability or suitability as a result of the analysis phase. The prototype can continue to evolve throughout the project life-cycle.
4.0 Design Phase
4.1 General Design
The general design should capture and document a technology independent view of the business process to automate as well as preliminary planning of other aspects of the project:
business flow data structures
data and procedure interaction reports
screens prototypes data conversions
interfaces to other systems preliminary training plan
preliminary test plan
preliminary implementation plan
coding and other appropriate infrastructure standards, such as conformance to campus data administration standards as they are developed
technical architecture (development, testing, training, production environments, capacity planning)
preliminary contingency plan access and authorization plan operations plan.
4.2 Review General Design business expert review
quality assurance review to assure all requirements are being met system architect to ensure that all designs have no integrity problems
and are compatible and technical architecture is viable. 4.3 Detail Design
The detail design should consist of technical specifications for all software objects to be built, finalization of other plans.
4.3.1 Technical specifications for: screens
reports
batch routines call-able modules
data structure implementation data integrity implementation conversions interfaces technical architecture. 4.3.2 Plans to be finalized: training test implementation
configuration management (includes version control, code migration, security, application server, etc..)
contingency plan disaster recovery capacity growth
access and authorization plan operations plan.
business expert review
quality assurance review to assure that all requirements are met and standards have been followed
system architectural review to ensure that designs have no integrity problems and are compatible and that technical architecture is viable.
4.5 Notes on Rapid Application Development
Rapid Application Development is a technique and can be viewed as a merging or blending of the Detail Design Step and the Construction Phase, in order to speed the development process. Prototypes of screens or
processes can be built that capture the detailed requirements, and provide preliminary software objects for eventual implementation. This can be an iterative process, and can be controlled by using techniques such as "time-boxing" or limiting the number of iterations.
5.0 Construction Phase
5.1 Build
Build and unit test these components: technical architecture
configuration environment software objects
test data.
5.2 Large Scale Tests.
After unit testing of all software objects, it is time to perform full scale tests that include:
integration - tests that all software works in concert and produces expected results from a cradle-to-grave perspective)
system - tests that the technical architecture performs in the expected manner in terms of response, recovery, back-up, error-correction, loading and stress
acceptance - ensures that users see the results they expect security
application software distribution.
6.0 Training Phase
The training plan for implementation and maintenance should be finalized, and user training should commence. Consideration should be given to on-going training after the implementation phase is complete.
The implementation and contingency plan should be completed and implementation should commence.
Implementation should include: data conversions
completion of the production environment including intermediate servers completion of the desktop environment
software support emergency response help-desk documentation. Back Deborah A. Lauriano 12/10/98
