Computer Network tutorial provides basic and advanced concepts of Data Communication & Networks (DCN). Our Computer Networking Tutorial is designed for beginners and professionals. Our Computer Network tutorial includes all topics of Computer Network such as introduction, features, types of computer network, architecture, hardware, software, internet, intranet, website, LAN, WAN, etc. What is Computer Network? A computer network is a set of devices connected through links. A node can be computer, printer, or any other device capable of sending or receiving the data. The links connecting the nodes are known as communication channels. Computer Network uses distributed processing in which task is divided among several computers. Instead, a single computer handles an entire task, each separate computer handles a subset. Following are the advantages of Distributed processing: Security: It provides limited interaction that a user can have with the entire system. For example, a bank allows the users to access their own accounts through an ATM without allowing them to access the bank's entire database. Faster problem solving: Multiple computers can solve the problem faster than a single machine working alone. Security through redundancy: Multiple computers running the same program at the same time can

1. SOFTWARE ENGINEERING
18BTCECC503
Prof. Nisha Vadodariya
Assistant Professor
CE Department
ATMIYA - Rajkot
UNIT 5-
SOFTWARE PROJECT AND RISK
MANAGEMENT

2. SOFTWARE METRICS DATA TYPES
● The standard of measure for the estimation of quality,
progress and health of the software testing effort is called
software metrics.
● A metric is a measurement of the level at which any impute
belongs to a system product or process.
● To determine (to define) quality of a product or process.
● To predict qualities of a product or process.
● To improve quality of a product or process.
● There are 4 functions related to software metrics:
Planning, Organizing, Controlling, Improving
● It can be divided into three groups:
1. product metrics,
2. process metrics, and
3. project metrics.

3. 1. Product Metrics
● The product characteristics like size, features of the design,
complexity, performance, level of quality, etc., is described
using product metrics.
● The characteristics of the software product are measured
using product metrics.
Some of the important characteristics of the software are:
1. Software size and complexity
2. Software reliability and quality

4. 2. Process metrics
● In contrast, software development and maintenance are
improved using process metrics.
● Process metrics are used to measure the characteristics
of the process of software development.
● The example includes the efficiency of detection of fault
etc.
● The characteristics of the methods, tools, and
techniques used for software development can be
measured using process metrics

5. 3. Project metrics
● The project’s characteristics and execution are described by
project metrics whose examples include the count of software
developers, cost, etc.
● The progress of the project is checked by the project manager
using the metrics called project metrics.
● Various metrics such as time, cost, etc., are collected by using
the data from the projects in the past, and they are used as an
estimate for the new software.
● The project manager checks the progress of the project from
time to time, and effort, time and cost are compared with the
original effort, time and cost.
● The cost of development, efforts, risks and time can be reduced
by using these metrics.
● The quality of the project can also be improved.
● With the increase in quality, there is a reduction in the number of
errors, time, cost, etc.

6. Advantages of Software Metrics :
1. Reduction in cost or budget.
2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product.
6. It helps to determine the complexity of the code and to test
the code with resources.
7. It helps in providing effective planning, controlling and
managing of the entire product.

7. Disadvantages of Software Metrics :
1. It is expensive and difficult to implement the metrics in some
cases.
2. Performance of the entire team or an individual from the
team can’t be determined. Only the performance of the
product is determined.
3. Sometimes the quality of the product is not met with the
expectation.
4. It leads to measure the unwanted data which is wastage of
time.
5. Measuring the incorrect data leads to make wrong decision
making.

8. SOFTWARE PROJECT PLANNING
Once a project is found to be possible, computer code project managers undertake
project designing.
Project designing is undertaken and completed even before any development
activity starts.
Estimating the subsequent attributes of the project:
● Project size:
What’s going to be downside quality in terms of the trouble and time needed
to develop the product?
● Cost:
What proportion is it reaching to value to develop the project?
● Duration:
However long is it reaching to want complete development?
● Effort:
What proportion effort would be required?

