| Date post: | 07-Apr-2018 |
| Category: |
Documents |
| Upload: | victoria-friday-williams |
| View: | 217 times |
| Download: | 0 times |
of 49
8/6/2019 Risk Management w2
1/49
Risk Management
22/03/10
8/6/2019 Risk Management w2
2/49
Management-Topics covered
Management activities
Project planning
Project scheduling Risk management
8/6/2019 Risk Management w2
3/49
Concerned with activities involved in ensuring
that software is delivered
on time
within the budget in accordance with the requirements
Project management is needed because software
development is always subject to budget and schedule
constraints Set by the development organisation or the customer
Software project management
8/6/2019 Risk Management w2
4/49
The product is intangible (Progress cant be seen)
The product is uniquely flexible
The product is uniquely complex
The software development process is notstandardised
Many software projects are one-off projects (Lessonlearned from previous projects might not be applied)
Software management distinctions
8/6/2019 Risk Management w2
5/49
Proposal writing
Project planning and scheduling
Project costing Project monitoring and reviews
Personnel selection and evaluation
Report writing and presentations
Management activities
8/6/2019 Risk Management w2
6/49
Project staffing
May not be possible to appoint the ideal people to work on aproject
Project budget may not allow for the use ofhighly-paid staff
Staff with the appropriate experience may not be available
An organisation may wish to develop employee skills on asoftware project
Heres Bob. Hes a sophomore. Hell be a member of yourHazMat Rover team. He doesnt know much yet, but hecan brew a mean cup of coffee and has a great personality.
Managers have to work within these constraints
especially when (as is currently the case) there is aninternational shortage of skilled IT staff
8/6/2019 Risk Management w2
7/49
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
Various different types of plan may bedeveloped to support the main software project
plan that is concerned with schedule and budget
8/6/2019 Risk Management w2
8/49
Types of project plan
Plan Description
Quality plan Describes the quality procedures andstandards that will be used in a project.
Validation plan Describes the approach, resources andschedule 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 effort
required.Staff development plan. Describes how the skills and experience of
the project team members will bedeveloped.
8/6/2019 Risk Management w2
9/49
Project plan concerned with
development process Set project constraint (time, budget )
Project organization (team and roles)
Risk Analysis Hardware/software resource requirements
Work Breakdown (identify milestones)
Project schedule (milestones, people) Project monitoring
8/6/2019 Risk Management w2
10/49
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 activity
Deliverables are project results delivered to customers
Evaluationreport
Prototypedevelopment
Requirementsdefinition
Requirementsanalysis
Feasibilityreport
Feasibilitystudy
Architecturaldesign
Designstudy
Requirementsspecification
Requirementsspecification
ACTIVITIES
MILESTONES
8/6/2019 Risk Management w2
11/49
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
experienceEstimate resources
for activitiesIdentify activity
dependencies
Identifyactivities
Allocate peopleto activities
Create projectcharts
Softwarerequirements
Activity chartsand bar charts
8/6/2019 Risk Management w2
12/49
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 always happens
Always allow contingency in planning
8/6/2019 Risk Management w2
13/49
Bar charts and activity networks
Graphical notations used to illustrate the
project schedule
Show project breakdown into tasks Tasks should not be too small
They should take about a week or two
Activity charts show task dependenciesand the the critical path
Bar charts show schedule against
calendar time
8/6/2019 Risk Management w2
14/49
Task durations and
dependenciesTask Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 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)
8/6/2019 Risk Management w2
15/49
Activity network
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days
5/9/99
10 days
19/9/99
15 days
11/8/99
25 days
10 days
20 days
5 days25/7/99
15 days
25/7/99
18/7/99
10 days
T1
M1 T3
T9
M6
T11
M8
T12
M4
Critical Path: The minimum time required to finish the project (i.e the
longest path in the activity graph)
8/6/2019 Risk Management w2
16/49
Activity timeline Gantt chart4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Start
Finish
8/6/2019 Risk Management w2
17/49
Staff allocation4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
8/6/2019 Risk Management w2
18/49
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 circumstancewill 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
8/6/2019 Risk Management w2
19/49
Software risksRisk Risk type Description
Staffturnover Project Experienced staffwillleavethe
project beforeitis finished.
Managementchange Project There will beachangeof
organisationalmanagement with
differentpriorities.
Hardwareunavailability Project Hardware whichis essentialforthe
project willnot bedeliveredonschedule.
Requirements change Projectand
product
There will bealargernumberof
changes totherequirements than
anticipated.
Specificationdelays Projectand
product
Specifications ofessentialinterfaces
arenotavailableon schedule
Sizeunderestimate Projectand
product
The sizeofthe systemhas been
underestimated.CASEtoolunder-
performance
Product CASEtools which supportthe
projectdonotperformas anticipated
Technologychange Business Theunderlyingtechnologyon which
the systemis builtis superseded by
new technology.
Productcompetition Business Acompetitiveproductis marketed
beforethe systemis completed.
8/6/2019 Risk Management w2
20/49
The risk management process
Risk identification Identify project, product and business risks
Risk analysis Assess the likelihood and consequences of risks
Risk planning Draw up plans to avoid/minimise risk effects
Risk monitoring Monitor the risks throughout the project and mitigate
risks
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
8/6/2019 Risk Management w2
21/49
Risk analysis
Assess probability and seriousness of each risk
Probability may be
very low
low moderate
high
very high
Risk effects might be catastrophic
serious
tolerable
insignificant
8/6/2019 Risk Management w2
22/49
Risk analysis
Risk Probability Effects
Organisational financialproblems forcereductionsintheproject budget.
Low atastrophic
Itis impossibletorecruit staffwiththe skillsrequired fortheproject.
igh atastrophic
Key staffareill atcriticaltimes inthe project. Moderate erious
Softwarecomponents which should bereused
contain defects whichlimittheirfunctionality.
Moderate Serious
Changes torequirements whichrequiremajordesignreworkareproposed.
Moderate Serious
Theorganisationis restructured sothat differentmanagementareresponsible fortheproject.
igh Serious
The databaseused inthe systemcannotprocess asmanytransactions persecond as expected.
Moderate Serious
Thetimerequired to developthe softwareis
underestimated.
igh Serious
CASE tools cannot beintegrated. igh Tolerable
Customers failtounderstand theimpactofrequirements changes.
Moderate Tolerable
equired training forstaffis notavailable. Moderate Tolerable
Therateof defectrepairis underestimated. Moderate Tolerable
The sizeofthe softwareis underestimated. igh Tolerable
Thecodegenerated by CASE tools is inefficient. Moderate Insignificant
8/6/2019 Risk Management w2
23/49
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
8/6/2019 Risk Management w2
24/49
Risk planning strategies
Risk Strategy
Organisational
financialproblems
Preparea briefingdocumentforseniormanagement showing
how theprojectis makingaveryimportantcontributiontothe
goals ofthe business.
Recruitment
problems
Alertcustomerofpotentialdifficulties andthepossibilityof
delays, investigate buying-incomponents.
Staffillness Reorganiseteam sothatthereis moreoverlapofworkand
peoplethereforeunderstandeachothersjobs.
Defective
components
Replacepotentiallydefectivecomponents with bought-in
components ofknownreliability.
Requirements
changes
Derivetraceabilityinformationtoassess requirements change
impact, maximiseinformationhidinginthedesign.
Organisational
restructuring
Preparea briefingdocumentforseniormanagement showing
how theprojectis makingaveryimportantcontributiontothe
goals ofthe business.
Database
performance
Investigatethepossibilityof buyingahigher-performance
database.
Underestimated
developmenttime
Investigate buyingincomponents, investigateuseofaprogram
generator.
8/6/2019 Risk Management w2
25/49
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
8/6/2019 Risk Management w2
26/49
Requirements
8/6/2019 Risk Management w2
27/49
Requirements engineering
The process of establishing the services that
the customer requires from a system and the
constraints under which it operates and is
developed
Requirements specify what the system is
supposed to do, but not how the system is to
accomplish its task
8/6/2019 Risk Management w2
28/49
What is a requirement?
It may span a wide range of statements
from a high-level abstract statement of a
service or of a system constraint
to a detailed mathematical functional
specification
Types of requirements
User requirements
System requirements
Software specifications provide more (design)
detail
8/6/2019 Risk Management w2
29/49
User requirements
Should describe functional and non-
functional requirements in such a way that
they are understandable by system users
who dont have detailed technical
knowledge.
User requirements are defined using
natural language, tables and diagrams asthese can be understood by all users.
8/6/2019 Risk Management w2
30/49
Problems with natural language
Lack of clarity
Precision is difficult without making the
document difficult to read.
Requirements confusion
Functional and non-functional requirements
tend to be mixed-up.
Requirements amalgamation
Several different requirements may be
expressed together.
8/6/2019 Risk Management w2
31/49
System requirements
More detailed specifications of user
requirements
Serve as a basis for designing the system May be used as part of the system
contract
8/6/2019 Risk Management w2
32/49
Definitions and specifications
8/6/2019 Risk Management w2
33/49
Functional and non-functional requirements
Functional requirements Describe functionality or system services.
Depend on the type of software, expected users and the type of system
where the software is used.
Functional user requirements may be high-level statements of what the
system should do but functional system requirements should describe
the system services in detail.
Inputs, outputs and exceptions
Non-functional requirements
constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
They usually apply to the system as a whole
Domain requirements
Requirements that come from the application domain of the system and
that reflect characteristics of that domain
8/6/2019 Risk Management w2
34/49
The LIBSYS system
A library system that provides a single interface to a
number of databases of articles in different libraries.
Users can search for, download and print these articles
for personal study.
8/6/2019 Risk Management w2
35/49
Examples of functional requirements
For the library systems the following are functional
requirements
The user shall be able to search either all of the initial set
of databases or select a subset from it.
The system shall provide appropriate viewers for the
user to read documents in the document store.
Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to the
accounts permanent storage area.
8/6/2019 Risk Management w2
36/49
Requirements precision, completeness, and
consistency
In principle requirements should be precise, complete, and
consistent
Precise
They should state exactlywhat is desired of the system
Complete
They should include descriptions of all facilities required
Consistent
There should be no conflicts or contradictions in the
descriptions of the system facilities In practice, it is very difficult to produce a complete and
consistent requirements document
8/6/2019 Risk Management w2
37/49
Requirements imprecision
Problems arise when requirements are not precisely
stated.
Ambiguous requirements may be interpreted in different
ways by developers and users. Consider the term appropriate viewers
User intention - special purpose viewer for each
different document type;
Developer interpretation - Provide a text viewer thatshows the contents of the document.
8/6/2019 Risk Management w2
38/49
Non-functional requirements
These are the requirements that are not directlyconcerned with the specific functions delivered by thesystem and might relate to emergent systemproperties such as reliability response time
They define system properties and constraints e.g.
reliability, response time and storage requirements.Constraints are I/O device capability, systemrepresentations, etc.
Process requirements may also be specified
mandating a particular CASE system, programminglanguage or development method.
Non-functional requirements may be more critical thanfunctional requirements. If these are not met, the systemis useless.
8/6/2019 Risk Management w2
39/49
Non-functional classifications Product requirements
Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirements
Requirements which are a consequence of organisationalpolicies and procedures e.g. process standards used,
implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to the
system and its development process e.g. interoperabilityrequirements, legislative requirements, etc.
8/6/2019 Risk Management w2
40/49
Non-functional requirement
types
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
8/6/2019 Risk Management w2
41/49
Non-functional requirements examples
Product requirement
8.1 The user interface for LIBSYS shall be implemented
as simple HTML without frames or Java applets
Organisational requirement
9.3.2 The system development process and
deliverable documents shall conform to the process
and deliverables defined in XYZCo-SP-STAN-95
External requirement 7.6.5 The system shall not disclose any personal
information about customers apart from their name and
reference number to the operators of the system
8/6/2019 Risk Management w2
42/49
8/6/2019 Risk Management w2
43/49
Requirements interaction
Conflicts between different non-functional requirements
are common in complex systems
Spacecraft system
To minimise weight, the number of separate chips inthe system should be minimised
To minimise power consumption, lower power chips
should be used
But, using low power chips may mean that morechips have to be used
Which is the most critical requirement?
8/6/2019 Risk Management w2
44/49
Domain requirements
Derived from the application domain and
describe system characteristics and
features that reflect the domain.
Domain requirements be new functional
requirements, constraints on existing
requirements or define specific
computations.
If domain requirements are not satisfied,
the system may be unworkable.
8/6/2019 Risk Management w2
45/49
Library system domain
requirements There shall be a standard user interface to all
databases which shall be based on the Z39.50standard.
Because of copyright restrictions, somedocuments must be deleted immediately onarrival. Depending on the users requirements,these documents will either be printed locally on
the system server for manually forwarding to theuser or routed to a network printer.
8/6/2019 Risk Management w2
46/49
Domain Requirement:Train protection system
The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where Dgradientis 9.81ms2* compensated gradient/alpha and where the
values of 9.81ms2/alpha are known for different types of train.
Problems
Understandability
Requirements are expressed in the language of the
application domain
This is often not understood by software engineers Implicitness
Domain specialists understand the area so well that they
do not think of making the domain requirements explicit
8/6/2019 Risk Management w2
47/49
Guidelines for writing
requirements
Invent a standard format and use it for all
requirements.
Use language in a consistent way. Useshall for mandatory requirements, should
for desirable requirements.
Use text highlighting to identify key parts
of the requirement.
Avoid the use of computer jargon.
8/6/2019 Risk Management w2
48/49
Requirements document
Specify external system behaviour
Specify implementation constraints
Easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the
system
i.e. predict changes Characterise responses to unexpected events
8/6/2019 Risk Management w2
49/49
Users of a
requirements
document
Use the requirements todevelop validation tests forthe system
Use the requirementsdocument to plan a bid forthe system and to plan thesystem development process
Use the requirements tounderstand what system is tobe developed
System test
engineers
Managers
System engineers
Specify the requirements andread them to check that theymeet their needs. Theyspecify changes to therequirements
System customers
Use the requirements to helpunderstand the system andthe relationships between itsparts
Systemmaintenance
engineers
