Our system design standards are in place to ensure the highest degree of customer satisfaction possible. Unlike some consultants, we prefer to include client participation in the design process so that our systems support their long-term business strategies. We have other standards in place so as to ensure system scalability and supportability. A high-level list of these standards are as follows:

• Business Case/Analysis
• Customer Approval/Participation
• Design Documentation Standards
  o Use Case/Functional Diagrams,
  o Context Diagrams
  o Data Flow Diagrams,
• Design Technical Reviews, which ensures that the system can be developed as designed within the project constraints
• Multi tiered systems for scalability
• Non-proprietary/Open Systems for interface with external systems
• Remote accessible systems for maintenance and support. Preferably via TCP/IP or via direct modem access.

Coding Standards

We follow two levels of application development structure. One is in the processes framework that we follow to develop our code. These processes are in place to ensure that all code developed meets all customer requirements, meet all project timelines and budget constraints. These process standards are discussed in the RFP and in question #3 of this document.

The second level or our development standards is at the technical coding level. These standards ensure our coding effectiveness, supportability and a reduction in system defects. We the following discusses our coding level standards.

• Tools Standards
• Library utilization standards
• Naming standards
• Syntax validation tools
• Inline coding documentation standards
• Revision tracking standards
• Technical/Peer Reviews

First we select development tools and libraries that are considered to be stable and supportable in the industry. In the case of open source software we rely on third party modules where we have access to the source code such that we can test and resolve bugs without having to rely on others for support. We subscribe to several Open-source communities and users groups so that access to other developers in the community. This interaction within the community gives us an awareness of problems with any open source tools prior often resolving them prior to them affecting our client. Should such a bug show us in our client’s open source application we have access to a vast experience base, which allows us to reduce our research and resolution time for the software. We include other factors in our tools selection such as size of the system, time to market requirements, system performance and flexibility requirements. That way we use the tool set most suited to the client’s needs. Finally we keep in mind the customer’s request and their ability to transition support to their own IT department.

During our coding process we use structured names for all variables used so that they are easier to track within the code without having to resort to using a separate “data dictionary”. All designs and code pass through a peer review process by a senior technician to make sure that the code design is well thought out and technically sound even before any coding begins. Where tools are available, we run code checkers to ensure that all coding syntax is complete and accurate. These checkers reduce errors based on typographical errors within the code.

We have a standard requirement for all of our programming staff to provide documentation comments within the code at the time it is developed. This allows us to use several teams of programmers on the same piece of code simultaneously and ensures that the code is easily supportable. A part of this documentation process is to track and archive code by major milestones and/or release versions. This ensures that we are able to track changes that may have an effect on other internal or external systems. It also prevents us from accidentally working on and installing in a production environment an older version of our code.

During the peer review process the code is “walked through” by this senior technician to make sure that there are no errors such as infinite loops, permanent wait states, or “dead end branching”. This walk through also ensures that all functional requirements are met as created in the design documents prior to releasing the software.

Our three phase testing has the following elements:

Our three phase testing starts at the coding level by the developer(s) and their peers. This ensures that each function can be performed even before the entire system has been completed. In addition to the actual functional testing the developer walks through the code with his peer to validate that the code meets the design documents and any formally accepted change documents.

The second phase is performed by a separate QA team that reviews the system in its’ entirety for both functionality and esthetics from a user’s perspective. This testing is performed on a system that matches the production environment as close as is practical. Often this testing phase includes the system designer and the project manager. The testing document as agreed to by the client is used and signed off by the QA team and presented to the client upon completion. Additionally for software that will be installed on multiple systems, we perform an installation and documentation check to ensure that the code will be installed properly at the time of deployment.

The third phase is where the client reviews the code. The client uses the same testing document as earlier. This step ensures that any last minute corrections either functional or esthetic are resolved prior to deployment. This phase is a milestone for fixed price contracts, which is required to be met prior to DSi getting paid for the work performed. Once the testing has been approved the new system is put into the production environment.

These basic elements are:
a) Establish project plan and structure
b) Gather application requirements
c) Analyze the requirements
d) Design the system/application
e) Develop the application
f) Test the application
g) Deploy the application to the customer/production environment
h) Support the implemented system

We organize these elements into of the following three categories that allow us to meet our client’s business needs.

	Standard application development
	Modular application development
	Rapid application/prototyping development

Use: Fixed price contracts Hourly contracts Staffing contracts Benefits: Fully documented results Established fixed delivery Define roles and responsibilities Identified risks and contingency plan Established metrics and milestones Documented testing plan Established metrics and deliverables Managed schedule

Use: Fixed price contracts Hourly contracts Staffing contracts Benefits: Faster partial implementation Iterative documented results Flexible (modular) delivery Defined roles and responsibilities Establish metrics and milestones Documented testing plan(s) Spread out payments

Use: Hourly or monthly contracts Benefits: Faster development Increased customer involvement Flexible development Changes can be made earlier Try it before you buy it Lower development costs Spread-out payments Risks quickly identified and managed through “trial and error”

From a business side, we start by setting the expectations for all teams participating in the project. These expectations are documented and agreed to as early as possible in the project. The expectations are deliverables, milestones, participation, budgets, etc. We constantly monitor the progress of the project to ensure that the project stays on track. We identify any issues or problems notifying the effected parties so that they are resolved in a timely fashion.

We have the experience in small to large projects, we are proficient in technical matters, our experience show us how to test for problems prior to migrating to a production environment. Any anomalies are found, reported and often resolved early in the process before they become so large that they have an adverse affect on the project. Our analysis process identifies potential technical risks such as environmental/infrastructure issues, platform stability, systems integration and security risks, scalability and others.

We view our project plan as the most critical piece of what we do. We (DSi and our Immagration.com) will create it, approve it, monitor it and manage it. In a nutshell, we say what we do and we do what we say.