9. A Software Project is the complete methodology of programming advancement
from requirement gathering to testing and support, completed by the execution
procedures, in a specified period to achieve intended software product.
Need of Software Project Management
● Most programming items are customized to accommodate customer's
necessities.
● The most significant is that the underlying technology changes and
advances so generally and rapidly that experience of one element may not
be connected to the other one.
● There are three needs for software project management. These are:
1. Time
2. Cost
3. Quality
● It is a procedure of managing, allocating and timing resources to develop
computer software that fulfills requirements.

10. Activities:
Software Project Management consists of many activities, that includes
planning of the project, deciding the scope of product, estimation of cost in
different terms, scheduling of tasks, etc.
The list of activities are as follows:
1. Project planning and Tracking
2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management

11. Software Project Manager
Software manager is responsible for planning and scheduling project
development.
They manage the work to ensure that it is completed to the required standard.
They monitor the progress to check that the event is on time and within budget.
The project planning must incorporate the major issues like size & cost estimation
scheduling, project monitoring, personnel selection evaluation & risk management.
To plan a successful software project, we must understand:
● Scope of work to be completed
● Risk analysis
● The resources mandatory
● The project to be accomplished
● Record of being followed

12. Software Project planning starts before technical work start. The various steps of
planning activities are:
The size is the crucial parameter for the estimation of other activities. Resources
requirement are required based on cost and development time. Project schedule
may prove to be very useful for controlling and monitoring the progress of the
project. This is dependent on resources & development time.

13. W5HH PRINCIPLE
● Barry Boehm gave a philosophy that prepares easy and
manageable designs or outlines for software projects.
● He also gave a technique to discuss objectives,
management, duties, and technical approach of the project
and its necessary resources.
● Then he named it the W5HH principle when few questions
resulted in project properties, definition, and resultant plan to
make the project successful.
● The W5HH principle in software management exists to help
project managers guide objectives, timelines,
responsibilities, management styles, and resources.
● Boehm’s W5HH principle is applicable regardless of the size
or complexity of a software project. The questions noted
provide an excellent planning outline for the project manager
and the software team.

14. The W5HH principle outlines a series of questions that can help
project managers more efficiently manage software projects.
Each letter in W5HH stands for a question in the series of
questions to help a project manager lead. (Notice there are five
”W” questions and two ”H” questions).
W5HH questions :
1. Why?
● Why the system is going to be developed?
● Enables all parties to assess the validity of business reasons
for the software work. In another words - does the business
purpose justify the expenditure of people, time, and money?
● This focuses a team on the business reasons for developing
the software.

15. 2. What?
● What is activities are needed to be done in this?
● In this Barry questions what task is needed to be done for a project
currently.
● This is the guiding principle in determining the tasks that need to be
completed.
3. When?
● When is this done?
● Project Scheduling is done by the team after recognizing when project
tasks will be started and when they enter into the final stage to reach
the goal.
● This includes the timeline for the project.

16. 4. Who?
● Who is responsible?
● Role and responsibility of each member
● This is where you determine which team member takes on which
responsibilities. You may also identify external stakeholders with a
claim in the project.
5. Where?
● Where are these authoritatively located?
● Not only do software practitioners have roles in this but also users,
customers, stakeholders also have roles and responsibilities
organizationally.
● This step gives you time to determine what other stakeholders have
a role in the project and where they are found.

17. 6. How Will?
● How will the job be done technically and managerially?
● Management and technical strategy must be defined
7. How much?
● How much of each resource is needed?
● Develop estimation
● The goal of this step is to figure out the number of resources
necessary to complete the project.

18. SOFTWARE PROJECT ESTIMATION
• Estimation of various project parameters is a basic
project planning activity.
• project size, effort required to develop the software,
project duration, and cost estimates help in resource
planning and scheduling.
Software Project Estimation Technique:
1. Project size Estimation
2. Problem based Estimation
3. Process based Estimation
4. Cost and efforts Estimation

19. 1. Project size Estimation
● Estimation of the size of the software is an essential part of
Software Project Management.
● It helps the project manager to further predict the effort and
time which will be needed to build the project.
● Various measures are used in project size estimation.
Some of these are:
1. Lines of Code
2. Number of entities in ER diagram
3. Total number of processes in detailed data flow diagram
4. Function points

