UNIT-I

PROJECT:

A project is “a temporary endeavor undertaken to create a unique product,

service, or result” Operations, on the other hand, is work done in organizations to
sustain the business. Projects are different from operations in that they end when
their objectives have been reached if the project has been terminated.

PROJECT ATTRIBUTES:

As you can see, projects come in all shapes and sizes. The following
attributes help to define a project further;

 A project has a unique purpose.

 A project is a developed using progressive elaboration.
 A project is temporary
 A project requires resources, often from various areas
 A project should have a primary customer of sponsor
 A project involves uncertainty

THE TRIPLE CONSTRAINT

Every project is constrained in differend way by its scope, time, and cost
goals. These limitations are sometimes refered to in project management as the
tripleconstraint. To create a successful project, a project manager must consider
scope, time, and cost and balance these three often competing goals. He or she
must consider the following:
  Scope: What work will be done as part of the project? What unique ptoduct,
service, or result does the customer or sponsor expect from the project? How
will the scope be verified?
 Time: How long should it take to complete the pfoject? What is the project’s
schedule? How will the team track actual schedule performance?
 Cost: What should it cost to complete the project? What is the project’s
budget? How will costs be tracked? Who can authorize changes to the
budget?

(Successful project management means meeting all three goals and satisfying the
project’s sponsor)

PROJECT MANAGEMENT:

Project management is “the application of knowledge, skills tool and

techniques to project activities to meet project requirements.”

PROJECT MANAGEMENT FRAMEWORK:

Project Management Knowledge Areas

The four core knowledge areas of project management include project scope,
time, cost, and quality management. These are core knowledge areas because they
lead to specific project objectives. Brief Descriptions of each core knowledge area
are as follows:

 Project scope management involves defining and managing all the work
required to complete the project successfully.
  Project time management includes estimating how long it will take to
complere the work, development an acceptable project schedule, and
ensuring timelu completion of the project.
 Project cost management consists of prepating and managing the budget for
the project.
 Project quality management ensures that the project will satisfy the stated of
implied needs for which it was undertaken.

Common Project Management Tools Techniques by Knowledge Area

Integration management :

Project selection methods, project management methodologies, stakeholder

analysis, project charts, project management plans, project management software,
project review meetings

Scope management:

Scope statements, work breakdown structures, statements of work,

requirements analusis, scope management plans, and scope change controls

Cost management:
Net present value, return on investment, payback analysis, earned value
management, project portfolio management, cost management plans

Time management:

Project network diagrams, critical path method, crashing, fast tracking,

schedule performance measurements.
Quality management :

Quality metrics, checklists, quality control charts, pareto diagrams, fishbone

diagrams, maturity models, stastical model

Communication management:

Communications management plans, kick off meetings, conflict

management , communication media selection, starus and progress reports, virtual
communications, templates, project web sites

Human resource management :

Motion techniques, empathic listening, responsibility assignment matrices,

project organizational charts, resource diagrams, team buildings exercises.

Risk management:

Risk management plans, risk registers, probability impact matrices, risk

rankings.

Procurement management:

Make-or-buy analysis, contracts, requests for proposals of quotes, source

selections, supplier evaluation matrices.

THE ROLE OF THE PROJECT MANAGER

We already known that project managers must work closely with the other
stakeholders on a project especially the sponsor and project team. They also are
more effective if the are familiar with the nine project management knowledge
areas and the various tools and techniques related to project management.
Experienced project managers help projects succeed.

Suggested skills for project managers:

Project managers need to have a wide variety of skills and be able to decide
which particular skills are more important in different situations. As you can
imagine good project managers should have many skills. The project management
body of knowledge suggests that the project management team understand and use
expertise in the following areas:

 The project management body of knowledge

 Application area knowledge, standards, and regulations
 Project environment knowledge
 General management knowledge and skills
 Soft skills or human relations skills

