Project Planning Software Engineering unit-3

RAJIV GANDHI INSTITUTE OF PETROLEUM
TECHNOLOGY, JAIS, AMETHI
B.Tech. 3rd Year
Software Engineering (CS331)
By
Dr. Kalka Dubey
Department of Computer Science and Engineering
Dr. Kalka Dubey Assistantt Professor RGIPT Jais Amethi 1

UNIT-III (Planning a Software Project)
 Cost estimation
 Project scheduling
 Staffing and personnel planning
 Team structure
 Software configuration management
 Quality assurance plans
 Monitoring plans
 Management.

Introduction
• Goal of software project management:
• enable a group of engineers to work efficiently towards successful
completion of a software project.

Introduction
• A project manager’s activities are varied.
• can be broadly classified into:
• Project planning
• Project monitoring and control activities.

Project Planning
•Once a project is found to be feasible,
• project managers undertake project planning.

Project Planning Activities
• Estimation:
• Effort, cost, resource, and project duration
• Project scheduling:
• Staff organization:
• staffing plans
• Risk handling:
• identification, analysis, and abatement procedures
• Miscellaneous plans:
• quality assurance plan, configuration management plan, etc.

Project planning
• Requires utmost care and attention.
• Commitments to unrealistic time and not proper estimation of resources
result in:
• Irritating delays.
• Customer dissatisfaction
• Adverse effect on team morale
• poor quality work
• Project failure.

Responsibility of Project Managers
• Project proposal writing
• Project cost estimation
• Scheduling
• Project staffing
• Project monitoring and control
• Software configuration management
• Risk management
• Managerial report writing and presentations

Sliding Window Planning
• Involves project planning over several stages:
• Protects managers from making big commitments too early.
• More information becomes available as the project progresses.
• Facilitates accurate planning

SPMP Document
• After planning is complete:
• Document the plans:
• in a Software Project Management Plan(SPMP) document.

Organization of SPMP Document
• Introduction (Objectives, Major Functions, Performance Issues, Management and Technical Constraints)
• Project Estimates (Historical Data, Estimation Techniques, Effort, Cost, and Project Duration Estimates)
• Project Resources Plan(People, Hardware and Software, Special Resources)
• Schedules (Work Breakdown Structure, Task Network, Gantt Chart Representation, PERT Chart Representation)
• Risk Management Plan (Risk Analysis, Risk Identification, Risk Estimation, Abatement Procedures)
• Project Tracking and Control Plan
• Miscellaneous Plans (Process Tailoring, Quality Assurance)

Software Cost Estimation
• Determine size of the product.
• From the size estimate,
• determine the effort needed.
• From the effort estimate,
• determine project duration, and cost.

Size
Estimation
Effort
Estimation
Cost
Estimation
Duration
Estimation
Staffing
Estimation
Scheduling

Software Size Metrics
• LOC (Lines of Code):
• Simplest and most widely used metric.
• Comments and blank lines should not be counted.

Disadvantages of Using LOC
• Size can vary with coding style.
• Focuses on coding activity alone.
• Correlates poorly with the quality and efficiency of code.
• Penalizes higher-level programming languages, code reuse, etc.

Disadvantages of Using LOC (cont...)
• Measures lexical/textual complexity only.
• does not address the issues of structural or logical
complexity.
• Difficult to estimate LOC from problem description.
• So not useful for project planning

Function Point Metric
• Overcomes some of the shortcomings of the LOC metric.
• Proposed by Albrecht in early 80's:
• FPs measure software size.
• It is widely accepted as an industry standard for functional sizing.

• Input:
• A set of related inputs is counted as one input.
• Output:
• A set of related outputs is counted as one output.
• Inquiries:
• Each user query type is counted.
• Files:
• Files are logically related data and thus can be data structures or physical files.
• Interface:
• Data transfer to other systems.

