© 2000 franz kurfess project management 1 csc 205: software engineering i dr. franz j. kurfess...

© 2000 Franz Kurfess Project Management 1

CSC 205: Software Engineering ICSC 205: Software Engineering I

Dr. Franz J. Kurfess

Computer Science Department

Cal Poly


Course OverviewCourse Overview Introduction Requirements Engineering

Requirements Elicitation Requirements Management

Project Management System Design Methods

and Notations

Design Models and Object-Oriented Design

Design Analysis and Formal Specification

Design Analysis and Verification

Conclusions


Chapter OverviewProject ManagementChapter Overview

Project Management Motivation Objectives Management activities Project planning

Project scheduling Risk management Important Concepts and

Terms Chapter Summary


ObjectivesObjectives

to introduce software project management and to describe its distinctive characteristics

to discuss project planning and the planning processto show how graphical schedule representations are

used by project managementto discuss the notion of risks and the risk

management process


Project Management

organizing, planning and scheduling software projects management activities project planning project scheduling risk management

[Sommerville 01]


concerned with activities involved in ensuring that software is delivered on time and on schedule in accordance with the requirements of the organisations

developing and procuring the softwareneeded because software development is always subject

to budget and schedule constraints set by the organisation developing the software influenced by the customer possibly additional sources of constraints

external (standards, governing bodies) internal (resource limitations, internal processes)

Software Project Management

[Sommerville 01]


the product is intangiblethe product is uniquely flexiblesoftware engineering is not (yet) recognized as an

engineering discipline with the same status as mechanical, electrical engineering, etc.

the software development process is not (yet) standardized

many software projects are “one-of-a-kind” projects

Software Management Distinctions

[Sommerville 01]


proposal writingproject planning and schedulingproject costingproject monitoring and reviewspersonnel selection and evaluationreport writing and presentations

Management Activities

[Sommerville 01]


these activities are not peculiar to software management

many techniques of engineering project management are equally applicable to software project management

technically complex engineering systems tend to suffer from the same problems as software systems

Management Commonalties

[Sommerville 01]


Project Staffing

it may not be possible to appoint the ideal people to work on a project project budget may not allow for the use of highly-paid staff staff with the appropriate experience may not be available an organisation may wish to develop employee skills on a

software project

managers have to work within these constraints especially when there is an wide shortage of skilled IT staff

[Sommerville 01]


Project Planning

probably the most time-consuming project management activity

continuous activity from initial concept through to system delivery plans must be regularly revised as new information

becomes available

different types of plans may be developed to support the main software project plan that is

concerned with schedule and budget

[Sommerville 01]


Types of Project Plan

Plan DescriptionQuality plan Describes the quality procedures and

standards that will be used in a project.Validation plan Describes the approach, resources and

schedule used for system validation. Configurationmanagement plan

Describes the configuration managementprocedures and structures to be used.

Maintenance plan Predicts the maintenance requirements ofthe system, maintenance costs and effortrequired.

Staff development plan. Describes how the skills and experience ofthe project team members will bedeveloped.

[Sommerville 01]


Project Planning Process

Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverableswhile project has not been completed or cancelled loop

Draw up project scheduleInitiate activities according to schedule

Wait ( for a while ) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if ( problems arise ) then Initiate technical review and possible revision end ifend loop

[Sommerville 01]


Project Plan Structure

introductionproject organisationrisk analysishardware and software resource requirementswork breakdownproject schedulemonitoring and reporting mechanisms

[Sommerville 01]


Activity Organization

activities in a project should be organised to produce tangible outputs for management to judge progress

milestones are the end-point of a process activitydeliverables are project results delivered to

customersthe waterfall process allows for the straightforward

definition of progress milestones

[Sommerville 01]


Milestones in the RE Process

EvaluationreportPrototypedevelopmentRequirementsdefinitionRequirementsanalysisFeasibilityreportFeasibilitystudy ArchitecturaldesignDesignstudyRequirementsspecificationRequirementsspecificationACTIVITIESMILESTONES

[Sommerville 01]


Project Scheduling

split project into tasks and estimate time and resources required to complete each task

organize tasks concurrently to make optimal use of workforce

minimize task dependencies to avoid delays caused by one task waiting for another to complete

dependent on project managers intuition and experience

[Sommerville 01]


The Project Scheduling ProcessThe Project Scheduling Process

Estimate resourcesfor activitiesIdentify activitydependenciesIdentifyactivities Allocate peopleto activitiesCreate projectchartsSoftwarerequirements Activity chartsand bar charts[Sommerville 01]


Scheduling Problems

estimating the difficulty of problems and hence the cost of developing a solution is hard

productivity is not proportional to the number of people working on a task

adding people to a late project makes it later because of communication overheads

the unexpected can always happen allow contingency in planning

[Sommerville 01]