Project managers shoukd also possess general management knowledge and skills.
They should understand important topics related to financial management,
accounting, procurement, sales, marketing, contracts, manufacturing, distribution,
logistics, the supply chain, strategic planning, tactical planning, operations
management, organizational structures and behavior, personnel administration,
compensation, benefits, career paths, and health safty practices. Even so the project
manager must be intelligent and experienced enough to know which of these areas
are most important and who is qualified to do the work. He or she must also make
and or take responsibility for all key project decisions.
PROJECT MANAGEMENT PROFESSION:

The profession of project management is growing at a very rapid pace.

To understand this line of work, it is helpful to briefly review the history of project
management, introduce to the project management institute and some of its
services, and discuss the growth in project management software.

Project management institute

The project management institute (PMI), an international professional

society for project managers founded in 1969, has continues to attract and retain
members work in the field. Project management also has SIGs for aero
space/defense, financial services, healthcare, hospitality management,
manufacturing, new product development, retail, and urban development, to name
a few.

Project management software:

Many people still use basic productivity software, such as Microsoft word or
Excel, to perform many project management functions, such as determining project
scope, time, and cost, assigning resources, preparing project documentation, and so
on. People often use productivity software instead of specialized project
management software because they already have it and how to use it. How ever,
there are hundreds of project management software tools can be divided into three
general categories based on functionality and price
SYSTEM VIEW OF PROJECT MANAGEMENT

System approach:

The term system approach emerged in the 1950s to describe a holisticand

analytical approach to solving complex problems that includes using,

 System philosophy
 System analysis
 System management

System philosophy:

A system philosophy is an overall model for thinking about things as

systems. Systems are sets of interacting components working within an
environment to fulfill some purpose. For example the human body is a system
composed of many subsystem-the nervous system, the skeletal system and so on.

System analysis:

It is a problem-solving approach that requires defining the scope of the

system, dividing it into its components, and then identifying and evaluating its
problems, alternative solutions for inproving the current situation identifies an
optimum, or at least satisfactory solution or action plan, and examines that plan
against the entire system.

System management:

System management address the business, technological, and organizational

issues associated with creating, maintaining, and making a change to a system.
Using a systems approach is critical to successful project management. Top
management and project managers must follow a system philosophy to understand
how projects relate to the whole organization. They must use system systems
management to identify key business, technological, and organizational issues
related to each project in order to identify and satisfy key stakeholders and do what
is best for the entire organization.

Three-sphere model for the systems management

Many business students understand the concepts of system and performing a

system analysis. However they often gloss over the topic of system management.
The simple ideaof addressing the three spheres of systems management-business,
organization, and technology-can have a huge impact on selecting and managing
projects successfully.

STAKEHOLDER MANAGEMENT

Stakeholders are the people involver on or affected by project activities.

Stakeholders can be internal to the organization, external to the organization,
directly involved in the project or simply affecter by the project.

Internal stakeholders generally include the project sponsor, project team, support
staff, and internal customers for the project. Other internal stakeholders include top
management, other functional managers, and other project managers.

External stakeholders include the project customers, compititors, suppliers, and

ither external groups potentially involved in or affecter by the project, suxh as
government officials or concerned citizens.since the purpose of project
management is to meet project requirements and manage relationship with all
project stakeholders.
UNIT-2

PROCESS MODELS

Prescriptive model

Prescriptive process models were originally proposed to bring order to the

choice of software development. History has indicated that these traditional models
have brought a certain amount of useful structure to software engineering work and
engineering work and the product that it produces remain on the edge of chaos. If
prescriptive process models strive for structure and order, are they inappropriate
for a software world that thrives on change? Yet, if we reject traditional
processmodels and replace them with somethimg less structured, do we make it
impossible to achieve coordination and coherence in software work?

There are no easy answers to these questions, but ther are alternatives
available to software engineers. In the sections that follow, I examine the
prescriptive process approach in which order and project consistency are dominant
issues. They call them “prescriptive” because they prescribe a set of process
elements frame work activities, tasks, work products,, quality assurance, and
change control mechanisms for each project. Each process model also prescribes
a process flow – that is, the manner in which the peocess elements are
interrelated to one another.

