1 UNIT 2 PROJECT SCHEDULING AND TRACKING

UNIT 2
Pr oj e ct Sch e d u li n g a n d Tr a ck i n g

INTRODUCTION


Although there are many resons why software is delilvered late, most can be traced to one or more
of the following root causes.


An unrealistic deadline established by someone outside the software engineering group and
forced on managers and practitioners within the group.
Changing customer requirements that are not reflected in schedule changes.
An honest underestimate of the amount of effort and/or the number of resources that will
be required to do the job.
Predictable and/or unpredictable risks that were not considered when the project commenced
Technical difficulties that could not have been foreseen in advance.
Human difficulties that could not have been foreseen in advance.
Miscommunication among project staff that results in delays.
A failure by project management to recognize that the project is falling behind schedule and a
lack of action to correct the problem.


The following steps are recommended in this situation:

1. Perform a detailed estimate using data from past projects. Determine the estimated effort
and duration for the project.

2. Using an incremental process model develop a development strategy that will deliver
critical functionality by the imposed deadline, but delay other functionality until later.
Document the plan.

3. Meet with the customer and explain why the imposed deadline is unrealistic. Be certain to
note that all estimate are based on performance on past projects. Also be certain to indicate
the percentage
improvement that would be required to achieve the deadline as it currently exists.

4. Offer the incremental development strategy as an alternative.

Ba sic p r in ciple s


The project managers objective is to define all project tasks, identify the ones that are critical,
and then track their progress to ensure that delay is recognized one day at a time. To
accomplish this, the manager must have a schedule that has been defined at a degree of resolution
that enables the manager to monitor progress and control the project.


Software project scheduling is an activity that distributes estimated effort across the planned
2 UNIT 2 PROJECT SCHEDULING AND TRACKING
project duration by allocating the effort to specific software engineering tasks. It is important to
note, however, that the schedule evolves over time. During early stages of project planning, a
macroscopic schedule is developed. This type of schedule identifies all major software
engineering activities and the product functions to which they are applied. As the project gets
under way, each entry on the macroscopic schedule is refined into a detailed schedule. Here,
specific software tasks are identified and scheduled.


Scheduling for software development projects can be viewed from two rather different
perspectives. In the first, an end date for release of a computer based system has already been
established. The software organization is constrained to distribute effort with in the prescribed
time frame. The second view of software scheduling assumes that rough chronological bounds
have been discussed but that the end date is set by the software engineering organizatin. Effort is
distributed to make best use of resources, and an end date is defined after careful analysis of the
software. Unfortunately the first situation is encountered far more frequently than the second.
Like all other areas of software engineering, a number of basic principles guide software project
scheduling:


Compartmentalization The project must compartmentalized into a number of manageable
activities and tasks. To accomplish compartmentalization, both the product and the process are
decomposed.


Interdependency The interdependencies of each compartmentalized activity or task must be
determined. Some tasks must occur in sequence; others can occur in parallel. Some activities
cannot commence until the work product produced by another is available. Other activities can
occur independently.


Time Allocation Each task to be scheduled must be allocated some number of work units. In
addition, each task must assigned a start date and a completion date that are functions of the
interdependencies and whether work will be conducted on a full time or part time basis.


Effort validation Every project has a defined number of staff member. As time allocation
occurs, the project manager must ensure that no more than the allocated number of people have
been allocated at any given time. For example, consider a project that has three assigned staff
members. On a given day, seven concurrent tasks must be accomplished. Each task requires 0.50
person days of effort. More effort has been allocated than there are people to do the work.


Defined responsibilities. Every task that is scheduled should be assigned to a specific team member.


Defined outcomes. Every task that is scheduled should have a defined outcome. For software
projects, the outcome is normally a work product or a part of a work product. Work products are
often combined in deliverables.


Defined milestones. Every task or group of tasks should be associated with a project
milestone. A milestone is accomplished when one or more work products have been reviewed
for quality and have been approved.


Each of the above principles is applied as the project schedule evolves.


Th e Re la t in sh ip Be t w e e n Pe op le a n d Ef f or t
3 UNIT 2 PROJECT SCHEDULING AND TRACKING

In a small software development project a single person can analyze requirements, perform
design, generate code, and conduct tests. As the size of a project increases, more people must
become involved.


