0% found this document useful (0 votes)
18 views

Unit - 2

aa

Uploaded by

Vrinda
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views

Unit - 2

aa

Uploaded by

Vrinda
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 29

Unit – 2

Project Management
Concepts & Project
Metrics
BE Sem – 7 SE – 3173213

Ms. Zarana Gajjar (IT-ICT Department)


Outline
• 4 P’s of Project Management
• W5HH Principle
• Project Management concepts
• Software Metrics
• Process, Product and Project
Metrics

Ms. Zarana Gajjar (IT-ICT Department)


4 P’s of Project Management
• People
• Product
• Process
• Project

Ms. Zarana Gajjar (IT-ICT Department)


4 P’s of Project Management
• People – the most important element of a successful
project
o Stakeholders
o Team Leaders
o Software Team
o Agile Team

• Product – the software to be built


o Product objective, scope
o Cost estimation
o Risk estimation
o Project schedule
o Alternative solutions

Ms. Zarana Gajjar (IT-ICT Department)


4 P’s of Project Management cont.
• Process – the set of framework activities & software
engineering tasks to get the job done
o Requirement Gathering
o Framework activities
o Umbrella activities
o Quality Assurance
o Software management

• Project – all work required to make the product a


reality
o Start on the right
o Maintain momentum
o Track progress
o Make smart decisions
Ms. Zarana Gajjar (IT-ICT Department)
W5HH Principle
• Bary Boehm suggested an approach
for addressing - project objectives,
deciding milestones and schedules,
roles & responsibilities, project
management, technical approaches,
and required resources by W5HH
principle
• W5HH principle is nothing but the
series of questions in the form of
why, what, when, who, how & so
on.

Ms. Zarana Gajjar (IT-ICT Department)


W5HH of Project Management
• Why is the system being developed?
o Enables all parties to assess the validity of business
reasons for the software work. Stated in another way,
does the business purpose justify the expenditure of
people, time, and money?

• What will be done?


o The answers to these questions help the team to establish
a project schedule by identifying key project tasks and the
milestones that are required by the customer.

• When will it be accomplished?


o Project schedule to achieve milestone.

Ms. Zarana Gajjar (IT-ICT Department)


W5HH of Project Management
• Who is responsible?
o Role and responsibility of each member.

• Where are they organizationally located?


o Not all roles & responsibilities beside within the software
team itself. The customer, users & other stakeholders also
have responsibilities.

• How will the job be done technically and managerially?


o Management and technical strategy must be defined

• How much of each resource is needed?


o Develop estimation based on answers to earlier questions.

Ms. Zarana Gajjar (IT-ICT Department)


Project Management concepts
Task Set for project planning

I. Establish project scope b. Develop estimates using size,


II. Determine feasibility function points, process tasks,
III. Analyze risks or use cases.
c. Reconcile the estimates
IV. Define required resources
a. Determine required human
VI. Develop a project schedule
a. Establish a meaningful task set
resources
b. Define a task network
b. Define reusable software
c. Use scheduling tools to develop
resources
a time-line chart
c. Identify environmental resource
d. Define schedule tracking
V. Estimate cost & effort mechanisms
a. Decompose the problem

Ms. Zarana Gajjar (IT-ICT Department)


Terminologies
• Measure
✓ It provides a quantitative indication of the extent (range), amount,
dimension, capacity or size of some attributes of a product or process
✓ Ex., the number of uncovered errors

• Metrics
✓ It is a quantitative measure of the degree (limit) to which a system,
component or process possesses (obtain) a given attribute.
✓ It relates individual measures in some way
✓ Ex., number of errors found per review

• Faults
✓ Errors - Faults found by the practitioners during software development
✓ Defects - Faults found by the customers after release

Ms. Zarana Gajjar (IT-ICT Department)


Terminologies cont.
• Direct Metrics
✓ Immediately measurable attributes
✓ Ex., Line of Code (LOC), Execution Speed, Defects Reported

• Indirect Metrics
✓ Aspects that are not immediately quantifiable
✓ Ex., Functionality, Quantity, Reliability