Bar Charts and Activity Networksgraphical notations used to illustrate the project scheduleshow project breakdown into tasks

tasks should not be too small they should take about a week or two

activity charts show task dependencies and the the critical path

bar charts show schedule against calendar timeproject scheduling software is available

not always easy to use often expensive

[Sommerville 01]


Task Durations and Dependencies

Task Duration (days) DependenciesT1 8T2 15T3 15 T1 (M1)T4 10T5 10 T2, T4 (M2)T6 5 T1, T2 (M3)T7 20 T1 (M1)T8 25 T4 (M5)T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)T11 7 T9 (M6)T12 10 T11 (M8)

[Sommerville 01]

T1, …, T12 Tasks M1, …, T8Milestones


Activity Network

startT2M3T6FinishT10M7T5T7M2T4M5 T8

4/7/998 days14/7/9915 days4/8/9915 days25/8/997 days5/9/9910 days19/9/9915 days11/8/99

25 days10 days20 days5 days25/7/9915 days25/7/9918/7/9910 days

T1M1T3T9M6T11M8T12M4

[Sommerville 01]


Activity Timeline4/711/718/725/71/88/815/822/829/85/912/919/9T4T1T2M1T7T3M5T8M3M2T6T5M4T9M7T10M6T11M8T12

Start

Finish[Sommerville 01]


Staff Allocation4/711/718/725/1/88/815/822/829/85/912/919/9T4T8 T11T12T1T3T9T2T6T10T7T5FredJaneAnneMaryJim

[Sommerville 01]


Risk ManagementRisk Management

risk management is concerned with identifying risks and drawing up plans to minimise their impact 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

[Sommerville 01]


Risk ManagementRisk Management

manage risks so they don’t manage you

what is a risk? something that can adversely affect project success cost schedule technical: functional, non-functional

once a risk happens -- it’s an issue goals

prevent risks from escalating to issues if it happens minimize or control the impact

[Kearns 00]


Approaches to Risk ManagementApproaches to Risk Management

some approaches crisis management fix on failure risk mitigation prevention elimination of root causes “wait and see”

maybe the most popular risk management approach

[Kearns 00]


CSC 205/206 Risk ManagementCSC 205/206 Risk Management

think about the risks that your project will face over the course of the next two quarters

develop an approach to identify, address, and eliminate sources of risk before they prevent the successful completion of your

software project

monitor the risks and adapt your risk management approach if necessary


Elements of Risk ManagementElements of Risk Management

risk assessment risk identification risk analysis risk prioritization

risk avoidancerisk control

plan to deal with each significant risk execute the plan monitor risk activities with specific milestones

[Kearns 00]


General RisksGeneral Risks

classic risks people-related mistakes process-related mistakes product-related mistakes technology-related mistakes

ignoring development fundamentals management, technical quality

failing to actively manage risks plan to deal with each significant risk execute the plan monitor risk activities with specific milestones

[Kearns 00]


Schedule RisksSchedule Risks

feature creepgold-platingshortchanged qualityoptimistic schedulesinadequate designsilver-bullet syndromefriction between developers and customers

[Kearns 00]


Risk Risk type DescriptionStaff 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 product There will be a larger number of changes to the

requirements than anticipated.Specification delays Project and product Specifications of essential interfaces are not

available on scheduleSize underestimate Project and product The size of the system has been underestimated.CASE tool under-performance

Product CASE tools which support the project do notperform as anticipated

Technology change Business The underlying technology on which the systemis built is superseded by new technology.

Product competition Business A competitive product is marketed before thesystem is completed.

Software RisksSoftware Risks

[Sommerville 01]


Requirements-related Risks: Elicitation

Requirements-related Risks: Elicitation

scope creepnot enough time spent on requirements developmentrequirements not complete, correct

e.g. new products

neglect of non-functional requirementslow customer involvement/approval of requirementsunstated requirementssolutions presented as needs

[Kearns 00]


Requirements-related Risks: Analysis

Requirements-related Risks: Analysis

no prioritization, can’t make tradeoffstechnically difficult features

success is always “right around the corner”

underestimating the overhead involved in learning and using new methods, tools, technologies

[Kearns 00]


Requirements-related Risks: Specification

Requirements-related Risks: Specification

expectation gaps between customer and developers even after requirements are written

time pressure to proceed despite gaps in requirements need target dates for all uncertainties to be resolved

ambiguous terminologyunnecessary design constraints included in the

system requirements specification, SRS

[Kearns 00]


Requirements-related Risks: Verification

Requirements-related Risks: Verification

unverified requirementsinadequate requirements inspection training

[Kearns 00]


Requirements Related Risks: Management

Requirements Related Risks: Management

changing requirementslack of an effective, well-defined change processoverlooked or duplicated requirementsexpanding project scope

[Kearns 00]


The Risk Management ProcessThe 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 minimize the effects of the risk