There is a common myth that is still believed by many managers who are responsible for
software development effort: If we fall the project, Unfortunately, adding people late in a
project often has a disruptive effect, causing schedules to slip even further. People late in a project
often has disruptive effect, causing schedules to slip even further. People who are added must learn
the system, and the people who teach them are the same people who were doing the work. While
they are teaching, no work is done and the project falls further behind.


In addition to the time it takes to learn the system, involving more people increases the
number of communication paths and the complexity of communication throughout a project.
Although communication is absolutely essential to successful software development, every new
communication path requires additional effort and therefore additional time.

An e m pir ica l r e la t ion sh ip


We can demonstrate the highly nonlinear relationship between chronological time to complete a
project and human effort applied to the project. The number of delivered lines of code L are
related to effort and development time by the equation :

L = P X (E/B)
1/3
T
4/3


Where E is development effort in person months ; P is a productivity parameter that reflects a
variety of facators that lead to high quality software engineering work B is a special skill factor
that ranges between
0.16 and 0.39 and is a function of the size of the software to be produced; and t is the project
duration in calendar months.


Rearranging the software equation (above), we arrive at an expression for development effort E.


E =L
3
/(P
3
T
4
)

Where E is the effort expended over the entire life cycle for software development and maintenance,
and T is the development time in years. The equation for development effort can be related to
development cost by the inclusion of a burdened labor rate factor ($/person-year).

D e f in in g a Ta sk Se t for t h e Soft w a r e Pr oj e ct



There is no single set of tasks that is appropriate for all projectss. The set of tasks that would
be appropritae for a large complex system would likely be perceived as overkill for a small
relatively simple project. Therefore an effective software process should define a colletion of task
sets each designed to meet the needs of different types of projects.


A task set is a collection fo softwarte engineering work tasks, milestone and deliverables that
must be accomplished to complete a particualr project. The task set to be chosen must provide
enough discipline to achieve high software quality. But at the same time, it must not burden the
project team with unnecessary work.
4 UNIT 2 PROJECT SCHEDULING AND TRACKING

Task sets are designed to accommodate different type of projectsa dn different degrees fo rigor.
Although it is difficult to develop a comprehensive taxonomy, most software organizations
encounter projecs of the following types :


I. Concept Development Projects. That are initiated to explore some new business
concept or application of some new technology.
II. New Application Development Projects That are undertaken as a consequence of a specific
customer request.
III. Application Enhancement Projects That occur when existing software undergoes major
modification to function performance or interfaces that are observable by the end user.
IV. Application Maintenance Projects That correct, adapt or extend, existing software in ways
that may not be immediately obvious to the end user.
V. Reengineering Projects That are undertaken with the intent of rebuilding an existing (legacy)
system in whole or in part.


Even within a single project type there are many factors that influence the task set to be chosen.
When taken in combination these factors provide an indication of the degree of rigor with which
the software process should be applied.
D e g r e e of Rigor

Even for a project of a particular type the degree of rigor with which the software process is applied
may vary significantly. The degree of rigor is function of many project characteristics. As an
example, small, non-business, critical projects can generally be addressed with somewhat less
rigor than large complex baseline critical applications. It should be noted however that all
projects must be conducted in manner that results in timely high quality deliverables. Four
different degrees of rigor can be defined:
Casual. All process frame work activities are applied but only a minimum task set is required. In
general umbrella tasks will be minimized and documentation requirements will be reduced. All
basic principles of software engineering are still applicable.


Structured. The process framework will be applied for this project . Framework activities and
related tasks appropriate to the project type will be applied and umbrella activities necessary to
ensure high quality will be applied. SQA, SCM documentation and measurement tasks will be
conducted in a streamlined manner.


Strict. The full process will be applied for this project with a degree of discipline that will ensure
high quality. All umbrella activities will be applied and robust documentation will be produced.


Quick Reaction. The process framework will be applied for this project but because of an
emergency situation only those tasks essential to maintaining good quality will be applied
Back-filling (i.e., developing a complete set of documentation conducting additional reviews)
will be accomplished after the application/product is delivered to the customer.


The project manager must develop a systematic approach for selecting the degree of rigor that is
appropriate for a particular project. To accomplish this project adaptation criteria are defined and a
task set selector value is computed.


5 UNIT 2 PROJECT SCHEDULING AND TRACKING
D e f in in g Ad a pt a t ion Cr it e r ia

Adaptation criteria are used to determine the recommended degree of rigor with which the
software process should be applied on a project. Eleven adaptation criteria are defined for software
projects:


Size of the project
Number of potential users
Mission critically
Application longevity
Stability of requirements
Ease of customer/developer communication
Maturity of applicable technology
Performance constraints
Embedded /non embedded characteristics
Project staffing
Reengineering factors
Each of the adaptation criteria is assigned a grade that ranges between 1 and 5 where 1 represents a
project in which a small subset of process tasks are required and over all methodological and
documentation of requirements are minima l and 5 represents a project in which a complete set of
process tasks should be applied and overall methodological and documentation requirements are
substantial

Com p u t in g a Ta sk Se t Se le ct or V a lu e

To select the appropriate task set for a project the following steps should be conducted:

1. Review each of the adaptation criteria sin Section 7.3.2 and assign the appropriate grades (1
to 5) based on the characteristic of the project. These grades should be entered into Table 7.1
2. Review the weighting factors assigned to each of the criteria. The value of a weighting factor
ranges from 0.8 to 1.2 and provides an indication of the relative importance of a
particular adaptation criterion to the types of software developed within the local
environments. If modification are required to better reflect local circumstances they should be
made.
3. Multiply the grade entered in Table 7.1 by the weighting factor and by the entry point
multiplier for the type of project to be undertaken. The entry point multiple user takes on a
value of 0 or 1 and indicates that relevance of the adaptation criterion to the project type.
The result of the product: Grade*weighting factor* entry point multiplier
4. Compute the average of all entries in the Product column and place the result in the space
marked task set selector. This value will be used to help you select the task set that is most
appropriate for the project.


Adaptation criteria Grade Weight
Conc.
Entry Point Moltiplier
N.Dev. Enhan. Main.
Product
Reeng.
Size of project ----- 1.20 0 1 1 1 1 -----
No. of users ----- 1.10 0 1 1 1 1 -----
6 UNIT 2 PROJECT SCHEDULING AND TRACKING



Computing the task set selector
I n t e r pr e t in g t h e TSS V a lu e a n d Se le ct in g t h e Ta sk Se t


Once the task set selector is computed, the following guidelines can be used to select the
appropriate task set for a project.


Task Set Selector Value Degree of Rigor
TSS<1.2 casual
1.0 <TSS <3.0 structured
TSS>2.4 strict

The overlap in TSS values from one recommended task set to another is purposeful and is
intended to illustrate that sharp boundaries are impossible to define when making ask set
selections. In the final analysis the task set selector value past experience and common sense must
all be factored into the choice of the task set for a project. The entry in the Product column is
computed using


Grade*Weight* Entry Point Multiplier

The final decision is made once all project factors have been considered.

Se le ct in g Soft w a r e En g in e e r in g Ta sk s


Concept development projects are approached by applying the following major tasks:


Concept Scoping determines the overall scope of the project


Preliminary Concept Planning establishes the organizations ability to undertake the work
implied by the project scope.


Technology risk assessment evaluates the risk associated with the technology to be implemented
as part of project scope.


Proof of concept demonstrates the viability of a new technology in the software context.


Concept implementation implements the concept representation in a manner that can be
reviewed by a customer and is used for marketing purposes when a concept must be sold to
other customers or management.


Business criticality ----- 1.10 0 1 1 1 1 -----
Longevity ----- 0.90 0 1 1 0 0 -----
Stability of work ----- 1.20 0 1 1 1 1 -----
Ease of
communication
----- 0.90 1 1 1 1 1 -----
Modularity of Tech. ----- 0.90 1 1 0 0 1 -----
Performance
constraint
----- 0.80 0 1 1 0 1 -----
Embedeed/nonembed
ded
----- 1.20 1 1 1 0 1 -----
Project staffing ----- 1.00 1 1 1 1 1 -----
Interoperability ----- 1.10 0 1 1 1 1 -----
Reengineering factors ----- 1.20 0 0 0 0 1 -----
7 UNIT 2 PROJECT SCHEDULING AND TRACKING
Customer reaction to concept solicits feedback on a new technology concept and targets specific
customer applications.


Re f in e m e n t of M a j or Ta sk s

The major tasks described in previous section may be used to define a macroscopic schedule
would be used to define a task network for the project.

















Concept development tasks in a linear, sequential model


The macroscopic schedule must be refined to create a detailed project schedule. Refinement begins
by taking each major task and decomposing it into a set of subtasks.




