4. How Bad are Our Projects?
Only 34 percent of all projects succeed.
The average project has a 43 percent cost
overrun.
5. Why Projects FAIL
Overlooked one or more of the crucial
elements of project management.
Risk engineering and management
Human resource management
Effort and cost estimation
Project monitoring
Tracking and control
Time and financial management
Proper use of project management tools
6. What is Project Management?
Did you say:
People skills
Software
7. What is Software Project
Management?
Encompasses a set of activities that are
performed during the phases of a typical
software development project.
9. Software Project Manager
Continuously ensure that the
software product is developed
according to:
The client’s business requirements
Within allocated time
Within allocated budget
10. Elements of Software Project
Management
The project itself
The people working on the project
The process used to produce the project
deliverables
The final product delivered to the client
11. Common Mistakes why Projects
FAIL
Project managers begin without knowing what
the project is.
Project managers do not have a plan.
Project managers do not break the project
down to manageable pieces.
12. Project Plan
Is an important deliverable that must be
developed carefully.
Once written, the plan must be executed by
the project manager.
People involved should be well-versed
Progress must be closely monitored by the
manager
13. People
Engaging the proper people to perform the
prescribed tasks according to the project plan
is important.
Training people on the proper use of tools and
techniques is essential.
Communication and reporting must be well-
defined to ensure frictionless environment.
Transparent and continuous monitoring of
people involved is critical for the early
detection of problem symptoms.
14. Process and Phases
Must be understood and defined because they
determine deliverable and the efforts involved
in their execution.
An appropriate software life cycle model must
be adapted for the project
The development team needs to be
knowledgeable regarding that model.
15. Project Management Activities
Project management activities
During project Estimation Developing the work plan:
start-up Staffing activities, schedule,
Resource acquisition resources, and budget
Training allocation
During project Quality assurance control Budget control
execution Reporting and tracking Schedule control
Metrics collection Requirements control
Risk monitoring and mitigation Verification and validation
Configuration management Documentation
Process Improvement Problem resolution
Subcontractor management
During project Product acceptance Archiving
closeout Staff reassignment Post-mortem evaluation and
User training assessment
Product installation Integration and conversion
17. Estimation
One of the most critical activity during project
startup
Estimate the effort needed to complete the
project
Affects many resource aspects (financial and
human)
Must be realistic and accurate
18. Common Problems
Underestimation
Project milestones cannot be met
What to do?
Leads to low employee morale, decline in
reputation, and a stressful work environment
Overestimation
Lead to losing the bid
19. ESTIMATION TECHNIQUE #1:
Informal approaches
One or more expert opinions
Experiences from peers
Opinions of hired consultants
20. ESTIMATION TECHNIQUE #2:
Decomposition Process
Break down the project into functional
components
Ask potential developers of these components to
provide their own estimates based on prior
experiences
22. MICRO-LEVEL ESTIMATION
Decompose the product into smallest possible
components
Estimate for those components
Requires more time to produce, but accurate
estimates are produced
23. CATEGORIES
Black box-based / Requirements-based ET
Estimations are obtained once the software
project scope is clearly defined in terms of the
required functionalities
Function points and use case points estimation
techniques
Based on projected size of the final SW
product in terms of lines of code (LOC)
COCOMO technique
24. How to solve a problem?
When we have a problem that consists of two
particular aspects, we should consider taking
care about each aspect separately. Once the
first of problems is solved, we can turn to
another. After that, everything left is to check
whether the particular solutions work well
together with greater problem.
25. Back to measuring application
complexity …
The analysis based on function points can be
compared to slicing the problem into smaller
parts.
26. Function Points (to simplify)
FP is a standard method for quantifying the
software deliverable based upon the user
view, where:
User is any person or thing that communicates or
interacts with the software at any time
User View is the Functional User Requirements
as seen by the user
Functional user requirements describe what the
software shall do, in terms of tasks and services.
27. Five Functional Components
INTERNAL LOGIC FILES (ILF)
Files created and maintained within the application
EXTERNAL INTERFACE FILES (EIF)
Files that are owned and are exchanged by other
systems
EXTERNAL INPUTS (EI)
Inputs that affect the control flow and internal logic of the
application leading to the creation and maintenance of
data
EXTERNAL OUTPUTS (EO)
Data leaving the application to different devices, files or
external systems
EXTERNAL INQUIRIES (EQ)
28. How to perform Function Points
Analysis?
Basically people solve problems by dividing
them into smaller parts.
Instead of trying to evaluate the application as
a whole, we need to rate each of the selected
groups.
How exactly to do it?
We need to classify the complexity of each
category.
29. Function Points Analysis (FPA)
We have three possibilities.
COMPLEXITY
COMPONENT
SIMPLE AVERAGE COMPLEX
External Input 3 4 6
External Output 4 5 7
User Inquiry 3 4 6
External Interface File 7 10 15
Internal Logic File 5 7 10
Then, the whole “problem” is to sum the values.
A total of them represents the number of
application’s function points.
30. Function Point Metrics
SIMPLE AVERAGE COMPLEX
How many?
How many?
How many?
Product
Product
Product
Weight
Weight
Weight
Factor
Factor
Factor
External Input 3 1 3 4 2 8 6 1 6
External Output 4 3 12 5 0 0 7 1 7
User Inquiry 3 1 3 4 1 4 6 0 0
External Interface File 7 0 0 10 0 0 15 3 45
Internal Logic File 5 0 0 7 0 0 10 1 10
TOTAL 18 12 68
NO. of FPs 18 + 12 + 68 = 98 function points
31. CASE STUDY
STOCK CONTROL SYSTEM – estimating the
time needed to develop this application
Let's imagine a company which sells goods on the
phone - if agents call the customers, customers call
the agents, and so on - business operates
successfully, but there comes a time for putting the
whole in order. There occurs a need for developing
a system able to control the whole stock, from
orders to payments. Our thing is to estimate how
complex such system can be and - after that - try
to predict how long it would take to develop it.
32. HELP??.. :’(
At first, we should pay attention to the
functionality – what exactly the system should
be able to do.
Then, let us group functions into five
categories.
Let math do the last thing. (^_^)
33. Let’s predict every function’s complexity is
simple …
Category Multiplier Weight Factor
External Inputs 4 3
External Outputs 4 4
External InQuiries 3 3
Internal Logic Files 4 5
4 * 3 + 4 * 4 + 3 * 3 + 4 * 5 = 57 [Function
HowPoints]takes to produce 57 function points?
long it
57 * 8 = 456 [hours]
The answer?
- The estimate for developing the application would
take
about 456 hours of work.
34. Technical factors affecting
complexity of software projects
Reliable backup and recovery needed
Data communications needed
Distributed functions required
Performance required
Heavily used configuration
Real-time data entry needed
Ease of use
35. Technical factors affecting
complexity of software projects
Real-time update needed
Complexity of the interfaces
Complexity of the processing
Reusability
Ease of installation
Multiple sites
Easy to change
38. Use Case Points
introduced by Gustav Kamer in 1993
Extension of the FP method based on the use
cases existing in the use case model of a
software system
39. Categories of actors:
Simple – are other systems that
communicate with your software via a pre-
defined API. Complex – has more than 10
transactions
40. Categories of actors:
Average - can either be human beings interacting in a
well defined protocol, or they could be systems that
interact through a more complex or flexible API.
41. Categories of actors:
Complex - users who interact with the
software through a graphical
user interface are complex
actors
- users who interact with the
system in unpredictable ways
42.
43. Categories of use cases:
Simple – at most 3 transactions
Average – has 4 to 7 transactions
Complex – has more than 7 transactions
49. Unadjusted Use Case Point
(UUCP)
the unadjusted size of the overall system
UUCP= UAW + UUCW
e.g.
UUCP = 560 + 40
=600
50. Adjusted Use Case Points
(AUCP)
total effort to develop a system in respect to
the different factors impacting Technical
Complexity Factor and Environmental Factor
AUCP = (UAW + UCCW * TCF * EF)
51. Technical Complexity Factor
- Sum of all the weighted values computed
for each of the 13 technical factors which are
mainly related to the product and its complexity in
terms of functional and non-functional
requirements.
TCF = 0.6 + (0.01 * TF)
58. Constructed Cost Model
(COCOMO)
introduced by Barry Boehm in 1981
provides an estimate of the effort in person-
months needed to develop a software product
Based on the estimation of the size of the
software in terms of the number of lines of
codes
59. Types of Software
1. Organic Products
-are relatively small and simple
2. Semi-detached
-are average in size and simplicity
60. 3. Embedded
- complex in the sense that they must meet the
constraints of their embedding environment and
interfaces, including software and hardware
61.
62. 3 Versions of COCOMO
Basic
- provides an estimate of the effort as a function
of an estimate of the program size.
-the development effort and the development
duration are calculated on the basis of the
estimated DSI.
E = a * Sizeb
D = c * Ed
P = E/D
63. Intermediate
-The same basic equation for the model is
used, but fifteen cost drivers are rated on a
scale of 'very low' to 'very high' to calculate
the specific effort multiplier and each of them
returns an adjustment factor which multiplied
yields in the total EAF (Effort Adjustment
Factor).
E = a * Size * EAF
64.
65. Detailed
-computes effort as a function of program size and a
set of cost drivers weighted according to each phase
of the software lifecycle.
66. 4 phases of Detailed COCOMO
1. Requirements Planning and Product
design
2. Detailed Design
3. Code and Unit Test
4. Integration and Test
We need to make a choice right now.TO LEARN or NOT TO LEARN Project ManagementProject management has a lot that can offer us.One thing we want you to realize is that PROJECTS ARE REALLY BAD
How about extra time?Do you really want to be working on your project more time than you need to?
The manager must develop a management plan to follow closely during the execution of the project. This plan must be monitored and necessary modifications made by the manager to ensure the timely delivery of a quality software product.
If I would ask you..Neither of these are correct.Sure you need people skills. But we need people’s skills are for lots of things.Yes! There are good softwares out there, but it only HELPS you to manage projects, its NOT going to TELL you how to manage projects.
The project plan is a multipage document describing the schedule, costs, resources, risks, communication, and quality for the product AND how they will be managed.Any delays in the execution of the plan and any foreseen or unforeseen risks that arise during the project progress must be detected. Proper project progress monitoring tools must be used to ensure the timely delivery of the product. A review of the project plan and its timeline can be needed as a result of a corrective action.
Most important resources for the execution of a project.
COCOMO – Constructive Cost Model
+ The idea of function points - slicing the system into smaller parts - seems simple, but the problem was how to distinguish each part. + The first two are data-based components and the last three are transaction-based components