Software project management


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software project management

  1. 1. Software Pr j tS ft r Project Manage ent Management R. Akerkar TMRF, K lh TMRF Kolhapur, India I di R. Akerkar - SPM 1
  2. 2. Introduction Many software projects fail:  due to faulty project management practices:  It is important to learn different aspects of software project management. management R. Akerkar - SPM 2
  3. 3. Introduction Goal of software project management: g  enable a group of engineers to work efficiently towards successful completion of a software project. R. Akerkar - SPM 3
  4. 4. Responsibility of project managers Project proposal writing writing, Project cost estimation, Scheduling, g, Project staffing, Project monitoring and control, Software configuration management, Risk management, Managerial report writing and presentations, etc. M i l t iti d t ti t R. Akerkar - SPM 4
  5. 5. IntroductionA project manager’s activities manager s are varied.  can be broadly classified into:  project planning planning,  project monitoring and control activities. R. Akerkar - SPM 5
  6. 6. Project Planning j g Once a project is found to be feasible,  project managers undertake project p planning. g R. Akerkar - SPM 6
  7. 7. Project Planning Activities j g Estimation:  Effort, cost, resource, and project duration Project scheduling: j g Staff organization:  staffing plans Risk handling: Ri k h dli  identification, analysis, and abatement procedures Miscellaneous plans:  quality assurance plan, configuration management plan, etc. R. Akerkar - SPM 7
  8. 8. Project p j planning g Requires utmost care and attention --- commitments to unrealistic time and resource estimates result in:  irritating delays.  cus o e dissatisfaction customer d ssa s ac o  adverse affect on team morale  poor quality work  project failure. R. Akerkar - SPM 8
  9. 9. Sliding Window Planning g g Involves project planning over several stages:  protects managers from making big commitments too early. y  More information becomes available as project progresses progresses.  Facilitates accurate planning R. Akerkar - SPM 9
  10. 10. SPMP Document After planning is complete:  Document the plans: p  in a Software Project Management Plan(SPMP) document. R. Akerkar - SPM 10
  11. 11. Organization of SPMP Document g  Introduction (Objectives Major Functions,Performance Issues,Management and (Objectives,Major Functions Performance Issues Management Technical Constraints)  Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project Duration Estimates) )  Project Resources Plan (People,Hardware and Software,Special Resources)  Schedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT Chart Representation)  Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation, Abatement Procedures)  Project Tracking and Control Plan  Miscellaneous Plans(Process Tailoring Quality Assurance) Tailoring,Quality R. Akerkar - SPM 11
  12. 12. Software Cost Estimation Determine size of the product product. From the size estimate,  determine the effort needed needed. From the effort estimate,  determine project duration, and cost. R. Akerkar - SPM 12
  13. 13. Software Cost Estimation Effort Cost Estimation Estimation Size StaffingEstimation Estimation Duration Estimation Scheduling R. Akerkar - SPM 13
  14. 14. Organization Structure g Functional Organization:  Engineers are organized into functional groups, e.g. groups e g  specification, design, coding, testing, maintenance, etc. maintenance etc  Engineers from functional groups get assigned to different projects R. Akerkar - SPM 14
  15. 15. Advantages of FunctionalOrganization Specialization Ease of staffing Good documentation is produced  d e e t phases are carried different p ases a e ca ed out by d e e t different teams of engineers. Helps identify errors earlier earlier. R. Akerkar - SPM 15
  16. 16. Project Organization j g Engineers get assigned to a project for the entire duration of the project  Same set of engineers carry out all the phases Advantages:  Engineers save time on learning details of every project project.  Leads to job rotation R. Akerkar - SPM 16
  17. 17. Team Structure Problems of different complexities and sizes require different team structures:  Chief programmer Chief-programmer team  Democratic team  Mi Mixed organization d i ti R. Akerkar - SPM 17
  18. 18. Democratic Teams Suitable for:  small projects requiring less than five or six engineers i  research-oriented projects A manager provides administrative p leadership:  at different times different members of the g p provide technical leadership. group p p R. Akerkar - SPM 18
  19. 19. Democratic Teams Democratic organization provides  higher morale and job satisfaction to the engineers  therefore leads to less employee turnover turnover. Suitable for less understood problems,  a group of engineers can invent better solutions than a single individual. R. Akerkar - SPM 19
  20. 20. Democratic Teams Di Disadvantage: d t  team members may waste a lot time arguing about trivial points:  absence of any authority i th b f th it in the team. R. Akerkar - SPM 20
  21. 21. Chief Programmer Team gA senior engineer provides technical leadership:  partitions the task among the team members.  verifies and integrates the products developed by the members. R. Akerkar - SPM 21
  22. 22. Chief Programmer Team g Works well when  the task is well understood  also within the intellectual grasp of a single individual,  importance of early completion outweighs other factors  team morale, personal development, etc. R. Akerkar - SPM 22
  23. 23. Chief Programmer Team g Chief programmer team is subject to single point failure:  too t much responsibility and authority is h ibilit d th it i assigned to the chief programmer. R. Akerkar - SPM 23
  24. 24. Team Organization g Democratic Team Chief Programmer team R. Akerkar - SPM 24
  25. 25. Mixed team organization g R. Akerkar - SPM 25
  26. 26. Staffing Project Managers usually take responsibility for choosing their team: h i th i t  need to identify and select y good software engineers for the success of the project project. R. Akerkar - SPM 26
  27. 27. Staffing A common misconception: p  one software engineer is as productive as another: Experiments reveal: E i t l  a large variation in productivity between the worst and best in a scale of 1 to 10. 10  Worst engineers even help reduce the overall productivity of the team  in effect exhibit negative productivity. R. Akerkar - SPM 27
  28. 28. Who is a Good Software Engineer?  Good programming abilities  Good knowledge of the project areas (Domain) G dk l d f h j (D i )  Exposure to Systematic Techniques  Fundamental Knowledge of Computer Science  Ability to work in a team  Intelligence  Good communication skills:  Oral  Written  Interpersonal  High Motivation R. Akerkar - SPM 28
  29. 29. Who is a Good Software Engineer? (cont.)  Studies show:  these attributes vary as much as 1:30 for poor and bright candidates.  Technical knowledge in the area of the project (domain knowledge) is an important factor, determines:  productivity of an individual  quality of the product he develops. R. Akerkar - SPM 29
  30. 30. Who is a Good Software Engineer? (cont.)  A programmer having thorough knowledge of database applications (e.g MIS): (e g  may turn out to be a poor data communication engineer engineer. R. Akerkar - SPM 30
  31. 31. Scheduling Scheduling is an important activity for the g y project managers. To determine project schedule:  Identify tasks needed to complete the project.  Determine the dependency among different tasks.  Determine the most likely estimates for the duration of the identified tasks.  Plan the starting and ending dates for various tasks. t k R. Akerkar - SPM 31
  32. 32. Work Breakdown Structure Work Breakdown Structure (WBS) provides a notation for f representing task structure: i k  Activities are represented as nodes of a tree.  The root of the tree is labelled by the problem name.  Each task is broken down into smaller tasks and represented as children nodes. It is not useful to subdivide tasks into units which take less than a week or two to execute.  Finer subdivisions mean that a large amount of time must be spent on estimating and chart revision. R. Akerkar - SPM 32
  33. 33. Work Breakdown Structure Compiler Project p jRequirements Design Code Test Write Manual Lexer Parser Code Generator R. Akerkar - SPM 33
  34. 34. Activity Networks WBS structure can be refined into an activity network representation:  Network of boxes and arrows  shows different tasks making up a project, h diff tt k ki j t  represents the ordering among the tasks. It is important to realize that developing WBS and activity network  requires a thorough understanding of the tasks involved. R. Akerkar - SPM 34
  35. 35. Activity Network Code Lexer Design Code Parser Requirements Code Code Generator Test Write Manual R. Akerkar - SPM 35
  36. 36. Risk Management A risk is any unfavourable event or circumstance:  which might hamper successful or timely completion of a project. p p j Risk management:  concerned with the reduction of the impact of risks. Risk management consists of three activities:  risk identification,  risk assessment, and  risk containment. i k t i t R. Akerkar - SPM 36
  37. 37. Risk identification  To be able to identify various risks: y  we must categorize risks into different classes.  Three main categories of risks can affect a software project:  project risks  technical risks  business risks R. Akerkar - SPM 37
  38. 38. Project Risks j Project risks associated with:  budget,  schedule,  personnel, p ,  resource, and  customer problems. t bl R. Akerkar - SPM 38
  39. 39. Technical Risks Technical risks concern:  requirements specification  (e.g ambiguous, incomplete, changing specifications)  design problems, problems  implementation problems,  interfacing problems, gp ,  testing, and maintenance problems.  technical uncertainty, and technical obsolescence are technical risk factors too too. R. Akerkar - SPM 39
  40. 40. Business Risks Business Risks include:  building an excellent product that no one wants,  losing budgetary or personnel commitments, etc. It i I is a good idea to have a “ d id h “company di disaster list”,  a list of all bad things that have happened in the past  project managers can jog their mind to see which items th i project is vulnerable to. it their j ti l bl t R. Akerkar - SPM 40
  41. 41. Risk assessment Objective of risk assessment is to j prioritize the risks:  Likelihood of a risk being real.  C Consequence of th problems associated f the bl i t d with that risk. Prioritization helps in handling the most damaging risks first.  Priority of a risk is the product of the likelihood of the risk and the consequences of the problems associated with that risk. R. Akerkar - SPM 41
  42. 42. Risk Handling g Three main strategies for risk handling:  Avoid the risk: e.g. change the requirements for performance or functionality.  Transfer the risk: allocate risks to third party  or buy insurance to cover any financial loss should the risk become a reality.  Contingency planning: Prepare contingency pans to minimize the impact of the risk. R. Akerkar - SPM 42