Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software project management


Published on

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

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