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.

Overview

Purpose, scope, and objectives;

assumptions and constraints; project

deliverables; schedule and budget

summary; evolution of the plan

Project organization

External interfaces; internal structure;

roles and responsibilities

Managerial process plan

Start-up plans; work plan schedule;

control plan; risk management plan;

closeout plan

Technical process plan

Process model; methods, tools, and

techniques ; infrastructure plan; product

acceptance plan

Supporting process plans

Configuration management plan;

verification and validation plan;

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?

Rough order of

magnitude

Very early in the

project life cycle,

often 3-5 years

before project

completion

Provides estimate

of cost for

selection decisions -50% to +100%

Budgetary Early,1-2 years out Puts dollars In the

budget plans

-10% to +25%

Definitive Later in the project

less than 1year out

Provides details

for purchases,

estimates actual

costs

-5 to +10%

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.