****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.
