Tuli e services_development_process

3

Click here to load reader

Transcript of Tuli e services_development_process

Page 1: Tuli e services_development_process

Tuli eServices Confidential

Development process Tuli eServices Inc. has evolved a process over the years to optimize globally distributed development projects. Offshoring is fraught with quality and cost issues if the engagement framework and attendant processes do not factor the challenges. We strive to align our process with our clients’ needs. Since we are an end-to-end developer, we are able to pitch in wherever the client needs. Be it design, development, testing or deployment. Project Management Tuli eServices Inc. follows Agile methodology. We deliver through monthly releases, for development timeline spanning a few months, that contain a QA tested set of pre-defined features. Our approach is to deliver a demonstrable feature and keep building on it. We can take the project from concept to release phases. Requirements Document Usually a concept or a detailed requirements document is sent by the client. The product manager and tech architect get involved from the very first day we receive the concept. The product manager analyses the concept, looks for references and comes up with a flow and questions. The tech architect checks the feasibility of the concept. These are then discussed with client and after few iterations the concept is nailed down. Based on this detail software requirements specifications (SRS) document is prepared which when approved becomes the baseline document for the team. The SRS becomes a living document that gets updated as we receive feedback and feature request from client. A new version of the requirement document is released to the development team only after the updates are signed off by the client. All feedbacks and feature requests are brain stormed with the client before releasing updated version of the requirement document. When the client provides a detailed requirement document then the product manager analyses and comes up with queries. The technical architect reviews the requirement document from feasibility aspect. Once the requirement document is signed off the development process begins. Development Methodology

Once the requirements are agreed upon, we list down features. On discussion with client we assign priority to each feature. The features are grouped for multiple releases. Based on this a release plan is prepared. Usually we define a monthly release, but based on clients requirements and necessity we may have more than one release in a month. The features planned for first release are further broken down into tasks and efforts are estimated for each. The list of identified features for a release is no longer changeable, but we welcome any changes in the other features left to be done. A formal change request document is prepared and shared with the client for the cost/effort impact approval. Graphics production Based on the wireframes contained in the requirement document, the team creates the assets list. The art team looks into the branding/style, references. Mockups are created for few screens giving couple of options. On approval by client, the production for other assets based on the development plan proceeds. The first task is to define the guideline for developers to integrate art assets. If the art work is provided by the client, the art team gives the assets in required format to the developers. They make sure the guidelines defined by client is understood and followed by the developers. Visual QA is continuously done as the art gets integrated.

Page 2: Tuli e services_development_process

Tuli eServices Confidential

Risk Management: Progress is visible in real time with the burn down chart. If there is a drop in velocity due to an unforeseen impediment, its impact on the overall project is assessed and communicated to the client, but the release is nonetheless done. Towards the end of first month we start listing down the features /tasks list for month 2. Any spill-over tasks from first month, feedback on the releases made is also added to the list. As a part of contingency planning we are ready to augment the team to catch up in case of any slippage. One of the ways we do is to assign shadow resource(s) equivalent to 25% of the team size to the project from beginning. Visibility: A spreadsheet for each month’s release(s) is maintained and shared with the client. It lists down the milestone, the tasks and sub-tasks to be executed during the release(s). Against each task the resource name is mentioned. The sheet is updated by the project manager on a daily basis and the development progress for each task is tracked. The sheet has the Est (efforts required to accomplish), Eta (remaining hours to finish the task) and Act (actual hours taken to accomplish the task.

Communication We define a communication plan - Details of the key personnel, escalation matrix, weekly status updates, weekly status calls (though the team is always available on phone, email and IM). If required a daily progress update call can be arranged. A meeting is always followed up with MOM listing down the Items discussed and Action items. The action items are assigned to the team members (client and us) and are tracked. The dependencies between the teams are highlighted if any. Version control / repository A version control repository (SVN) is maintained on our servers. Access to these servers will be provided to check out the latest files worked on. The team member checks in the code to SVN on a daily basis. The SVN does not permit to check-in the code unless it is peer reviewed. An automated email confirming the check ins is sent to the leads. Testing Test plan is defined to test the application developed against the requirements. Test scenarios followed by detail test cases are written. We use TestLink to manage the test scenarios and test cases. The QA team is engaged in the project from the kick off. QA is divided into visual and functionality testing. The visual QA is done by the art lead. In functional testing the testers check all the scenarios and validate the app rules. Bug Tracking Mantis is used to track the bugs and issues. Access is provided to client. Process steps Milestone 1

Pre-Production ● Software requirements specifications (SRS and Interaction mockup) ● Technical Design Document (TDD - flow, system design, technical approach) ● Budget, Schedule and Staffing assignments ● Checklist for Milestone 2 (iteration plan, schedule spreadsheet) ● Review/sign off cycle of 48 clock hours.

Page 3: Tuli e services_development_process

Tuli eServices Confidential

Milestone 2 ● Delivery as defined in Milestone 2 checklist ● Build Notes ● Updated SRS ● Updated TDD ● Updated Budget, Schedule and Staffing Assignments ● Review/sign off cycle of 48 clock hours for milestone 2 delivery. ● Checklist for Milestone 3

Milestone … Milestone Alpha100

● Usable product with placeholder graphics ● Functionality tested ● Review/sign off cycle of 48 clock hours

Milestone Alpha200 ● Implement client feedback ● Review/sign off cycle of 48 clock hours

Milestone Alpha... Milestone Beta

● Usable product with all graphics implemented. ● Fully tested with no major issues open. ● All client feedback implemented.

Milestone GM ● Product ready for release.