It is important to choose the appropriate development lifecycle process for the proposed project because all other activities are derived from the development process. Our approach to the development process is governed by the client´s requirements, the proposed technology environment, business objectives etc. Our development processes include SDLC models that allow for collaborative development while keeping all quality objectives and goals in the forefront.

Gathering and agreeing on requirements is fundamental to a successful project. It is not possible to finalise all requirements before any architecture, design, and coding are done, but it is important for the development team to understand what needs to be built. Quality requirements are broken up into two kinds: functional and non-functional. One of the best practices used to document functional requirements is done using Use Cases. Non-functional requirements would aim to describe the performance and system characteristics of the application. It is important to gather them because they have a major impact on the application architecture, design, and performance.

Choosing the appropriate architecture for the proposed application is a key task to be accomplished. Often when a project in trouble is reviewed it is found that the development team did not apply well-known industry architecture best practices. A good way to avoid this type of problem by stringently following an established industry standard architecture framework. Our consultants work side by side with the client team and ensure that the projects are based on tried and tested practices and technology frameworks

Application Designs are based on our knowledge artefacts of software best practices and design patterns covering the full lifecycle of software projects. Each project is viewed differently and an important objective for all projects is to realise the return on investment (ROI). This knowledge is a well-managed and defined practice that is transferred to each project to save the overall project costs. Our Application Design Practise translates to:

• All methods used to define system architecture and software design being documented in the project management plan and being frequently and regularly evaluated through internal quality audits.
• The allocation of system architecture to hardware, software, or operational procedures is through predefined engineering processes and is tracked through traceability practises and frequent quality evaluations.
• All system architecture decisions being based on a predefined engineering process and studies conducted to evaluate alternatives.
• System and software architectures are developed and maintained consistent with standards, methodologies, and external interfaces specified in the system and software development plans.
• Systems engineering requirements studies include efforts to mitigate software risks.
• System requirements, including derived requirements, being documented and allocated to hardware components and software components. The requirements for each software component in the system architecture and derived requirements are allocated among all components and interfaces of the software component in the system architecture.

Code Construction is a fraction of the total project effort, but it is often the most visible. Other work equally important includes requirements, architecture, analysis, design, and testing. Best practice for constructing code includes the daily build and smoke test (wherever applicable) to minimise integration, quality risks and easier defect diagnosis

It is important to review other people's work. Experience has shown that problems are eliminated faster and earlier this way. Reviews have at times proven even more effective than testing. Any artefact from the development process is reviewed, including plans, requirements, architecture, design, code, and test cases. Our Peer review processes are helpful in trying to produce software quality at top speed.

To us testing is not an afterthought or cutback when the schedule gets tight. It is an integral part of software development that needs to be well-planned. It is important that testing is done proactively and in tune with the development methodology that is being followed.

Testing is usually the last resort to catch application defects. It is labour intensive and usually only catches coding defects. Architecture and design defects may be missed. One of the methods used by us to determine architectural defects is to simulate load testing on the application before it is deployed and to deal with performance issues before they become problems.

Our robust configuration management processes are introduced at the Project Initiation stage and are carried throughout the development lifecycle. All projects have a dedicated Configuration Librarian to take care of configuration management needs. Configuration Management involves:

• Identification of CI(s)
• Baseline Criteria, Revision Criteria and Library Definition
• Change Control Practices
• Change Request Management Practices
• Status Accounting
• Defining Check-in, Check-out policies

It is important to establish quality priorities and release criteria for the project so that a plan is constructed to help the team achieve quality software. As the project is coded and tested, the defect arrival and fix rate can help measure the maturity of the code. It is important that a defect tracking system is used that is linked to the source control management system.

Deployment or the final stage of releasing an application for users is yet another important phase in a project life-cycle. The purpose of following industry standard best practices is to successfully deploy the application. Our plan for deployment essentially uses a deployment checklist.

In applications that are not entirely brand new but mixed consisting of partly new and part enhancements or rewrites of existing applications, Data Migration from the existing data sources is usually a major activity in itself. This is not a task typically assigned to junior programmers. It is as important as the new application. Usually the new application has better business rules and expects higher quality data. Improving the quality of data is a complex subject and is addressed with the best of skills and expertise.

Project management is key to a successful project implementation. Most of the other best practices mentioned above are related to project management. There are other checklists and tip sheets for project management which could be also applied. Our principal objective is to provide professional project management services to assist the client with building quality into the software throughout the system life cycle. We are committed to helping our clients successfully develop, maintain, and integrate complex systems in today's challenging, and sometimes overwhelming, system acquisition jungle. This means providing trusted and reliable support services that ensure our clients achieve their corporate IT strategies on time and on budget, while meeting specific operational system requirements. The bottom-line being "if you fail to plan, you plan to fail!"

Our Risk Management practices allows for continuous identification, reporting, analysis, prioritization, monitoring, and control of internal and external activities, conditions and/or events that can cause an undesirable project impact. Risk Management is an essential component of our best practices that supports sound business, project management and engineering processes. It allows the management to be proactive rather than reactive and enables open and honest communication among all stakeholders, both internal and external to an organization. Risk Management is a continuous process that involves all members of the team to become integral part of daily business and engineering activities.