Home > Process and Methodology
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:

arrow_bullet  Detailed face to face discussion with the client at onsite.
arrow_bullet  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.
arrow_bullet  Timely communication through e-mail, Phone, Chat, Video conferencing etc.
arrow_bullet  Creation of design documents, prototypes followed by confirmation with the client.

Review method in each development process:

arrow_bullet  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.
arrow_bullet  Perform the source code review.
arrow_bullet  Mainly we adopt top-down testing. This will be carried out from high priority module to lower priority module.
arrow_bullet  Implementing third party testing.

Review Points:

arrow_bullet  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.
arrow_bullet  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?

arrow_bullet  Detailed design review

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

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

arrow_bullet  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:

arrow_bulletCalculation 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.
arrow_bulletFunction 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.