The Waterfall Model:

The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins with customer
specification of requirements and progress through planning, modeling,
construction, and deployment, culminating in ongoing support of the completed
software

Communication

project initiation requirements gathering

Planning

Estimating scheduling tracking

Modeling

Analysis design

Construction

Code test

Deployment

Delivery support feedback

The waterfall model is the oldest paradigm for software engineering.

However, over the past three decades, criticism of this process model has caused
even ardent supporters to question its efficacy. Among the problems that are
sometimes encountered when the waterfall model is applied are:

1. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly.
As a result, changes can cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of themany projects.
3. The customer must have patience. A working version of the program will
not be available until the working program is reviewed, can be disastrous.

INCREMENTAL MODEL

The incremental model applies linear sequences in a staggered fashion as

calendar time progress. Each linear sequence produces deliverable ‘increments ‘of
the software in a manner that is similar to the increments produced by an
evolutionary process flow.

When incremental model is used, the first increment is often a core product.
That is, basic requirements are addressed but many supplementary features remain
undelivered. The core product is used by the customer.

The incremental process model focuses on the delivery of an operational

product with each increment. Early increments are stripped-down versions of the
final product, but they do provide capability that serves the user and also provide a
platform for evaluation by the user.

Incremental development is particularly useful when staffing is unavailable

for a complete implementation by the business deadline that has been established
fir the project. Early increments can be implemented with fewer people. It might be
possible to plan early increments in a way that avoids the use of this hardware,
thereby enabling partial functionality to be delivered to end users without in
ordinary delay.

EVOLUTIONARY MODEL

Software, like all complex systems, evolves over a period of time. Business
and product requirements often change as development proceeds, making a straight
line path to an end product unrealistic: tight market deadlines make completion if a
comprehensive software product impossible, but a limited version must be
introduced to meet competitive or business pressure: a set of core product or
system requirements is well understood, but the details of product or system
extensions have yet to ne defined. In these and similar situations, you need a
process model that has been explicitly designed to accommodate a product that
evolves over time.

Evolutionary models are iterative. They are characterized in a manner that

enables you to develop increasingly more complete versions of the software,

AGILE PROCESS MODEL

Agility has become today’s buzzword when describing a modern software

process. Every one is agile. An agile team is a nimble team able to appropriately
respond to changes. Change is what software development is veruy much about.
An ag ile team recognizes that software is developed by individuals working in
teams and that the skills of these people, their ability to collaborate is at the core
for the success of the project.

Any agile software process is characterized in a manner that addresses a number of

key assumptions about the majority of software projects:

1. It is difficult to predict in advance which software requirements willpersist

and which will change. It is equally difficult to predict how customer
priorities will ehanges as the project proceeds.
2. For many types of software, design and construction are interleaved. That is,
both activities should be performed in tandem so that design models are
proven as they re created.
3. Analysis, design, construction, and resting are not as predictable as we might
like.

The most widely used of all agile process model is exreme programming. But
many other agile process models nave been proposed and are in use across the
industry. Among the most common are:

 Adaptive software development

 Scrum
 Dynamic systems development method
 Crystal
 Feature drive development
 Lean software development
 Agile modeling
  Agile unified process

CORE PRINCIPLES OF SOFTWARE ENGINEERING

Software engineering is guided by a collection of core principles that help in

the application of a meaningful sofrware process and the execution of effective
software engineering methods.

Principles that guide process

 Be agile
 Focus on quality at every step
 Be ready ti adapt
 Build an effective team
 Manage change
 Asses risk
 Create work products that provide value for others

Principles that guide practice

 Divide and conquer

 Understand the use of abstraction
 Strive for consistency
 Focus on the transfer of information
 Build software that exhibits effective modularity
 Look for patterns
 Remember that someone will maintain the software
Principles that guide each framework activity

 Communication principles
 Planning principles
 Modeling principles
 Construction principles
 Deployment principles
UNIT-3

PROJECT INREGRATION MANAGEMENT

Strategic planning and project selection

