The Application Development Process

Software Life-Cycle

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:

1. Planning and Requirements
2. Analysis and Design
3. Programming and Construction
4. Testing and Documentation
5. Implementation and Training
6. Maintenance

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:

1. Conception
2. Planning
3. Requirements (functional specification)
4. Design (technical specification)
5. Development
6. Testing
7. Documentation
8. Implementation
9. Training
10. Post-Implementation Evaluation

Application development should follow these stages, in the general order indicated, according to the guidelines outlined below.

Conception

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:

• Problem/Improvement Opportunity -A summary of the problem or opportunity the client proposes to address; written in terms of the problem or opportunity, not in terms of the solution.
• Request Description - A description of the proposed solution, in functional terms, that addresses the problem or opportunity listed above.
• Strategic Benefit - In terms of the University's mission
• Required - Indicates whether the project is required to sustain operations or reduce risk or cost.
• Current State - Identifies the current state of existing systems
• Stakeholders - Lists the client groups for which the project is being undertaken and will receive benefits.
• Timeline Flexibility - Indicates whether there is flexibility in the timeline.
• ITS Resource Time Estimate - Describes the anticipated ITS resources needed.
• Sponsor's Resource Time Estimate - Describes the anticipated sponsor and/or stakeholder resources needed
• Systems Reduction/Increase - Indicates the effect on the number of systems.
• Time Savings to Customer - Describes efficiencies the project adds to stakeholder productivity.
• Implementation Cost Range - Estimate of the cost to implement.
• Operational Cost - Identifies one time, recurring, and licensing costs.
• Resource Risks/Dependencies - Identifies project or existing systems that have a relationship/dependency to the project.

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:

Project Description

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.

Project Scope

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.

Methods/Approach

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.

Assumptions

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.

Constraints

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.

Risks

Identifies the risks involved to successfully complete the project. The probability of occurrence and expected severity of impact are also noted.

Deliverables (Objectives)

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.

Success Criteria

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.

Planning

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.

Requirements (Functional Specification)

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:

• Define the process boundaries that mark the entry and exit points of the process inputs and process outputs, respectively,
• Describe the process activities and their interrelationships (often using a process flow diagram).
• Determine the capacity of each step in the process.
• Identify bottlenecks (steps having the lowest capacity) and other limitations.

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:

• A complete list of existing systems with which the new system will interface and the nature of those interfaces (i.e., batch, online, or both).
• A classification and the characteristics of the user groups of each component of the system, with the security/access restrictions of those groups.
• Descriptions of all new data elements to be created in the system.
• Edit criteria for all data collected or processed in the system.
• Mock-ups or prototypes for all online components along with descriptions on how the component will be used and the data elements used.
• Description of online help requirements.
• Mock-ups or layouts and descriptions of for all reports and/or downloads including which data elements are being referenced..
• Data and/or process flow analysis (from the functional perspective).
• Time constraints and schedules for any automated processes.
• Notation of any probable or conceived enhancements that may be requested in the future.

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.

Design (Technical Specification)

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.

• To reduce data redundancy and maximize data integrity, relational tables should be normalized to the Third Normal Form (3NF) or higher. Use of Second Normal Form (2NF) or First Normal Form (1NF) tables is discouraged and must be justified from a performance standpoint; all such exceptions must be approved by the appropriate Database Administrator.
• Every relational table should have a unique primary index or key and data should be "clustered" (contiguously organized) by this index/key.
• Implementation of Referential Integrity constraints is strongly encouraged whenever feasible.
• All database designs must be reviewed by the appropriate Database Administrator.

The Technical Specification must include:

• System integration points (and impact).
• Identification of existing data sources.
• Table, index and file definitions with field/column definitions and attributes.
• Estimate of file/table size requirements, including growth rates.
• Names and descriptions of the program components to be created.
• Application security needs of each module.
• Error handing design for each component.

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.

Development

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

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:

• All Test files/tables should be a representative sample or cross section of the "real" data (i.e., once the system is moved into production).
• All error conditions should be tested for every module in the system and each common error condition must produce a standard message as outline in the programming standards for the platform.
• All action operations (insert, update, delete, etc.) should be tested for every module in the system.
• All edit and validation checks should be tested for every module in the system.
• All security and authorization checks should be tested for every module in the system. This may require the replication of security classes, user IDs and so forth from the production environment to the testing environment
• Where applicable, all transfers to other modules, both inside and outside the system, should be tested for every module in the system.
• Abnormal terminations are considered intolerable. To avoid data exceptions, the Analysts and developers should take great care in ensuring that data is initialized, edited, manipulated and converted according to proper standards. Likewise, runaway tasks, un-trapped error conditions and improperly terminated browses must be avoided at all times. Abnormal terminations can be avoided by strict adherence to the programming standards developed for the language in question.

Documentation

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.

• The documents compiled as part of the project implementation (Request Summary, Project Charter, Functional Specification, etc.).
• Notations in the actual software code referencing the application development request, programming dates and author.

External documentation includes:

• Job catalog entries for batch systems.
• Online help for interactive systems.
• Processing flow narratives
• Documentation for the Support Center

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

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.

Training

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.

Post-Implementation Evaluation

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.

Definitions

Key Stakeholders

• Business Analyst -Prepares the conception documentation which defines the goals and scope of the project.
• ITS Sponsor - Member of Enterprise Systems management team (typically the Director), assigns the Business Analyst and Project Manager, assists with major issues and policy conflicts, approves scope changes, signs of on major deliverables and provides approval to proceed to each succeeding project phase.
• Project Manager - Assigns ITS resources to tasks, processes change requests, plans schedule, monitors the project progress.
• Project Sponsor - Provides input to scope changes, provides resources/User Representatives for consultation/testing as necessary for the project.
• Requestor - Initiates the request for service, identifies the Project Sponsor.
• Team Members - Analysts, developers and other individuals assigned to complete project assignments.
• Technical Lead - Directs work effort and monitors work by team members.
• User Representative - Consultation for clarification about the project, testing system and training as necessary.

Documents

• Application Development Request - The initial request that begins the project.
• Request Summary - A summary document prepared by the business analyst which outlines the functions of the proposed system, including a potential benefits of the system.
• Project Charter - A document prepared by the business analyst which defines the goals, scope and deliverables of the project.
• Project Plan - A Microsoft Project document which contains the tasks, assignments and timeline for the project.
• Project Checklist - A document listing the major milestones of the project which captures the approvals (sign-offs) for each milestone.
• Functional Specification - The detailed functional design of the proposed system.
• Technical Specification - A detail technical description of the tables, files and programs to be created to support the functional design.
• Test Plan - A document outlining the test scenarios to be used to ensure the new system is functioning as designed.