Requirement Gathering:

Clients inform BlueLine about their requirements in one of the following methods:

• Method 1: Give BlueLine written specifications in terms of UI and backend functionality.
  
• Method 2: Give BlueLine a sample program and tell BlueLine to modify it or replicate it.
  
• Method 3: Have BlueLine project managers visit clients and verbally explain client's requirements to BlueLine project managers.
  
• Method 4: Have client's project managers visit BlueLine and verbally explain requirements to BlueLine project managers.
  
• Method 5: A combination of more than one method listed above. These are explained in greater detail later in this section.
  

The important thing to remember is that requirement gathering is a difficult task no matter where. The procedures are similar to what they will be if the company who is developing the software is in another city than where you are. The problems encountered are similar, the only difference is an emotional barrier, which enforces a perception that reading an Email from a client or a telephone call with a client separated by a few miles is easier than with a client separated by a few thousand miles.

• Method 1: Clients who want BlueLine to work on something completely new and who know exactly what they want, give the specifications in writing to BlueLine. This document could be a general or a very specific document. If this is a detailed document, this becomes the Bible that is followed for the project. If this is a general document, BlueLine will create a specification document that is very detailed. This is discussed in greater detail later in this document. Clients that typically follow this method are other software companies who are getting software developed by BlueLine International.
  

• Method 2: Some clients have seen something or already have something which they want BlueLine to replicate with some changes. Clients that typically follow this method are end-users or software companies who wish to get their product generalized.
  

• Method 3: Some clients want the BlueLine project managers to visit them in their companies and spend time with their project managers. Together they evolve the requirements and create the specification document. Typically clients that are looking at a large project to be implemented at their client's site will follow this method. This is also the most expensive method for requirement gathering.
  

• Method 4: Some clients feel more comfortable sending their project managers to BlueLine. They explain the specifications to the BlueLine project managers. Typically clients who want to make sure that the project managers have understood the requirements clearly from day 1 adopt this path. There is an added benefit that developers and project managers get to see each other and realize that they are all part of the same team and not adversaries.
  

• Method 5: In most cases requirements are a combination of two or more methods described above. Requirement gathering may start using one method but may quickly change to another method. Typically all requirement gathering exercises end up following Method 1 as there are always certain items that trickle in even after the first or the second cut of requirements is delivered.

Specifications Document Approval

After the BlueLine project manager has gathered the specifications he produces a document that has the following sections:

• Existing Scenario - This describes how the process is being executed currently
• Proposed Scenario - This describes in short how the process will be executed with the proposed software
  
• Functional Specifications - This describes in detail the front end, the backend calculations, and the database layout
  
• Quantitative Specifications - This describes in detail all the limitations of the proposed system
  
• Schedule - This describes the overall schedule of the development including integration and testing. It also marks out, clearly, the deliverables to be made along the way. This document is reviewed and verified at BlueLine by members of the development team against the requirements listed by the client. After the review and verification, it is sent to the client for his approval.
  

High Level Design Approval

The project is broken down into major modules and the interfaces between the various modules (functional model) are worked out. The development language to be used for the project development and the databases to be used are identified. This information is written in a high-level design document that is again reviewed and verified by members of the development team at BlueLine. After this process, the high-level design document is sent to the client for his approval.

Module Level Design Approval

Each major module is broken down into smaller portions in terms of classes and the interaction between the classes (Object Model). Further, the directory structure for development and implementation is worked out. This information is written in a Module Level Design Document. This document is again reviewed and verified by members of the development team at BlueLine. If the client wants to look at this document, it is sent to them, otherwise the implementation is started at BlueLine. Typically clients who are very technical and want to be involved in a greater detail look at this document. The project schedule is kept using the Microsoft Project Manager. On a weekly basis, a project meeting is held and this schedule is updated. In addition to it, every other day programmer fills out a form detailing the progress the programmer has made in the past two days. This information is sent to the client on a weekly basis.

Making deliverables:
There may be one or more deliverables for the project. The final deliverable consists of the executable, the source code and a project document that describes the design in detail. The deliverables are made via Email or Ftp'ed to a desired site. A feedback sheet is also sent along with the deliverable. Clients are requested to fill this out to help us identify how we can serve them better. BlueLine project managers work very closely with client to ensure a successful implementation.