Many people are familiar with “SWOT” analysis. analyzing Streangths,

Weakness, Opportunities, and Threats that is used to aid in strategic planning. It is
very important to have managers from outside the information technology
department assist in the information technology planning process, as they can help
information technology personnel understand organizational strategies and identify
the business areas that support them.

After identifying strategic goals, the next step in the planning process for
selecting information technology projects is to perform a business area analysis,
this analysis outlines business process that are central to achieving strategic goals
and helps determine which ones could most benefits from information technology.
The next step is to start defining potential information technological projects, their
scope, benefits and constraints. The last step in the planning process for selecting
information technology project is choosing which project to do and assigning for
working on them.

Methods for selecting projects

Selecting projects is not an exact science, but it is a necessary part of project

management. Many methods exist for selecting from among possible projects. Five
common techniques are:

1. Focusing on broad organizational needs

2. Categorizing information technology projects
3. Performing net present value or other financial analyses
 4. Using a weighted scoring model
5. Implementing a balanced scorecard

Focusing on Broad organizational Needs

Top managers must focus on meeting their organization’s many needs when
deciding what projects to undertake, when to undertake them, and to what level.
Project that address broad organizational needs are much more likely to be
successful because they will be important to the organization. However, it is often
difficult to provide a strong justification for many information technology projects
releated to these broad organizational needs.

Categorizing information technology projects

Another method for selecting project is based on various categorizations,

such as the impetus for the project, the time window for the project, and the
general priority for the project. The impetus for a project is often to respond to a
problem, an opportunity, or a directive.

Performing net present value analysis

Financial consideration are often an important aspect of the project selection

process, especially during tough economic times. As authors Dennis Cohen and
Robert Graham put it, “projects are never ends in themselves. Financially they are
always a means to an end. three primary metods for determining the project
financial value of projects include net present value analysis, return on investment,
and pay back period.

Using a weighted scoring model

 It is a tool that provides a systematic process for selecting projects based on
many criteria. These criteria can include factors such as meeting broad
organizational needs, addressing problems, opportunities’, or directives. Some
possible criteria for information technology projects include:

 Supports key business objectives

 Has strong internal sponsor
 Has strong customer support
 Uses realistic level of technology
 Can be implemented in one year or less
 Provides positive NPV

Implementing a balanced scorecard

A balanced scorecard is a methodology that converts an organization’s value

drivers, such as customer service, innovation, operational efficiency, and financial
performance, to a series of defined matrices.

Project management plans

To coordinate and integrate information across project management

knowledge areas and across organization, there must be a good project
management plan. A project management plan is a document used to coordinate all
project planning documents and help guide a project execution and control.plans
creared in the other knowledge areas are considered subsidiary parts of the over all
project management plan.
 To create and assemble a good project management plan, the peoject
manager mist practice the art of project integration management, since information
is required from all of the project management knowledge areas.

Using a guidelines to create project management

Many organizations use guidelines to create project management plans.

Project 2003 and other project management software packages come with several
template files to use as guidelines. However, do not confuse a project management
plan with a Gantt chart. The project management plans includes all project
planning documents. Plans created in the other knowledge areas can be considered
subsidiary parts of the overall project management plan.

Purpose, scope, and objectives;

assumptions and constraints; project
Overview deliverables; schedule and budget
summary; evolution of the plan

External interfaces; internal structure;

Project organization roles and responsibilities
 Start-up plans; work plan schedule;
Managerial process plan control plan; risk management plan;
closeout plan

Process model; methods, tools, and

Technical process plan techniques ; infrastructure plan; product
acceptance plan

Configuration management plan;

verification and validation plan;
Supporting process plans documentation plan; quality assurance
plan; reviews and audits; problem
resolution plan; process improvement
plan.

Project execution

Directing and managing project management and performing the work

described in the project management plan. The majority of time on execution, as is
most of the project’s budget. The application area of the project directly affects
project execution because the products of the project are produced during project
execution.

Project execution tools and techniques