Function Point Metric Calculation (
FP =UFP * CAF
• FP- Function Point
• UAF- Unadjusted Function Point
• CAF- Complexity Adjustment Factor

•Step 1-: Calculate Unadjusted Function Point (UFP)
Dr. Kalka Dubey Assistantt Professor RGIPT Jais Amethi
unction Units Low Avg High
EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10
21

•Step-2: calculate the Complexity Adjustment Factor (CAF)
CAF = 0.65 + ( 0.01 * F )

• Step-3:
F = 14 * scale
• Scale varies from 0 to 5 according to Complexity Adjustment Factor
(CAF) characteristics.
0 - No Influence
1 - Incidental
2 – Moderate
3 - Average
4 – Significant
5 - Essential

•Step-4: Calculate Function Point
FP = UFP * CAF

Example 1
Given the following values, compute the function point when
complexity weighting factors for I, O, E, F and N are high. It is
also given that, out of fourteen value adjustment factors that
influence the development effort are Moderate.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4

Function Point Metric Calculation
• Solution:
FP = UAF * CAF
UAF = 50 * 6 + 40 * 7 + 35 * 6 + 06 * 15 + 04 * 10 = 920

• Solution:
F= 14*Scale
F= 14*2
F= 28
CAF= .65 +.01*F
CAF = .65+.01*28
CAF= .93

• Solution:
FP = UAF * CAF
FP= 920 * .93
FP= 855.6

Example 2
• Consider a software project with the following information domain characteristics for the
calculation of function point metric.
• Number of external inputs (I) = 30
• Number of external outputs (O) = 60
• Number of external inquiries (E) = 23
• Number of files (F) = 08
• Number of external interfaces (N) = 02
• It is given that the complexity weighting factors for I, O, E, F and N are 4, 5, 4, 10 and 7,
respectively. It is also given that, out of fourteen value adjustment factors that influence the
development effort, four factors are not applicable, each of the other four factors have value 3,
and each of the remaining factors have value 4. The computed value of function point metric is ?

• Solution:
FP = UAF * CAF
UAF = 30 * 4 + 60 * 5 + 23 * 4 + 08 * 10 + 02 * 7 = 606

F= 14*Scale
F = [4*0+ 4 * 3 + 6 * 4]
F= 36
CAF= .65 + .01*36
CAF = 1.01
• So, FP = 606 * 1.01 = 612.06

Function Point Metric(CONT.)
•Suffers from a major drawback:
• the size of a function is considered to be independent of its
complexity.
•Extend function point metric:
• Feature Point metric:
• considers an extra parameter:
• Algorithm Complexity.

Staffing and Personnel Planning

Halstead's Software Science
•An analytical technique to estimate:
• Size
• Development effort
• Development time

• Halstead’s Software metrics are a set of measures proposed by Maurice Halstead to evaluate the complexity
of a software program
• Halstead used a few primitive program parameters
• number of operators and operands
• Derived expressions for:
• Overall program length (N)
• Vocabulary size (n)
• Program volume (V)
• Language level (L)
• Program Difficulty (D)
• Effort (E)

• Overall, Halstead’s software metrics can be a useful tool for software
developers and project managers to estimate the effort required to develop and
maintain software programs.
n1 = Number of distinct operators.
n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.

• Halstead Program Length: The total number of operator occurrences and the
total number of operand occurrences.
N = N1 + N2
• Halstead Vocabulary: The total number of unique operators and unique
operand occurrences.
n = n1 + n2

• Halstead Estimated Program Length: Estimated program length is denoted
by N^.
N^ = n1log2n1 + n2log2n2

• Program Volume: Proportional to program size, represents the size, in bits, of
space necessary for storing the program.
• This parameter is dependent on specific algorithm implementation.
• The properties V, N, and the number of lines in the code are shown to be
linearly connected and equally valid for measuring relative program size.
V = N * log2(n)

• Potential Minimum Volume: The potential minimum volume V* is defined
as the volume of the shortest program in which a problem can be coded.
V* = (2 + n2*) * log2 (2 + n2*)
Here, n2* is the count of unique input and output parameters

• Program Level: To rank the programming languages, the level of abstraction
provided by the programming language, Program Level (L) is considered.
• The higher the level of a language, the less effort it takes to develop a program
using that language.
L = V* /V

• Program Difficulty: This parameter shows how difficult to handle the
program is.
D = 1 / L

• Programming Effort: Measures the amount of mental activity needed to
translate the existing algorithm into implementation in the specified program
language.
E = V / L = D * V = Difficulty * Volume

Example 1: Obtain Halstead’s length and volume measure for a C function
which has 5 operators with the occurrence of 16 and 9 operands with the
occurrence of 21.

Solution: N = N1 + N2
N = 16 +21 = 37
N = 37
n = n1 + n2
n= 5 + 9 = 14
n = 14
Estimated length = n1 log n1 + n2 log n2
= 5 log 5 + 9 log 9
= 5 * 2.32 + 9 * 3.17 = 39.5
Estimated length = 39.5
Volume = N * log n
= 37 * log (14)
=37 * 3.807
= 140.85
Volume (V) = 140.85

Example 2: Obtain Halstead’s length, volume, difficulty, level, and
Programming Effort measure for a C function which has 14 operators with the
occurrence of 53 whereas 10 operands with have the occurrence of 38. The
number of unique input and output is 3.

Solution: N = N1 + N2
N = 53 +38 = 91
N = 91
n = n1 + n2
n= 14 + 10 = 24
n = 24
Estimated length = n1 log n1 + n2 log n2
= 14log 14 + 10 log 10
= 14 * 3.8 + 10 * 3.3 = 83.5
Estimated length = 83.5
Volume = N * log n
= 91 * log (24)
=91 * 4.584
= 417.1
Volume (V) = 417.1

Solution:
Potential Minimum Volume V* = (2 + n2*) * log2 (2 + n2*)
=(2+3) * log2 (2 + 3)
= 5*log 2(5)
=5*2.32
Potential Minimum Volume V* = 11.6
Program Level L = V* /V
= 11.6/417.1
Program Level L= .027

Solution:
Program Difficulty D = 1 / L
D= 1/0.027
Program Difficulty D= 37.03
Programming Effort E = D *V
E= 37.03 * 417
Programming Effort E= 15441

Norden Staffing Level Estimation
• Number of personnel required during any development project:
• not constant.
• Norden in 1958 analysed many R&D projects and observed:
• Rayleigh curve represents the number of full-time personnel required at
any time.

Rayleigh Curve
• Rayleigh curve is specified
by two parameters:
• td the time at which the curve
reaches its maximum
• K the total area under the
curve.
L=f(K, td)
Effort
Time
td
Rayleigh Curve

Rayleigh Curve
• Very small number of engineers are needed at the beginning of a project
• carry out planning and specification.
• As the project progresses:
• more detailed work is required,
• number of engineers slowly increases and reaches a peak.

Rayleigh Curve
•Putnam observed that:
• the time at which the Rayleigh curve reaches its maximum
value
• corresponds to system testing and product release.
• After system testing,
• the number of project staff falls till product installation and delivery.

Rayleigh Curve
• From the Rayleigh curve observe that:
• approximately 40% of the area under the Rayleigh curve is to the left of
td
• and 60% to the right.

Putnam’s Work:
• In 1976, Putnam studied the problem of staffing of software projects:
• observed that the level of effort required in software development
efforts has a similar envelope.
• found that the Rayleigh-Norden curve
• relates the number of delivered lines of code to effort and
development time.

Putnam’s Work
• Putnam analyzed a large number of army projects, and derived the expression:
L= 𝑪𝒌 ∗ 𝑲
𝟏
𝟑 ∗ 𝒕𝒅
𝟒
𝟑
• L is the size in KLOC.
• K is the effort.
• td is the time to develop the software.
• Ck is the state of technology constant that reflects factors that affect
programmer productivity.

Putnam’s Work
• Ck=2 for poor development environment
• no methodology, poor documentation, and review, etc.
• Ck=8 for good software development environment
• software engineering principles used
• Ck=11 for an excellent environment

Effect of Schedule Change on Cost
• Using the Putnam's expression for L,
K=
𝐿3
𝐶𝑘3𝑡𝑑4
K=C1/𝑡𝑑4
• For the same product size, C1=
𝐿3
𝐶𝑘3 is a constant.

Effect of Schedule Change on Cost(CONT.)
• Putnam model indicates extreme penalty for schedule compression
• and extreme reward for expanding the schedule.
• Putnam estimation model works reasonably well for very large systems,
• but seriously overestimates the effort for medium and small systems.

Example
• If the estimated development time is 1 year, then in order to develop the
product in 6 months,
• The Efforts increased by 16 times.
• In other words,
• the relationship between effort and the chronological delivery time is
highly nonlinear.

•Boehm observed:
• “There is a limit beyond which the schedule of a software
project cannot be reduced by buying any more personnel
or equipment.”
• This limit occurs roughly at 75% of the nominal time
estimate.

• Example 1: If a project manager receives a project that has a completion
time of 01 year with 100 people whereas the customer demands to
compress the development time to 07 months. Is it possible to complete the
above project? If possible calculate the extra person needed to complete the
project in 07 month duration.

• Solution: No it is not possible to complete it on 07 Month. The maximum
duration at which the project is completed is 09 Month (25%) due to:
• every project has only a limited amount of parallel activities.
• sequential activities cannot be speeded up by hiring any number of
additional engineers.
• many engineers have to sit idle.

• Solution:
Effort = 1/ td^4
= 1/ (3/4)^4
= 256/81
=3.16

Jensen Model
• Jensen model is very similar to Putnam model.
• Attempts to soften the effect of schedule compression on effort.
• Makes it applicable to smaller and medium-sized projects.

Jensen Model
•Jensen proposed the equation:
L=Cte * td *𝐾1/2
• Where,
• Cte is the effective technology constant,
• td is the time to develop the software, and
• K is the effort needed to develop the software.

Jensen Model
•Jensen proposed the equation:
L=Cte * td *𝐾1/2
K= L^2 / Cte^2 *td^2

Organization Structure
•Functional Organization:
• Engineers are organized into functional groups, e.g.
• specification, design, coding, testing, maintenance, etc.
• Engineers from functional groups get assigned to different
projects

Advantages of Functional Organization
•Specialization
•Ease of staffing
•Good documentation is produced
• different phases are carried out by different teams of engineers.
•Helps identify errors earlier.

Project Organization
•Engineers get assigned to a project for the entire duration
of the project
• The same set of engineers carries out all the phases.
•Advantages:
• Engineers save time by learning the details of every project.
• Leads to job rotation.

Team Structure
• Problems of different complexities and sizes require different team structures:
• Chief-programmer team
• Democratic team
• Mixed organization

Chief Programmer Team
• A senior engineer provides technical leadership:
• partitions the task among the team members.
• verifies and integrates the products developed by the members.

Chief Programmer team

•Works well when
• the task is well understood
• also within the intellectual grasp of a single individual,
• importance of early completion outweighs other factors
• team morale, personal development, etc.

•Chief programmer team is subject to single-point failure:
• too much responsibility and authority are assigned to the chief
programmer.

Democratic Teams
• Suitable for:
• small projects requiring less than five or six engineers
• research-oriented projects
• A manager provides administrative leadership:
• at different times different members of the group provide technical
leadership.

Democratic Teams
Democratic Team

Democratic Teams
• Democratic organization provides
• higher morale and job satisfaction for the engineers
• therefore leads to less employee turnover.
• Suitable for less understood problems,
• a group of engineers can invent better solutions than a single individual.

Democratic Teams
• Disadvantage:
• team members may waste a lot time arguing about trivial points:
• absence of any authority in the team.

Mixed Control Team Organization
• Draws upon ideas from both:
• democratic organization and
• chief-programmer team organization.
• Communication is limited
• to a small group that is most likely to benefit from it.
• Suitable for large organizations.

Mixed team organization

Summary
• Project teams can be organized in following ways:
• Chief programmer: suitable for routine work.
• Democratic: Small teams doing R&D type work
• Mixed: Large projects

Cost Estimation

•Three main approaches to estimation:
•Empirical
•Heuristic
•Analytical

Empirical Size Estimation Techniques
•An educated guess based on past experience
•Expert Judgement:
•Delphi Estimation:

Expert Judgement
• Experts divide a software product into component
units:
• e.g. GUI, database module, data communication module,
billing module, etc.
• Add up the guesses for each of the components.

Delphi Estimation:
•Team of Experts and a coordinator.
•Experts carry out estimation independently:
• mention the rationale behind their estimation.
• coordinator notes down any extraordinary rationale:
• circulates among experts.

Delphi Estimation:
•Experts re-estimate.
•Experts never meet each other
• to discuss their viewpoints.

Heuristic Estimation Techniques
• The characteristics to be estimated can be expressed in terms of
some mathematical expression.
• Single Variable Model:
• Parameter to be Estimated=C1(Estimated Characteristic)d1
• Multivariable Model:
• Assumes that the parameter to be estimated depends on more than
one characteristic.
• Parameter to be Estimated=C1(Estimated Characteristic)d1+ C2(Estimated
Characteristic)d2+…
• Usually more accurate than single variable models.

Analytical techniques
• Derive the required results starting from certain simple assumptions.

COCOMO Model
•COCOMO (COnstructive COst MOdel) proposed by
Boehm in 1981.
•The key parameters that define the quality of any software
products, which are also an outcome of the Cocomo are
primarily:
 Effort
 Schedule

COCOMO Model(CONT.)
• For each of the three product categories:
• From size estimation (in KLOC), Boehm provides equations to predict:
• project duration in months
• effort in programmer-months
• Boehm obtained these equations:
• examined historical data collected from a large number of actual projects.

COCOMO Product classes
• Roughly correspond to:
• Application, Utility, and System programs respectively.
• Data processing and scientific programs are considered to be
application programs.
• Compilers, linkers, editors, etc., are utility programs.
• Operating systems and real-time system programs, etc. are system
programs.

Elaboration of Product classes
• Organic:
• Relatively small groups
• working to develop well-understood applications.
• Semidetached:
• Project team consists of a mixture of experienced and inexperienced staff.
• Embedded:
• The software is strongly coupled to complex hardware, or real-time systems.

• Example: Compute the function point, and , cost for the following
data:
• Number of user inputs = 24
• Number of user outputs = 46
• Number of inquiries = 8
• Number of files = 4
• Number of external interfaces = 2
• Cost per function = $700
• Effort = 36.9 p-m
• Average weighting factors are: 4, 4, 6, 10, 5

• Solution:
FP = UAF * CAF
UAF = 24 * 4 + 46 * 4 + 8 * 6 + 4 * 10 + 2 *5 = 378

CAF = 0.65 + [.01*F]
F= 14*Scale
F = 14*3
F= 42
CAF= .65 + .01*42
CAF = 1.07
• So, FP = 378* 1.07 = 404.78

Cost = Cost per function * Productivity
Productivity = FP/ Efforts
= 404.78/36.9
= 10.96
Cost = 700*10.96
Cost = 7672.68 $

COCOMO Model (CONT.)
• Software cost estimation is done through three stages:
• Basic COCOMO
• Intermediate COCOMO
• Complete COCOMO

Basic COCOMO Model(CONT.)
• Gives only an approximate estimation:
• Effort = a1 * (KLOC) * a2
• Tdev = b1 * (Effort) *b2
• KLOC is the estimated kilo lines of source code
• a1,a2,b1,b2 are constants for different categories of software products
• Tdev is the estimated time to develop the software in months
• Effort estimation is obtained in terms of person months (PMs).

Development Effort Estimation
• Organic :
• Effort = 2.4 (KLOC)1.05 PM
• Semi-detached:
• Effort = 3.0(KLOC)1.12 PM
• Embedded:
• Effort = 3.6 (KLOC)1.20PM

Development Time Estimation
• Organic:
• Tdev = 2.5 (Effort)0.38 Months
• Semi-detached:
• Embedded:

Example
• The size of an organic software product has been estimated to be 32,000 lines
of source code.
• Effort = 2.4*(32)1.05 = 91 PM
• Nominal development time = 2.5*(91)0.38 = 14 months

• Effort is somewhat
super-linear in
problem size.
Effort
Size

• Development time
• sublinear function of product
size.
• When product size increases
two times,
• development time does not
double.
• Time taken:
• almost same for all the three
product categories.
Size
Dev. Time
60K
18 Months
14 Months
30K

Basic COCOMO Model (CONT.)
• Development time does not increase linearly with product size:
• For larger products more parallel activities can be identified:
• can be carried out simultaneously by a number of engineers.

• Development time is roughly the same for all three categories of products:
• For example, a 60 KLOC program can be developed in approximately 18 months
• regardless of whether it is of organic, semi-detached, or embedded type.
• There is more scope for parallel activities for system and application programs than
utility programs.

Intermediate COCOMO
• Basic COCOMO model assumes
• effort and development time depend on product size alone.
• However, several parameters affect effort and development time:
• Reliability requirements
• Availability of CASE (Computer-aided software engineering) tools and modern facilities to
the developers
• Size of data to be handled

Intermediate COCOMO
• For accurate estimation,
• the effect of all relevant parameters must be considered:
• The intermediate COCOMO model recognizes this fact:
• refines the initial estimate obtained by the basic COCOMO by using
a set of 15 cost drivers (multipliers).

Intermediate COCOMO(CONT.)
• If modern programming practices are used,
• initial estimates are scaled downwards.
• If there are stringent reliability requirements on the product :
• initial estimate is scaled upwards.

• Rate different parameters on a scale of one to three:
• Depending on these ratings,
• Multiply cost driver values with the estimate obtained using the basic
COCOMO.

• Cost driver classes:
• Product: Inherent complexity of the product, reliability requirements of the product, etc.
• Computer: Execution time, storage requirements, etc.
• Personnel: Experience of personnel, etc.
• Development Environment: Sophistication of the tools used for software development.
• Other parameters: Meeting, proposal, etc.
* Reliability requirements are typically part of a technical specifications document. They
can be requirements that a company sets for its product and its own engineers or what it
reports as its reliability to its customers.*

Shortcoming of basic and intermediate COCOMO models
• Both models:
• consider a software product as a single homogeneous entity:
• However, most large systems are made up of several smaller sub-systems.
• Some sub-systems may be considered as organic type, some may be considered embedded, etc.
• for some the reliability requirements may be high, and so on.

Complete COCOMO
• Cost of each sub-system is estimated separately.
• Costs of the sub-systems are added to obtain the total cost.
• Reduces the margin of error in the final estimate.

Complete COCOMO Example
• A Management Information System (MIS) for an organization having
offices at several places across the country:
• Database part (semi-detached)
• Graphical User Interface (GUI) part (organic)
• Communication part (embedded)
• Costs of the components are estimated separately:
• summed up to give the overall cost of the system.

Project Scheduling

• Software Project Scheduling is an activity that distributes Estimated Effort
across the Planned Project Duration by allocating the Effort to a specific Software
Engineering Task.
• Project Scheduling establishes a “Road Map” for the Project Manager When
combined with Estimation Methods and Risk Analysis.
• Project Scheduling begins with Process Decompositions.
• The characteristics of the Project are used to adapt an appropriate task set for the
Work to be done.
Project Scheduling

Project Scheduling
• A software project manager needs to do the following
• Identify all the major activities that need to be carried out to complete the
project.
• Break down each activity into tasks.
• Determine the dependency among different tasks.
• Establish the estimates for the time durations necessary to complete the
tasks.

Activity Network
• Represent the information in the form of an activity network.
• Determine task starting and ending dates from the information
represented in the activity network.
• Determine the critical path.
• Allocate resources to tasks.

• A Task Network depicts each engineering task, its dependency on other tasks and
its projected duration.
• The Task Network is used to compute the Critical Path, a Timeline Chart, and a
variety of project information.
• Using the Project Schedule as a guide, the Project Manager can track and control
each step in the Software process.
Task Network

Task Network

Project Scheduling Methods
• Scheduling tools and techniques can be applied with little modification for
Software Projects.
• PERT (Program (Project) Evaluation and Review Technique)
• CPM (Critical Path Method)
• These are two most useful Project Scheduling Methods that can be applied
to Software development.

NETWORK TECHNIQUES
PERT CPM
-Program Evaluation and
Review Technique
- Developed by the US
Navy on the Polaris
Missile/Submarine
program 1958.
-Critical Path Method
-Developed by El Dupont
for Chemical Plant
Shutdown program.
Both use same calculations, almost similar
Main difference is probabilistic and deterministic in time
estimation

• Helpful in Scheduling and Planning.
• Inter-Relationship of various activities.
• Cost Control.
• Minimization of Maintenance.
• Reduction of time.
• Control on Idle Resources.
• Avoiding Delays , interruptions.
Objective Of Project Scheduling

1)Helpful in planning : Network analysis is powerful tool for planning ,
scheduling and controlling.
2)Inter-Relationship of various activities: Network analysis creates inter-
relationship and inter dependence of various activities of project or a
programme.
3)Cost Control : In certain cases we can measure cost of delay in the
completion of the project. This cost can be compared to the cost of the
resources required to carry out various activities at various speed.
Objective Of Networking