Identifying & Resolving Issues:
Any person (at Client end or at BlueLine's end) can identify issues. All issues are entered in an issue database. Issues are entered as tasks into the Project Schedule. From this point on they are considered as tasks, which are completed according to the given schedule.

Creation:
The module level design is created, after the high level design is approved by the client and before the actual development of the project starts, by the Project Leader. Module level design is usually influenced by the implementation language, but it is not the same as implementation. Module level design process has the following steps:

• Different modules in the project are identified.
  
• Under each module, required classes and objects are identified.
  
• The relationship among these classes/objects is identified.
  
• Each class is documented in a well-structured format that includes the name of class, it's attributes and operations (with input/output parameters).
• An entity relationship diagram for all the databases is drawn to show the logical relationship between databases/tables.

Review:
Module Level Design is reviewed by the Project Manager. The purpose of module level design review is to determine the acceptability of software design specifications.

Verification:
MLD is verified by the Project Manager. In the design review of a module, following points are checked against high level design specifications:

• The sub division of module to ensure that
  
• There is a proper hierarchy among different classes/objects
  
• Each class is logically a complete entity
  
• The physical layout of databases
  
• The interface of the module with other modules is checked and ensured that it is same as one which is defined in the high level design. The interface within the module is checked and ensured that the classes interaction is well defined.
  

Forming a team and informing Team Members:
Once the MLD is verified by the Project Manager, the team members are informed about various modules of the project, their sub division and other details of the project. At this stage, team members are made aware of the overall system for which they will do the development.

Identification Of Threads:
After verifying the module level design, Project Manager identifies the threads. Thread is basically a group of tasks, which logically belong together. It is possible that two or more threads may be run in parallel or thread(s) may have a dependency on other thread(s). If two or more threads can be performed in parallel they will have the same sequence number. The Project Manager fills out the threads so identified for the project in the 'Project Thread Definition Sheet'.

Identification And Assignment Of Tasks:
After the threads are identified, the Project Manager breaks the threads into several tasks. It is possible that two or more tasks within a thread may be run in parallel or tasks may have a dependency on other tasks. If two or more tasks can be performed in parallel, they have the same sequence number. These tasks are assigned to the various Engineers in the 'Start Of Project Meeting' and 'Subsequent Weekly Meetings' for the project by filling the 'Task Breakdown, Sequencing and Assignment Sheet' by the Project Manager.

Start Of Project Meeting:
This meeting is attended by the Project Team Members, Project Coordinator and the Client (if present). In this meeting,

1. Team members are informed about the overall design of the project and their suggestions are welcomed. It includes the following :
   
   
   • Overall hierarchy of the design.
     
   • Interface between parts of the module.
     
   • Global which are accessed in the module.
     
   • Physical layout of the common data structures & databases.
     
   • Initializations and control flow.
     
   • Any project specific philosophy, e.g. Japanese String Handling.
     
     
2. New threads identified are informed to the people present in the meeting.
3. New tasks identified are informed to the people present in the meeting.
   
4. Their opinions are taken on these and the appropriate sheets are updated on the spot.
   
5. Assignments of the tasks to the Team Members is done.
   
6. A reasonably detailed schedule in the form of design plan for the full project is prepared. Design plan specifies the planned dates (start and finish) for different activities and is updated with actual dates in subsequent weeks.
   
7. A detailed schedule for the coming week is planned.

The result of this meeting is the completely filled out 'Project Thread Definition Sheet' and 'Task breakdown, Sequencing and Assignment Sheet'. At the End of the meeting, these sheets are taken by the Project Assistant and a new 'Full Project Schedule Report' is generated.

Weekly Meetings:
For each project, on one day of the week, which is fixed for the weekly meeting, the project planning meeting is held with all the Project Team Members, the Project Coordinator and the Client (if present). In this meeting,

1. Last week's assigned task's progress is updated, in terms of percentage completion at the time of meeting
   
2. New threads, if any, are identified
   
3. New tasks, if any, are identified
   
4. Schedule for the coming week is planned
   
5. Issues raised are discussed and assigned

This information is filled out in the 'Project Thread Definition Sheet' and 'Task Breakdown, Sequencing and Assignment Sheet' and previous weeks 'Weekly Schedule Report'.

At the end of the meeting, these sheets are taken by the Project Assistant and a new 'Weekly Schedule Report' for the coming week is prepared.

Weekly Team Report:

Project Manager is responsible for preparing the 'Weekly Team Report' for his/her team after the weekly meeting.

This report specifies the last week's completed tasks or the tasks started by the team, list of the problems solution(s) which depend on the client, and the team's plan for the next week and the date of next deliverable.

This report is given to the client if he is present, otherwise it is sent through email to the client.

Weekly/Full Project Schedule Report:

The Project Assistant is responsible for preparing the 'Weekly Project Schedule Report'. This report is also called the 'Full Project Schedule Report', if it has the information about the full project.

'Project Schedule Report' gives the details of how the project will proceed in the coming week and is prepared every week after the meeting.

The Project Manager signs the 'Project Schedule Report'.

Before any person can commence work, their work plan must be entered in the 'Weekly Project Schedule Report'.

Coding And Unit Testing:

After assigning the tasks to the engineers, coding for the deliverable is done by the Project Manager and his team. After the code is written by the Engineer, unit testing of the code is done by the Project Leader. Unit testing is done to ensure that the development completed so far results in the required functionality and has acceptable high performance. The purpose of unit testing is to verify that the program unit carries out the functions defined in the specifications. Each engineer makes the changes in the existing code according to the result of the testing.

At the end of each day the Project Manager for the project fills out the "Individual Project Health Check Sheet". Project Manager should mark the "Individual Project Health Check Sheet" taking into consideration performance, maintainability of the project developed so far and the time involved.

Unit Level Code Walk Through:
Before giving the deliverable of the demo, code walk through for the deliverable is done by the Project Manager. While doing the code walk through, Project Manager ensures that the code is easily maintainable. The result of the code walk through is documented in the 'Project Level Code Walk Through' by the Project Manager and the necessary changes in the existing code are made by the team.

Project Level Code Walk Through:
As soon as the coding for a function is completed by the engineer, its code walk through is done by the Project Leader to ensure that the development is carried in the right direction and the software is easily maintainable. If there is any possibility of improvement, Project Leader informs the team member who has coded it by filling the 'Unit Level Code Walk Through Document' and the concerned engineer does the needful. All the changes made by the Engineer are reviewed by the Project Leader.

Integration Testing:
Integration testing is done on the integrated code of all the developers. It is done to check whether the project completed so far adheres to the specifications received from the client.

Testing of the executable is done by the Project Assistant according to a test plan duly prepared by the team members and the Project Assistant with the consent of the Project Manager and the Client (if present). This is the formal integration testing and is done according to a strict plan.

Integration Testing is also done by the development team after the development for a deliverable is over and everybody has integrated their code. This is more of an informal process, which is done with random inputs.

Testing by Project Manager:
After the incorporation of the result of code walk through, Project Manager tests the software more deeply. PM checks the deliverable against the specifications received from the client, clarifications received from the client regarding the specification, the High Level Design and any other issue. PM checks the deliverable more technically and also takes care about the side effects and ensures that the software performs optimally and meets the required functionality. After his/her satisfaction regarding the quality of the deliverable, deliverable is handed over to the certification group.

Testing By Certification Group:
Once the integration testing and Project Manager's testing is over, testing of the deliverable is done by the member of the certification group. Member of the certification group checks whether the deliverable that is to be given to the Client is:

• Properly compiling and linking or not.
• Verifies the deliverable against the 'BlueLine Specification Document' and 'Modification History Document' to check that the deliverable has all the required functionality or not, and
• Verifies the issues listed in the 'Issue List' that have the status as 'Completed by the Engineer' to ensure that it has been resolved by the engineer and has no side effects.

If any of the required functionality is not in the deliverable or if any issue is not complete though it has the status as 'Completed by the Engineer', the certification group informs the Project Manager and Project Leader and rejects the deliverable that is to be given to the Client. And again steps from 3.15 are repeated. If all the criteria are fulfilled, a pass certificate is issued which accompanies the deliverable.

Internal Demo:
Once the deliverable is certified by the certification group to be free from known bugs, internal demo is given to the client (if present) or to the Program Manager by the Project Manager. While giving the internal demo, feedback about the internal demo in the form of issues, filled in the 'Issues Raising Form' is received from the Client or from the Program Manager.

Intermediate Deliverable To The Client:
Intermediate deliverable is given to the client through a 'Delivery Letter'. This letter specifies the documents, which are to be given along with the deliverable, list of known issues with reason, which are not completed and are included in the deliverable.

Final Project Design Document:
After the project is completed, the final design document of the project is prepared by the Project Manager and his/her team. This design specifies the directory name, class names used, files used within a class, methods adopted and the variables used. With the final design of the project, final deliverable is given to the client.

Final Delivery to the Client:
After the completion of the project, it is finally delivered to the client along with a 'Delivery Letter'. As and when any issues are received relating to the project, they are incorporated and delivered to the client.