Directing and managing project execution requires specialized tools and
techniques, some of which are unique to project management. Project mangers can
use specific tools and techniques to perform activities that are part of execution
processes. These include:

 Project management methodology: many experienced project managers

believe the most effective way to improve project management is to follow a
methodology that describes not only what to do in managing a project, but
how to do it.
 Project management information system: there are hundreds of project
management software products available on the market today. Many large
organizations are moving toward powerful enterprise project management
systems that are accessible via the internet. Project managers or other team
members can create Gantt charts that includes links to other planning

INTEGERATED CHANGE CONTROL

Integrated change control involves identifying, evaluating, and managing

changes throughout the project life cycle. The main objectives of integrated change
control are:

1. Influencing the factors that create changes to ensure that changes are
beneficial
2. Determining that a change has occurred
3. Managing actual changes as they occur
Important inputs to the integrated change control process include the project
management plan, work information, request changes, recommended preventive
and corrective actions, recommended defect repair, and deliverables. Important
outputs include approved and rejected change requested,and updates to the project
management plan and project scope statement.

Change control system:

A change control system is a formal, documented process that describes

when and how official project documents may be changed. It also describes the
people authorized to make changes, the paperwork required for this change, and
any automated or manual tracking systems the project will use. A change control
systems often includes a change control board, configuration management, and a
process for communicating changes.

PROJECT SCOPE MANAGEMENT

Project scope management includes the process involved in dfining and

controlling what is or is not included in a project. It ensures that the project team
and stakeholders have the same understanding of what products the project will
produce and what process the project team will use to produce them there are five
main processes involved in project scope management

1. Scope planning
2. Scope definition
 3. Creating the WBS
4. Scope verification
5. Scope control

Scope planning and the scope management plan

The first step in project scope management is scope planning. The project’s
size, complexity, importance, and other factors will affect how much effort is spent
on scope planning. The scope management plan must be in the following form,

 Introduction about the project

 Preparing the scope statement
 Creating the work breakdown structure
 Verifying completion of project deliverables
 Managing request for changes to project scope

Project scope statement

The main out put of scope definition is the project scope statement. The
project team develops a preliminary scope statement in initiating a project as part if
the project integration management knowledge area. This document , as well as the
project charter, organizational process assets, and approved change requests
provide a basis for creating the project scope statement. The preliminary project
scope statement should provide basic scope information, and the project scope
statement should continue to clarify and provide information that is more specific.
CREATING THE WORK BREAKDOWN STRUCTURE

After completing scope planning and definition processes, the next step in
project management is to create a work breakdown structure. A work breakdown
structure is a deliverable- oriented grouping of the work involved in a project that
defines the total scope of the project. Because most projects involve many people
and many different deliverables, in is important to organize and divide the work
into logical parts based on how the work will be performed. The WBS is a
foundation document in project management because it provides the basis for
planning and managing project schedules, costs, resources, and changes.

Since the WBS defines the total scope of the project, some project
management experts believe that work should not be done on a project if it is not
included in the WBS. Therefore, it is crucial to develop a good WBS.

UNIT-4

PROJECT TIME MANAGEMENT

 Many information technology projects are failures in terms of meeting
scope, and cost projections. Managers often cite delivering projects on time as one
of their biggest challenges and the main cause of conflict.

Part of the reason schedule problems are so common is that time is easily
simply measured. Achieving timely completion of a project however, is by no
means simple. There are six main process involved in project time management:

1. Activity definition involves identifying the specific activities that the project
team members and stakeholders must perform to produce the project
deliverables.
2. Activity sequencing involves identifying and documenting the relationship
between project activities.
3. Activity resource estimating involves estimating how many resources-
people, equipment, and meterials –a project team should use to perform
project activities.
4. Activity duration estimating involves estimating the number of work periods
are needed to complete individual activities.
5. Schedule development involve analyzing activity sequences, activity
resource estimates, and activity duration estimates to creat the project
schedule.
6. Schedule control involves controlling and managing changes to the project
schedule.

Activity definition:

The activity list is a tabulation of activities to be included on a project

schedule. The list should include the activity name, an activity identifier or
number, and a brief description of the activity. The activity attributes provide more
schedule-related information about each activity, such as predecessors, successors,
logical relationship, leads and lags, resource requirements, constraints imposed
dates, and assumptions related t the activity.

Activity sequencing

After defining project activities, the next step in project time management is
activity sequencing. Activity sequencing involves reviewing the activity list and
attributes project scope statement, milestone list, and approved change request to
determine the relationship between activities. It also involves evaluating the
reasons for dependencies and the different types of attributes.

Dependencies

A dependency or relationship relate to the sequencing of project activities or

tasks. Determining these relationships between activities has a significant impact
on developing and managing a project schedule.

There are four types of dependencies can occur among project activities:

 Finish-to-start
 Start-to-start
 Finish-tofinish
 Start-to-finish

Schedule development

Schedule development uses the results of all the preceding project time
management processes to determine the start and end dates of the project. There
are often several iterations of all the project time management processes before a
project schedule is finalized. The monitoring project progress for the time
dimension of the project. The main outputs of this process are project schedule,
schedule model data and the project management plan.

Several tools and techniques assist in the schedule development process:

 A Gantt chart
 Critical path analysis
 Critical chain scheduling
 PERT analysis

Gantt charts:

Gantt charts provide a standard format for displaying project schedule

information by listening project activities and their corresponding start and finish
dates in a calendar format.

Critical path analysis:

Many project fail to meet schedule expectations. Critical path method also
Called critical path analysis, it is a network diagramming technique used to predict
total project duration.

Critical chain scheduling:

 Another technique that addresses the challenge of meeting or beating project
finish dates is an application of the theory of constraints called critical chain
scheduling.

PERT analysis:

Another project time management technique is the program evaluation and

review technique is a net work analysis technique used duration when there is a
high degree of uncertainty about the individual activity duration estimates.

PROJECT COST MANAGEMENT

Project cost management includes the process required to ensure that a

project team completes a project within an approved budget. Project managers
must make sure their projects are well defined, have accurate time and cost
estimates, and have a realistic budget that they were involved in approving. It is the
project managers job to satisfy projects stakeholders while continuously strive to
reduce and cost controls.

There are three cost management process:

 Cost estimating
 Cost budgeting
 Cost control

Basic principles of cost management

 Important concepts such as net present value analysis, return on investment,
and payback analysis were discussed in earlier, project integration management
likewise many projects that are started never finish because of cost management
problems. Most members of an executive board have a understanding of and are
more intrested in financial terms .

Cost estimating

Project managers must take cost seriously if they want to complete projects
within budgets constraints. After developing a food resource requirements list,
project teams must develop several estimates of the costs for these resources.

Types of cost estimates

Project managers normally prepared several type of cost estimates for most
projects. Three basic types of estimates include the following

 Rough order of magnitude

 Budgetary
 Definitive

The above three types are clearly explained bellow for, when it done? Why it
done? And how accurate?
 Very early in the Provides estimate
Rough order of project life cycle, of cost for
magnitude often 3-5 years selection decisions -50% to +100%
before project
completion

Budgetary Early,1-2 years out Puts dollars In the -10% to +25%

budget plans

Provides details
Definitive Later in the project for purchases, -5 to +10%
less than 1year out estimates actual
costs
 UNIT-5

QUALITY MANAGEMENT

Project quality management is a difficult knowledge area to define. The

international organization for standardization define quality as “the totality of
characteristics of an entity that bear on its ability to satisfy stated or implied needs”
Quality therefore, must be on an equal level with project scope, time, and cost. If a
project’s stakeholders are not satisfied with the quality of the project management
of the resulting products of the project, the project team will need to adjust scope,
time, and cost to satisfy the stake holder.

Project quality management involves three main process:

1. Quality planning
2. Quality assurance
3. Quality control

Quality planning

Quality planning includes identifying which quality standards are relevant to