4)Minimization of Maintenance: Network analysis helps the management to
minimize the total maintenance time.
5)Reduction of time: Sometime we have to arrange existing resources with a
view to reducing the total time for the project , rather than reducing cost.
6)Control on Idle Resources: Network analysis also helps to control the idle
resources. We should not allow large fluctuation in the use of limited
resources .We adhere to our scheduled cost and time.

7)Avoiding Delays , interruptions : Network analysis develops discipline
and systematic approach in planning scheduling etc. this not the case in
traditional methods . It helps managers to avoid delays.

128
Pert Chart
• One of the most difficult and most error prone activities when constructing a Project Schedule is the
determination of the TIME DURATION for each task within a Work Breakdown Structure (WBS),
especially when there is a high degree of complexity and uncertainty about a task.
• PERT is a technique used to calculate the Expected Duration for tasks.
• PERT is a technique that uses Estimates for:
• Optimistic time (O),
• Pessimistic time (P)
• Realistic Time (R)
• To calculate the EXPECTED DURATION (ED) of a particular task.

129
Program Evaluation Review Technique (Pert)
• The Optimistic time (O) and Pessimistic time (P) reflects the minimum and
maximum possible periods of time for an activity to be completed.
• The Realistic time (R) or the Most likely time, reflects the Project Manager’s “Best
Guess” of the amount of time required for task completion.

