Chapter 3

Process Planning
This chapter describes the Infosys development process and process tailoring.
A development process, even after tailoring, generally cannot handle
change requests. This chapter also describes the requirement change
management process used at Infosys.
3.1 THE INFOSYS DEVELOPMENT PROCESS
During project planning, a project manager must decide what process should
be used for engineering the software.
3.1.1 The Standard Process
The standard development process used at Infosys resembles the waterfall
model, although the traditional phases have been broken into smaller
phases, or stages, to allow parallel execution of some phases.
The phases in the process include requirements analysis, high-level design,
detailed design, build, unit testing, integration planning, integration,
system test planning, system testing, documentation, acceptance and
installation, and warranty support.
Figure 3.1. The Infosys development process
The formal description of this process specifies the entry and exit criteria, inputs
and outputs, participants, activities, and other information for each phase
(stage). The process descriptions are generally brief, specifying the list of
activities to be undertaken in that phase. This basic process is also used by
projects that do iterative development or prototyping or perform only some
stages of the life cycle. In these situations this standard process is adjusted to
suit the project.
3.1.2 Process Tailoring - A defined process must be tailored to suit the needs of the
current project. Tailoring is the process of adjusting a previously defined
process of an organization to obtain a process that is suitable for the particular
business or technical needs of a project. We can view tailoring as adding,
deleting, or modifying the activities of a process so that the resulting process is
better suited to achieving the project's goals. Uncontrolled tailoring effectively
implies creating a process from scratch. To allow effective reuse of previously
defined processes, tailoring guidelines are provided. These guidelines define
the conditions and the types of changes that should be made to a standard
process. In essence, they define a set of permitted deviations to the standard
process in the hope that the optimal process can be defined for a project.
Figure 3.2. Process tailoring

The standard development process does not specify how code review should be
performed. Tailoring guidelines can help a project manager by advising that the
activity Do code review be performed only for certain types of programs (such as
complex programs or external interfaces) and by suggesting the optimal form of
the review (group review or one-person review). The Infosys tailoring approach is
similar to the table-based approach proposed by Ginsberg and Quinn, 7in which the
project manager specifies the process element, the tailorable attribute, the options
for each attribute, and the reasons for selecting a particular option. A project
manager performs tailoring at two levels: summary and detailed.
• Summary-Level Tailoring
• In summary-level tailoring, depending on the project characteristics, the project
manager applies overall guidelines for tailoring the standard process. That is, it
provides some general rules regarding certain types of detailed activities. To
perform this step, the project manager first identifies certain characteristics of
the project. For development projects, the following characteristics are used for
tailoring:
• Experience and skill level of the team and the project manager
• Peak team size
• Clarity of the requirements
• Project duration
• Application criticality
The experience level of the team is considered high if a majority of team members
have more than two years of experience with the technology being deployed in
the project; otherwise, it is considered low. Application criticality is considered
high if the effect of the application on a customer's business or Infosys's
business is significant; otherwise, it is low. Duration of the project is considered
particularly short if the project must be delivered in less than three months.
Summary tailoring guidelines are provided for different values of these characteristics.
The summary guidelines are generally review-related, effort-related, schedule-related,
resources-related, or formality-related. Review-related guidelines typically specify
when reviews should be done and what type of review should take place. Similarly,
the effort-related guidelines suggest steps to be taken for the project that may affect
the effort. These general guidelines set the context for detailed process tailoring and
defining a suitable process for the project.
Detailed Tailoring
Detailed tailoring covers execution of activities, their review, and documentation needs.
Tailoring guidelines may specify an activity as optional, in which case the project
manager can decide whether or not to execute the activity. Similarly, preparation of
some documents may be optional, in which case the project manager decides
whether or not the project needs the document. For review, the general alternatives
are Do group review, Do one-person review, or Do not review. In addition, a project
manager may add some new activities or may repeat some activities.
When detailed tailoring is finished, the sequence of activities to be performed in the
process for the project is defined. These definitions are then used to plan and
schedule activities and form the basis of project execution. The tailoring performed is
highlighted in the project plan, so the process definition and tailoring also are
reviewed when the plan is reviewed.
3.2 REQUIREMENT CHANGE MANAGEMENT
Requirements change And changes in requirements can come at any time
during the life of a project (or even after that). Uncontrolled changes to
requirements can have an adverse effect on the cost, schedule, and quality
of the project. Requirement changes can account for as much as 40% of
the total cost.
3.2.1 The Change Management Process
During project planning, a project manager decides which process is to be
followed for handling change requests. The planned process is discussed
with the customer so that both the customer and the vendor are in
agreement about how to manage changes. Generally, the process specifies
how the change requests will be made, when formal approvals are
needed, and so on. When a request for a requirements change comes in,
the requirements change management process must be executed.
The commonly used change management process at Infosys has the following
steps.
1. Log the changes.
2. Perform an impact analysis on the work products.
3. Estimate the effort needed for the change requests.
4. Reestimate the delivery schedule.
5. Perform a cumulative cost impact analysis.
6. Review the impact with senior management if thresholds are exceeded.
7. Obtain customer sign-off.
8. Rework work products