the project and how to satisfy to those standards. Incorporating quality standards in
to project design is a key pat of quality planning. Quality standards can also apply
to information technology services. The main outputs of quality planning are a
quality management plan, quality metrics, quality checklists, a process
improvement plan, a quality baseline.
Quality assurance

Quality assurance involves periodically evaluating overall project

performance to ensure that the project will satisfy the relevant quality standards.
The quality assurance process involves taking responsibility for quality throughout
the project’s life cycle. Top management must take the lead in emphasizing the
roles all employees play in quality assurance, especially senior manager roles.

Quality control

Many people only think of quality control when they think of quality
management. Perhaps it is because there are many popular tools and techniques in
these area. Before describing some of these tools and techniques, it is important to
distinguish quality control from quality planning and quality assurance.

Tools and techniques for quality control

Quality control includes many general tools and techniques. This section describes
the seven basic tools of quality, statistical sampling, and six sigma and discusses
how they can be applied to information technology projects.

The following seven tools are known as the seven basic tools of quality:

1. Cause-and-effect diagrams
2. Control charts
3. Run chart
4. Scatter diagram
5. Histogram
6. Pareto charts
7. Flow charts
Modern quality management

Modern quality management requires customer satisfaction, prefers prevention to

inspection, and recognizes management responsibility for quality. The suggestion
from quality experts led to many projects to improve quality and provided the
foundation for today’s six sigma projects.

Software testing

Fundamentals:

The goal of testing is to finding errors, and a good test is one that has a high
probability of finding an error. Therefore, you should design and implement a
computer based system or a product with “testability” in mind.

WHITE BOX TESTING

White box testing some times called glass box testing, is test case design
philosophy that uses the control structure described the control structure as part of
component level design to derive test cases. Using white box methods you can
derive test cases that

1. Gaurantee that all independent paths within a module have been

exercised at least once
2. Exercise all logical decision on their true and false sides
3. Execute all loops at their boundaries and within their operational
bounds
4. Exercise internal data structures to ensure their validity
BLACK BOX TESTING

It is also called behavioral testing, focuses on the functional requirements of the

software. That is black box testing techniques enable you to derive sets of input
conditions that will fully exercise all functional requirements for aprogram. Black
box testing is not an alternative to white box techniques. Rather it is a
complementary approach that is likely to uncover a different class of errors than
white box methods.

Black box testing attempts to find errors in the following categories:

1. Incorrect or missing function

2. Interface errors
3. Errors in data structures or external database access
4. Behavior or performance errors
5. Initialization and termination

Methods of black box testing:

 Graph based testing

 Equivalence partitioning
 Boundary value analysis
 Orthogonal array testing

Graph based testing:

The first step in black box testing is to understand the objects that are
modeled in software and the relationship that connect these objects these objects.
Once this has been accomplished the next step is to define a series of tests that
verify “all objects have the expected relationship to one another” stated in another
way, software testing begins by creating a graph of important objects and their
relationships and then devising a series of tests that will cover the graph so that
each object and relationship is exercised and errors are uncovered.

Equivalence partitioning:

Equivalence portioning is a black box testing method that divides the input
domain of a program into classes of data from which test cases can be drived. An
ideal test case single handedly uncovers a class of errors that might otherwise
require many test cases to be executed before the general errors is observed. An
equivalence class is represents a set of valid or invalid states for input conditions.
Typically an input condition is either a specific numeric value a range of values a
set of related values or a Boolean condition.

Equivalence may be defined according to the following guidelines:

1. If an input condition specifies a range, one valid and two invalid equivalence
classes are defined.
2. If an input condition requires a specific value, one valid and two invalid
equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid
equivalence class are defined.
4. If an input condition is Boolean, one valid and one invalid class are defined

Boundary value analysis:

A greater number of errors occurs at the boundaries of the input domain

rather than in the “center”. it is for this reason that boundary value analysis has
been developed as a testing technique. Boundary value analysis leads to a selection
test cases that exercise bounding values.

Guide lines for BVA are similar in many respects to those provided for e
equivalence portioning:

1. If an input condition specifies a range bounded by values a and b, test cases

should be designed with values a and b and just above and just bellow a and
b.
2. If an input condition specifies a number of values, test cases should be
developed that exercise the minimum and maximum numbers. Values just
above and bellow minimum and maximum are also tested.
3. Apply guidelines 1 and 2 to output conditions. Test cases should be designed
to create an output report that produces the maximum allowable number of
table entries.
4. If internal program data structures have prescriber boundary be certain to
design a test case to exercise the data structure at its boundary.

Orthogonal array testing:

There are many applications in which the input domain is relatively limited.
That is the number of input parameters is small and the values that each of the
parameters may take are clearly bounded. When the numbers are very small it is
possible to consider every input permutation and exhaustively test the input
domain.

Orthogonal array testing can be applied to problems in which the input

domain is relatively small but too large to accommodate exhaustive testing. The
orthogonal array testing method is particularly useful in finding region faults an
error category associated with faulty logic within a software component.
Test strategies for conventional software

There are many strategies that can be used to test software. At once extreme,
you can wait until the system is fully constructed and then conduct tests on the
overall system in hopes of finding errors. This approach, although appealing,
simply does not work. It will result in buggy software that disappoints all
stakeholders.

A testing strategy that is chosen by most software team falls between the
two extremes. It takes extremes incremental view of testing , beginning with the
testing of individual program units . each of these classes of tests is described in
the section that follow:

Unit testing:

Unit test focuses verification effort on the smallest unit of software design
the software component or module. Using the component level design description
as a guide, important control paths are tested to uncover within the boundary of the
module. The unit test focuses on the internal processing logic and data structures
within the boundaries of a compound.

Integration testing:

Integration testing is a systematic technique for constructing the software

architecture while at the same time conducting tests to uncover errors associated
with interfacing. The objective is to take unit tested components and build a
program structure that has been dictated by design. Incremental integration is the
antithesis of the bang approach. The program is constructed and tested in small
increments, where errors are easier to isolate and correct. In the perhaps that
follow, a number of different incremental integration strategies are discussed.

Top down integration

Top-down integration testing is an incremental approach to construction of

the software architecture. Modules are integrated by moving downward through
the control hierarchy, beginning with the main control module. The integration
process performed in a series of five steps:

1. The main control module is used as a test driver and stubs are substitutes for
all components directly subordinate to the main control module.
2. Depending on the integration approach selected subordinate stubs are
replaced one at a time with actual components.
3. Tests are conducted as each components is integrated.
4. On completion of each set of tests, another stub is replaced with the real
component.
5. Regression testing may be conducted to ensure that new errors have not been
introduced.

The process continues from step2 until the entire program structure is built.

Bottom-up integration

Bottom-up integration testing, as its name implies, begins construction and

testing with atomic modules. Because components are integrated from the bottom
up, the functionality provided by components subordinate to a given level is
always available and the need for stubs is eliminated. A bottom up integration
strategy may be implemented with the following steps:
 1. Low level components are combined into clusters that perform a specific
software subsection.
2. A driver is written to coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the
program structure.

The debugging process

Debugging is not testing often occurs as a consequence of testing. The

debugging process begins with the execution of a test case. Results are assessed
and a lack of correspondence between expected and actual performance is
encountered. The debugging process will usually have one of two outcomes:

1. The cause will be found and corrected

2. The cause will not be found

However, a few characteristics of bugs provide some clues:

1. The symptom and the cause may be geographically remote. That is, the
symptom may appear in one part of a program, while the cause may actually
be located at a site that is far removed.
2. The symptom may disappear when another error is corrected.
3. The symptom may actually be caused by non errors
4. The symptom may be caused by human error that is not easily traced.
5. The symptom may be a result of timing problems, rather than processing
problems.
6. It may be difficult to accurately reproduce input condition.
7. The symptom may be intermittent. This particularly common in embedded
systems that couple hardware and software inextricably.
8. The symptom may be due to causes that are distributed across a number of
tasks running in different processors.