risk monitoring monitor the risks throughout the project

[Sommerville 01]


The Risk Management ProcessThe Risk Management Process

Risk avoidanceand contingencyplansRisk planningPrioritised risklistRisk analysisList of potentialrisksRiskidentification RiskassessmentRiskmonitoring[Sommerville 01]


Risk IdentificationRisk Identification

technology riskspeople risksorganisational risksrequirements risksestimation risks

[Sommerville 01]


Risks and Risk TypesRisks and Risk Types

Risk 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 whichlimit 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 areresponsible 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 areproposed.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.

[Sommerville 01]


Risk AnalysisRisk Analysis

assess probability and seriousness of each riskprobability may be very low, low, moderate, high or

very highrisk effects might be catastrophic, serious, tolerable

or insignificant

[Sommerville 01]


Risk AnalysisRisk AnalysisRisk Probability EffectsOrganisational financial problems force reductions in theproject budget.

Low Catastrophic

It is impossible to recruit staff with the skills requiredfor the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate SeriousSoftware components which should be reused containdefects which limit their functionality.

Moderate Serious

Changes to requirements which require major designrework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

The database used in the system cannot process as manytransactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High TolerableCustomers fail to understand the impact of requirementschanges.

Moderate Tolerable

Required training for staff is not available. Moderate TolerableThe rate of defect repair is underestimated. Moderate TolerableThe size of the software is underestimated. High TolerableThe code generated by CASE tools is inefficient. Moderate Insignificant

[Sommerville 01]


Risk PlanningRisk 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

[Sommerville 01]


Risk Management StrategiesRisk Management StrategiesRisk Strategy

Organisationalfinancial problems

Prepare a briefing document for senior management showing how theproject is making a very important contribution to the goals of thebusiness.

Recruitment problems Alert customer of potential difficulties and the possibility of delays,investigate buying-in components.

Staff illness Reorganise team so that there is more overlap of work and peopletherefore understand each other’s jobs.

Defective components Replace potentially defective components with bought-in components ofknown reliability.

Requirementschanges

Derive traceability information to assess requirements change impact,maximise information hiding in the design.

Organisationalrestructuring

Prepare a briefing document for senior management showing how theproject is making a very important contribution to the goals of thebusiness.

Database performance Investigate the possibility of buying a higher-performance database.

Underestimateddevelopment time

Investigate buying in components, investigate use of a programgenerator.

[Sommerville 01]


Risk MonitoringRisk 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

[Sommerville 01]


Risk Documentation: Risk Item Tracking Template

Risk Documentation: Risk Item Tracking Template

ID (name)initial date, date closeddescription of risk: condition, consequenceprobability: likelihood of riskimpact: consequencesexposure = probability * impactwarning flags (risk becomes an issue)mitigation plan (ways to control or minimize)owner

[Kearns 00]


Documenting RisksDocumenting Risks

goal is to identify the most significant risksdon’t try to be too precise too soonimportant to follow through. need owner and

checkpoints for each riskkeep top 10 list and focus on the ones that are

critical at any given time without losing sight of the others

[Kearns 00]


Risk FactorsRisk Factors

Risk type Potential indicators

Technology late delivery of hardware or support software, many reportedtechnology problems

People poor staff morale, poor relationships amongst team member, jobavailability

Organisational organisational gossip, lack of action by senior management

Tools reluctance by team members to use tools, complaints aboutCASE tools, demands for higher-powered workstations

Requirements many requirements change requests, customer complaints

Estimation failure to meet agreed schedule, failure to clear reported defects

[Sommerville 01]


What Are the Priorities of 205/206 Risks

What Are the Priorities of 205/206 Risks

risk probability size risk

of loss of loss exposure

[Kearns 00]


What Risks Apply to Your Project?What Risks Apply to Your Project?

[Kearns 00]


Approaches to Risk ResolutionApproaches to Risk Resolution

avoid risk get more information eliminate root causes assume risk - suffer the consequences publicize the risk contingency planning

[Kearns 00]


Important Concepts and TermsImportant Concepts and Terms requirements analysis requirements elicitation requirements specification requirements verification risk assessment risk avoidance risk control risk management risk monitoring risk planning software development process software project system engineering task

activity network bar chart business risk deliverable management milestone product risk project management project plan project risk project schedule proposal


Chapter SummaryChapter Summary

good project management is essential for project success

the intangible nature of software causes problems for management

managers have diverse roles but their most significant activities are planning, estimating and scheduling

planning and estimating are iterative processes which continue throughout the course of a project


a project milestone is a predictable state where some formal report of progress is presented to management.

risks may be project risks, product risks or business risks

risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats

Summary (cont.)

[Sommerville 01]

© 2000 franz kurfess project management 1 csc 205: software engineering i dr. franz j. kurfess...

Documents