SOFTWARE PROJECTMANAGEMENT
How Bad are Our Projects?   Only 34 percent of all projects succeed.   The average project has a 43 percent cost    over...
Why Projects FAIL   Overlooked one or more of the crucial    elements of project management.     Risk engineering and ma...
What is Project Management?   Did you say:     People skills     Software
What is Software ProjectManagement?   Encompasses a set of activities that are    performed during the phases of a typica...
Software Project Manager      Manage Software         Projects
Software Project Manager         Continuously ensure that the          software product is developed          according t...
Elements of Software ProjectManagement   The project itself   The people working on the project   The process used to p...
Common Mistakes why ProjectsFAIL   Project managers begin without knowing what    the project is.   Project managers do ...
Project Plan   Is an important deliverable that must be    developed carefully.   Once written, the plan must be execute...
People   Engaging the proper people to perform the    prescribed tasks according to the project plan    is important.   ...
Process and Phases   Must be understood and defined because they    determine deliverable and the efforts involved    in ...
Project Management Activities                                  Project management activitiesDuring project   Estimation   ...
ESTIMATIONTECHNIQUES ANDSOFTWAREMETRICSGood day.. (^_^)
Estimation   One of the most critical activity during project    startup   Estimate the effort needed to complete the   ...
Common Problems   Underestimation     Project milestones cannot be met     What to do?     Leads to low employee moral...
ESTIMATION TECHNIQUE #1:   Informal approaches     One or more expert opinions     Experiences from peers     Opinions...
ESTIMATION TECHNIQUE #2:   Decomposition Process     Break down the project into functional      components     Ask pot...
MACRO-LEVEL ESTIMATION   Consider the software product as a whole
MICRO-LEVEL ESTIMATION   Decompose the product into smallest possible    components   Estimate for those components   R...
CATEGORIES   Black box-based / Requirements-based ET     Estimations are obtained once the software      project scope i...
How to solve a problem?   When we have a problem that consists of two    particular aspects, we should consider taking   ...
Back to measuring applicationcomplexity …   The analysis based on function points can be    compared to slicing the probl...
Function Points (to simplify)   FP is a standard method for quantifying the    software deliverable based upon the user  ...
Five Functional Components   INTERNAL LOGIC FILES (ILF)      Files created and maintained within the application   EXTE...
How to perform Function PointsAnalysis?   Basically people solve problems by dividing    them into smaller parts.   Inst...
Function Points Analysis (FPA)   We have three possibilities.                                        COMPLEXITY         C...
Function Point Metrics                               SIMPLE                          AVERAGE                          COMP...
CASE STUDY   STOCK CONTROL SYSTEM – estimating the    time needed to develop this applicationLets imagine a company which...
HELP??.. :’(   At first, we should pay attention to the    functionality – what exactly the system should    be able to d...
Let’s predict every function’s complexity issimple …       Category             Multiplier        Weight FactorExternal In...
Technical factors affectingcomplexity of software projects   Reliable backup and recovery needed   Data communications n...
Technical factors affectingcomplexity of software projects   Real-time update needed   Complexity of the interfaces   C...
USE CASE POINTS  ANDCOCOMO
Use Case Points
Use Case Points   introduced by Gustav Kamer in 1993   Extension of the FP method based on the use    cases existing in ...
Categories of actors:      Simple – are other systems that       communicate with your software via a pre-       defined ...
Categories of actors:    Average - can either be human beings interacting in a     well defined protocol, or they could b...
Categories of actors:      Complex - users who interact with the                   software through a graphical          ...
Categories of use cases:    Simple – at most 3 transactions    Average – has 4 to 7 transactions    Complex – has more ...
Unadjusted Actor Weight(UAW)   sum of complexity values assigned to       each actor   sum of all actor weights
e.g.
Unadjusted Use Case Weight(UUCW)   sum of complexity values assigned to each    use case
e.g.
Unadjusted Use Case Point(UUCP)   the unadjusted size of the overall system             UUCP= UAW + UUCWe.g.       UUCP =...
Adjusted Use Case Points(AUCP)   total effort to develop a system in respect to    the different factors impacting Techni...
   Technical Complexity Factor        - Sum of all the weighted values     computed    for each of the 13 technical facto...
e.g.       TCF = 0.6 + (0.01 * 42)           = 1.02
   Environmental Factor       - related to the people, process and project    aspects of the software                EF =...
e.g.       EF = 1.4 + (-0.03 * 17.5)         = 1.4 + (-0.03 * 17.5)         = 0.89
COCOMO
Constructed Cost Model(COCOMO)   introduced by Barry Boehm in 1981   provides an estimate of the effort in person-    mo...
Types of Software1. Organic Products    -are relatively small and simple2. Semi-detached    -are average in size and simpl...
3. Embedded     - complex in the sense that they must meet the   constraints of their embedding environment and   interfac...
3 Versions of COCOMO   Basic        - provides an estimate of the effort as a function    of an estimate of the program s...
   Intermediate         -The same basic equation for the model is    used, but fifteen cost drivers are rated on a    sca...
   Detailed        -computes effort as a function of program size and a      set of cost drivers weighted according to ea...
4 phases of Detailed COCOMO     1. Requirements Planning and Product           design     2. Detailed Design     3. Code a...
Thank you.. :P                 By : wa lng.. :D
Estimation techniques and software metrics
Estimation techniques and software metrics
Estimation techniques and software metrics
Estimation techniques and software metrics
Estimation techniques and software metrics
Estimation techniques and software metrics
Estimation techniques and software metrics
Estimation techniques and software metrics
Upcoming SlideShare
Loading in...5
×

Estimation techniques and software metrics

7,590

Published on

Software Eng Subject / Tiu & Mark

Published in: Technology, Business
1 Comment
7 Likes
Statistics
Notes
No Downloads
Views
Total Views
7,590
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
338
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide
  • 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
  • Estimation techniques and software metrics

    1. 1. SOFTWARE PROJECTMANAGEMENT
    2. 2. How Bad are Our Projects? Only 34 percent of all projects succeed. The average project has a 43 percent cost overrun.
    3. 3. 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
    4. 4. What is Project Management? Did you say:  People skills  Software
    5. 5. What is Software ProjectManagement? Encompasses a set of activities that are performed during the phases of a typical software development project.
    6. 6. Software Project Manager Manage Software Projects
    7. 7. Software Project Manager  Continuously ensure that the software product is developed according to:  The client’s business requirements  Within allocated time  Within allocated budget
    8. 8. Elements of Software ProjectManagement The project itself The people working on the project The process used to produce the project deliverables The final product delivered to the client
    9. 9. Common Mistakes why ProjectsFAIL 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.
    10. 10. 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
    11. 11. 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.
    12. 12. 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.
    13. 13. Project Management Activities Project management activitiesDuring project Estimation Developing the work plan:start-up Staffing activities, schedule, Resource acquisition resources, and budget Training allocationDuring project Quality assurance control Budget controlexecution Reporting and tracking Schedule control Metrics collection Requirements control Risk monitoring and mitigation Verification and validation Configuration management Documentation Process Improvement Problem resolution Subcontractor managementDuring project Product acceptance Archivingcloseout Staff reassignment Post-mortem evaluation and User training assessment Product installation Integration and conversion
    14. 14. ESTIMATIONTECHNIQUES ANDSOFTWAREMETRICSGood day.. (^_^)
    15. 15. 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
    16. 16. 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
    17. 17. ESTIMATION TECHNIQUE #1: Informal approaches  One or more expert opinions  Experiences from peers  Opinions of hired consultants
    18. 18. 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
    19. 19. MACRO-LEVEL ESTIMATION Consider the software product as a whole
    20. 20. MICRO-LEVEL ESTIMATION Decompose the product into smallest possible components Estimate for those components Requires more time to produce, but accurate estimates are produced
    21. 21. 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
    22. 22. 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.
    23. 23. Back to measuring applicationcomplexity … The analysis based on function points can be compared to slicing the problem into smaller parts.
    24. 24. 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.
    25. 25. 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)
    26. 26. How to perform Function PointsAnalysis? 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.
    27. 27. 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.
    28. 28. Function Point Metrics SIMPLE AVERAGE COMPLEX How many? How many? How many? Product Product Product Weight Weight Weight Factor Factor FactorExternal Input 3 1 3 4 2 8 6 1 6External Output 4 3 12 5 0 0 7 1 7User Inquiry 3 1 3 4 1 4 6 0 0External Interface File 7 0 0 10 0 0 15 3 45Internal Logic File 5 0 0 7 0 0 10 1 10TOTAL 18 12 68NO. of FPs 18 + 12 + 68 = 98 function points
    29. 29. CASE STUDY STOCK CONTROL SYSTEM – estimating the time needed to develop this applicationLets imagine a company which sells goods on thephone - if agents call the customers, customers callthe agents, and so on - business operatessuccessfully, but there comes a time for putting thewhole in order. There occurs a need for developinga system able to control the whole stock, fromorders to payments. Our thing is to estimate howcomplex such system can be and - after that - tryto predict how long it would take to develop it.
    30. 30. 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. (^_^)
    31. 31. Let’s predict every function’s complexity issimple … Category Multiplier Weight FactorExternal Inputs 4 3External Outputs 4 4External InQuiries 3 3Internal Logic Files 4 5 4 * 3 + 4 * 4 + 3 * 3 + 4 * 5 = 57 [FunctionHowPoints]takes to produce 57 function points? long it 57 * 8 = 456 [hours]The answer? - The estimate for developing the application wouldtake about 456 hours of work.
    32. 32. Technical factors affectingcomplexity 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
    33. 33. Technical factors affectingcomplexity of software projects Real-time update needed Complexity of the interfaces Complexity of the processing Reusability Ease of installation Multiple sites Easy to change
    34. 34. USE CASE POINTS ANDCOCOMO
    35. 35. Use Case Points
    36. 36. 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
    37. 37. Categories of actors:  Simple – are other systems that communicate with your software via a pre- defined API. Complex – has more than 10 transactions
    38. 38. 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.
    39. 39. 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
    40. 40. Categories of use cases:  Simple – at most 3 transactions  Average – has 4 to 7 transactions  Complex – has more than 7 transactions
    41. 41. Unadjusted Actor Weight(UAW) sum of complexity values assigned to each actor sum of all actor weights
    42. 42. e.g.
    43. 43. Unadjusted Use Case Weight(UUCW) sum of complexity values assigned to each use case
    44. 44. e.g.
    45. 45. Unadjusted Use Case Point(UUCP) the unadjusted size of the overall system UUCP= UAW + UUCWe.g. UUCP = 560 + 40 =600
    46. 46. 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)
    47. 47.  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)
    48. 48. e.g. TCF = 0.6 + (0.01 * 42) = 1.02
    49. 49.  Environmental Factor - related to the people, process and project aspects of the software EF = 1.4 - (-0.03 * EF)
    50. 50. e.g. EF = 1.4 + (-0.03 * 17.5) = 1.4 + (-0.03 * 17.5) = 0.89
    51. 51. COCOMO
    52. 52. 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
    53. 53. Types of Software1. Organic Products -are relatively small and simple2. Semi-detached -are average in size and simplicity
    54. 54. 3. Embedded - complex in the sense that they must meet the constraints of their embedding environment and interfaces, including software and hardware
    55. 55. 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
    56. 56.  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
    57. 57.  Detailed -computes effort as a function of program size and a set of cost drivers weighted according to each phase of the software lifecycle.
    58. 58. 4 phases of Detailed COCOMO 1. Requirements Planning and Product design 2. Detailed Design 3. Code and Unit Test 4. Integration and Test
    59. 59. Thank you.. :P By : wa lng.. :D
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×