There are several stages in the system/application development process. These represent the life-cycle of software developed by the Enterprise Systems unit in the department of Information Technology Services (ITS). The major stages are:
The length of each of these stages varies from project to project and the boundaries between stages are sometimes not clear. Furthermore, the progression from one stage to the next is not always unidirectional or contiguous. For example, new requirements or problems encountered during the programming or testing stages may necessitate a return to the analysis/design or requirements stages. Also, use of prototyping techniques routinely involves regressions from the testing to the analysis/design and programming stages. Nevertheless, these stages adequately represent the conceptual progression of an application under development.
The maintenance stage may actually involve some or all of its preceding stages, depending upon the scope of the maintenance project. Some maintenance projects are relatively minor, while others may involve significant enhancements to an existing system. Maintenance requests, Software Maintenance Process; minor maintenance requests need follow only the standards and procedures outlined therein, while major projects must follow those outlined in the present chapter as well.
Whether a request will result in a major or maintenance project is not always apparent at the time a request is made. For that reason, all requests go through an initial review. The initial review is conducted by one or more members of the Enterprise Systems management team. If the management team determines the request constitutes a major project, a business analyst will be assigned to the project. The business analyst will work with the requestor and prepare a request summary outlining the proposed solution.
Enterprise Systems uses Microsoft Project to track progress on the development of new applications and major enhancements to existing applications. The major steps or milestones of the project document are used to create a Project Checklist. The list is employed by end users and analysts alike to record approvals (sign-offs) and completion dates at the various steps during an application development project. The Project Checklist encompasses all of the stages of the life-cycle model, although the stages are separated into to more discrete steps (see below).
The typical development steps included in the project plan are as follows:
Application development should follow these stages, in the general order indicated, according to the guidelines outlined below.
This step begins with an Application Development Request from the end user (the Project Sponsor) that specifies, in broad terms, the nature of the proposed system. The initial request need only ask for "Consultation/Analytical Support" as it has not yet been determined that the system will actually be developed locally.
A Business Analyst is assigned to work with the sponsor (or a User Representative) to explore the problem or opportunity.
When applicable, the sponsor and the business analyst should both participate in an exploration of commercial alternatives (i.e., third-party packages). Some applications are so unique that no commercial solutions are available, while others may have several commercial alternatives. The sponsor, in consultation with the business analyst, must decide whether any commercial alternative is acceptable. An acceptable alternative should not only meet the functional requirements of the Requestor, but should also be economically feasible, run in an environment supported by Information Technology Services and support any necessary interfaces to existing systems. If a commercial solution is chosen, the development process stops here. However, this will begin a new process. See the process for Acquisition of Commercial Software.
The first deliverable from this step is the Request Summary document.
The document is prepared by the business analyst after consultation with the sponsor. The document outlines the functions of the proposed system, including a statement regarding the potential benefits of the system to the University. Although this document is at a general level, it should be comprehensive, that is, it should describe in general terms as many of the desired functions of the system as possible.
More specifically, the document incorporates the following:
The Request Summary document is scored and returned to the Enterprise Systems management team for evaluation and approval to proceed. Depending on the scope and impact of the proposal, the document may be forwarded to ITS or other University governance groups for the decision.
Once the approval to proceed has been received, the second deliverable is the Project Charter. The analyst will work closely with the sponsor or user representative(s) to define the goals and scope of the project. The Project Charter is prepared by the business analyst and contains the following:
This section describes the proposed solution. A project has one goal that gives purpose and direction to the project. This will be used as a continual point of reference for any questions that arise regarding scope or purpose. This section should be written in language that is easy for everyone to understand. It describes what will be implemented, corrected, installed, replaced or otherwise addressed to solve the problem.
A short Scope Statement that defines what the project is going to deliver. Then briefly describes the proposed "in-scope" boundaries of the project and functionality. "Out-of-scope" is listed as well to establish boundaries of the project.
This section identifies other projects or existing systems that have a relationship to this project. In particular, any dependencies this project has with other proposed projects are noted.
This section lists key assumptions that the project depends upon (resources, policies, technology, scheduling, etc.). These are critical factors that are considered to be real, true, or certain.
Typically these cover cost, scheduling, staffing and quality - Example: Project must be completed by June 27, 2014 which is the beginning of Fall 2014 registration because the work will impact the Banner registration process.
Identifies the risks involved to successfully complete the project. The probability of occurrence and expected severity of impact are also noted.
These are a more detailed version of the project scope. It is what will be accomplished in this project. Objective statements clarify the boundaries of the project scope and define boundaries of the scope of the project. Every object must be accomplished in order to reach the goal and accomplish the purpose of this project.
This is the measurable business value resulting from doing this project and address quantitative and tangible business benefits in terms of what will be improved, what problems will be reduced or what benefit will this be to the University.
The completed Project Charter is approved by both the project sponsor and ITS management. In certain cases, the plan may be forwarded governing bodies for the decision.
Once the appropriate approvals of the Project Charter have been obtained, the project proceeds to the Planning step. At this point, the Enterprise Systems management team will appoint a Project Manager who will be responsible for creating the project plan and guide the project through to its completion.
A preliminary specification should be developed from the in-scope areas of the Project Charter. The project manger will use this specification to identify the anticipated resources and the general areas for which task assignments must be made.
The project manger creates the project plan in Microsoft Project; identifying the tasks, establishing the project timeline and assigning resources to the tasks within the project. In larger projects, the manager may also identify Technical Leads to direct and monitor work by the project team members.
A communication plan is develop detailing how the members of the project team will communicate and share information. Depending on the project's scope, this might include use of communication tools such as SharePoint, establishment of regular meeting schedules, requirements for status reporting and so forth.
Upon completion of the plan, another risk assessment is performed with a focus on resource contention, particularly within ITS.
The project plan is submitted to Enterprise Systems management for approval. In certain cases, the plan may be forwarded to ITS management or governing bodies for the decision.
In the Requirements step, the complete set of detailed requirements of the solution is developed. The deliverable from the Requirements stage is the Functional Specification.
The functional specification should be thorough and describe the details of all components of the proposed system. It should be written in precise, clear and unambiguous language which is understandable to both the functional stakeholders and technical members of the project team.
The analyst(s) assigned to develop the specification must review and be completely familiar with the Project Charter. The analyst will conduct additional interviews with the project sponsor, user representatives and stakeholders as needed.
Often, a Business Process Analysis (BPA) is conducted. The BPA is a means of analyzing current and future business processes and documenting the activities, offices and documents which are part of the process.
At a minimum, the BPA should contain the following:
The Functional Specification should be organized by component (module, screen, report, etc.) describing in detail each component's functions and processing flow. This description should not only include the special processes occurring within the module in question, but also their interactions with other processes, both inside and outside the system.
The specification must include:
Upon completion of the Functional Specification, the project sponsor, appropriate stakeholders, and members of the project team are given the opportunity for review. Based on feedback from the review, the specifications are altered until all parties agree the specification is complete and correct.
The completed Functional Specification must be approved by the project sponsor and Enterprise Systems management. In certain cases, the plan may be forwarded to ITS management or governing bodies for the decision.
Once the appropriate approvals of the Functional Specification have been obtained, the project proceeds to the Design step. The project manager reviews the specification and adjusts, if necessary, the assignments and timelines for the next stages of the project.
The deliverable from the Design stage is the Technical Specification.
The analyst(s) assigned to this area will create the Technical Specification from the requirements contained in the Functional Specification. Thus, they must account for all requirements contain therein.
The Technical Specification encompasses both data and process design specifications. This involves decomposing the system into its components or modules, describing in detail the logic and processing in each component, including all edit and validation criteria.
Some special standards have been developed for systems employing Oracle or SQL/DS relational database designs.
The Technical Specification must include:
Upon completion of the Technical Specification, members of the project team are given the opportunity for review. Based on feedback from the review, the specification is altered until specification is complete and correct.
The completed Technical Specification must be approved by the Enterprise Systems management.
Upon approval of the Technical Specification, the project proceeds to the Development step. In this step, the developer produces the actual low-level code that will build the system.
The standard programming languages for online and batch systems at CFRDC are PL/SQL and SQL*Plus, respectively. The standard programming language for both online and batch systems in the local environment are .NET C# and Java. The developer must adhere to the applicable standards for the language being used. Refer to the appropriate platform-specific standards manual(s) more details.
The developer must review and become familiar the information contained in the Technical Specification. The developer creates a coding plan (pseudo code, outline, flow chart or whatever method suites the developer). The plan should follow the Technical Specification.
The developer should have the code-plan reviewed by the Technical Lead (if one was appointed) or immediate supervisor. Upon approval, the developer will create the tables, indexes and other objects specified in the specification and then proceed to create the program modules in the appropriate development environment.
Although life-cycle classification scheme treats testing as a separate stage than development, testing is an inextricable extension of development and thus testing should be an on-going part of the programming stage. The developer is initially responsible for testing, at least until after the possibility of abnormal terminations has been eliminated, all error conditions have been tested satisfactorily and all action keys or buttons operate as labeled.
Upon completion of the coding, a code review will be conducted by project team members as assigned by the project manager. Feedback should be incorporated into the code. Once the final review is complete, the team issues an approval to proceed.
Testing is conducted primarily to determine if the programs actually meet the functional requirements and perform without error. Two levels of testing are performed: unit testing and integration testing.
Unit testing involves testing the individual components of the system. Thus these tests can be conducted as each component has been completed. Integration testing is done with all components complete and the system installed in a production-like environment.
The project manager will assign analyst(s) to develop test plans for unit and integration testing. The manager will also assign individuals to conduct the initial tests as outlined in the test plans.
ITS also typically requires end-user testing as part of the Project Charter. This testing is done in a pre-production environment. The Project Charter will indicate if the project sponsor requires ITS assistance in developing a test plan or staging data for end-user testing.
The Project Checklist requires the sponsor to certify that system-wide testing has been performed and that the results are satisfactory.
Testing should conform to the following guidelines:
Two types of documentation are required as part of any project: internal and external.
Internal documentation includes the following. Refer to the programming standards for the appropriate program platform for documentation standards.
External documentation includes:
Comprehensive User Manuals are typically prepared by user representatives designated by the project sponsor. This ensures the documentation will incorporate not only the mechanical use of the new system, but also how use of the system relates to other business processes within the operational units. The Project Charter will indicate the extent to which ITS will be involved in preparing this type of document for a given project.
Implementation is the process of placing an application into production. The standards and procedures involved in placing a system into production vary depending on the environment in which the application executes.
Comprehensive training for the ultimate end-users of a system is typically prepared and executed by user representatives. This ensures the training will be tailored to use of the new system within the context of the business processes in the operational units.
In most cases, ITS will provide initial training to a few individuals (selected by the project sponsor) using a “train the trainer” model. These individuals will then develop a more comprehensive training plan for the end-user community.
The Project Charter will indicated the level and type of training the Sponsor expects ITS to provide. As part of the Project Checklist, the project sponsor must certify the training received was satisfactory.
To ensure that the system is performing to the satisfaction of the user community, a Post-Implementation Evaluation is conducted approximately two to three months after the system has been implemented. This evaluation should take the form of a meeting (or meetings) between the project sponsor, the project team and other personnel as needed.
The main purpose of these meetings is to evaluate the system, as implemented, according to the functional requirements and to identify any problems or errors the user has experienced in that regard. A secondary goal is to evaluate the execution of the project itself. Feedback from this examination is used to improve the application development process.
Any new requirements (extensions, enhancements, improvements, etc.) for the system should follow the guidelines outlined in the Application Maintenance Process.
Copyright © 2016 University of North Florida1 UNF Drive | Jacksonville, FL 32224 | Phone: (904) 620-1000