20. 1. Lines of Code (LOC): As the name suggests, LOC count the total
number of lines of source code in a project. The units of LOC are:
● KLOC- Thousand lines of code
● NLOC- Non-comment lines of code
● KDSI- Thousands of delivered source instruction
Two separate source files having a similar number of lines may not require
the same effort. A file with complicated logic would take longer to create
than one with simple logic. Proper estimation may not be attainable based
on LOC.
The length of time it takes to solve an issue is measured in LOC. This
statistic will differ greatly from one programmer to the next. A seasoned
programmer can write the same logic in fewer lines than a newbie coder.

21. Advantages:
● Universally accepted and is used in many models like COCOMO.
● Estimation is closer to the developer’s perspective.
● Simple to use.
Disadvantages:
● Different programming languages contain a different number of
lines.
● No proper industry standard exists for this technique.
● It is difficult to estimate the size using this technique in the early
stages of the project.

22. 2. Number of entities in ER diagram: ER model provides a static view of
the project. It describes the entities and their relationships. The number of
entities in ER model can be used to measure the estimation of the size of
the project. The number of entities depends on the size of the project. This
is because more entities needed more classes/structures thus leading to
more coding.
Advantages:
● Size estimation can be done during the initial stages of planning.
● The number of entities is independent of the programming
technologies used.
Disadvantages:
● No fixed standards exist. Some entities contribute more project size
than others.
● Just like FPA, it is less used in the cost estimation model. Hence, it
must be converted to LOC.

23. 3. Total number of processes in detailed data flow diagram: Data Flow
Diagram(DFD) represents the functional view of software. The model
depicts the main processes/functions involved in software and the flow
of data between them. Utilization of the number of functions in DFD to
predict software size. Already existing processes of similar type are
studied and used to estimate the size of the process. Sum of the
estimated size of each process gives the final estimated size.
Advantages:
● It is independent of the programming language.
● Each major process can be decomposed into smaller processes.
This will increase the accuracy of estimation
Disadvantages:
● Studying similar kinds of processes to estimate size takes
additional time and effort.
● All software projects are not required for the construction of DFD.

24. 4. Function Point Analysis:
FPA provides a standardized method to functionally size the
software work product. This work product is the output of software
new development and improvement projects for subsequent
releases. It is the software that is relocated to the production
application at project implementation. It measures functionality
from the user’s point of view i.e. on the basis of what the user
requests and receives in return.
In this method, the number and type of functions supported by the
software are utilized to find FPC(function point count).
Function Point (FP) is an element of software development which
helps to approximate the cost of development early in the process.
It may measures functionality from user’s point of view.

25. Function /
Application
Internal
Logic Files
User /
Event
User /
Event
Other
Applicati
ons
external
inputs
(EIs)
external
outputs (EOs)
external
inquiries (EQs)
external interface
files (EIFs)

26. Counting Function Point (FP):
Step-1:
F = 14 * scale
Scale varies from 0 to 5 according to character of Complexity
Adjustment Factor (CAF). Below table shows scale:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
Step-2: Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + ( 0.01 * F )

27. Step-3: Calculate Unadjusted Function Point (UFP).
TABLE (Required)
Multiply each individual function point to corresponding values in TABLE.
Step-4: Calculate Function Point.
FP = UFP * CAF
Function Units Low Avg High
EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10

28. Example 1:
Given the following values, compute function point when all complexity
adjustment factor (CAF) and weighting factors are average.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Explanation:
Step-1: As complexity adjustment factor is average (given in question),
hence,
scale = 3.
● F = 14 * 3 = 42

29. Step-2:
CAF = 0.65 + ( 0.01 * 42 ) = 1.07
Step-3: As weighting factors are also average (given in question)
hence we will multiply each individual function point to
corresponding values in TABLE.
UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
Step-4:
Function Point = 628 * 1.07 = 671.96
This is the required answer.

