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 software products.

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

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 Specifications (SFS).

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 of these.

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 Analysis" calculation.

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 clients place.

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)