1. Fact Finding.
Meet with appropriate client personnel to determine goals, objectives, and criteria for project success/failure, high level requirements, project scope, cost/time constraints, identity of client domain experts and stakeholders for the project. Meet with all domain experts and stakeholders in topic-focused meetings to fully characterize all of the issues within the project scope.

2. Needs Analysis.
Review meeting notes, analyze all of the needs within each subject area of the project. Special attention is given to identifying possible conflicts and risks. Follow-on meetings or conference calls with the stakeholders may be required to elaborate or further articulate properties in this phase. Risks and conflicts are discussed with stakeholders and mitigation strategies are defined.

3. Requirements Specification.
All of the project system requirements are defined, described, and assigned a priority, risk, and status. This is document is provided to the client and discussed at length. Requirements are modified, added, priorities are changed to meet the specific needs of the client. Requirements are reviewed to ensure full audit of the System Design. Client confirms before advancing to Design.

4. System Design/Definition.
The System Design (Definition) is constructed in UML. The design is comprised of all of the artifacts, which define the structure, and behavior of the system. This involves the data architecture (Class Diagrams), the Use Cases, Activity and State Chart Diagrams, user dialogs, configurations, and other artifacts. The Design is audited against the Requirements and elaborated with the Client.

5. System Development.
The actual code and system components are built and configured under direction of the design and requirements. "Builds" which include specific components (use cases) from the design are tied to schedules to ensure that the project is kept on schedule and within budget.

6. Testing & Validation.
The resulting system is tested in a component and phased approach centered on "Build" definitions. A Control Document is used to track exceptions and change requests throughout this phase. Progress is visible to all stakeholders through this document.

7. QA Tests.
After the system is validated with all "Release 1" exceptions and change requests solved and tested, the system moves to its final Quality Assurance Tests. Actual workplace data and processes are used by client stakeholders on a test system to simulate the actual use environment. Exceptions and change requests are logged to the control document and resolved. This phase is completed with all entries in the Control Document resolved and confirmed by the Client.

8. System Delivery & Training.
All elements of the System are delivered on official release CDs (multiple copies). Training is performed per the needs of the clients’ user and administrative community. Training may involve the users or a "train the trainers" for large user groups.

9. Ongoing Support.
Most systems are supported with some period of post delivery support. Some have on-going support. First line is telephone support with various levels of hands on support. Today, much of the trouble-shooting and remedial support is performed via remote access.

10. Scheduled Enhancements.
We encourage the use of Scheduled Enhancements to add non-critical (yet valuable) features to the system. This allows faster time to deployment and provides a higher Return on Investment (ROI). It also allows the future features to be refined based on actual experience with the system.
* For a detailed definition of our software development process see our "Guidelines for Software Development" – available on our web site as a downloadable PDF.

Capabilities Summary

Our Process - A Summary

Our People - the Team

Whitepapers

Partners