30. FP = Count Total * [ 0.65 + 0.01 * ∑(Fi
) ]
Count Total is the sum of all FP entries
Fi (i=1 to 14) are complexity value adjustment factors (VAF).
• F1. Data Communication
• F2. Distributed Data Processing
• F3. Performance
• F4. Heavily Used Configuration
• F5. Transaction Role
• F6. Online Data Entry
• F7. End-User Efficiency
• F8. Online Update
• F9. Complex Processing
• F10. Reusability
• F11. Installation Ease
• F12. Operational Ease
• F13. Multiple Sites
• F14. Facilitate Change

31. EXAMPLE 2: Used Adjustment Factors and assumed values are,
F09. Complex internal processing = 3
F10. Code to be reusable = 2
F03. High performance = 4
F13. Multiple sites = 3
F02. Distributed processing = 5
Project Adjustment
Factor (VAF) = 17
FP = Count Total * [ 0.65 + 0.01 * ∑(Fi
) ]
FP = [50]* [0.65 + 0.01 * 17]
FP = [50]* [0.65 + 0.17]
FP = [50]* [0.82] = 41

32. 7
10
6
17
4
28
40
18
119
28
233
Value adjustment factors (VAF) = 32 given
FP = Count Total * [ 0.65 + 0.01 * ∑(Fi
) ]
= 233 * [ 0.65 + 0.01 * 32]
= 233 * 0.97 = 226.01
EXAMPLE 3: Study of requirement specification for a project has produced
following results
Need for 7 inputs, 10 outputs, 6 inquiries, 17 files and 4 external interfaces
Input and external interface function point attributes are of average
complexity and all other function points attributes are of low complexity
Determine adjusted function points assuming complexity adjustment value is
32.

33. 2. Cost and efforts Estimation
● Cost estimation simply means a technique that is used to find
out the cost estimates. The cost estimate is the financial
spend that is done on the efforts to develop and test software
in Software Engineering.
● Cost estimation models are some mathematical algorithms or
parametric equations that are used to estimate the cost of a
product or a project.
There are three broad categories of estimation techniques:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques

34. Empirical estimation techniques:
• Empirical estimation techniques are based on making an educated
guess of the project parameters.
• Although empirical estimation techniques are based on common
sense, different activities involved in estimation have been
formalized over the years.
• These techniques are usually based on the data that is collected
previously from a project and also based on some guesses, prior
experience with the development of similar types of projects, and
assumptions
• It uses the size of the software to estimate the effort.
• In this technique, an educated guess of project parameters is made.
Hence, these models are based on common sense.
Empirical estimation techniques are:
• Expert judgment technique
• Delphi cost estimation.

35. 1. Expert judgment technique:
• An expert makes an educated guess of the problem size after
analyzing the problem thoroughly.
• Usually, the expert estimates the cost of the different components of
the system and then combines them to arrive at the overall estimate.
• However, this technique is subject to human errors and individual
bias.
• Also, it is possible that the expert may overlook some factors
inadvertently. Further, an expert making an estimate may not have
experience and knowledge of all aspects of a project.
• For example, he may be conversant with the database and user
interface parts but may not be very knowledgeable about the
computer communication part.
Disadvantages:
Human error, considering not all factors and aspects of the project,
individual bias, more chances of failure.

36. 2. Delphi cost estimation:
● Delphi cost estimation approach tries to overcome some of the limitations of the expert judgment
approach.
● Delphi estimation is carried out by a team comprising of a group of experts and a coordinator.
● In this approach, the coordinator provides each estimator with a copy of the software requirements
specification (SRS) document and a form for recording his cost estimate.
● Estimators complete their individual estimates anonymously and submit to the coordinator.
● In their estimates, the estimators mention any unusual characteristic of the product which has influenced
his estimation.
● The coordinator prepares and distributes the summary of the responses of all the estimators, and includes
any unusual rationale noted by any of the estimators.
● Based on this summary, the estimators re-estimate. This process is iterated for several rounds.
● However, no discussion among the estimators is allowed during the entire estimation process.
● The idea behind this is that if any discussion is allowed among the estimators, then many estimators may
easily get influenced by the rationale of an estimator who may be more experienced or senior.
● After the completion of several iterations of estimations, the coordinator takes the responsibility of
compiling the results and preparing the final estimate.

