SOFTWARE ENGINEERING

Chapter 6: Software Project Management

❖ Measure and Metric:
• Measures
➢ A Measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some
attribute of a product or process. (ex. - LOC)
➢ Measurement is the act of determining a measure.
➢ When a single data point has been collected (e.g., the number of errors open in the review of a single
module), a measure has been established.
➢ Measurement occurs as the result of the collection of one or more data points. A software engineer
collects measures and develops metrics so that indicators will be obtained.

• Metric
➢ It is “a quantitative measure of the degree to which a system, component, or process possesses a given
attribute.” (ex. – SPI of student)
➢ Metrics should be collected so that process and product indicators can be find out.
➢ Process indicators enable a software engineering organization to gain insight into the efficiency of an
existing process.

❖ Software measures:
➢ It can be categorized in two ways:
1. Direct measures (e.g., the length of a attach)
2. Indirect measures (e.g., the "quality" of attach produced, measured by counting rejects).
➢ Direct measures of the software engineering process include cost and effort applied. Direct measures of
the product include lines of code (LOC) produced, execution speed, memory size, and defects reported
over some set period of time.
➢ Indirect measures of the product include functionality, quality, complexity, efficiency, reliability,
maintainability, and many other "–abilities".
➢ For proper Software Measurement, we have two kinds of Metrics.
1) Size-Oriented Metrics (Direct)
2) Function-Oriented Metrics (Indirect)

• Size-oriented metrics
➢ Size-oriented software metrics are derived by normalizing quality and/or productivity measures by
considering the size of the software that has been produced.
➢ If a software organization maintains simple records, a table of size-oriented measures, such as the one
shown in Figure.
➢ The table lists each software development project that has been completed over the past few years and
corresponding measures for that project.
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
➢ 12,100 lines of code [LOC] were developed with 24 person-months of effort at a cost of $168,000.
➢ It should be noted that the effort and cost recorded in the table represent all software engineering
activities (analysis, design, code, and test), not just coding.
➢ Further information for project alpha indicates that 365 pages of documentation were developed, 134
errors were recorded before the software was released, and 29 defects were come across after release to
the customer within the first year of operation.
➢ Three people worked on the development of software for project alpha.
➢ A set of simple size-oriented metrics can be developed for each project:
1. Errors per KLOC (thousand lines of code).
2. Defects per KLOC.
3. $ per LOC.
4. Page of documentation per KLOC.
➢ In addition, other interesting metrics can be computed:
5. Errors per person-month.
6. LOC per person-month.
7. $ per page of documentation.

• Function-oriented metrics
➢ Function-oriented software metrics use a measure of the functionality delivered by the application as a
normalization value.
➢ Functionality cannot be measured directly, it must be derived indirectly using other direct measures like
Function Point.
➢ Function points are derived using an observed relationship based on direct measures of software's
information domain and assessments of software complexity.

➢ The principle of Albrecht’s function point analysis (FPA) is that a system is decomposed into functional
units.
- Inputs: information entering the system
- Outputs: information leaving the system
- Enquiries: requests for instant access to information
- Internal logical files: information held within the system
- External interface files: information held by other system that is used by the system being analyzed.
➢ The FPA functional units are shown in figure given below:
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management

➢ The five functional units are divided in two categories:

(i) Data function types
o Internal Logical Files (ILF): A user identifiable group of logical related data or control information
maintained within the system.
o External Interface files (EIF): A user identifiable group of logically related data or control
information referenced by the system, but maintained within another system. This means that EIF
counted for one system, may be an ILF in another system.
(ii) Transactional function types
o External Input (EI): An EI processes data or control information that comes from outside the system.
The EI is an elementary process, which is the smallest unit of activity that is meaningful to the end
user in the business.
o External Output (EO): An EO is an elementary process that generate data or control information to
be sent outside the system.
o External Inquiry (EQ): An EQ is an elementary process that is made up to an input-output
combination that results in data retrieval.
➢ Formula for Function Point is:

➢ Where count total is total obtained as in above table.

➢ Where Fi (i = 1 to 14) are value adjustment factors (VAF) based on responses to the following questions:
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer information to or from the application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to be built over multiple screens or operations?
8. Are the ILFs updated online?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
➢ Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5
(absolutely essential) (1-incidental, 2-moderate, 3-average, 4-significant).
➢ The constant values in Equation and the weighting factors that are applied to information domain counts
are determined empirically.
➢ Functions points may compute the following important metrics:
Productivity = FP / persons*months (person*months = efforts)
Quality = Defects / FP
Cost = Rupees / FP
Documentation = Pages of documentation per FP
➢ These metrics are controversial and are not universally acceptable.