130
• Calculating Expected Completion Time (Et)
ED = [O + (4* R) + P] / 6
• Expected Duration should be closer to the Realistic Time (R).
• It is typically weighed Four times more than the Optimistic time (O) and the Pessimistic
time (P).
Program Evaluation Review Technique (Pert)

131
How To Construct A Pert Chart
• Developing a network diagram is a four-step process:-
1. Identify each Project Task to be completed
2. Determine Time Estimates and calculate the Expected Duration for each Activity
3. For each Task, identify the immediate Predecessor Tasks
4. Enter the Task with connecting Arrows based on Dependencies and calculate Start and end times
based on Duration and Resources.

Merits of PERT
Expected project completion time.
Probability of completion before a specified date.
The critical path activities that directly impact the completion time.
It permits more effective planning and control.
It enables the use of statistical analysis.

It does not lay any emphasis on the cost of a project.
It lays emphasis only on time.
It does not help in the routine planning of recurring events.
Demerits of PERT

• The Critical Path method is a technique used in Software Engineering to
map out the best order of execution of project activities in order to
complete the project in the least amount of time.
• It is a sequence of connected activities that lead from the beginning of the
project to the end of the project.
• The longest path in the network is called the Critical Path.
Critical Path Method(CPM):

• Specify the Individual Activities.
• Determine the Sequence of the Activities.
• Draw the Network Diagram.
• Estimate Activity Completion Time.
• Identify the Critical Path.
Steps in CPM Project Planning