37. Heuristic estimation techniques:
As techniques basically uses the concept of learning from the previous
project and estimate the cost. Although intuitively very similar to expertise
based techniques, heuristic estimation technique take a different angle. The
objective is to find a similar system produced earlier and through knowing how
the properties of the new system vary from the existing one.
Learning Oriented Techniques :
Two classes of different heuristic Estimation Techniques:
- single variable model
- multi variable model

38. Single Variable Estimation Models:
It provides a means to estimate the desired characteristics Of a problem,
using some previously estimated basic (independent) characteristic of
the software product such as its size.
A single variable estimator model takes the following form:
Estimated Parameter=c1*ed1
e= characteristic which already have been calculated.
c1 and d1 are constants- calculated from past projects.
COCOMO is one of this type of models example.

39. Multivariable Cost Estimation Model:
It has the following form
Estimated Resources=c1*e1d1+c2*e1d1+----
e1 and e2 are the basic independent characteristics of the software
already estimated.
c1, c2, d1, d2, are constants.
Multivariable Estimation Models are expected to give more accurate
estimate compared to the Single Variable Models, since a project
parameters is typically influenced by several independent parameters.
The independent parameters influence the dependent parameter to
different extents.

40. COCOMO MODEL
● Cocomo (Constructive Cost Model) is a regression model based on
LOC, i.e number of Lines of Code.
● It is a procedural cost estimate model for software projects and is
often used as a process of reliably predicting the various
parameters associated with making a project such as size, effort,
cost, time, and quality.
● Boehm proposed COCOMO (Constructive Cost Estimation Model) in
1981.
● COCOMO is one of the most generally used software estimation
models in the world.
● COCOMO predicts the efforts and schedule of a software product
based on the size of the software.

41. In COCOMO, projects are categorized into three types:
1. Organic:
A development project can be treated of the organic type, if the project
deals with developing a well-understood application program, the size of
the development team is reasonably small, and the team members are
experienced in developing similar methods of projects. Examples of this
type of projects are simple business systems, simple inventory
management systems, and data processing systems.
2. Semi-detached:
A development project can be treated with semi-detached type if the
development consists of a mixture of experienced and inexperienced
staff. Team members may have finite experience in related systems but
may be unfamiliar with some aspects of the order being
developed. Example of Semidetached system includes developing a new
operating system (OS), a Database Management System (DBMS), and
complex inventory management system

42. 3. Embedded:
A development project is treated to be of an embedded type, if the
software being developed is strongly coupled to complex hardware, or if
the stringent regulations on the operational method exist. For
Example: ATM, Air Traffic control.
According to Boehm, software cost estimation should be done through
three stages:
• Basic Model
• Intermediate Model
• Detailed Model

43. 1. Basic Model
The basic COCOMO model gives an approximate estimate of the
project parameters
Effort = a*(KLOC)b
PM
Time = c*(efforts)d
Months
PersonRequired = Effort / Time
• KLOC is the estimated size of the software product expressed in
Kilo Lines of Code
• a, b, c, d are constants for each category of software products,
• Time is the estimated time to develop the software, expressed in
months,
• Effort is the total effort required to develop the software product,
expressed in person months (PMs).

44. Estimation of development effort
• For the three classes of software products, the formulas for estimating the
effort based on the code size are shown below:
• Organic: Effort = 2.4(KLOC)1.05
PM
• Semi-detached: Effort = 3.0(KLOC)1.12
PM
• Embedded: Effort = 3.6(KLOC) 1.20
PM
Estimation of development time
• For the three classes of software products, the formulas for estimating the
development time based on the effort are given below:
• Organic: Time = 2.5(Effort)0.38
Months
• Semi-detached: Time = 2.5(Effort)0.35
Months
• Embedded: Time = 2.5(Effort)0.32
Months
Project a b c d
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

45. The values of a, b, c, d for different categories of products (i.e. organic,
semi-detached, and embedded) as given by Boehm
He derived the expressions by examining historical data collected from a large
number of actual projects
The effort estimation is expressed in units of person-months (PM)
An effort of 100 PM
does not imply that 100 persons should work for 1 month
does not imply that 1 person should be employed for 100 months
it denotes the area under the person-month curve (fig.)