Example – 1:
Consider a project with the following functional units:
Number of user inputs = 50
Number of user outputs = 40
Number of user enquiries = 35
Number of user files = 06
Number of external interfaces = 04
Assume all complexity adjustment factors and weighting factors are average.
Compute the function points for the project.

ANS:

➢ Also, it is given that all complexity adjustment factors are average

Σ (Fi) = 14 * 3 = 42
➢ Now,
FP = count total x [0.65 + 0.01 * Σ (Fi)]
FP = 628 x [0.65 + 0.01 * 42]
FP = 672

Example – 2:
Computer the FP value for a project with the following information domain characteristics:
No. of user inputs = 32
No. of user outputs = 60
No. of user inquiries = 24
No. of user files = 08
No. of External interfaces = 2
No of person involved = 4, No of month = 3
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
Assume that all complexity adjustment values are average. Assume 14 algorithms have been counted.
Also calculate productivity for above project.

ANS:
Data Count Weighing factor (Avg.) Count * Factor
EI 32 4 128
EO 60 5 300
EsQ 24 4 96
ILF 8 10 80
EIF 2 7 14
COUNT TOTAL 618

➢ Σ (Fi) = 14 * 3 = 42 (because in the question it is given that complexity adjustment values are average
and all 14 algorithms are counted)
➢ Now,
FP = count total x [0.65 + 0.01 * Σ (Fi)]
FP = 618 x [0.65 + 0.01 * 42]
FP = 661.26
➢ Productivity = FP / Efforts
= 661.26 / (4*3)
= 55.105

❖ Project estimation:
➢ Estimation of resources, cost, and schedule for a software engineering effort requires experience, access
to good historical information (metrics), and the courage to commit to quantitative predictions when
qualitative information is all that exists.

• Factors that effect on estimation:

1. Project complexity: It has a strong effect on the uncertainty inherent in planning. Complexity,
however, is a relative measure that is affected by familiarity with past effort.
2. Project size: It is another important factor that can affect the accuracy and efficiency of estimates.
As size increases, the interdependency among various elements of the software grows rapidly.
3. The degree of structural uncertainty: It also has an effect on estimation risk. In this context,
structure refers to the degree to which requirements have been solidified, the ease with which
functions can be compartmentalized, and the hierarchical nature of the information that must be
processed.
4. The availability of historical information: It has a strong influence on estimation risk. By looking
back, you can emulate things that worked and improve areas where problems arose.
5. Project scope: If it is poorly understood or project requirements are subject to change, uncertainty
and estimation risk become dangerously high.

❖ Project Planning Process:

➢ Task Set for Project Planning is as follows:
1. Establish project scope.
2. Determine feasibility.
3. Analyze risks.
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
4. Define required resources.
a. Determine required human resources.
b. Define reusable software resources.
c. Identify environmental resources.
5. Estimate cost and effort.
a. Decompose the problem.
b. Develop two or more estimates using size, function points, process tasks, or use cases.
c. Reconcile the estimates.
6. Develop a project schedule.
a. Establish a meaningful task set.
b. Define a task network.
c. Use scheduling tools to develop a time-line chart.
d. Define schedule tracking mechanisms.

❖ COCOMO MODEL:
➢ The Constructive Cost Model (COCOMO) is an empirical estimation model i.e., the model uses a
theoretically derived formula to predict cost related factors.
➢ This model was created by “Barry Boehm”.
➢ The COCOMO model consists of three models:
1) The Basic COCOMO model: - It computes the effort & related cost applied on the software
development process as a function of program size expressed in terms of estimated lines of code
(LOC or KLOC).
2) The Intermediate COCOMO model: - It computes the software development effort as a function of –
a) Program size, and b) A set of cost drivers that includes subjective assessments of product,
hardware, personnel, and project attributes.
3) The Advanced COCOMO model

• Basic COCOMO model:

1) Organic projects: - These are relatively small and simple software projects which require small team
structure having good application experience. The project requirements are not rigid. (Ex. – any library
management, system, HTML)
2) Semi-detached projects: - These are medium size projects with a mix of rigid and less than rigid
requirements level (Ex. – Any OS)
3) Embedded projects: - These are large projects that have a very rigid requirements level. Here the
hardware, software and operational constraints are of prime importance (Ex. – Lift, ATM)
➢ Equation for basic COCOMO model is:
E = a * (KLOC)b
D = c * (E)d
Where, E = Effort applied by per person per month, D = development time in consecutive months
➢ The coefficients a, b, c & d are given in table below:
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
Example – 3:
Consider a project to develop a full screen editor. The major components identified are screen edit,
command language interpreter, file input and output, cursor movement, screen movement. The sizes
for these are estimated to be 4K, 2K, 1K, 2K and 3K delivered source lines. Use Basic COCOMO
Model to determine: a) Overall cost and schedule estimates. b) Cost and schedules for different
phases.

ANS:
a) For overall estimation,
➢ Total LOC size = 4K + 2K + 1K + 2K + 3K = 12K
➢ If we are analyzing out project, then we find that full screen editor is a semidetached project. So, for
estimation purpose, we will make, use of those constants.
➢ E = a * (KLOC)b
= 3 * (12)1.12 = 48.51 person month
➢ D = c * (E)d
= 2.5 * (48.51)0.35 = 9.73 month
➢ Number of people, N = E/D = 4.98 = 5 persons approximately
b) For individual phases,
➢ All modules will be organic software project because they are simple and we will make use of concerned
constants.
1) Screen edit
E = 2.4 * (4)1.05 = 10.28 person months
D = 2.5 * (10.20)0.38 = 6.06 months
N = E/D = 1.6 = 2 persons (approximately)
2) Command Language Interpreter
E = 2.4 * (2)1.05 = 4.96 person months
D = 2.5 * (4.96)0.38 = 4.59 months
N = E/D = 1.08 = 2 persons (approximately)
3) File input and output
E = 2.4 * (1)1.05 = 2.4 person months
D = 2.5 * (2.4)0.38 = 3.48 months
N = E/D = 0.68 person = 1 person
4) Cursor Movement
E = 2.4 * (2)1.05 = 4.96 person months
D = 2.5 * (4.96)0.38 = 4.59 months
N = E/D = 1.08 = 2 person (approximately)
5) Screen Movement
E = 2.4 * (3)1.05 = 7.6 person months
D = 2.5 * (7.6)0.38 = 5.4 months
N = E/D = 1.4 = 2 person (approximately)

• Intermediate COCOMO model:

➢ Equation for basic COCOMO model is:
E = a * (KLOC)b * (EAF)
D = c * (E)d
➢ EAF is Effort Adjustment Factor whose typical ranges from 0.9 to 1.4.
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
➢ Value of EAF can be determined by the tables published by “Barry Boehm” for four major categories –
product attributes, hardware attributes, personal attributes and project attributes.
➢ Intermediate Model Software Project Planning cost drivers
(i) Product Attributes
- Required s/w reliability
- Size of application database
- Complexity of the product
(ii) Hardware Attributes
- Run time performance constraints
- Memory constraints
- Virtual machine volatility
- Turnaround time
(iii) Personal Attributes
- Analyst capability
- Programmer capability
- Application experience
- Virtual m/c experience
- Programming language experience
(iv) Project Attributes
- Modern programming practices
- Use of software tools
- Required development Schedule
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management

Example – 4:
A new project with estimated 400 KLOC embedded system has to be developed. Project manager has
a choice of hiring from two pools of developers: Very high application experience with very little
experience in the programming language being used Or Developers of very low application experience
but a lot of experience with the programming language. What is the impact of hiring all developers
from one or the other pool?

ANS:
➢ Case - I:
E = a * (KLOC)b * (EAF)
= 2.8 * (400)1.2 * (0.82*1.14) = 3470.154 person month
D = c * (E)d
= 2.5 * (3470.154)0.32 = 33.95 month
➢ Case - II:
E = a * (KLOC)b * (EAF)
= 2.8 * (400)1.2 * (1.29*0.95) = 4549.29 person month
D = c * (E)d
= 2.5 * (4549.29)0.32 = 37.024 month
➢ Case – II requires more time and effort. Hence, very low application experience developers with lot of
programming language experience could not match with performance of very high application
experience with very low programming language experience.

❖ Project scheduling:
➢ Software project scheduling is an action that distributes estimated effort across the planned project
duration by allocating the effort to specific software engineering tasks.