1)Specify the Individual Activities : From the work break down structure , a listing can
be made of all the activities in the project.
• This listing can be used as the basis for adding sequence and duration information in
later steps.
2)Determine the Sequence of the Activities: Some activities are dependent on the
completion of others.

3)Draw the Network Diagram: Once the activities and their sequencing
have been defined, the CPM diagram can be drawn.
4)Estimate Activity Completion Time : The time required to complete
each activity can be estimated using past experience or the estimates of
knowledgeable persons.
5)Identify the Critical Path

Determine below five parameters of each activity of the network.
 1. Earliest start time (ES) = Max (EF of predecessor nodes).
 2. Earliest finish time (EF) = ES + D

 3. Latest finish time (LF) - The latest time an activity can finish without
delaying the project.
 For the final task LF = EF
 For the remaining task LF = min (LS of the successor nodes)
 4. Latest start time LS=LF−D
 5. Slack or Float Time (SL)=LF−EF

• float/slack activity is actually the difference between an activity’s
Earliest start and its latest start date or the difference between the
activity’s Earliest finish and its latest finish date.
• It indicates how much the activity can be delayed without delaying
the completion of the whole project.
• If the float/slack of activity is zero, then the activity is a critical activity
and must be added to the critical path of the project network.

Activity Precedents
Duration (in weeks)
A
- 5
B A 4
C A 5
D B 6
E C 3
F D, E 4
Example 1: Do a CPM Analysis and Identify the critical path of the following activity.

