5/23/10 31P5 Software Engineering
Upcoming SlideShare
Loading in...5
×
 

5/23/10 31P5 Software Engineering

on

  • 338 views

 

Statistics

Views

Total Views
338
Views on SlideShare
338
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    5/23/10 31P5 Software Engineering 5/23/10 31P5 Software Engineering Presentation Transcript

    • 31P5: Software Engineering I Project Planning
    • Aims
      • To understand the main management activities involved in Project Planning
      • To develop a behavioural model of Project Management and to use it to ask “What if” questions
      • To consider a number of project costing techniques
    • Management activities
      • No standard job description for Software Manager
      • Generally involves the following activities:
        • proposal writing
        • project planning and scheduling
        • project costing
        • project monitoring and reviews
        • personnel selection and evaluation
        • report writing and presentations
    • Software project planning
      • The project plan sets out the resources available, the work breakdown, and the schedule
      • The project plan may be: a single document including all the different types of plans such as:
        • Quality plan : quality procedures and standards to be used for system validation
        • Validation plan : approach, resources and schedule for system validation
        • Configuration management plan : configuration management procedures and structures used
        • Maintenance plan : predicts maintenance requirements of system, maintenance costs and effort required
        • Staff development plan : describes how skills and experience of project team members developed
    • Planning (cont’d)
      • Or, a document concerned with the development process:
        • Introduction : briefly, the objectives of project and sets constraints (e.g., budget, time, etc.) which affect project management
        • Project organisation : way in which development team are organised, the people involved and their roles in the team
        • Risk analysis : possible project risks, their likelihood of occurrence, and risk reduction strategies proposed
        • Hardware/software : support required for the development; if hardware to be bought, estimates of price and delivery schedule
    • Planning (cont’d)
        • Work breakdown : breakdown of project into activities and tasks, and identifies milestones and deliverables associated with each task
        • Project schedule : dependencies between activities, estimated time required to reach each milestone, and allocation of people to activities
        • Monitoring and reporting mechanisms : management reports which should be produced, when, and the monitoring mechanism.
    • An Integrative View
      • Integrates:
        • management-type functions of planning, controlling, staffing
        • production-type functions of designing, coding, reviewing, testing
      • “ The behaviour of an individual subsystem in isolation may be different from its behaviour when it interacts with other subsystems.”
      • Software project management is a DYNAMIC and COMPLEX process.
      • Control of the process involves application of FEEDBACK CONTROL SYSTEMS principles
      • Feedback control may be positive or negative
    • Critical management decisions
      • A project is behind schedule. Possible management actions include revising the completion date, holding to the planned completion date but hiring more staff, and holding to the planned completion date but working current staff overtime. What are the implications of the alternatives?
      • How much of the development effort should be expended on quality assurance and how does that affect completion time and total cost?
      • What is the impact of different distributions of effort among project phases (e.g., should the division of effort between development and testing be 80:20 or 60:40 percent)?
    • Critical management decisions (cont’d)
      • What are the reasons for and implications of the differences among potential productivity, actual productivity, and perceived productivity?
      • Why does the “90% completion syndrome”, whereby a project appears to get stuck when it reaches the 90% completion point, chronically occur?
    • Simple Model: software project process
    • Simple Model: software project process
      • Project resources: manpower, facilities, equipment
      • Work completed on project reported through project control system
      • Reports accumulate and are processed to create project’s forecast completion date by adding indicated time remaining to current date
      • Assessing remaining time:
        • effort (person-days) to complete job
        • level of personnel working on project
        • perceived productivity of project team
      • Original scheduled completion date
      • Feedback loop closed: difference (5-4) causes adjustments in magnitude or allocation of resources
    • Adding more people to a late project
    • Adding more people to a late project
      • Model suggests direct relationship
      • Increase people resources Increase in work rate
      • Problem:
        • more people higher communication, training cost
        • lower project team productivity
        • lower progress rates
        • delay to already late project
        • additional round of loop
        • more people
        • … ..
      • Brook’s Law : adding more people to a late project makes it later
    • Adjusting schedule of late project
    • Adjusting schedule of late project
      • Impact of project pressures (e.g., schedule pressure) on developers’ actions/decisions
      • Project behind schedule:
        • developers work longer hours
        • concentrate on essential task
      • Boehm experiment: found number of person-hours devoted to project increased by 100%
      • Schedule pressure affects Productivity
      • Problem:
        • Schedule pressure increased error rate
        • rework on project: negative effect
      • “ People under time pressure don’t work better, they just work faster … The first casuality [is] the quality of the software delivered”
    • Adjusting schedule of late project
    • Adjusting schedule of late project
      • Impact of schedule pressure on workforce turnover rate:
      • Workforce turnover rate increases when scheduling pressure persists
        • can be very costly
        • high turnover rate lower productivity on project
    • How late is a late project?
    • How late is a late project?
      • Difficult to assess real progress on a project because of the nature of software (intangible?); very few sensible and usable metrics
      • Therefore,
        • Perceived progress rate =|= Real progress rate
      • Errors in perceived cumulative progress + bias (overoptimism) + delay (in gathering and processing control information) distorts reported progress
    • Comprehensive Model
      • Model so far too simple
      • It needs:
        • significantly more depth and detail
        • a systematic way to organise the information
      • To achieve this need to consider a number of subsystems, including HUMAN RESOURCE MANAGEMENT, SOFTWARE PRODUCTION, CONTROL, PLANNING
    • Single-Project Model
    • Overview of Single-Project Model
      • Human Resource Management Deals with Hiring, Assimilation and Transfer of People
      • Workforce may be Newly Hired or Experienced
      • needed to capture differences in productivity, error proneness
      • allows the capture of training processes to assimilate new members:
        • normally, veterans train newcomers
        • training overheads significantly affect project’s progress by utilising veterans’ productivity
    • Software Production
      • Includes Designing, Coding, Testing
      • Reviews to detect errors, e.g., quality assurance via structured walkthroughs
      • Some errors are caught by testing
      • Productivity = Potential productivity — Faulty process losses
      • Potential productivity depends on the nature of
        • communication overheads
        • coordination overheads
        • low motivation
    • Control
      • As progress is made, it is reported
      • Information is often inaccurate!
        • Problems to deal with
          • information flow
          • time lags
          • distortion
        • early in project: progress measured by resources used
        • later: progress measured by work actually accomplished
    • Planning
      • Project resources and schedule estimates are made and revised, e.g.,
        • project behind schedule
        • Workforce needed = Person-days remaining / Time remaining
      • Time remaining is affected by workforce stability and workforce ceiling limitations (e.g., budget constraints)
      • Possible to extend our single-project model to multi-project model
        • coupling between single-project models, e.g., at the human resources level with sharing of staff
    • Project Planning Estimation
      • The major issues which the project plan addresses are:
        • Cost estimation
        • Schedule and milestones
        • Personnel plan
        • Team structure
        • Software quality assurance plans
        • Configuration management plans
        • Project minotoring plans
        • Risk management plans
    • Major cost estimation techniques System level focus, efficient Less detailed basis; less stable Bottom-up More detailed basis More stable Fosters individual commitment May overlook systems costs Requires more effort Method Strengths Weaknesses Algorithmic Objective, repeatable, analysable formulae Efficient, good for sensitivity analysis Objectively calibrated to experience Subjective inputs Assessment of exceptional circumstances Calibrated to past, not future Expert judgement Assessment of representativeness interactions, exceptions No better than participants Biases, incomplete recall Analogy Based on representative experience Representativeness of experience Parkinson Correlates with some experience Re-enforces poor practice Price-to-win Often gets contract! Generally produces large overruns Top-down
    • Summary
      • A number of management activities associated with project planning have been identified
      • A simple model of project management has been developed and used to discuss simple problems and their solutions
      • Cost/effort estimation approaches, their strengths and weaknesses considered
      • In the next section, a particular cost/effort/schedule technique will be highlighted