• Basic principles:
1) Compartmentalization:
➢ The project must be compartmentalized into a number of manageable activities and tasks. To accomplish
compartmentalization, both the product and the process are refined.
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
2) Interdependency:
➢ The interdependency of each compartmentalized activity or task must be determined. Some tasks must
occur in sequence, while others can occur in parallel. Some activities cannot commence until the work
product produced by another is available. Other activities can occur independently.
3) Time allocation:
➢ Each task to be scheduled must be allocated some number of work units (e.g., person-days of effort). In
addition, each task must be assigned a start date and a completion date that are a function of the
interdependencies and whether work will be conducted on a full-time or part-time basis.
4) Effort validation:
➢ Every project has a defined number of people on the software team. As time allocation occurs, you must
ensure that no more than the allocated number of people has been scheduled at any given time. For
example, consider a project that has three assigned software engineers (e.g., three person-days are
available per day of assigned effort). 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.
5) Defined responsibilities:
➢ Every task that is scheduled should be assigned to a specific team member.
6) Defined outcomes:
➢ Every task that is scheduled should have a defined outcome. For software projects, the outcome is
normally a work product (e.g., the design of a component) or a part of a work product. Work products
are often combined in deliverables.
7) 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 has been reviewed for quality and has been approved. Each of these
principles is applied as the project schedule evolves.

❖ Critical Path method (CPM):

➢ Critical path method (CPM) is project scheduling method that can be applied to software development.
➢ This method is 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 tasks
➢ Interdependencies among tasks may be defined using a task network.
➢ Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a
whole or for individual functions.
➢ In project management, a critical path is the sequence of project network activities which add up to the
longest overall duration, regardless if that longest duration has float or not. This determines the shortest
time possible to complete the project.
➢ To identify critical path, you need to determine four parameters of each activity of network.
➢ Earliest start time (ES) = The earliest time an activity can start once the previous dependent
activities are over.
➢ Earliest finish time (EF) = ES + activity duration.
➢ Latest finish time (LF) = The latest time an activity can finish without delaying the project.
➢ Latest start time (LS) = LF - activity duration.
➢ The float time (also called slake time) for an activity is the time between the earliest (ES)
and the latest (LS) start time or between the earliest (EF) and latest (LF) finish times.
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
➢ During the float time, an activity can be delayed without delaying the project finish date.
➢ When slake time is zero, it is called Critical path activities.
➢ The critical path is the longest path of the network diagram.
➢ The activities in the critical path have an effect on the deadline of the project.
➢ If an activity of this path is delayed, the project will be delayed.
➢ We have to compulsory complete tasks which lies over critical path.
➢ In case if the project management needs to accelerate the project, the times for critical path activities
should be reduced.
Task No. Task Duration Dependent on task
T1 Specification 15 -
T2 Design database 45 T1
T3 Design GUI 30 T1
T4 Code database 105 T2
T5 Code GUI 45 T3
T6 Integrate and test 120 T4 & T5
T7 Write user manual 60 T1

Task ES EF LS LF ST
Specification 0 15 0 15 0
Design database 15 60 15 60 0
Design GUI 15 45 90 120 75
Code database 60 165 60 165 0
Code GUI 45 90 120 165 75
Integrate and test 165 285 165 285 0
Write user manual 15 75 225 285 210

➢ Task network

• Advantages of CPM:
➢ Offers a visual representation of the project activities.
➢ Presents the time to complete the tasks and the overall project.
➢ Tracking of critical activities.
 SOFTWARE ENGINEERING
Chapter 6: Software Project Management
❖ Gantt Chart (Scheduling Timeline chart):
➢ While creating a software project schedule the planner begins with a set of tasks. If automated tools are
used then the work breakdown as a task network or task outline.
➢ In addition, tasks may be assigned to specific individuals.
➢ As a consequence, 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 also
developed.
➢ Figure illustrates the format of a time-line chart. It depicts a part of a software project schedule that
emphasizes the concept scoping task for a word-processing (WP) software product.
➢ All project tasks (for concept scoping) are listed in the lefthand column.
➢ The horizontal bars indicate the duration of each task.
➢ When multiple bars occur at the same time on the calendar, task concurrency is implied.
➢ The diamonds indicate milestones.

❖ Project tracking:
➢ 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) have been accomplished
by the scheduled date.
- Comparing actual start-date to planned start-date for each project task listed in the resource table.
- Meeting informally with practitioners to obtain their subjective assessment of progress to date and
problems on the horizon.
- Using earned value analysis to assess progress quantitatively.