****JavaScript
based drop down DHTML menu generated by NavStudio. (OpenCube
Inc. - http://www.opencube.com)****
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
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.
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 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.
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.
