csc 205: software engineering i
DESCRIPTION
CSC 205: Software Engineering I. Dr. Franz J. Kurfess Computer Science Department Cal Poly. Introduction Requirements Engineering Requirements Elicitation Requirements Management Project Management System Design Methods and Notations. Design Models and Object-Oriented Design - PowerPoint PPT PresentationTRANSCRIPT
© 2000 Franz Kurfess Project Management 1
CSC 205: Software Engineering ICSC 205: Software Engineering I
Dr. Franz J. Kurfess
Computer Science Department
Cal Poly
© 2000 Franz Kurfess Project Management 2
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
© 2000 Franz Kurfess Project Management 3
Chapter OverviewProject ManagementChapter Overview
Project Management Motivation Objectives Management activities Project planning
Project scheduling Risk management Important Concepts and
Terms Chapter Summary
© 2000 Franz Kurfess Project Management 8
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
© 2000 Franz Kurfess Project Management 10
Project Management
organizing, planning and scheduling software projects management activities project planning project scheduling risk management
[Sommerville 01]
© 2000 Franz Kurfess Project Management 11
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]
© 2000 Franz Kurfess Project Management 12
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]
© 2000 Franz Kurfess Project Management 13
proposal writingproject planning and schedulingproject costingproject monitoring and reviewspersonnel selection and evaluationreport writing and presentations
Management Activities
[Sommerville 01]
© 2000 Franz Kurfess Project Management 14
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]
© 2000 Franz Kurfess Project Management 15
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]
© 2000 Franz Kurfess Project Management 16
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]
© 2000 Franz Kurfess Project Management 17
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]
© 2000 Franz Kurfess Project Management 18
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]
© 2000 Franz Kurfess Project Management 19
Project Plan Structure
introductionproject organisationrisk analysishardware and software resource requirementswork breakdownproject schedulemonitoring and reporting mechanisms
[Sommerville 01]
© 2000 Franz Kurfess Project Management 20
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]
© 2000 Franz Kurfess Project Management 21
Milestones in the RE Process
EvaluationreportPrototypedevelopmentRequirementsdefinitionRequirementsanalysisFeasibilityreportFeasibilitystudy ArchitecturaldesignDesignstudyRequirementsspecificationRequirementsspecificationACTIVITIESMILESTONES
[Sommerville 01]
© 2000 Franz Kurfess Project Management 22
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]
© 2000 Franz Kurfess Project Management 23
The Project Scheduling ProcessThe Project Scheduling Process
Estimate resourcesfor activitiesIdentify activitydependenciesIdentifyactivities Allocate peopleto activitiesCreate projectchartsSoftwarerequirements Activity chartsand bar charts[Sommerville 01]
© 2000 Franz Kurfess Project Management 24
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]
© 2000 Franz Kurfess Project Management 25
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]
© 2000 Franz Kurfess Project Management 26
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
© 2000 Franz Kurfess Project Management 27
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]
© 2000 Franz Kurfess Project Management 28
Activity Timeline4/711/718/725/71/88/815/822/829/85/912/919/9T4T1T2M1T7T3M5T8M3M2T6T5M4T9M7T10M6T11M8T12
Start
Finish[Sommerville 01]
© 2000 Franz Kurfess Project Management 29
Staff Allocation4/711/718/725/1/88/815/822/829/85/912/919/9T4T8 T11T12T1T3T9T2T6T10T7T5FredJaneAnneMaryJim
[Sommerville 01]
© 2000 Franz Kurfess Project Management 30
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]
© 2000 Franz Kurfess Project Management 31
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]
© 2000 Franz Kurfess Project Management 32
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]
© 2000 Franz Kurfess Project Management 33
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
© 2000 Franz Kurfess Project Management 34
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]
© 2000 Franz Kurfess Project Management 35
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]
© 2000 Franz Kurfess Project Management 36
Schedule RisksSchedule Risks
feature creepgold-platingshortchanged qualityoptimistic schedulesinadequate designsilver-bullet syndromefriction between developers and customers
[Kearns 00]
© 2000 Franz Kurfess Project Management 37
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]
© 2000 Franz Kurfess Project Management 38
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]
© 2000 Franz Kurfess Project Management 39
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]
© 2000 Franz Kurfess Project Management 40
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]
© 2000 Franz Kurfess Project Management 41
Requirements-related Risks: Verification
Requirements-related Risks: Verification
unverified requirementsinadequate requirements inspection training
[Kearns 00]
© 2000 Franz Kurfess Project Management 42
Requirements Related Risks: Management
Requirements Related Risks: Management
changing requirementslack of an effective, well-defined change processoverlooked or duplicated requirementsexpanding project scope
[Kearns 00]
© 2000 Franz Kurfess Project Management 43
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]
© 2000 Franz Kurfess Project Management 44
The Risk Management ProcessThe Risk Management Process
Risk avoidanceand contingencyplansRisk planningPrioritised risklistRisk analysisList of potentialrisksRiskidentification RiskassessmentRiskmonitoring[Sommerville 01]
© 2000 Franz Kurfess Project Management 45
Risk IdentificationRisk Identification
technology riskspeople risksorganisational risksrequirements risksestimation risks
[Sommerville 01]
© 2000 Franz Kurfess Project Management 46
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]
© 2000 Franz Kurfess Project Management 47
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]
© 2000 Franz Kurfess Project Management 48
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]
© 2000 Franz Kurfess Project Management 49
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]
© 2000 Franz Kurfess Project Management 50
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]
© 2000 Franz Kurfess Project Management 51
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]
© 2000 Franz Kurfess Project Management 52
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]
© 2000 Franz Kurfess Project Management 53
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]
© 2000 Franz Kurfess Project Management 54
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]
© 2000 Franz Kurfess Project Management 55
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]
© 2000 Franz Kurfess Project Management 56
What Risks Apply to Your Project?What Risks Apply to Your Project?
[Kearns 00]
© 2000 Franz Kurfess Project Management 57
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]
© 2000 Franz Kurfess Project Management 60
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
© 2000 Franz Kurfess Project Management 61
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
© 2000 Franz Kurfess Project Management 62
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 63