Methodology & Delivery Process

HomeMethodology & Delivery Process

Our Methodology and Project Delivery Process

The following is an example of a typical Application / Software Development project delivery process at Thejes identifying the major project phases, milestones and associated deliverables and work products. The actual application development and project delivery process and related work products will be customized based on specifics of the Client project requirements.

    • “High Level” Business Requirements reviewed with Client
    • Submit Project Proposal (and review with Client as required)
    • Client Sign-off on Project Proposal and Initial SOW Contract

 

During the Concept phase (also known as Feasibility or Discovery) “high level” business requirements are documented and reviewed with the Client. Generally the Client will document the “high level” business requirements with assistance from Thejes consultants as required. Depending on the project, sometimes the “detailed” requirements analysis is also completed during this initial project phase.

Based on the requirements we will develop and distribute a Project Proposal to the customer in response to the RFP request. The Project Proposal includes a Rough Order of Magnitude (ROM) Estimate Range for the project (“Straw Man” estimates) including an initial forecast of the probable project delivery timelines. The Client review and sign of on the Project Proposal and/or Initial Statement of Work (SOW) generally signifies the close of this phase.

    • “Detailed” Business Requirements.
      • “Detailed” Business Requirements completed & reviewed with Client
      • “Detailed” Business Requirements – Client Sign-off
    • External (High Level) Design
      • Complete and distribute External Design to Client
      • External (High Level) Design – Client Sign-off
    • SQA Test Planning
      • Software Quality Assurance (SQA) Test Strategy & Planning
      • Review Test Plans with Client (and obtain Sign-off)

 

    • Conduct Project Risk Assessment
    • Revised Project Estimates based on Design & SQA Test Planning
    • Detailed Project Plan / Schedule
    • Obtain Client Approval on Final Estimates & Schedule (Modify and Sign-off Final SOW)

The Planning phase starts with “Detailed” Business Requirements Analysis with our Business Analysts working closely with Client Subject Matter Experts (SME) and stakeholders. The finalized “Detailed” Business Requirements Document including the prioritized in-scope requirements are reviewed with the Client and then formally approved. Sometimes a more accurate (interim) project estimate will be prepared after completion of detailed requirements, which is sometimes referred to as a “Tin Man” estimate.

During the final stages of the “detailed” business requirements analysis the Application Architecture and External (high level) Design activities will commence. An Application Risk Assessment (technical review) is completed at the end of the Design activities. The planning phase will also include formulating the project Testing Strategy and development of Test Plans for Software Quality Assurance (SQA).

We will also complete a formal overall Project Risk Assessment in conjunction with the Client stakeholders, and develop appropriate Mitigation strategies and Contingency Plans for the identified Risks. Upon completion of the external design and test plans we will revisit the project estimates to provide a Firm Quote (“Iron Man” estimate) generally at about 90% confidence level. Based on these more accurate and firm estimates we will develop a detailed Project Plan and Schedule with firm dates for key project milestones and deliverables. The Client approval of the firm estimates, committed project schedule and the Final SOW signifies the end of the planning phase.

    • Internal (Detailed) Design
    • Construction & Unit Testing
    • Code Integration & Testing
    • Develop Test Cases, Test Data & Test Environment Set-up

 

It is during the Development phase (also sometimes referred to as Construction) that the actual coding and development of the business application will take place. The development phase generally starts with Internal Design (a more detailed design) based on the pervious External Design Document (EDD). Then we will proceed to Coding / Programming the application according to the technical design specifications.

Unit Testing is carried out as each individual coding component or unit of source code is completed to ensure it is working according to design specification. In procedural programming a unit may be an individual program, function, procedure, web page, menu etc, while in object-oriented programming, the smallest unit is always a Class; which may be a base/super class, abstract class or derived/child class.

Once all the required individual coding modules are completed, Code Integration activities will tale place, including some quick testing to ensure the code integration is working fine. Close to the completion of all coding activities, Code Review will take place (by peer developers, or facilitated by a technical lead) to ensure that the developed code adheres to required coding standards and best practices.