46. Effort and the duration estimations obtained using the
COCOMO model are called as nominal effort estimate and
nominal duration estimate
The term nominal implies that
if anyone tries to complete the project in a time shorter than the
estimated duration, then the cost will increase drastically
But, if anyone completed the project over a longer period of
time than the estimated, then there is almost no decrease in the
estimated cost value

47. Example: Assume that the size of an organic type software product has
been estimated to be 32,000 lines of source code. Assume that the
average salary of software engineers be Rs. 15,000/- per month.
Determine the effort required to develop the software product and the
nominal development time
Effort = a*(KLOC)b
PM
= 2.4*(32)1.05
PM
= 91 PM
Time = c*(efforts)d
Months
= 2.5*(91)0.38
Months
= 14 Months
Cost required to develop the product = 14 x 15000
= Rs. 2,10,000/-

48. 2. Intermediate Model
● The basic Cocomo model considers that the effort is only a function
of the number of lines of code and some constants calculated
according to the various software systems.
● The intermediate COCOMO model recognizes these facts and refines
the initial estimates obtained through the basic COCOMO model by
using a set of 15 cost drivers based on various attributes of
software engineering.
● The basic Cocomo model assumes that the effort is only a function of
the number of lines of code and some constants evaluated according
to the different software systems.
● However, in reality, no system’s effort and schedule can be solely
calculated on the basis of Lines of Code.
● For that, various other factors such as reliability, experience,
Capability.
● These factors are known as Cost Drivers and the Intermediate Model
utilizes 15 such drivers for cost estimation.

49. Classification of Cost Drivers and their attributes:
(i) Product attributes -
• Required software reliability extent
• Size of the application database
• The complexity of the product
(ii) Hardware attributes -
• Run-time performance constraints(Execution Speed)
• Memory constraints
• The volatility of the virtual machine environment
• Required turn about time

50. (iii) Personnel attributes -
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
(iv) Project attributes -
• Use of software tools
• Application of software engineering methods
• Required development schedule

51. 2. Detailed Model
A major shortcoming of both the basic and intermediate
COCOMO models is that they consider a software product as a
single homogeneous entity
Most large systems are made up several smaller sub-systems
These sub-systems may have widely different characteristics
E.g., some sub-systems may be considered as organic type, some
semidetached, and some embedded
Also for some subsystems the reliability requirements may be high, for
some the development team might have no previous experience of similar
development etc.
The complete COCOMO model considers these differences in
characteristics of the subsystems and estimates the effort and
development time as the sum of the estimates for the individual
subsystems
The cost of each subsystem is estimated separately
This approach reduces the margin of error in the final estimate.

52. Analytical estimation techniques:
● An important feature of this technique, which helps to improve
accuracy, is that a whole job should be broken down into smaller
individual tasks.
● Derive the required results starting with basic assumptions regarding
the project.
● Analytical techniques do have scientific basis.
● Analytical estimation is a type of technique that is used to measure
work. In this technique, firstly the task is divided or broken down into
its basic component operations or elements for analyzing. Second, if
the standard time is available from some other source, then these
sources are applied to each element or component of work.
● Third, if there is no such time available, then the work is estimated
based on the experience of the work. In this technique, results are
derived by making certain basic assumptions about the project.
Hence, the analytical estimation technique has some scientific basis.
Halstead’s software science is based on an analytical estimation
model.

53. 3. Process based Estimation
This is one of the most commonly used technique
Identify the set of functions that the software needs to perform as
obtained from the project scope
Identify the series of framework activities that need to be performed for
each function
Estimate the effort (in person months) that will be required to
accomplish each software process activity for each function
Apply average labor rates (i.e., cost/unit effort) to the effort estimated
for each process activity
Compute the total cost and effort for each function and each framework
activity.
Compare the resulting values to those obtained by way of the LOC and
FP estimates
If both sets of estimates agree, then your numbers are highly reliable
Otherwise, conduct further investigation and analysis concerning the
function and activity breakdown

