OVERVIEW

Cambridge’s methodology is a judicial blend of Onsite and Offshore delivery model tightly integrated at various levels – Knowledge, Build Process, Design and Architecture as well as skill sets. Cambridge’s Development Methodology shall be is built on integrated steps with well defined value additions in each stage of build and iteration cycle with focus on continuous build & improvement and clear takeaways in line with end target for each iteration, release as well as overall project.

Cambridge proposes to continue to use the current integrated Build tools being used by its customers e.g. Maven and Anthem.

Build Development Process

• Use cases and functional process definitions to be started in parallel
• Start development as soon as use case is ready and not necessarily wait till all use cases are ready
• Business conception to be done by offshore team for use cases that are implemented there
• Focus on Better unit tests + their maintenance
• Offshore and Onsite teams to be well populated in terms of following:
• Build leaders to exist both – Onsite and Offshore
• Design and High end technology skills to be focused at least Onsite
• Complex integration activity to be completed onsite
• The integrated development team to have mixed roles among onsite and offshore instead of dedicated subjects committed at one place
• Low level roles (Development & testing) to have similar skills both – onsite and offshore
• Focus on continuous spread of knowledge through continuous interaction & sharing
• Focus on Architecture and design relay

Development Collaboration Management
Cambridge proposes to use a portal such as liferay - an open source portal that would help Cambridge team and its customer’s users organizations collaborate more efficiently by providing a consolidated view of applications. Liferay has an extensive list of features that compares with most commercial portals, but without the high license fees. Liferay features would be leveraged for the IMI Phase I project collaboration including personalization, user/group management, web mail, message boards and content management in an integrated manner for overall Project Collaboration Management.

Time-box / Sprint based Iteration Planning Process
Sprint - a Time-box-based fixed iteration shall ensure timely delivery discipline. This shall be the cornerstone of the development process and the content would be changed continuously, if required, to adhere to Sprint iterations. This will set in a development rhythm across the team and provide a strong unifying factor. The project would focus on identifying features / tasks, which could be broken to the least level of functional granularity. This will form the basis of linking tasks, features, Scrums / Iterations and releases. This will ensure easy progress follow-up as well as generate adequate documentation in the form of release notes on continuous basis.

Sharing of Functional and Build knowledge

• Knowledge to Travel in both directions
• Project Leads understand and do business conception as much as possible
• Open chat and high interaction frequency channels such as e-mail among Consultants
• Team to have designated coordinators for process and technology
• Functional tests to be developed alongside with use cases by having complementary teams among onsite and offshore, where possible

Relate various types of Build Projects in a clear manner

• Release / Applications / work packets: a set of modules packaged together to make an application.
• Scrums / Iterations : A set of related functionality leading towards an integrated module or set of features within modules
• Features : A set of system functionality at lowest level than can be further broken by tasks, if possible for which an independent user story or story cards can be written and converted into a technical piece of software by a pair of functional and technical consultants
• Technical Components : The projects shall also be related by technical progress in terms of containers - a set of applications that execute inside a container including container configuration files and container directory structure; Modules - set of libraries containing business logic and can depend on each other; and Nodes -: set of containers that will be deployed on a specific machine

Project Delivery Schedule
As part of lower task level build process using XP methodology, Cambridge team shall work closely with its customer’s team to define and prioritize the granular units of functionality (or requirements) and define them in form of User Stories / Story Cards. The story cards shall be defined in a uniform manner within an agreed and pre-defined framework to ensure consistency. Multiple story cards shall form an iteration unit which in normal circumstance shall be built into weekly intervals.

Cambridge shall adopt a team-based approach with tight integration among the homogenous set of teams who will be involved in building, testing and deploying story cards. This shall ensure focus on team goals and less on individual achievement. The delivery schedule comprising of Integrated Release and Build cycle is presented in a pictorial form.

return to top