• Indicators
✓ It is a metric or combination of metrics that provides insight into the
software process, project or the product itself
✓ It enables the project manager or software engineers to adjust the
process, the project or the product to make things better
✓ Ex., Product Size (analysis and specification metrics) is an indicator of
increased coding, integration and testing effort

Ms. Zarana Gajjar (IT-ICT Department)


Why Measure Software?
• 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

Metric Classification Base

• Process
✓ Specifies activities related to production of software.
✓ Specifies the abstract set of activities that should be performed to go
from user needs to final product.
• Project
✓ Software development work in which a software process is used
✓ The actual act of executing the activities for some specific user needs
• Product
✓ The outcomes of a software project
✓ All the outputs that are produced while the activities are being executed

Ms. Zarana Gajjar (IT-ICT Department)


Types of Measures
Categories of Software Measurement

Direct measures of the Indirect measures of the


Software process Software product
Ex., cost, effort, etc. Ex. functionality, quality,
Software product complexity, efficiency,
Ex., lines of code produced, reliability, etc.
execution speed,
defects reported, etc.

Metric Classification Base


Metrics for Software Size Oriented Metrics
Cost and Effort Function Oriented Metrics
estimations Object Oriented Metrics
Use Case Oriented Metrics

Ms. Zarana Gajjar (IT-ICT Department)


Size-Oriented Metrics
• One of the earliest and simpler metrics for calculating the size of the
computer program.
• Generally used in calculating and comparing the productivity of
programmers.
• Any lines in code apart from comments & blanks, includes header,
declaration as well as executable & non executable statements.
• Derived by normalizing (standardizing) quality and/or productivity
measures by considering the size of the software produced.
• Thousand lines of code (KLOC) are often chosen as the normalization value.
• Size-oriented metrics of project computed by:
• Error per KLOC (thousand lines of code)
• Defects per KLOC
• $ per KLOC
• Pages of documentation per KLOC
• Other interesting metrics can be computed, like
• Errors per person-month
• KLOC per person-month
• $ per page of documentation

Ms. Zarana Gajjar (IT-ICT Department)


Size-Oriented Metrics cont.
Advantages

• Simple to measure

Disadvantages

• It is defined on the code. For example, it cannot measure the size of the
specification.
• It characterizes only one specific view of size, namely length, it takes no
account of functionality or complexity
• Bad software design may cause an excessive line of code
• Not universally accepted as the best way to measure the software process
• It is language dependent
• Users cannot easily understand it

Ms. Zarana Gajjar (IT-ICT Department)


Function Oriented Metrics
• Function-oriented metrics use a measure of the functionality
delivered by the application as a normalization value.
• Functionality is measured indirectly using a measure called function
point.
• Function points (FP) - derived using an empirical relationship based
on countable measures of software & assessments of software
complexity
FP = Count Total * [0.65 + 0.01 * Sum (Value Adjustment Factors)]
• The FP metric can be used effectively as a means for measuring the
functionality delivered by a system
• Using historical data, the FP metric can be used to
• Estimate the cost or effort required to design, code, and test the
software
• Predict the number of errors that will be encountered during
testing
• Forecast the number of components and/or the number of
projected source lines in the implemented system
Ms. Zarana Gajjar (IT-ICT Department)
Function Point Metrics
User / Event

Other
User / Event external Applications
inquiries (EQs)

external
inputs (EIs) external interface
files (EIFs)

external
outputs (EOs) Internal
Logic Files(ILFs)

Function / Application

Ms. Zarana Gajjar (IT-ICT Department)


Function Point Metrics cont.
Information domain values (components) are defined in the following
manner
• Number of external inputs (EIs) - input data originates from a user
or is transmitted from another application
• Number of external outputs (EOs) - external output is derived data
within the application that provides information to the user
- output refers to reports, screens, error messages, etc.
• Number of external inquiries (EQs) - external inquiry is defined as
an online input that results in the generation of some immediate
software response in the form of an online output
• Number of internal logical files (ILFs) - internal logical file is a
logical grouping of data that resides within the application’s boundary
and is maintained via external inputs
• Number of external interface files (EIFs) - external interface file is
a logical grouping of data that resides external to the application but
provides information that may be of use to the another application

