Software Eng Subject / Tiu & Mark

1. SOFTWARE PROJECT
MANAGEMENT

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.

8. Software Project Manager
Manage Software
Projects

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

16. ESTIMATION
TECHNIQUES AND
SOFTWARE
METRICS
Good day.. (^_^)

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

21. MACRO-LEVEL ESTIMATION
 Consider the software product as a whole

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

36. USE CASE
POINTS
AND
COCOMO

37. Use Case Points

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

43. Categories of use cases:
 Simple – at most 3 transactions
 Average – has 4 to 7 transactions
 Complex – has more than 7 transactions

45. Unadjusted Actor Weight
(UAW)
 sum of complexity values assigned to
each actor
 sum of all actor weights

46. e.g.

47. Unadjusted Use Case Weight
(UUCW)
 sum of complexity values assigned to each
use case

48. e.g.

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)

53. e.g.
TCF = 0.6 + (0.01 * 42)
= 1.02

54.  Environmental Factor
- related to the people, process and project
aspects of the software
EF = 1.4 - (-0.03 * EF)

56. e.g.
EF = 1.4 + (-0.03 * 17.5)
= 1.4 + (-0.03 * 17.5)
= 0.89

57. COCOMO

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

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

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

67. Thank you.. :P
By : wa lng.. :D