Example

 Found two paths from start to finish. These are:
A → C → E → F
A → B → D → F
 For the first path (A → C → E → F), the total float/slack time is 4 (0 + 2 + 2 + 0).
 For the second path (A → B → D → F), the total float/slack time is 0 (0 + 0 + 0 + 0).
 The critical path for the project is:
A → B → D → F
Example

Activity Duration (in weeks) Precedents
A 6 –
B 4 –
C 3 A
D 4 B
E 3 B
F 10 –
G 3 E,F
H 2 C,D
Example 2: Do a CPM Analysis and Identify the critical path of the following activity.

Disadvantages of CPM
• CPM’s can be complicated , and complexity increases for larger projects.
• Does not handle the scheduling of personnel or the allocation of resources.
• The critical path is not always clear and needs to be calculated carefully.
• Estimating activity completion times can be difficult.

Comparison Between CPM and PERT
PERT CPM
1 It is a probabilistic model. It is a deterministic model.
2 In PERT estimates are uncertain and we talk of ranges
of duration and the probability that an activity duration
will fall into that range.
In CPM estimates of activity duration are based on
historical data.
3 It is known for non- repetitive jobs like research and
development programmes.
It is used for repetitive jobs like residential construction.
4 It does not deal with the concept of crashing. It deals with concept of crashing.
5 Example: Involving new activities or products,
research and development
Example: construction projects, building one off
machines, ships, etc
150