Concept development tasks using an evolutionary model







8 UNIT 2 PROJECT SCHEDULING AND TRACKING
D e f in in g a Ta sk s N e t w or k

Individual tasks and subtasks have interdependencies based on their sequence. In addition, when
more3 than one person is involved in a software engineering project. It is likely that development
activities and tasks will be performed in parallel. When this occurs, concurrent tasks must be
coordinated so that they will be complete when later tasks require their work product.


A task network is a graphic representation of the task flow for a project. It is sometimes used
as the mechanism through which task sequence and dependencies are input to an automated
project scheduling tool. In its simplest form, the task network depicts major software engineering
tasks. The following figure
shows a schematic task network for a concept development project.


The concurrent nature of software engineering activities leads to a number of important
scheduling requirements. Because parallel tasks occur asynchronously, the planner must
determine inter task dependencies to ensure continuous progress toward completion. In addition,
the project manager should be aware of these tasks that lie on the critical path. That is, tasks that
must be completed on schedule if the project as a whole is to be completed on schedule.

S
o
f
t
w
a
r
e

E
n
g
i
n
e
e
r
i
n
g

C
o
n
c
e
p
t
s

&

I
m
p
l
e
m
e
n
t
a
t
i
o
n

I
t

i
s

i
m
p
o
r
t
a
n
t

t
o

n
o
t
e

t
h
a
t

t
h
e

t
a
s
k

n
e
t
w
o
r
k

s
h
o
w
n

i
n

f
i
g
u
r
e

8
.
1

m
a
c
r
o
s
c
o
p
i
c
.

I
n

a

d
e
t
a
i
l
e
d

t
a
s
k

n
e
t
w
o
r
k

e
a
c
h

a
c
t
i
v
i
t
y

s
h
o
w
n

i
n

f
i
g
u
r
e

8
.
1

w
o
u
l
d

b
e

e
x
p
a
n
d
e
d
.

F
o
r

e
x
a
m
p
l
e

t
a
s
k

I
.
1

w
o
u
l
d

b
e

e
x
p
a
n
d
e
d

t
o

s
h
o
w

a
l
l

t
a
s
k
s

d
e
t
a
i
l
e
d

i
n

t
h
e

r
e
f
i
n
e
m
e
n
t
.
















I. 3a Tech.
Risk
Assessment
I. 5a Concept
Implemenati
on


I.1 Concept I.2 Concept I.3b Tech. Risk I.4 Proof of I.5b Concept I.1 Concept I.6 Customer
scoping Planning
Assessment
Concept Implement scoping Reaction


I. 3c Tech.
Risk
Assessment
I.5c Concept
Implement







Three I.3 tasks are applied
in parellel to 3 different
concept functions
Three I.3 tasks are applied
in parellel to 3 different
concept functions





A task network for a concept development project

10 UNIT 2 PROJECT SCHEDULING AND TRACKING


Sch e du lin g


Scheduling of a software projects does not differ greatly from scheduling of any multitask
engineering effort. Therefore, generalized project scheduling tools and techniques can be applied to
software with little modification.


Program evaluation and review technique (PERT) and critical path method (CPM) are two project
scheduling methods that can be applied to software development. Both techniques are driven by
information already developed in earlier project planning activities:

Estimates of effort
A decomposition of product function
The selection of the appropriate process model
The selection of project type and task set

Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the
project work breakdown structure, are defined for the product as a whole or for individual functions.


Both PERT and CPM provide quantitative tools that allow the software planner to (1)
determine the critical path- the chain of tasks that determines the duration of the project; (2)
establish most likely time estimates for individual tasks by applying statistical models; and (3)
calculate boundary times that define a time window for a particular task.


Boundary time calculations can be very useful in software project scheduling. Slippage in the
design of one function, for example, can retard further development of other functions. Riggs
describes important boundary times that may be discerned from a PERT or CPM network (1) the
earliest time that a task can begin when all preceding tasks are completed in the shortest
possible time;(2) the latest time for task initiation before the minimum project completion time
is delayed;(3) the earliest finish-the sum of the earliest start and the task duration (4) the latest
finish-the latest start time added to task duration and (5) the total float the amount of surplus
time or leeway allowed in scheduling tasks so that the network critical path is maintained on
schedule. Boundary time calculations lead to a determination of critical path and provide the
manager with a quantitative method for evaluating progress as tasks are completed.


