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 factor 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:
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 a large non-bilingual engineers thereby reducing the overall cost.
Specification Understanding:
- Detailed face to face discussion with the client at onsite.
- Client es 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.
-
Basic design 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:
Generally it is waterfall model.
When the specification is still not decided, when lot of specification changes occurs and when delivery period is short, we go for spiral model. Prototype model is used for big projects or the project that requires analyzing new technologies.
About the Estimation method:
-
Calculation method
Analyze 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 |
|
|
Top |
|
|
|
|