Software Configuration and Quality Management

Introduction
• Traditional definition of quality:
• Fitness of purpose:
• A quality product does exactly what the users want it to do.
• Fitness of purpose for software products:
• Satisfaction of the requirements specified in the SRS document.

Fitness of Purpose
•A satisfactory definition of quality for many
products:
• A car, a table fan, a food mixer, microwave oven, etc.
•But, not satisfactory for software products.
• Why?

Quality for Software Products
•Consider a software product:
•Functionally correct:
• Performs all functions as specified in the SRS document.
•But, has an almost unusable user interface.
• Cannot be considered as a quality product.

Modern View of Quality
• Several quality factors are associated with a software product
• Correctness
• Reliability
• Efficiency (includes efficiency of resource utilization)
• Portability
• Usability
• Reusability
• Maintainability

Correctness
•A software product is correct:
•If different requirements as specified in the SRS
document have been correctly implemented.
•Results are accurate.

Portability
•A software product is said to be portable:
•If it can be easily made to work
•In different operating systems.
•In different machines,
•With other software products, etc.

Reusability
•A software product has good reusability:
•If different modules of the product can easily be
reused to develop new products.

Usability
•A software product has good usability:
•If different categories of users (i.e. both expert and
novice users) can easily invoke the functions of the
product.