Both PERT and CPM have been implemented in a wide variety of automated tools that are
available for virtually every personal computer. Such tools are easy to use and make the scheduling
methods described above available to every software project manager.


Tim e lin e Ch a r t s

When creating a software project schedule, the planner begins with a set of tasks(the work
breakdown structure). If automated tools are used, the work breakdown is input as a task
network or task outline. Effort, duration and start date are then input for each tasks. In addition,
tasks may be assigned to specific individuals.

11 UNIT 2 PROJECT SCHEDULING AND TRACKING





I.1.1
Work tasks Week 1 Week 2 Week 3 Week 4
Identify need and benefits Meet
with customers
Identify needs and project constraints
Establish product statement
Milestone: product statement defined
I.1.2
Define desired output/control/input(OCI) Scope
keyboard functions
Scope voice input functions Scope
modes of interaction Scope
document diagnostics Scope other
WP functions Document OCI
FTR: Review OCI with customer
Revise OCI as required; Milestone:
OCI defined
I.1.3
Define the functionality/hehavior Define
keyboard functions
Define voice input functions
Describe modes of interaction
Describe spell/grammar check
Describe other WP functions
FTR: Review OCI definition with customer
Revise as required
Milestonre: OCI definition complete
I.1.4
Isolate software elements Milestone:
Software elements defined I.1.5
Research availability of existing software
Research text editing components Research
voice input components Research file
management components Research
spell/grammar check components Milestone:
Reusable components identified


An example timeline chart


As a consequence of this input, a timeline chart, also called a Gantt chart, is generated. A timeline
chart can be developed for the entire project. Alternatively, separate charts can be developed for
each project function or for each individual working on the project.


Figure illustrates the format of a timeline chart. It depicts a part of a software project schedule
that emphasizes the concept scoping task for a new work-processing software product. All project
tasks (for concept scoping) are listed in the left hand column. The horizontal bars indicate the
during of each task. When multiple bars occur at the same time on the calendar, task concurrency
is implied. The diamonds indicate milestones.
12 UNIT 2 PROJECT SCHEDULING AND TRACKING



Once the information necessary for the generation of a timeline chart has been input, the
majority of software project scheduling tools produce project tables a tabular listing of all project
tasks, their planned and actual start and end dates, and a variety of related information. Used in
conjunction with the timeline chart, project tables enable the project manager to track progress.

Tr a ck in g t h e Sch e d u le

The project schedule provides a road map for a software project manager. If it has been
properly developed, the project schedule defines the tasks and milestones that must be tracked
and controlled as the project proceeds. Tracking can be accomplished in a number of different
ways.


Conducting periodic project status meetings in which each team member reports progress
and problems.
Evaluating the results of all reviews conducted throughout the software engineering process
Determining whether formal project milestones ( the diamonds shown in figure 8.4) have
been accomplish by the scheduled date.
Comparing actual start date to planned start date for each project task listed in the project table.
Meeting informally with practitioners to obtain their subjective assessment of progress to date
and problems on the horizon.

In reality, all of these tracking techniques are used by experienced project managers.

Control is employed by a software project manager to administer project resource, cope with
problems and direct project manager to administered project (i.e., the project is on schedule
and within budget reviews indicate that real progress is being made and milestones are being
reached), control is light. But when problems occur the project manager must exercise control to
reconcile them as quickly as possible. After a problem has been diagnosed additional resources
may be focused on the problem area: Staff may be redeployed or the project schedule can be
redefined.
Work Tasks Planned
start
Actual
start
Planned
Complete
Actual
complete
Assigned
person
Effort
allocated
Notes
I.1.1




Wk1,d1




Wk1,d1




Wk1,d2




Wk1,d2




Wk1,d1




BLS




Scoping
Identify needs and benefits
Meet with customers
Identify needs and project constraints Wk1,d2 Wk1,d2 Wk1,d2 Wk1,d2 Wk1,d2 JPP will
Establish product statement Wk1,d3 Wk1,d3 Wk1,d3 Wk1,d3 Wk1,d3 BLS/JPP require
Milestone: product statement defined Wk1,d3 Wk1,d3 Wk1,d3 Wk1,d3 Wk1,d3

more
effort/
I.1.2
time
Defined desired output/control
/input (OCI)
Scope keyboard functions
Wk1,d4 Wk1,d4 Wk2,d2 Wk1,d4
BLS
Scope voice input functions
Wk1,d3 Wk1,d3 Wk2,d2 Wk1,d3
JPP
Scope modes of interaction
Wk2,d1

