AnalysisPlus™ Development Analysis Services
The objectives of the development stage AnalysisPlus are to provide for the best possible technology in terms of:
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
So that:
- Clients are satisfied
- Clients remain competitive in the marketplace
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.
Project 0% complete |
Project 50% complete |
Project 90% complete |
Control
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.
Project Phases
All AnalysisPlus projects consist of six Phases and seven corresponding Gates. Generally, before the project is allowed to move through a project gate, the corresponding phase must be completed. The formal review process of completing the phase and its deliverables and having these items reviewed is known as a Gate Review. For example, prior to starting the Requirements phase, the Initiation Phase must be completed and the Initiation Gate Review must take place. Depending on the type of project, the design and construction gate is not as defined.
Project Initiation
An important part of AnalysisPlus implementation involves getting started on the right track. The first stage of any project is Project Initiation. A prerequisite to starting the project is creating the Project Initiation Report. The project initiation report documents the findings of the previous phases as they relate to implantation. The report demonstrates that Due Diligence has been performed prior to starting any project. The report documents:
|
|
Design
In the System and Software Design phase, the architecture of the system is completed and various technical design issues are resolved. This phase varies greatly depending on the type of project being developed.
Development
In the Code and Construction phase, the system is constructed. For most projects this is considered the coding phase. The system is built using information from the requirements and design phases. This phase also includes unit testing and integration testing.
System Test
The System testing phase involves testing the system to ensure that all the requirements specified during the Detailed Requirements phase are implemented properly. Testing also ensures the system's reliability, correctness, robustness, etc.
Deployment
The Deployment phase involves the actual production of the system.
Maintenance
Team Members
AnalysisPlus implementation uses eight primary roles to develop quality software projects. Table 12 shows the team members in alphabetical order.
| Name | Requirements |
|---|---|
| Account Manager | The Account Manager is responsible for overall client satisfaction across all projects. The AM's role is critical in the beginning of the project during negotiations. |
| Business Analyst | The Business Analyst is responsible for obtaining requirements, documenting, and analyzing the proposed system. |
| Documentation Specialist | The Documentation Specialist is responsible for ensuring that the clients'; productivity of the system is a high as possible. Specific responsibilities include user training, user documentation, and system help files. |
| Project Manager | The Project Manager is responsible for orchestrating all project responsibilities. The PM generally creates the project plan and maintains the project schedule. The PM is also the main liaison between CSI and the client and between CSI management and the project team. |
| Software Quality Manager | The Software Quality Manager plans and manages test activities. The SQM creates test plans and coordinates project testing. The SQM is responsible for finding ways to make the software break. |
| System Architect | The System Architect is responsible for the conceptual integrity of the system. |
| System Developer | The System Developer is responsible for the detailed implementation of the system. Developers are responsible for the quality of the system and making the system work. |
| System Tester | The System Tester is responsible for performing the tasks detailed in the test plan(s). |
| Other Specialists | Depending on the project, there may be other specialists required. Examples of specialist may include security specialists, product specialists, and other niche specialists. |
AnalysisPlus 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:
- Change Control Procedures
- Critical Requirements Analysis
- Estimates
- Budget Summary
- Exception Management
- Issues Management
- Managing Iterations
- Progress Control
- Project Organization
- Scheduling
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.
Quality Plan
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.
Project Phases and Deliverables
Not every project requires the same deliverables depending upon the project classification. A checkmark (√) indicates that the deliverable is always required prior to the completion of the corresponding gate. An 'M' indicates that the deliverable may be required depending the classification of the project. An 'X' indicates that the portions of the deliverable are completed and reviewed over two or more phases.
|
Analysis & Design |
Development |
Test |
Deployment |
Maintenance |
|---|---|---|---|---|---|
Acceptance Criteria |
|
√ |
|
|
|
Administrator's Guide |
|
|
√ |
|
|
Database Design (logical) |
M |
|
|
|
|
Database Design (physical) |
M |
|
|
|
|
Defect Tracker |
|
X |
X |
X |
|
Deployment Plan |
|
|
|
√ |
|
Disaster Recovery Plan |
|
|
|
√ |
|
External Interface |
X |
|
|
|
|
Maintenance Guide |
|
|
√ |
|
|
Project Initiation Report |
√ |
|
|
|
|
Project Plan |
√ |
|
|
|
|
Quality Plan |
√ |
|
|
|
|
Requirements Traceability Matrix |
|
|
|
|
|
Risk Tracker |
X |
X |
X |
X |
|
Security Procedures |
|
|
|
√ |
|
Staffing Plan |
√ |
|
|
|
|
System Analysis and Design |
√ |
|
|
|
|
Test Plan |
√ |
|
|
|
|
Training Requirements |
|
|
√ |
|
|
User's Guide |
|
|
√ |
|
|
