Standards for Developing and Implementing Administrative Systems at UC Davis

Transcription

1 Page 1 of 7 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 , 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 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 primary users

2 Page 2 of 7 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. 1.6 Develop a project plan

3 Page 3 of 7 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.

4 Page 4 of 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

5 Page 5 of 7 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 Technical specifications for: screens reports batch routines call-able modules data structure implementation data integrity implementation conversions interfaces technical architecture 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. 4.4 Review Detail Design

6 Page 6 of 7 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 "timeboxing" 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. 7.0 Implementation Phase

7 Page 7 of 7 The implementation and contingency plan should be completed and implementation should commence. Implementation should include: Back data conversions completion of the production environment including intermediate servers completion of the desktop environment software support emergency response help-desk documentation. Deborah A. Lauriano 12/10/98