Wk2,d3 Wk2,d1
MLL
Scope document diagnostics
Wk2,d1

Wk2,d2 Wk2,d1
BLS
Scope other WP functions
Wk1,d4 Wk2,d1 Wk2,d3 Wk1,d4
JPP
Document OCI
Wk2,d1 Wk2,d3 Wk2,d1
MILL
FTR: Review OCI with customer
Wk2,d3 Wk2,d3 Wk2,d3
All
Revise OCI as required;
Wk2,d4 Wk2,d4 Wk2,d4
All
Milestone: OCI defined
Wk2,d5 Wk2,d5 Wk2,d5

I.1.3
Define the functionality/behavior
13 UNIT 2 PROJECT SCHEDULING AND TRACKING



An example project table

When faced with severe deadline pressure experienced project managers sometimes use a project
scheduling and control technique called time-boxing. The time boxing strategy recognizes that the
complete product may not be deliverable by the predefined deadline. Therefore an incremental
software paradigm is chosen and a schedule is derived for each incremental delivery.


The tasks associated with each increment are then time boxed . This means that the schedule for
each task is adjusted by working backward form the delivery date for the increment . A box is
put around each task. When a task hits the boundary of its time-box (plus or minus 10 percent )
work stops and the next task begins.


The initial reaction to the time-boxing approach is often negative. if the work isnt finished how
can we proceed? The answer lies in the way work is accomplished. By the time that time-
box boundary is encountered it is likely that 90 percent of the task has been completed. The
remaining 10 percent although important can (1) be delayed until the next increment for (2) be
completed late if required. Rather than becoming stuck on a task the project proceeds toward the
delivery date.


Th e Pr oj e ct Pla n


Each step in the software engineering process should produce a work product that can be reviewed
and that can act as a foundation for the steps that follow the Software project plan is
produced at the culmination of the planning tasks . It provides baseline cost and scheduling
information that will be used through out the software engineering process.


The software project plan is a relatively brief document that is addressed to a diverse audience. It
must (1) communicate scope and resources to software management technical staff and the
customer; (2) define risks and suggest risk management techniques ; (3) define cost and schedule
for management review ; (4) provide an overall approach to software development for all
people associated with the project; and (5)outline how quality will be ensured and change will
be managed. An outline of the software project plan is presented in Figure 8.6

A presentation of cost and schedule will vary with the audience to whom it is addressed. If the
plan is used only as an internal document, the result of each costing technique can be presented.
When the plan is disseminated outside the organization a reconciled cost breakdown (combining
the results of all costing techniques ) is provided. Similarly the degree of detail contained within
the schedule section may vary with the audience and formality of the plan.

The software project plan need not be a lengthy, complex document. Its purpose is to help
establish the viability of the software development effort. The plan concentrates on a general
statement of what and a specific statement of

I. Introduction
A. Purpose of Plan
B. Project Scope and Objectives
1. Statement of Scope
2. Major Functions
3. Performance Issues
14 UNIT 2 PROJECT SCHEDULING AND TRACKING


4. Management and Technical Constraints
II. Project Estimates
A. Historical Data used for Estimates
B. Estimation Techniques
C. Estimates of Effort, Cost , Duration

III. Risks Management Strategy
A. Risk Table
B. Discussion of Risks to be Managed
C. RMMM Plan for each risk:
1. Risk Mitigation
2. Risk Monitoring
3. Risk Management (contingency plans)

IV. Schedule
A. Project Work Breakdown Structure
B. Task Network
C. Timeline Chart (Gantt Chart)
D. Resource Table

V. Project Resources
A. People
B. Hardware and Software
C. Special Resources

VI. Staff Organization
A. Team Structure (if applicable)
B. Management Reporting

VII. Tracking and Control Mechanisms
A. Quality Assurance and Control
B. Change Management and Control

VIII. Appendices

How much and how long. Subsequent steps in the software engineering process will concentrate
on definition, development and maintenance.


Possible Questions


1. How do you define a Task Network?

2. Give a short note on Timeline Charts?

3. Explain briefly about Tracking the Schedule?

4. What is Project Plan?

5. What is Effort Distribution ?

6. Define Empirical Relationship ?

7. What is Degree of Rigor ?

8. How do you compute a TSS value ?