This phase will also see development of Test Scenarios and detailed Test Cases based on the Test Plan. Required Test Data will also be created, and the Test Environments will be setup in preparation to commence formal Software Quality Assurance (SQA) Testing activities. The close of this phase is signified by the completion of all development activities, and the application is ready to be passed on to the SQA team to commence testing.

    • System Integration Testing
    • Functional Testing (and Regression / End to End Testing)
    • Performance Testing & Stress/Load Testing (if required)
    • Final Regression Testing
    • User Acceptance Testing (by Client)
    • Test Report Sign-off by Client
    • Deployment (Implementation) Planning
    • System Documentation, User Manuals and Training Materials

 

The Qualify phase generally begins with a Systems Integration Testing normally carried out by the development team to ensure all the API interfaces between interfacing applications in scope for the project are working fine. The SQA team then commences Functional Testing on the application, and as defects are discovered they are sent to the development team for fixing. The fixes will be re-tested by the SQA team to ensure the defects are addressed, and in addition Regression Testing is performed to ensure that previously working functionality has not been broken by the fixes.

As required the development team will perform Performance Testing to determine how fast some aspect of a system performs under a particular workload. This testing can also serve to validate and verify other quality attributes of the system, such as scalability and reliability.

Stress / Load Testing will also be carried out by the development team to determine the stability of the system. Stress Testing involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Load Testing generally refers to the practice of modeling the expected usage of a software application by simulating multiple users accessing the application services concurrently. As such, this testing is most relevant for multi-user applications, often one built using a Client/Server or Three-tier/Multi-tier Architecture model, such as the Web, Application and Database Servers the and a Web Browser and end user Computer for the Client.

Deployment (or Implementation) Planning will also take place during this phase, including creation of any required System Documentation, User Manuals and Training Materials. Once the SQA team is satisfied with their testing and all major defects are fixed, the application may be also tested by the Client which is referred to as User Acceptance Testing (UAT). The conclusion of the Qualify phase is signified by the Test Report sign-off by the Client, and authorization to promote the new application to production environment.

    • Implementation to Production
      • Staging Server Implementation
      • Production Server Implementation
      • Production Verification
    • Warranty Support
    • Client Rollout Schedule
      • Pilot Testing
      • General Availability / Rollout Schedule
    • Lessons Learned
    • Client Satisfaction Survey
    • Project Close-out

 

The Deployment phase commences when the application has been fully tested and all major defects have been fixed and resolved to the Client satisfaction. For larger and more complex applications using a Three-tier/Multi-tier Architecture model, to be deployed in a Server Farm type hardware infrastructure, we will first deploy the new application to a Staging Server.

Website development usually involves Staging and Production servers. The staging site is used to assemble, test and review new versions of a website before it goes into production. Normally before updating a new version of application code to the production server it is updated to staging server for testing. The staging server will resemble the production environment, where the SQA team and end users can do the user acceptance testing activities.

Once the application have been satisfactorily tested and verified on the Staging Server environment the new application code will be deployed to the Production Server environment. Deployment to the production server generally takes place during regularly scheduled system maintenance windows (like weekends and after business hours) to minimize interruption to end users and risks to impacted applications. Production Verification activities are performed by the SQA team and select Client end users (immediately after deployment to production) to ensure the new application is working as designed. This is generally a quick testing and verification of critical application functionality in production environment. Now the new application has “Gone Live” and is available to end users to access for normal operations and processing.

Sometimes to minimize the risk to business in deploying a complex new application, it will first be deployed to a Pilot Group of end users to iron-out and fine-tune any business process issues. The application may then be deployed in stages to the remaining end user community. A key activity prior to deploying a new application to end users will be to provide them with adequate training on any new business processes and procedures for accessing and using the application.

Following the successful deployment of an application to production it will generally be under a Warranty Period during which the development team will be readily available for support to fix any major production issues or defects immediately.

The project is then formally closed-off with the completion of the following remaining activities:

    • Lessons Learned meeting with all project stakeholders (sometimes called Post Implementation Audit Review) to identify and discuss what we did well during the project, including any opportunities for improvement. The results of this meeting will be documented and published as a reference and learning for future project teams.
    • A Client Satisfaction Survey will be conducted to solicit formal written feedback from the Client on the Thejes delivery team’s performance.
    • Finally the Thejes Project Manager will complete the Project Close-out by obtaining formal acceptance / sign-off on the new application and project delivery from the Client Sponsor. In addition all key project documentation will be backed-up and stored for future use, and a CD of the relevant system and project documentation will be provided to the Client. Payments for the final project invoice (and any other outstanding project contract payments) will also be collected from the Client at this stage.