Maintainability
• A software product is maintainable:
• If errors can be easily corrected as and when they show up.
• New functions can be easily added to the product
• The functionalities of the product can be easily modified.

Software Quality Management System
• Quality management system (or quality system):
• Principal methodology used by organizations to ensure that the products
have desired quality.
• A quality system consists of the following:
Managerial Structure
Individual Responsibilities.
Responsibility of the organization as a whole.

Quality System
• Every quality conscious organization has an independent quality
department:
Performs several quality system activities.
Needs support of top management.
Without support at a high level in a company:
Many employees may not take the quality system seriously.

Quality System Activities
• Auditing of projects
• Development of:
• standards, procedures, and guidelines.
• Production of reports for the top management:
• Summarizing the effectiveness of the quality system in the
organization.
• Review of the quality system itself.

Good Quality System
• A good quality system must be well documented.
• Without a properly documented quality system,
• Application of quality procedures become ad hoc
• Results in large variations in the quality of the products
delivered.

Good Quality System
• An undocumented quality system:
• Sends clear messages to the staff about the attitude of the
organization towards quality assurance.
•International standards such as ISO 9000 provide:
• Guidance on how to organize a quality system.

Evolution of Quality Systems
• Quality systems have evolved:
• Over the last six decades.
• Prior to World War II:
• Accepted way to produce quality products:
• Inspect the finished products
• Eliminate defective products.

ISO 9000
•ISO (International Standards Organization):
• a consortium of 63 countries established to formulate and foster
standardization.
•ISO published its 9000 series of standards in 1987.

What is ISO 9000 Certification?
•ISO 9000 specifies:
• Guidelines for repeatable and high-quality product
development.
• Also addresses organizational aspects.
• Responsibilities, reporting, procedures, processes, and resources for
implementing quality management.

What is ISO 9000 Certification?
•ISO 9000 Certification:
•Serves as a reference for contracts between independent
parties.
•The ISO 9000 standard:
•Specifies guidelines for maintaining a quality system.

ISO 9000
•A set of guidelines for the production process.
•Not directly concerned about the product itself.
•A series of three standards:
• ISO 9001
• ISO 9002
• ISO 9003.

ISO 9001
•Applies to:
•Organizations engaged in design, development,
production, and servicing of goods.
•Applicable to most software development
organizations.

ISO 9002
• ISO 9002 applies to:
• Organizations who do not design products:
• but are only involved in production.
• Examples of this category of industries:
• Steel or car manufacturing industries
• Buy the product and plant designs from external sources:
• only manufacture products.
• Not applicable to software development organizations.

ISO 9003
•ISO 9003 applies to:
•Organizations involved only in installation and testing
of the products.

ISO 9000 for Software Industry
• ISO 9000 is a generic standard:
• Applicable to many industries,
• Starting from a steel manufacturing industry to a service rendering company.
• Many clauses of ISO 9000 documents:
• Use generic terminologies
• Very difficult to interpret them in the context of software organizations.

ISO 9000 Part-3
•ISO released a separate document called ISO 9000 part-3
in 1991:
• To help interpret the ISO standard for software industry.
•At present:
• Official guidance is inadequate.

ISO 9000: 2000
• ISO 9001:2000:
• Combines the three standards 9001, 9002, and 9003 into one.
• Design and development procedures are required:
• Only if a company does in fact engage in the creation of new products.
• The 2000 version sought to make a radical change in thinking:
• By actually highlighting the concept of process management.

ISO 9000: 2000
•Another goal is to improve effectiveness via process
performance metrics:
• Numerical measurement of the effectiveness of tasks and
activities.
• Continual process improvement and tracking customer
satisfaction were made explicit.

Why Get ISO 9000 Certification?
• Several benefits:
• Confidence of customers in an organization increases.
• If the organization qualified for ISO 9001 certification.
• This is especially true in the international market.
• Many international software development contracts insist that
development organization have ISO 9000 certification

How to Get ISO 9000 Certification?
• An organization intending to obtain ISO 9000 certification:
• Applies to a ISO 9000 registrar for registration.
• ISO 9000 registration process consists of several stages.
• Application stage
• Pre-assessment
• Document review and adequacy audit
• Compliance audit
• Registration
• Continued surveillance

End of Unit III

THANKS…..

Project Planning Software Engineering unit-3

More Related Content

Similar to Project Planning Software Engineering unit-3 (20)

Recently uploaded (20)

Project Planning Software Engineering unit-3