Successfully reported this slideshow.

Se lect13 btech

321 views

Published on

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

  • Be the first to like this

Se lect13 btech

  1. 1. Deliverables by Phase
  2. 2. Deliverables by Phase Possible Deliverables by Phase  Concept Document  Statement of Work (SOW)  Project Charter  RFP & Proposal Software  Requirements Document (Software Requirements Specification) Concept  Work Breakdown Structure (WBS) Requirements  Functional Specification ( Top Level Design Specification)  Entity Relationship Diagram  Data Flow Diagram Analysis  Detailed Design Specification  Object Diagrams  Detailed Data Model  Project Development Plan  (Software Development Plan ) Design  Coding Standards  Baseline Project Plan  Working Code  Quality Assurance Plan  Unit Tests  Configuration Management Plan Coding and  Risk Management Plan Debugging  Acceptance Test Procedures  Tested Application  Integration Plan Systems  Detailed SQA Test Plan Testing  Maintenance Specification  SQA Test Cases  Deployed Application Deployment &  User Documentation Maintenance  Training Plan 2
  3. 3. Risk managementRisk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.A risk is a probability that some adverse circumstance will occur.  Project risks affect schedule or resources  Product risks affect the quality or performance of the software being developed  Business risks affect the organisation developing or procuring the software
  4. 4. Software risks Risk Risk type Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware which is essential for the project will not be delivered on schedule. Requirements change Project and There will be a larger number of product changes to the requirements than anticipated. Specification delays Project and Specifications of essential interfaces product are not available on schedule Size underestimate Project and The size of the system has been product underestimated. CASE tool under- Product CASE tools which support the performance project do not perform as anticipated Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed.
  5. 5. The Risk Management Process• Risk identification – Identify project, product and business risks• Risk analysis – Assess the likelihood and consequences of these risks• Risk planning – Draw up plans to avoid or minimise the effects of the risk• Risk monitoring – Monitor the risks throughout the project
  6. 6. The risk management process Risk Risk analysis Risk planning Risk identification monitoringList of potential Risk avoidance Risk Prioritised risk and contingency risks list assessment plans
  7. 7. Risk identification• Technology risks• People risks• Organisational risks• Requirements risks• Estimation risks
  8. 8. Risks and risk typesRisk type Possible risksTechnology The database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality.People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available.Organisational The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget.Tools The code generated by CASE tools is inefficient. CASE tools cannot be integrated.Requirements Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes.Estimation The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.
  9. 9. Risk analysis• Assess probability and seriousness of each risk• Probability may be – very low – low – moderate – high or very high• Risk effects might be – catastrophic – serious – Tolerable – insignificant
  10. 10. Risk analysis Risk Probability Effects Organisational financial problems force reductions Low Catastrophic in the project budget. It is impossible to recruit staff with the skills High Catastrophic required for the project. Key staff are ill at critical times in the project. Moderate Serious Software components which should be reused Moderate Serious contain defects which limit their functionality. Changes to requirements which require major Moderate Serious design rework are proposed. The organisation is restructured so that different High Serious management are responsible for the project. The database used in the system cannot process as Moderate Serious many transactions per second as expected. The time required to develop the software is High Serious underestimated. CASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of Moderate Tolerable requirements changes. Required training for staff is not available. Moderate Tolerable The rate of defect repair is underestimated. Moderate Tolerable The size of the software is underestimated. High Tolerable The code generated by CASE tools is inefficient. Moderate Insignificant
  11. 11. Risk planningConsider each risk and develop a strategy to manage that riskAvoidance strategies  The probability that the risk will arise is reducedMinimisation strategies  The impact of the risk on the project or product will be reducedContingency plans  If the risk arises, contingency plans are plans to deal with that risk
  12. 12. Risk management strategies Risk Strategy Organisational Prepare a briefing document for senior management showing financial problems how the project is making a very important contribution to the goals of the business. Recruitment Alert customer of potential difficulties and the possibility of problems delays, investigate buying-in components. Staff illness Reorganise team so that there is more overlap of work and people therefore understand each other’s jobs. Defective Replace potentially defective components with bought-in components components of known reliability. Requirements Derive traceability information to assess requirements change changes impact, maximise information hiding in the design. Organisational Prepare a briefing document for senior management showing restructuring how the project is making a very important contribution to the goals of the business. Database Investigate the possibilit y of buying a higher-performance performance database. Underestimated Investigate buying in components, investigate use of a program development time generator.
  13. 13. Risk monitoring• Assess each identified risks regularly to decide whether or not it is becoming less or more probable• Also assess whether the effects of the risk have changed• Each key risk should be discussed at management progress meetings
  14. 14. Risk factorsRisk type Potential indicatorsTechnology Late delivery of hardware or support software, many reported technology problemsPeople Poor staff morale, poor relationships amongst team member, job availabilityOrganisational organisational gossip, lack of action by senior managementTools reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstationsRequirements many requirements change requests, customer complaintsEstimation failure to meet agreed schedule, failure to clear reported defects
  15. 15. Software Measurement &Matrices
  16. 16. Software MeasurementObjectives – Assessing status • Projects • Products for a specific project or projects • Processes • Resources – Identifying trends • Need to be able to differentiate between a healthy project and one that’s in trouble – Determine corrective action • Measurements should indicate the appropriate corrective action, if any is required. 16
  17. 17. Software Measurement Objectives • Types of information required to understand, control, and improve projects: – Managers • What does the process cost? • How productive is the staff? • How good is the code? • Will the customer/user be satisfied? • How can we improve? – Engineers • Are the requirements testable? • Have all the faults been found? • Have the product or process goals been met? • What will happen in the future? 17
  18. 18. The Scope of Software Metrics – Cost and effort estimation – Productivity measures and models – Data collection – Quality models and measures – Reliability models – Performance evaluation and models – Structural and complexity metrics – Capability-maturity assessment – Management by metrics – Evaluation of methods and tools 18
  19. 19. The Scope of Software Metrics • The Scope of Software Metrics – some details – Possible productivity model Productivity Cost Value Personnel Resources Complexity Quality Quantity Time HW Env ProblemReliability Defects Size Functionality Cnstrst difficulty Money SW 19
  20. 20. The Scope of Software Metrics• The Scope of Software Metrics – some details – Software quality model Use Factor Criteria Communicativeness Usability Accuracy Product Reliability Operatio Consistency n Efficiency Device Efficiency Accessibility Reusability Metrics Completeness Product Maintainability Structuredness Revisio Conciseness n Portability Device Independence Testability Legibility Self-descriptiveness 20 Traceability
  21. 21. Direct and Indirect Matrices
  22. 22. Measurement Basics• Direct and Indirect Measurement – Direct measure – relates an attribute to a number or symbol without reference to no other object or attribute (e.g., height). – Indirect measure • Used when an attribute must be measured by combining several of its aspects (e.g., density) • Requires a model of how measures are related to each other 22
  23. 23. Measurement Basics• Direct and Indirect Measures for Software – examples – Direct • Length or source code (lines of code) • Duration of testing process • Number of defects discovered during test • Time a developer spends on a project – Indirect • Programmer productivity (LOC/workmonths of effort) • Module defect density (number of defects/module size) • Defect detection efficiency (# defects detected/total defects) • Requirements stability (initial # requirements/total # requirements) • Test effectiveness ratio (number of items covered/total number of items) • System spoilage (effort spent fixing faults/total project effort) 23
  24. 24. Quality Models and Measures
  25. 25. Software product quality metrics• The quality of a product:- the “totality of characteristics that bear on its ability to satisfy stated or implied needs”. Metrics of the external quality attributes producer’s perspective: “conformance to requirements” customer’s perspective: “fitness for use” - customer’s expectations
  26. 26. Quality metrics• Two levels of software product quality metrics: Intrinsic product quality Customer oriented metrics
  27. 27. Intrinsic product quality metrics:  Reliability: number of hours the software can run before a failure  Defect density (rate): number of defects contained in software, relative to its size.Customer oriented metrics:  Customer problems  Customer satisfaction
  28. 28. Intrinsic product quality metrics Reliability --- Defect density• Correlated but different!• Both are predicted values.• Estimated using static and dynamic modelsDefect: an anomaly in the product (“bug”)Software failure: an execution whose effect is not conform tosoftware specification
  29. 29. ReliabilityReliability metrics:MTBF (Mean Time Between Failures)MTTF (Man Time To Failure)
  30. 30. MTBF (Mean Time Between Failures): the expected time between two successive failures of a system expressed in hours a key reliability metric for systems that can be repaired or restored(repairable systems) applicable when several system failures are expected.For a hardware product, MTBF decreases with the its age.
  31. 31. MTTF (Man Time To Failure): the expected time to failure of a system in reliability engineering  metric for non-repairable systems non-repairable systems can fail only once; example, a satellite is not repairable.Mean Time To Repair (MTTR): average time to restore a system after a failureWhen there are no delays in repair: MTBF = MTTF + MTTRSoftware products are repairable systems!Reliability models neglect the time needed to restore the system after a failure.with MTTR =0  MTBF = MTTFAvailability = MTTF / MTBF = MTTF / (MTTF + MTTR)
  32. 32. 3.1.2. Defect rate (density) Number of defects per KLOC or per Number of Function Point, in a given time unitExample:“The latent defect rate for this product, during next four years, is 2.0defects per KLOC”. Crude metric: a defect may involve one or more lines of codeLines Of Code-Different counting tools-Defect rate metric has to be completed with the counting method for LOC!-Not recommended to compare defect rates of two products written indifferent languages
  33. 33. Reliability or Defect Rate ?Reliability: often used with safety-critical systems such as: airline traffic control systems,avionics, weapons. (usage profile and scenarios are better defined)Defect density: in many commercial systems (systems for commercial use) • there is no typical user profile • development organizations use defect rate for maintenance cost and resource estimates • MTTF is more difficult to implement and may not be representative of all customers.
  34. 34. Customer Oriented Metrics Customer Problems Metric Customer problems when using the product: valid defects, usability problems, unclear documentation, user errors. Problems per user month (PUM) metric: PUM = TNP/ TNM TNP: Total number of problems reported by customers for a time period TNM: Total number of license-months of the software during the period = number of install licenses of the software x number of months in the period
  35. 35. 3.2.2. Customer satisfaction metrics Often measured on the five-point scale: 1. Very satisfied 2. Satisfied 3. Neutral 4. Dissatisfied 5. Very dissatisfied IBM: CUPRIMDSO (capability/functionality, usability, performance, reliability, installability, maintainability, documentation /information, service and overall) Hewlett-Packard: FURPS (functionality, usability, reliability, performance and service)
  36. 36. Overview of Project ManagementProject Concept & Definition Benefit Delivery Management Project P Es g Phase or Stage Planning t im ati End n Re g R so ur cin Pla Mobilis- Management, Control nin n ation & Reporting QA g Benefit Tracking & Management Quality Management Risk Management Issue Management Scope & Change Control Configuration Management Documentation Control Team building, Collaboration and Internal Communication Organisational Change Management External Communication Procurement & Accounting Subcontractor Management
  37. 37. Project Management• Project Failures• Project Successes
  38. 38. Project Failure• Identify reasons that project fail
  39. 39. Reasons for Project Failure1. Poor project and program management discipline2. Lack of executive-level support3. No linkage to the business strategy4. Wrong team members5. No measures for evaluating the success of the project6. No risk management7. Inability to manage change
  40. 40. Project Success Criteria• On time• On budget• Meeting the goals that have been agreed upon
  41. 41. Iron Triangle
  42. 42. Seven Traits of Good ProjectManagers Trait 1 Enthusiasm for the project Trait 2 Ability to manage change effectively Trait 3 A tolerant attitude toward ambiguity Trait 4 Team – building and negotiating skills
  43. 43. Seven Traits of Good ProjectManagersTrait 5 A customer-first orientationTrait 6 Adherence to the priorities of businessTrait 7 Knowledge of the industry or technology
  44. 44. Project Management• Project Management – The “application of knowledge, skills, tools and techniques to project activities to meet project requirements.”• 9 Knowledge areas
  45. 45. Integration Management• Fitting everything together• Planning• Project Changes
  46. 46. Project Scope Management• Clear scope statement• Prevent scope creep
  47. 47. Project Time Management• Time and Schedule – Planning – Managing
  48. 48. Project Cost Management• Manage costs – Out of your control – Competing projects
  49. 49. Project Quality Management• Planning quality• Enforcing quality• Checking quality control
  50. 50. Project Human ResourceManagement• Organizational planning• Staff acquisition• Making a team
  51. 51. Project CommunicationsManagement• Communication plan
  52. 52. Project Risk Management• Risk management plan
  53. 53. Project Procurement Management• Acquisition and contract management
  54. 54. Project Life Cycle
  55. 55. SMART goals• S – Specific• M – Measurable• A – Agreed upon• R – Realistic• T – Time related
  56. 56. Risk management• Identify – Sources of risk • Funding • Time • Staffing • Customer relations • Project size and/or complexity • Overall structure • Organizational resistance • External factors
  57. 57. Work Breakdown Structure (WBS)• Breaks large project into manageable units – Total project – Subprojects – Milestones (completion of an important set of work packages) – Major activities (summary tasks) – Work packages (tasks, activities, work elements)
  58. 58. Work Breakdown Structure 58
  59. 59. WBS• Helps to: – Identify all work needing to be done – Logically organize work so that is can be scheduled – Assign work to team members – Identify resources needed – Communicate what has to be done – Organize work using milestones
  60. 60. Budgeting• Budget = People + Resources + Time
  61. 61. Direct & Indirect Costs• Direct costs – Directly attributed to the project• Indirect costs – Shared amongst other projects
  62. 62. Types of Budgeting• Bottom-up• Top-Down• Phased
  63. 63. Project Time Management
  64. 64. Complexity of Scheduling Project Activities• Large number of activities• Precedence relationships• Limited time of the project 64
  65. 65. Importance of Project Schedules  Managers often cite delivering projects on time as one of their biggest challenges  Average time overrun from 1995 CHAOS report was 222%  Time has the least amount of flexibility; it passes no matter what  Schedule issues are the main reason for conflicts on projects, especially during the second half of projects
  66. 66. Conflict Intensity over the Life of A Project 0.40 0.35 0.30 Conflict Intensity Schedules 0.25 Average Total Conflict Priorities Manpower 0.20 Technical opinions Procedures 0.15 Cost Personality conflicts 0.10 0.05 0.00 Project Early Phases Middle Phases End Phases Formation
  67. 67. Project Time Management Processes  Project time management involves the processes required to ensure timely completion of a project, including:  Activity definition  Activity sequencing  Activity duration estimating  Schedule development  Schedule control
  68. 68. Where Do Schedules Come From? Defining Activities:  Project schedules grow out of the basic documents that initiate a project  Project charter includes start and end dates and budget information  Activity definition involves developing a more detailed PLANS and supporting explanations to understand all the work to be done
  69. 69. Activity Sequencing  Involves reviewing activities and determining dependencies  Mandatory dependencies: inherent in the nature of the work; hard logic  Optional dependencies: defined by the project team; soft logic  We must determine dependencies in order to use critical path analysis
  70. 70. Project Network Diagrams  Project network diagrams are the preferred technique for showing activity sequencing  A project network diagram is a schematic display of the logical relationships among, or sequencing of, project activities
  71. 71. Activity-on-Arrow (AOA) Network Diagram
  72. 72. Arrow Diagramming Method (ADM)  Also, called activity-on-arrow (AOA) project network diagrams  Activities are represented by arrows  Nodes or circles are the starting and ending points of activities  Can only show finish-to-start dependencies
  73. 73. Process for Creating AOA Diagrams 1. Find all of the activities that start at node 1. Draw their finish nodes and draw arrows between node 1 and those finish nodes. Put the activity letter or name and duration estimate on the associated arrow 2. Continue drawing the network diagram, working from left to right. Look for bursts and merges. Bursts occur when a single node is followed by two or more activities. A merge occurs when two or more nodes precede a single node 3. Continue drawing the project network diagram until all activities are included on the diagram that have dependencies 4. As a rule of thumb, all arrowheads should face toward the right, and no arrows should cross on an AOA network diagram
  74. 74. Project Planning When ActivityTimes are Known • Inputs – list of the activities that must be completed – activity completion times – activity precedence relationships 74
  75. 75. Project Planning When Activity Times are Known continued• Outputs – graphical representation of project – time to complete project – identification of critical path(s) and activities – activity and path slack – earliest and latest time each activity can be started – earliest and latest time each activity can be completed 75
  76. 76. ExampleActivity Time Preceded By A 10 -- B 7 -- C 5 A D 13 A E 4 B,C F 12 D G 14 E 76
  77. 77. Network Diagram 77
  78. 78. Early Start and Finish Times 78
  79. 79. Latest Start and Finish Times 79
  80. 80. Activity Slack TimeTES = earliest start time for activityTLS = latest start time for activityTEF = earliest finish time for activityTLF = latest finish time for activity Activity Slack = TLS - TES = TLF - TEF 80
  81. 81. Precedence Diagramming Method (PDM)  Activities are represented by boxes  Arrows show relationships between activities  More popular than ADM method and used by project management software  Better at showing different types of dependencies
  82. 82. Task Dependency Types
  83. 83. Activity Duration Estimating  After defining activities and determining their sequence, the next step in time management is duration estimating  Duration includes the actual amount of time worked on an activity plus elapsed time  People doing the work should help create estimates, and an expert should review them
  84. 84. Schedule Development  Schedule development uses results of the other time management processes to determine the start and end date of the project and its activities  Ultimate goal is to create a realistic project schedule that provides a basis for monitoring project progress for the time dimension of the project  Important tools and techniques include Gantt charts, PERT analysis, and critical path analysis
  85. 85. Gantt ChartPERT & CPM
  86. 86. Critical Path Method (CPM)  CPM is a project network analysis technique used to predict total project duration  A critical path for a project is the series of activities that determines the earliest time by which the project can be completed  The critical path is the longest path through the network diagram
  87. 87. Finding the Critical Path  First develop a good project network diagram  Add the durations for all activities on each path through the project network diagram  The longest path is the critical path
  88. 88. Determining the Critical Path
  89. 89. More on the Critical Path  If one of more activities on the critical path takes longer than planned, the whole project schedule will slip unless corrective action is taken  Misconceptions:  The critical path is not the one with all the critical activities; it only accounts for time  There can be more than one critical path if the lengths of two or more paths are the same  The critical path can change as the project progresses
  90. 90. Using Critical Path for Schedule Trade-offs  Knowing the critical path helps you make schedule trade-offs  Free slack or free float is the amount of time an activity can be delayed without delaying the early start of any immediately following activities  Total slack or total float is the amount of time an activity may be delayed from its early start without delaying the planned project finish date
  91. 91. Techniques for Shortening a Project Schedule  Shortening durations of critical tasks by adding more resources or changing their scope  Crashing tasks by obtaining the greatest amount of schedule compression for the least incremental cost  Fast tracking tasks by doing them in parallel or overlapping them
  92. 92. Shortening Project Schedules Original schedule Shortened duration Overlapped tasks
  93. 93. What are Gantt and PERT?Gantt and PERT charts are both “CPM” (Critical Path Method) tools to:• manage the tasks involved in big and complex projects• let project managers organise time, people, equipment and money• ensure the right people and equipment are in the right place and the right time • allow managers to monitor the progress of a project 93
  94. 94. Gantt Basics• Basically, a timeline with tasks that can be connected to each other• Note the spelling!• It is not all-capitals!• Can be created with simple tools like Excel, but specialised tools like Microsoft Project make life easier 94
  95. 95. Making a Gantt chart • Step 1 – list the tasks in the project 95
  96. 96. Making a Gantt chart • Step 2 – add task durations 96
  97. 97. Making a Gantt chart • Step 3 – add dependencies (which tasks cannot start before another task finishes) 97
  98. 98. Notes •The arrows indicate dependencies. •Task 1 is a predecessor of task 2 – i.e. task 2 cannot start before task 1 ends. •Task 3 is dependent on task 2. Task 7 is dependent on two other tasks •Electrics, plumbing and landscaping are concurrent tasks and can happen at the same time, so they overlap on the chart. All 3 can start after task 4 ends. •Task 9 has zero duration, and is a milestone 98
  99. 99. Making a Gantt chart • Step 4 – find the critical pathThe critical path is the sequence of tasks from beginning to end that takesthe longest time to complete.Any task on the critical path is called a critical task.No critical task can have its duration changed without affecting the enddate of the project. 99
  100. 100. PERT basics• PERT is an acronym so it’s in capital letters• Gantt is a name, so only has an initial capital• In Gantt chart, the length of a task’s bar is proportional to the length of the task. This rarely applies to PERT charts.• There are a few different “flavours” of PERT and Gantt charts… 100
  101. 101. PERT charts This PERT chart follows the “Activity on Arrow” style. •The tasks are shown by arrows. Task name are shown by letters, in this case. •The circles are called nodes. The nodes indicate the start or end of tasks. •Task durations are the shown by the numbers. 101
  102. 102. ‘Activity on Node’ style PERT Activity on Node is a different flavour of PERT: this time the nodes are tasks, and the arrows are merely connectors. The examiners prefer very simple PERT charts – 102 sometimes hybrid beasts that defy categorisation.
  103. 103. PERT EXAMPLE A PERT PROBLEM 103
  104. 104. • 1: Which tasks are on the critical path?• 2: What is the slack time for tasks C, D and G?• 3: Task C is delayed by one day. What impact would this have on the completion date of the project? Why?• 4: Task A will be delayed by 2 days because some equipment has arrived late. If the project manager wants to finish the project on time he will need to shorten the duration of one or more of the tasks. How can he achieve this?• 5: The project manager reduces the durations of tasks D and F by one day each. How will this affect the finishing date of the project? 104
  105. 105. 1: Which tasks are on the critical path? Possible paths: A,B,C,E,I = 2+3+1+4+3 = 13 days A,B,D,F,I = 2+3+3+3+3 = 14 days A,G,H,I = 2+2+5+3 = 12 days ANSWER: A,B,D,F,I 105
  106. 106. 2: What is the slack time for tasks C, D and G? TASKS C and D… Path C,E = 5 days, Path D,F = 6 days Difference (slack) = 1 day for tasks C or E compared to D,FTASK G…Path B,C,E = 8 days. Path B, D, F = 9 daysPath G, H = 7 days.So G & H have 2 days’ slack between them.B,C or E have 1 day’s slack. 106B,D,F have no slack.
  107. 107. 3: Task C starts one day late. What impact would this have on the completion date of the project? Why? No impact, because task C has one day’s slack (as discovered in previous question!) 107
  108. 108. 4: Task A will be delayed by 2 days because some equipment has arrived late. If the project manager still wants to finish the project within the original time frame, he will need to shorten the time for one or more of the tasks. What steps can he take to reduce the number of days allocated to a task? The answer has NOTHING to do with the chart! Just say how jobs can be finished more quickly, e.g. bringing in extra workers from slack tasks, working longer hours, working weekend, streamlining work practices, automating tasks etc. 108
  109. 109. • 5: The project manager decides to reduce the time needed for tasks D and F by one day each. How effective will this reduction be in achieving his aim of maintaining the original finish time for the project? It is only partially effective. Reducing tasks D and F by one day each means the path A,B,D,F,I is now 12 days long. However, path A,B,C,E,I is still 13 days so it becomes the longest path, and therefore becomes the new critical path. The project is now 13 days long instead of 14, a saving of only one day. 109
  110. 110. Project Management Software • There are a number of project management software tools available to help in the planning and control of large software development projects. – E.g. MS Project is a CASE software tool for Project Management • Most tools include functions to plan, schedule and control, but decision-making still has to be done by the project manager.
  111. 111. Project Management Software• Benefits of project management software: – Calculate project schedule – Resource smoothing – Automatic generation of reports and charts• Limitations of project management software – Allocation of resources to tasks – Estimation of tasks durations – Make decisions

×