Concept (Feasibility / Discovery) Phase
    • “High Level” Business Requirements reviewed with Client
    • Submit Project Proposal (and review with Client as required)
    • Client Sign-off on Project Proposal and Initial SOW Contract

 

During the Concept phase (also known as Feasibility or Discovery) “high level” business requirements are documented and reviewed with the Client. Generally the Client will document the “high level” business requirements with assistance from Thejes consultants as required. Depending on the project, sometimes the “detailed” requirements analysis is also completed during this initial project phase.

Based on the requirements we will develop and distribute a Project Proposal to the customer in response to the RFP request. The Project Proposal includes a Rough Order of Magnitude (ROM) Estimate Range for the project (“Straw Man” estimates) including an initial forecast of the probable project delivery timelines. The Client review and sign of on the Project Proposal and/or Initial Statement of Work (SOW) generally signifies the close of this phase.

Planning Phase
    • “Detailed” Business Requirements.
      • “Detailed” Business Requirements completed & reviewed with Client
      • “Detailed” Business Requirements – Client Sign-off
    • External (High Level) Design
      • Complete and distribute External Design to Client
      • External (High Level) Design – Client Sign-off
    • SQA Test Planning
      • Software Quality Assurance (SQA) Test Strategy & Planning
      • Review Test Plans with Client (and obtain Sign-off)

 

    • Conduct Project Risk Assessment
    • Revised Project Estimates based on Design & SQA Test Planning
    • Detailed Project Plan / Schedule
    • Obtain Client Approval on Final Estimates & Schedule (Modify and Sign-off Final SOW)

The Planning phase starts with “Detailed” Business Requirements Analysis with our Business Analysts working closely with Client Subject Matter Experts (SME) and stakeholders. The finalized “Detailed” Business Requirements Document including the prioritized in-scope requirements are reviewed with the Client and then formally approved. Sometimes a more accurate (interim) project estimate will be prepared after completion of detailed requirements, which is sometimes referred to as a “Tin Man” estimate.

During the final stages of the “detailed” business requirements analysis the Application Architecture and External (high level) Design activities will commence. An Application Risk Assessment (technical review) is completed at the end of the Design activities. The planning phase will also include formulating the project Testing Strategy and development of Test Plans for Software Quality Assurance (SQA).

We will also complete a formal overall Project Risk Assessment in conjunction with the Client stakeholders, and develop appropriate Mitigation strategies and Contingency Plans for the identified Risks. Upon completion of the external design and test plans we will revisit the project estimates to provide a Firm Quote (“Iron Man” estimate) generally at about 90% confidence level. Based on these more accurate and firm estimates we will develop a detailed Project Plan and Schedule with firm dates for key project milestones and deliverables. The Client approval of the firm estimates, committed project schedule and the Final SOW signifies the end of the planning phase.

Development Phase
    • Internal (Detailed) Design
    • Construction & Unit Testing
    • Code Integration & Testing
    • Develop Test Cases, Test Data & Test Environment Set-up

 

It is during the Development phase (also sometimes referred to as Construction) that the actual coding and development of the business application will take place. The development phase generally starts with Internal Design (a more detailed design) based on the pervious External Design Document (EDD). Then we will proceed to Coding / Programming the application according to the technical design specifications.

Unit Testing is carried out as each individual coding component or unit of source code is completed to ensure it is working according to design specification. In procedural programming a unit may be an individual program, function, procedure, web page, menu etc, while in object-oriented programming, the smallest unit is always a Class; which may be a base/super class, abstract class or derived/child class.

Once all the required individual coding modules are completed, Code Integration activities will tale place, including some quick testing to ensure the code integration is working fine. Close to the completion of all coding activities, Code Review will take place (by peer developers, or facilitated by a technical lead) to ensure that the developed code adheres to required coding standards and best practices.

This phase will also see development of Test Scenarios and detailed Test Cases based on the Test Plan. Required Test Data will also be created, and the Test Environments will be setup in preparation to commence formal Software Quality Assurance (SQA) Testing activities. The close of this phase is signified by the completion of all development activities, and the application is ready to be passed on to the SQA team to commence testing.

