Process – Offshore Development Process

The onsite/offshore model has by far been the most successful one among the various models that have emerged. The simple reason being that unlike in the case of pure offshore model, you have the satisfaction of coordinating and discussing requirements and deliverables with an onsite team, while at the same time enjoying the offshore cost advantage.

Net Android’s Offshore Development Methodology

Methodology – Software Engineering Techniques and Tools: Based on our experience with remote software development, Net Android follows a project methodology, which embodies the following principles:

  • Early UI Delivery
  • Frequent Client Feedback
  • Live Project Monitoring
  • Parallel Quality Management
  • Clear Communication Schedule
  • Reasonable Flexibility
  • Environment/Usage Scenario Duplication

We always follow these programming principles:

  • Coding discipline document (including code conventions)
  • Configuration management
  • Regular code reviews and walk-through
  • Algorithm reviews

The systems developed by Net Android are based on one or more of the following core software engineering principles:

  • Rational Unified Process
  • Incremental Spiral Development
  • Microsoft Solutions Framework
  • System Development Life Cycle
  • Unified Modeling Language.

Initiation – How a project starts

A project is started with certain set of activities that set basic principles in place: the people involved, the work required, and the time available.

Step1: The Project Hand Over Meeting

Every project’s engineering activity starts with the Project Hand-over Meeting. This marks the beginning of the development process, and is attended by Marketing, the Project Lead and the Quality Lead. Business relationship and payment details would have been worked out before this meeting.

Step 2: The Project Invitation email

Subsequent to the meeting, the client is sent a Project Invitation e-mail listing the Project Lead, Quality Lead and Relationship Manager. The Project Lead is the primary contact point, and responsible for the over-all project. Clients may escalate issues to the Relationship Manager when they find the need.

Step 3: The Specifications Sign-off

Thereafter, the Project Lead performs Gap Analysis and Specs Clarification. Skills and expertise required are identified, and knowledge areas listed. The Project Lead draws the client to clarify and sign-off on at least 80% of requirements. Some areas may be left flexible on purpose.

Step 4: The Early Project Activities

  • Producing a UI Prototype
  • Architecture/Design Documents
  • Database Design
  • Sub-Systems identification
  • Team Building
  • Quality Planning
  • Stage Delivery Planning

The Stage Delivery Plan identifies Stages, Stage Sequencing, Stage Manpower planning and Stage Milestones. Client milestones are married into the Stage Plan, and the Stage Plan is sent to the client.

Each Stage is a maximum of 10 weeks, and will have its own Work Breakdown Structure. Milestones, responsibilities, task sequencing and parallel activities are evolved during Stage Delivery Planning.

Project Execution:

A Project gets executed in stages, according to the Stage Delivery Plan.
Each Stage starts with Detailed Design. The entire team decides on Class Structure/File List/ Data access etc. for that Stage. It also identifies specific SQA role and points of hand-over.
Programming starts on the lines of design, according to coding discipline decisions already taken. Regular code reviews and walk-thru will be conducted to ensure excellence in quality. Each Stage is required to have a minimum of 2 code reviews.

Programmers are required to unit-test their code. The team might decide to have an active SQA role (with parallel, live testing) or a post-development testing strategy (with intermittent releases). On principle, each Stage’s bugs are removed as soon as they are found. Defect removal and defect occurrence statistics are maintained and circulated among all team members.

The SQA Lead declares Stage Closure when Acceptance for that Stage has been reached.

The Stage closes with a Post-Closure Meeting: This meeting is meant to identify issues, deviations, and potential problems and study impact on subsequent stages. It also throws light on new aspects of the project, unraveled during project execution.

Control and Reporting Processes

In a remote development software project, project control is vital. Net Android processes achieve control at multiple levels: requirements, programming, schedule and quality.

  • a) Requirements Control:

    It would be pre-requisite for the clients to sign off on the Requirements prior to development. Net Android will initiate this process. It is possible that only 80% of the requirements are frozen prior-to-start.
    Net Android’s design will be flexible enough to suit new features throughout the project.

    Even where the client has provided a formal Specifications document, the Project Lead will expand on the document, seek clarifications from the client and have the specifications as clearly defined as possible. Programming will start ONLY after the client has signed off on this document.

  • b) Programming control:

    The programming team follows development styles and guidelines as required by the client. Where the client has not provided such, we will follow the Net Android development styles and guidelines

  • c) Schedule control:

    The client is to be sent regular status updates. Each Stage will be defined and dated, each task within a stage will have milestones set.

  • d) Quality control: Every Stage has to be signed off by the SQA before closure.

Project Closure:

Project closure is a critical point in the cycle, and defining end-point can be an exercise in itself.

Internal project closure is achieved when SQA signs off on the final integrated release. This is based on the client’s Acceptance Criteria as listed in Requirements, and also SQA’s internal criteria.

Client project closure might involve a little more. Hence, external (client) closure is considered as a separate step. No project is defined closed till the client signs off, and final implementation/deployment as required has been completed.

After final implementation, the process requires the team to do a post-implementation analysis. The Relationship Manager takes feedback from the client, making sure that final points have been cleared up. The team holds a meeting to discuss the good, bad and ugly as experienced in the project, and learns for the future.

This is where metrics gathered during the project are also analyzed, and the project is benchmarked against similar projects in the past