The development portion of AnalysisPlus exists to address a single goal: Produce and maintain the highest quality software systems less expensively than your competitors. The objectives of the development stage AnalysisPlus are to provide for the best possible technology in terms of quality, accuracy, and effectiveness.

Quality. A quality software system delivers business functionality as documented by user requirements, on an agreed upon schedule, within an agreed budget. A quality software system is designed, constructed, and documented to simplify maintenance efforts and reduce the total cost of ownership of the product.

Accuracy. An accurate software system uses accurate schedules and budgets.

Control. A project in control is a project where the team knows the current state of the project, the team follows predefined processes, the team knows what tasks needs to be done next, and the team knows what the current project risks are and how to address the risks.

Effectiveness. Continually improve the quality, accuracy, and control of projects. In such a way that:

• All development processes are defined
• All processes are managed
• The results of the processes are documented
• Visibility of project status is always available
• Excessive administrative overhead is avoided

Quality

Effective processes support effective project management. More effective management generates more involvement from all project members. With more involvement, issues are discovered earlier, mistakes are avoided, and risks are controlled.

Accuracy

Without defined processes, product estimates of time, costs, and quality, are generally optimistic. Many times, estimates are reverse engineered from desired completion dates. Other times, schedules and budgets have no basis other than perhaps a gut feeling from project members. With processes in place, AnalysisPlus is able to produce more accurate schedules and cost estimates for new projects. Once processes with tasks are established, it becomes easier to generate accurate schedules because the sums of the estimates of the smaller tasks are more accurate than guesses for the whole project. Analysis of software projects becomes much more precise as the project progresses over time. Initially, the estimates are thorough, but probably imprecise simply based on the wide variation of the estimates.

Over time, as costs are actually incurred, and as the true feasibility of the technology becomes known, estimates become more precise. AnalysisPlus allows for an iterative approach where actual cost values can be input and risk values be adjusted to allow for more precise estimates as the project progresses. For example, consider the probability of a project completing on budget (or on schedule) over the course project development. Prior to starting the project, in this hypothetical example there is about a 40% chance of the project meeting this objective, and even meeting this low 40% is highly variable. This low percentage is due to many factors mostly related to imprecise data and many project risks. After the project is 50% complete, many of the risks are known and have been dealt with and the variability is much lower. After the project is 90% complete, virtually all risks are known and have been addressed.

Effectiveness

Once accurate estimates are routine, one must ask: "I have processes defined, and my schedules are accurate, but do I have effective control over the processes?" With control, every project becomes more consistent in their results.

AnalysisPlus™ Development Analysis Services

Inish can provide a multitude of services to successfully implement your project.

Project Plan

The project plan contains critical project management information including such items as:

Other deliverables

Inish can also provide many other deliverables that help ensure quality product development.

Acceptance Criteria

The criteria used to evaluate whether a system is ready for use in the production/live environment.

Administrator’s Guide

The Administrators Guide describes administrative and operational procedures used to manage the application. The guide is organized into sections that describe batch and on-line services, back-up and recovery and system security.

Application Requirements and Design

The Application Requirements and Design deliverable specifies the requirements for the usability of the application according to the types of end user. It specifies the users’ tasks and specifies a model of the tasks and the flow of work between the tasks. It specifies a model of the data manipulated by the users. It specifies a model of the objects that the users work with and manipulate. It specifies a graphical user interface design.

Database Design

The Database Design deliverable specifies the User Object/Actions and packaging them into database transactions. It specifies the integration of the processing logic and the data design to ensure that each can effectively support the other. The design specifies the data model and capturing volumetric data to be used to make partitioning decisions.

Defect Tracker

The defect tracker is a system that tracks defects, modifications, future enhancements, and ideas.

Deployment Plan

The Deployment Plan is a complete plan for how the application will be deployed, supported, and managed.

Disaster Recovery Plan

The Disaster Recovery Plan describes the procedures required to properly deal with disasters.

External Interfaces

This deliverable documents the external interface requirements of the system. It provides a detailed view of the system in terms of Interface Descriptions, Interface Content Specifications, Data Security Requirements, Data Coverage, Data Selection Logic, Transfer Specifications, Transfer Propagation Logic, Propagation Specifications, error Conditions/Impact to Business, Recovery Handling, and Interface Instance Handling.

Maintenance Guide

The Maintenance Guide describes procedures to be used for the ongoing management of the application and the supporting hardware and systems software.

Organizational Assessment

Capital Equipment. What capital equipment is needed in order to implement and maintain the system? Every project has unique requirements of what capital equipment will be required throughout the life of the project. Capital equipment requirements may be obvious such as new computer systems, or they may be subtler such as the requirement for a new phone automation system that will be required for help desk support.

Software. What enterprise software systems are needed to support the proposed system? Common examples of software are back office systems like database management systems, HTML servers, security components, compliers, CASE tools, and support systems.

People. People are perhaps the greatest cost driver of the software system. What are the resources required to implement and maintain the system? The roles of the people involved may include manager, designers, developers, testers, quality assurance, testers, and technical writers. Does the organization have these roles in place?

Capabilities. How do the resources translate into effective capabilities? Does the organization have the skills and capabilities to effectively complete the project? Capabilities are rated and risks assigned to various areas.

Project Initiation Report

The Project Initiation Report summarizes the results of the Project Initiation stage of the project and provides details of the next Stage.

The Quality Plan contains the standards, procedures, and quality controls to be used by an organization, in addition to the quality assurance and defect prevention/process improvement activities that will be used to support the organization’s information technology development. Part of the Infrastructure Team’s responsibilities deal with defect prevention via quality control mechanisms.

Requirements Traceability Matrix

The Requirements Traceability Matrix (RTM) is a matrix of detailing the project requirements for the system.

Security Procedures

The security procedures outline the security steps required to build, operate and maintain the system including details required for network security, user security, and physical security.

Technical Architecture

This document is a living document, updated as changes to the technical architecture are made. It is maintained by the Architecture Team and requests for changes to the document may be to that team. Its purpose is to document the Organizational Technical Architecture and provide a reference source for application analysts.

Test Plan

The Test Plan deliverable is a detailed, comprehensive plan for testing the application. Major activities include developing a test plan that is synchronized with the build plan, installing the testing environment, and describing the test data.

Training Requirements

The Training Requirements deliverable describes the material needed to educate staff on the new system. This includes the procedures for interacting with the system and those required to administer and operate the system.

User’s Guide

The Users Guide identifies and defines the procedures associated with user interaction with the application and the procedures for the generation and use of output data.