Qualify Phase
    • System Integration Testing
    • Functional Testing (and Regression / End to End Testing)
    • Performance Testing & Stress/Load Testing (if required)
    • Final Regression Testing
    • User Acceptance Testing (by Client)
    • Test Report Sign-off by Client
    • Deployment (Implementation) Planning
    • System Documentation, User Manuals and Training Materials

 

The Qualify phase generally begins with a Systems Integration Testing normally carried out by the development team to ensure all the API interfaces between interfacing applications in scope for the project are working fine. The SQA team then commences Functional Testing on the application, and as defects are discovered they are sent to the development team for fixing. The fixes will be re-tested by the SQA team to ensure the defects are addressed, and in addition Regression Testing is performed to ensure that previously working functionality has not been broken by the fixes.

As required the development team will perform Performance Testing to determine how fast some aspect of a system performs under a particular workload. This testing can also serve to validate and verify other quality attributes of the system, such as scalability and reliability.

Stress / Load Testing will also be carried out by the development team to determine the stability of the system. Stress Testing involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Load Testing generally refers to the practice of modeling the expected usage of a software application by simulating multiple users accessing the application services concurrently. As such, this testing is most relevant for multi-user applications, often one built using a Client/Server or Three-tier/Multi-tier Architecture model, such as the Web, Application and Database Servers the and a Web Browser and end user Computer for the Client.

Deployment (or Implementation) Planning will also take place during this phase, including creation of any required System Documentation, User Manuals and Training Materials. Once the SQA team is satisfied with their testing and all major defects are fixed, the application may be also tested by the Client which is referred to as User Acceptance Testing (UAT). The conclusion of the Qualify phase is signified by the Test Report sign-off by the Client, and authorization to promote the new application to production environment.

Deployment (Implementation / Rollout) Phase
    • Implementation to Production
      • Staging Server Implementation
      • Production Server Implementation
      • Production Verification
    • Warranty Support
    • Client Rollout Schedule
      • Pilot Testing
      • General Availability / Rollout Schedule
    • Lessons Learned
    • Client Satisfaction Survey
    • Project Close-out

 

The Deployment phase commences when the application has been fully tested and all major defects have been fixed and resolved to the Client satisfaction. For larger and more complex applications using a Three-tier/Multi-tier Architecture model, to be deployed in a Server Farm type hardware infrastructure, we will first deploy the new application to a Staging Server.

Website development usually involves Staging and Production servers. The staging site is used to assemble, test and review new versions of a website before it goes into production. Normally before updating a new version of application code to the production server it is updated to staging server for testing. The staging server will resemble the production environment, where the SQA team and end users can do the user acceptance testing activities.

Once the application have been satisfactorily tested and verified on the Staging Server environment the new application code will be deployed to the Production Server environment. Deployment to the production server generally takes place during regularly scheduled system maintenance windows (like weekends and after business hours) to minimize interruption to end users and risks to impacted applications. Production Verification activities are performed by the SQA team and select Client end users (immediately after deployment to production) to ensure the new application is working as designed. This is generally a quick testing and verification of critical application functionality in production environment. Now the new application has “Gone Live” and is available to end users to access for normal operations and processing.

Sometimes to minimize the risk to business in deploying a complex new application, it will first be deployed to a Pilot Group of end users to iron-out and fine-tune any business process issues. The application may then be deployed in stages to the remaining end user community. A key activity prior to deploying a new application to end users will be to provide them with adequate training on any new business processes and procedures for accessing and using the application.

Following the successful deployment of an application to production it will generally be under a Warranty Period during which the development team will be readily available for support to fix any major production issues or defects immediately.

The project is then formally closed-off with the completion of the following remaining activities:

    • Lessons Learned meeting with all project stakeholders (sometimes called Post Implementation Audit Review) to identify and discuss what we did well during the project, including any opportunities for improvement. The results of this meeting will be documented and published as a reference and learning for future project teams.
    • A Client Satisfaction Survey will be conducted to solicit formal written feedback from the Client on the Thejes delivery team’s performance.
    • Finally the Thejes Project Manager will complete the Project Close-out by obtaining formal acceptance / sign-off on the new application and project delivery from the Client Sponsor. In addition all key project documentation will be backed-up and stored for future use, and a CD of the relevant system and project documentation will be provided to the Client. Payments for the final project invoice (and any other outstanding project contract payments) will also be collected from the Client at this stage.