Ms. Zarana Gajjar (IT-ICT Department)


Compute Function Points
FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]

Ms. Zarana Gajjar (IT-ICT Department)


Compute Function Points
• Fi (i=1 to 14) are complexity value adjustment factors (VAF).
• Value adjustment factors are used to provide an indication of
problem complexity

Value Adjustment Factors

• F1. Data Communication • F8. Online Update


• F2. Distributed Data Processing • F9. Complex Processing
• F3. Performance • F10. Reusability
• F4. Heavily Used Configuration • F11. Installation Ease
• F5. Transaction Role • F12. Operational Ease
• F6. Online Data Entry • F13. Multiple Sites
• F7. End-User Efficiency • F14. Facilitate Change

Ms. Zarana Gajjar (IT-ICT Department)


Complexity Adjustment Factors
• Does the system require reliable backup & recovery?
• Are data communications required?
• Are there distributed processing functions?
• Is performance critical?
• Will the system run in an existing, heavily utilized operational
environment?
• Does the system require on-line data entry?
• Does the on-line data entry require the input transaction to be built over
multiple screens or operations?
• Are the master files updated on-line?
• Are the inputs, outputs, files, or inquiries complex?
• Is the internal processing complex?
• Is the code designed to be reusable?
• Are conversion and installation included in the design?
• Is the system designed for multiple installations in different organizations?
• Is the application designed to facilitate change & ease of use by the user?

Ms. Zarana Gajjar (IT-ICT Department)


Rate Complexity Factors

• For each complexity adjustment factor, give a rating


on a scale of 0 to 5

0 - No influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

Ms. Zarana Gajjar (IT-ICT Department)


Function Point Calculation Example

• 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.

Ms. Zarana Gajjar (IT-ICT Department)


Function Point Calculation Example

7 28
10 40
6 18
17 119
4 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

Ms. Zarana Gajjar (IT-ICT Department)


Function Oriented Metrics cont.
Advantages

• FP is programming language independent


• FP is based on data that are more likely to be known in the early stages of
a project, making it more attractive as an estimation approach

Disadvantages

• FP requires some “sleight of hand” because the computation is based on


subjective data
• Counts of the information domain can be difficult to collect
• FP has no direct physical meaning, it’s just a number

Ms. Zarana Gajjar (IT-ICT Department)


Object-Oriented Metrics

• Used for object-oriented projects


• Lines of Code or Functional Point metrics can be
used to estimate object-oriented software projects
• However, these metrics are not appropriate in the
case of incremental software development as they
do not provide adequate details for effort &
schedule estimation.
• Thus, for object-oriented projects, different sets of
metrics have been proposed.

Ms. Zarana Gajjar (IT-ICT Department)


Object-Oriented Metrics cont.
Lorenz & Kidd have proposed set of metrics for OO
projects :
• Number of scenario scripts
❑ Scenario scripts are detailed sequence of steps about user & application
interaction
❑ Scenario scripts are directly correlated to application size & no. of test cases
• Number of key classes
❑ Key classes are independent components
❑ They indicate amount of development effort & potential reuse
• Number of support classes
❑ Logical entities required to support the key classes
❑ Total number of support classes represent amount of software reusability &
total amount of reusability
• Average number of support classes per key class
• Number of sub systems (aggregation of classes)
❑ If identified, it is easier to lay out the schedule

Ms. Zarana Gajjar (IT-ICT Department)


Use-case Oriented Metrics

• Use-cases describe user visible functions & features


• They are defined early in software process & can
be used as normalization measure before
significant activities are initiated
• They are independent of programming language
• No. of use cases directly proportional to
• Size of application in LOC &
• No. of test cases that will be designed
• There is no standard size of a use case as they are
created at different levels of abstraction
• For this reason, it is a suspect as a normalization
measure (ex., effort expended per use case)

Ms. Zarana Gajjar (IT-ICT Department)


Ms. Zarana Gajjar (IT-ICT Department)

You might also like