54. 4. Problem based Estimation
Compute an LOC or FP value for each function
Derive cost or effort estimates by applying the LOC or FP values
to your baseline productivity metrics
Ex., LOC/person-month or FP/person-month
Decompose the software into problem functions that can each be
estimated individually
Combine function estimates to produce an overall estimate for
the entire project

55. PROJECT SCHEDULING
Project-task scheduling is a significant project planning activity. It
comprises deciding which functions would be taken up when. To schedule
the project plan, a software project manager wants to do the following:
1. Identify all the functions required to complete the project.
2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to
complete the activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities
that decide the duration of the project.

56. Scheduling Principles
● Compartmentalization: The product and process must be decomposed into a manageable
number of activities and tasks
● Interdependency: Tasks that can be completed in parallel must be separated from those that
must completed serially
● Time Allocation: Every task has start and completion dates that take the task
interdependencies into account
● Effort Validation: Project manager must ensure that on any given day there are enough staff
members assigned to complete the tasks within the time estimated in the project plan
● Define Responsibilities: Every scheduled task needs to be assigned to a specific team
member
● Define Outcomes: Every task in the schedule needs to have a defined outcome (usually a work
product or deliverable)
● Defined Milestones: A milestone is accomplished when one or more work products from an
engg task have passed quality review

57. Scheduling methods
Two project scheduling methods that can be applied to software
development.
Program Evaluation and Review Technique (PERT)
Critical Path Method (CPM)
Both techniques are driven by information already developed in
earlier project planning activities:
estimates of effort
a decomposition of the product function
the selection of the appropriate process model and task set
decomposition of the tasks that are selected
Both PERT and CPM provide quantitative tools that allow you to:
Determine the critical path—the chain of tasks that determines the
duration of the project
Establish “most likely” time estimates for individual tasks by applying
statistical models
Calculate “boundary times” that define a “time window” for a particular
task

58. PROJECT TRACKING
The project schedule provides a road map for a software project
manager.
It defines the tasks and milestones.
Several ways to track a project schedule:
Conducting periodic project status meeting
Evaluating the review results in the software process
Determine if formal project milestones have been accomplished
Compare actual start date to planned start date for each task
Informal meeting with practitioners
Using earned value analysis to assess progress quantitatively
Project manager takes the control of the schedule in the aspects
of
Project Staffing, Project Problems, Project Resources, Reviews, Project
Budget
Example: Gantt chart

59. Gantt chart:
A Gantt chart, commonly used in project management, is one of
the most popular and useful ways of showing activities (tasks or
events) displayed against time.
On the left of the chart is a list of the activities and along the top
is a suitable time scale.
Each activity is represented by a bar; the position and length of
the bar reflects the start date, duration and end date of the
activity.
This allows you to see at a glance:
● What the various activities are
● When each activity begins and ends
● How long each activity is scheduled to last
● Where activities overlap with other activities, and by how much
● The start and end date of the whole project

61. RISK ANALYSIS & MANAGEMENT
● A risk is a potential (probable) problem – which might happen
and might not
● Risk concerns future happenings
● Risk involves change in mind, opinion, actions, places, etc.
● Risk involves choice and the uncertainty that choice entails
Two characteristics of risk
1. Uncertainty: The risk may or may not happen, so there are no
100% risks (some of those may called constraints)
2. Loss: If the risk becomes a reality and unwanted consequences
or losses occur

62. Risk Categorization: Approach-1
1. Project risks
They threaten the project plan
If they become real, it is likely that the project schedule will slip and that
costs will increase
2. Technical risks
They threaten the quality and timeliness of the software to be produced
If they become real, implementation may become difficult or impossible
3. Business risks
They threaten the feasibility of the software to be built
If they become real, they threaten the project or the product

63. Sub-categories of Business risks
1. Market risk: Building an excellent product or system that no one really
wants
2. Strategic risk: Building a product that no longer fits into the overall
business strategy for the company
3. Sales risk: Building a product that the sales force doesn't understand how to
sell
4. Management risk: Losing the support of senior management due to a
change in focus or a change in people
5. Budget risk: Losing budgetary or personnel commitment

