| Our Software
Development Life Cycle
Our software development method includes soliciting end-user input,
identifying and managing risks, end-user testing and training, and
detailed deployment planning. Development and deployment of any
modern software solution also involves systems engineering. Whether
the issue is connectivity, performance, security or end-user deployment,
our systems engineers complement development and deployment of our
First Contact - The Proposal
On receiving the RFQ (Request For Quotation) from the Client, the
"Experts Team" at ITMust will prepare a detailed "Proposal
Document", with information such as development software and
hardware to be used, the optimal architecture, topology and methodology
to be followed, the life cycle of the system, the mandatory reports,
the interfacing of the proposed system with external applications,
etc. Most important, as our client, you will be kept aware of the
development process at every step.
Once the Proposal is accepted and the terms are signed-off, the
"Experts Team" will prepare the SRS (Software Requirements
Specification), the blueprint.
Software Requirements Specification (SRS)
The purpose of the Software Requirement Specifications (SRS) is
to define the scope of the system and list its key features.
The SRS also :
1. Aids in our understanding of a typical user of the System.
2. Helps the developers thoroughly understand your business and
its associated processes.
3. Aids our designers and developers to gather the complete metrics
to understand the Project Requirements and the business process.
4. Captures the user requirements, external systems with which
the system interacts, design constraints, security, performance
and maintainability features.
5. Captures information about "Product Functions" of
the System. All the How's, What's and When's are defined clearly.
6. Captures information about "User Problem Statements".
These are activities carried out by a manual system or the current
system and these are the statements which the proposed System should
7, Gives a detailed explanation of the business as it is done in
the "System Process" section.
Once the document is complete in all respects it is sent to the
client for approval.
If necessary, the SRS is revised to the clients satisfaction to
capture more information or to accommodate "Problem Statements"
not applicable to the system in place.
Once the SRS is approved and signed-off by the Client, the next
step will be to generate the System Architecture Document (SAD).
System Architecture Document (SAD)
The SAD will have the "System Overview" where we present
the System Architecture diagram of the proposed System. This architecture
is broken down into manageable blocks called Information Management,
Business Process Management and Business System, each block will
have a list of important modules.
The control flow between the different modules and blocks is presented
through this "System Overview" diagram, using which the
client can foresee the proposed System.
The SAD will address each Problem Statement listed in SRS, how
it is resolved. It also presents tentative screenshots for an understanding
of the user interface involved.
The "Process View" section of the SAD will describe the
different processes designed and defined to address the user Problem
Statements of the SRS.
The SAD also will capture details on scalability of the System
and considerations applicable for the proposed system.
The completed SAD is sent to the client for approval. Once approved
and signed-off, the next document to be worked is the Software Functional
Software Functional Specification (SFS)
The SFS will be a detailed technical document of how each "Process"
explained in SAD is developed. It will have information about the
inner workings of the System, public classes, public functions,
public variables, the attributes and parameters related to each
The SFS captures information of the Major classes, Features out
of scope, the system model, environmental requirements, the assumptions
to be taken into consideration and the standards that will be followed.
Now all the functions are detailed in SFS in different branches
like purpose of the function, user interface, the input, the output
and the processing to be taken care in that function. Details about
the system interfaces is also captured.
The SFS document has information of how the packaging of the system
is done, how different processes are accommodated in branches of
the package, the SFS document is generated for the complete application
at a glance or is branched into phases or releases.
As and when the SFS for each module is finished, Test Cases are
generated for the same viz., Unit test cases, Functional test cases,
Scenario test cases, etc.
Once the SFS document is completed, the time taken for each module
or section or block is calculated using " Functional Value
Software Testing Life Cycle (STLC)
After the coding phase is completed, the Module Team will test the
application with Unit test cases, and once the integration is complete,
the functional and scenario testing is conducted. The System, at
every stage, will go through a consistency testing, viz., UI consistency,
functionality consistency, etc. In this process of testing if any
bugs are reported, will be fixed and the complete Software Testing
Life Cycle is followed again.
Once all the bugs are fixed the system will go through, stress
test, load test and performance test, passing which the build is
released to the client for deployment.
Once the Deployment is completed, the System is stabilised at the
From the clients place there can be wide variety of requests to
the ITMust Development team, there can be bugs reported, change
requests or new features to be developed.
To efficiently follow up different requests of the clients, ITMust
has developed an application called Online Quality Management System
(OQMS) which is a distributed application using centralised data.
The On-site coordinator (OSC) will report the same with the OQMS
application, which will be escalated to the ITMust Development team,
the resource is identified and assigned the task.
On completion, the task is delivered to the testing team which
then goes though the STLC process and done to satisfaction. The
patch is delivered to the OSC team, where the patches are integrated,
tested and then uploaded into the Live Version.
Click to know more
about our Online Quality Management System (OQMS)