Chapter 9
Download
1 / 21

Chapter 9 - PowerPoint PPT Presentation


  • 115 Views
  • Updated On :

Chapter 9. Project Management. Introduction. Effective project management requires a well-structured project and diligent oversight A well-structured project consists of a series of finite, effective, well-defined tasks

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 9' - brick


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chapter 9 l.jpg

Chapter 9

Project Management


Introduction l.jpg
Introduction

  • Effective project management requires a well-structured project and diligent oversight

  • A well-structured project consists of a series of finite, effective, well-defined tasks

  • The phases of a software development methodology define the tasks to be managed to some extent


Project management responsibilities l.jpg
Project Management Responsibilities

  • Establish project schedule

  • Establish project budget

  • Structure the project into units of work

  • Assemble the project team

  • Assign units of work to individuals

  • Determine necessary resources

  • Carry out risk assessment

  • Monitor progress of project

  • Ensure resulting system meets requirements


Slide4 l.jpg

Software Metrics

  • Reasons to measure software:

    • To facilitate estimation of development time

    • To assess the productivity of developers

    • To assess the quality of the project

  • Current schools of thought:

    • Size-oriented

    • Function-oriented

    • Object-oriented


Size oriented metrics l.jpg
Size-oriented Metrics

  • Attempt to quantify software projects by using the size of the project to normalize other quality measures

  • Possible data to collect:

    • number of lines of code

    • number of person-months to complete

    • cost of the project

    • number of pages of documentation

    • number of errors corrected before release

    • number of bugs found post release


Problems with using lines of code loc as metric l.jpg
Problems with using Lines of Code (LOC) as Metric

  • Lines of source code comprising a project are not always good gages to the size and complexity of a project:

    • LOC to complete a task is language dependent

    • Code reuse reduces LOC but requires more effort, thus well-design system are penalized

    • Using a LOC based metric encourages programmers to create more LOC, which is ultimately less efficient to maintain


Function oriented metrics l.jpg
Function-Oriented Metrics

  • Attempt to measure the functionality of a software system

  • Use a unit of measure called function point

  • Some possible function points:

    • Internal data structures

    • External data structures

    • User inputs

    • User outputs

    • Transformations

    • Transitions


Issues with using function oriented metrics l.jpg
Issues with Using Function-Oriented Metrics

  • Requires that analysis and design of a project are completed before workload estimation can occur

  • Validity of the workload estimation is limited to the accuracy of the analysis and design

  • Complexity determination of function points is subjective


Object oriented metrics l.jpg
Object-Oriented Metrics

  • Suggested measurements for object-oriented systems:

    • Number of scenario scripts

    • Number of key classes

    • Number of subsystems

  • Disadvantages:

    • Excludes a history-base of non-object-oriented projects


Quality control metrics l.jpg
Quality Control Metrics

  • Correctness

    • Defects per thousand LOC

  • Maintainability

    • Mean time to change

  • Integrity

    • Likelihood of thwarting an attack

  • Usability

    • Skill required of users

    • Time required to become proficient

    • Net increase in productivity

    • Users’ attitude toward system


Other project management concepts l.jpg
Other Project Management Concepts

  • Mythical staff-month

  • Configuration management

  • Change control

  • Configuration Audit

  • Configuration status reporting


Project planning l.jpg
Project Planning

  • Project planning requires:

    • Defining the iterations of the project

    • Specifying subtasks

    • Determining the project schedule and allocating time for each subtask

    • Associating deliverables with each subtask to verify progress

    • Dividing the subtasks among the developers

    • Scheduling any interdependent tasks to minimize delays - use task network or PERT chart


Monitoring project progress l.jpg
Monitoring Project Progress

  • Develop project milestones with associated deliverables to gage progress

  • Milestones should be created so that the project manager receives sufficient feedback at regular intervals

  • The feedback should take the form of a natural artifact of the development process

  • See figure 9.9 for a list of deliverables


Four stages of team development l.jpg
Four Stages of Team Development

  • Forming

  • Storming

  • Norming

  • Performing


Conflict resolution strategies l.jpg
Conflict Resolution Strategies

  • Arbitration

  • Rules and regulations

  • Confrontation

  • Negotiation

  • Separation

  • Neglect

  • Coordination device


Risk management l.jpg
Risk Management

  • Risk management provides a structured evaluation of a development project to draw attention to sources of risk

  • The need for risk management is demonstrated by the high failure rate for large-scale software development initiatives

  • Successful project management relies on the additional time that is built into the development schedule to accommodate some level of delay due to risk factors


What is risk l.jpg
What is Risk?

  • A risk is any unanticipated condition or event that causes one or more tasks to be delayed, lengthened, or fail

  • Risks can delay or prevent the completion of a task or project as a whole

  • Two very general categories of risk will be identified here, technical and human risk


Sources of technical risk l.jpg
Sources of Technical Risk

  • Project complexity

  • Project size

  • Use of state-of-the-art technology

  • Network vulnerability

  • Disgruntled employees

  • Potential for white-collar crime

  • Data attainability

  • Accuracy of data source

  • Need for high-quality graphics


Sources of human risk l.jpg

Development team

Productivity

Experience

Knowledge

Dedication

End users

Technical knowledge

Support for project

Agreement on system

Administration

Budgetary constraints

Project priority

Realistic expectations

Sources of Human Risk


Consequences of risk l.jpg
Consequences of Risk

  • Delay project

  • Compromise the quality of the project

  • Cause the project to fail

  • Cause the project to be too expensive to implement or run


Reducing risk l.jpg
Reducing Risk

  • Early project evaluation

  • Early implementation of risky system aspects

  • Early use of new technology

  • Early resolution of class interaction problems