64. Risk Categorization: Approach-2
1. Known risks
Those risks that can be uncovered after careful evaluation of
the project plan, the business and technical environment in
which the project is being developed, and other reliable
information sources (Ex. unrealistic delivery date)
2. Predictable risks
Those risks that are deduced (draw conclusion) from past project
experience (Ex. past turnover)
3. Unpredictable risks
Those risks that can and do occur, but are extremely difficult to identify
in advance

65. Steps for Risk Management
1. Identify possible risks and recognize what can go wrong
2. Analyze each risk to estimate the probability that it will
occur and the impact (i.e., damage) that it will do if it
does occur
3. Rank the risks by probability and impact. Impact may be
negligible, marginal, critical, and catastrophic.
4. Develop a contingency plan to manage those risks
having high probability and high impact

66. RISK IDENTIFICATION
Risk identification is a systematic attempt to specify threats to
the project plan
By identifying known and predictable risks, the project manager
takes a first step toward,
avoiding them when possible
controlling them when necessary
Types of risk identification:
1. Generic Risks
Risks that are a potential threat to every software project
2. Product-specific Risks
Risks that can be identified only by clear understanding of the
technology, the people and the environment, that is specific to the
software that is to be built

67. 3. Known and Predictable Risk Categories
One method for identifying risks is to create a risk item
checklist
The checklist can be used for risk identification which focuses
on some subset of known and predictable risks in the following
generic subcategories:
Product Size: risks associated with overall size of the software to be
built
Business Impact: risks associated with constraints imposed by
management or the marketplace
Customer Characteristics: risks associated with sophistication of the
customer and the developer's ability to communicate with the customer
in a timely manner
Process Definition: risks associated with the degree to which the
software process has been defined and is followed
Development Environment: risks associated with availability and quality
of the tools to be used to build the project
Technology to be Built: risks associated with complexity of the system
to be built and the “newness” of the technology in the system
Staff Size and Experience: risks associated with overall technical and
project experience of the software engineers who will do the work

68. RISK PROJECTION
Risk projection (or estimation) attempts to rate each risk in two
ways
The probability that the risk is real
The consequence (effect) of the problems associated with the risk
Risk Projection/Estimation Steps
Establish a scale that reflects the perceived likelihood (probability) of a
risk. Ex., 1-low, 10-high
Explain the consequences of the risk
Estimate the impact of the risk on the project and product.
Note the overall accuracy of the risk projection so that there will be no
misunderstandings

69. RISK REFINEMENT
● A risk may be stated generally during early stages of project
planning.
● With the time, more is learn about project and risks can be refined to
more detailed from making it easier to mitigate, monitor and
manage.
● Also called Risk Assessment.
● Case:
Given that all reusable software components must conform to
specific design standards and that some do not conform, then there
is concern that (possibly) only 70 percent of the software
components are reusable and 30 percent need to be custom build.

70. This general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed
by a third party with no knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces
has not been solidified and may not conform to certain existing
reusable components.
Subcondition 3. Certain reusable components have been
implemented in a language that is not supported on the target
environment.

71. RMMM
Risk Mitigation, Monitoring, and Management (RMMM)
An effective strategy for dealing with risk must consider
three issues
Risk mitigation (i.e., avoidance)
Risk monitoring
Risk management and contingency planning
Risk Mitigation is a problem avoidance activity
Risk Monitoring is a project tracking activity
Risk Management includes contingency plans that risk will
occur

72. RISK MITIGATION
Risk mitigation (avoidance) is the primary strategy and is
achieved through a plan
For Ex., Risk of high staff turnover
To mitigate this risk, you would develop a strategy for reducing
turnover.
The possible steps to be taken are:
Meet with current staff to determine causes for turnover (e.g., poor
working conditions, low pay, and competitive job market)
Mitigate those causes that are under your control before the project
starts
Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave
Organize project teams so that information about each development
activity is widely dispersed
Define work product standards and establish mechanisms to be sure
that all models and documents are developed in a timely manner
Conduct peer reviews of all work (so that more than one person is “up
to speed”).
Assign a backup staff member for every critical technologist