Process and Methodology

Our company implements the following model as offshore business flow. Though this is an ideal case, it can also be customized according to the customer needs. For example, responsibility of detail design process or basic design patterns can be fine-tuned according to the requirements. Generally, the basic design is done at onsite. The onsite and offshore ratio varies from project to project, the average is around 3 (ONSITE): 7 (OFFSHORE). Effective communication with the client is one of the most important factors for the success of the offshore projects. This would be aided by the presence of onsite co-ordinator, resulting in increase of efficiency and also timely actions.

Team Structure(In case of Japanese Customers):

Project managers and leaders have several years of onsite experience in Japan and are responsible for the complete Project Management including client management with Customer Interactions, Project Design, Team Management of non-bilingual engineers, with bilingual and non-bilingual engineers performing development and testing. This way they can manage large non-bilingual engineers thereby reducing the overall cost.

Team Structure (In case of non-Japanese Customers):

Project managers and leaders have several years of experience in Offshore Delivery Model and are responsible for the complete Project Management including client management with Customer Interactions, Project Design, and Team Management.

Specification Understanding:

Detailed face to face discussion with the client at onsite.

Client‘s visit to India and explanation of the specifications to the offshore team members Client side leader class visits and explanation to team members.

Timely communication through e-mail, Phone, Chat, Video conferencing etc.

Creation of design documents, prototypes followed by confirmation with the client.

Review method in each development process:

Mainly we review by walk-through format. That means, assuming the program flow by visualizing the specifications, thorough understanding of specification and finding bugs, loopholes etc.

Perform the source code review.

Mainly we adopt top-down testing. This will be carried out from high priority module to lower priority module.

Implementing third party testing.

Review Points:

Requirement definition review

Check if the customer requirements have been met completely.
Emphasizing WHY, WHAT, WHO, WHERE, and WHEN (5W).
Properly documented when doing changes.

Requirement definition review

Are the requirements appropriately transformed to functionalities?
HOW is theorized at this stage.
Confirm if all the possibilities are covered or not?
Are the functions performing appropriately?

Detailed design review

Will all the logic execute properly?
Are the program structures and function modulates segregated appropriately?
Is Exception Handling done?

Code review

Confirm the validity and readability of source code.
Is the code is according to the coding rules?
The code walk through is done.

Test plan review

Confirm the appropriate test procedure and test content.
Confirm the test case coverage, including exhaustive error handling.

About the Development model:

We adopt a flexible approach as far as the development model is concerned. It can be Waterfall, Spiral or Agile depending on various factors.

About the Estimation method:

Calculation method
Analyse the required work in the project (work breakdown structure (WBS) is used) and estimate according to that work process. Here, previous project experience is the key factor.

Function point method(FP Method)

About the Progress report:

Though it depends on the client expectation, reporting is done based on unit of program or a process.
Generally once in a week.
Reporting and discussions through tele-conference, video-conference etc.,

About the Quality policy:

Though Nichi-In has not obtained any quality certifications, we adopt the practical quality policy as follow.

Quality = 100% client satisfaction
To deliver a System without defects on time.
To understands the requirements from the customer viewpoint and implement the same.
To handle changes in specification etc. flexibly according to the customer needs.
To perform design reviews and code reviews regularly.
To ensure coding rules are followed completely according to the regulations.
To create in-depth test specification covering all possible test cases.
To maintain proper communication with the customer and maintain SDLC history for anytime reference.
To create sufficient documents at each development stage.

About warranty period, bug support and specification changes support policy:

Warranty period is 1 year from the date of delivery.
Generally, the client shall not be billed for implementation of 5% to 10% of changes in specification.
Bug support policy is as follows.

Severity of the bug	Bug content	Response time
Severity 1	Sever bug or important functionality operation failure that requires immediate action.	24-48 hrs.
Severity 2	Significant failure due to defect in individual functionalities that requires immediate action.	24-72 hrs.
Severity 3	Minor defects in the individual functionalities that requires proper rectification.	48-96 hrs.
Severity 4	GUI based defects that will be rectified based on customer feedback.	72-120 hrs.

Home

Reach Us