Risk Management
Published Thursday, May 04, 2006 by Mathieu.
Assignment Due Wednesday 10th.
Risk Management - remember the 80/20 Rule. 80% of the impact will come from 20% of the risks.
Monitor the risks as the project progresses.
McFarlan's risk assessment method
Three factors:
Project Size
larger the project, the greater the risk.
Experience with the Technology
The difficulty is knowing which program you should be writing.
Project Structure
Organisations can't go on building low risk projects.
They should have a portfolio of risks in their system development.
But you have to take risks, or your competitors will get ahead.
So you have four main categories of techniques to manage risk.
External integration tools
Internal
Formal planning tools
... (see the slide)
Formal Planning Tools
PERT (Program Eval and Review Technique) and CPA (critical path analysis)
Formal Control Tools
Status reports, etc.
Reliability
IT Boom is over! But still possible to come up with killer apps :-D
What is reliability, failures and faults.
Reliability is how long a program will run for before it falls over.
How well do the users think it works?
You can't define reliability absolutely, only in relation to a particular operational context. Hell, people might deliberately try to break the system!
Faults cause failures to occur, they're static software characteristics. But faults don't necessarily cause failures.
A failure corresponds ti unexpected run-time behaviour observed by the user of the system.
Reliability is related to the probability that a fault will cause a failure while in operational use. Obvious statement huh
Reliability is desirable, but it's only one of many desirable characteristics. Besides, it costs a whole lot of cash. So you have to, as usual, weigh up how much more you want to increase costs by redundant hardware, additional design, additional implementation work etc. Even the product can become sluggish and a behemoth because of extra code to handle exceptions.
So what's the GOOD thing about reliability?
Unreliable software isn't used by anyone. No one updates them either. System failure costs can be very high (re. Wespac debacle). Don't optimise! (The rules of optimisation).
Good enough software. Microsoft might be able to get away with this more (!)
It's an old concept though, recently especially promulgated in the software industry.
So how do we measure reliability?
Most of the techniques are derived from hardware reliability metrics.
How many times a day will the mainframe fall over?
This is very important in any continuously running system.
誰のことも気にしない！集中
勉強する方法。簡単な言葉で同じ事を言う。シェアできるし、勉強にはなる。
Risk Management - remember the 80/20 Rule. 80% of the impact will come from 20% of the risks.
Monitor the risks as the project progresses.
McFarlan's risk assessment method
Three factors:
Project Size
larger the project, the greater the risk.
Experience with the Technology
The difficulty is knowing which program you should be writing.
Project Structure
Organisations can't go on building low risk projects.
They should have a portfolio of risks in their system development.
But you have to take risks, or your competitors will get ahead.
So you have four main categories of techniques to manage risk.
External integration tools
Internal
Formal planning tools
... (see the slide)
Formal Planning Tools
PERT (Program Eval and Review Technique) and CPA (critical path analysis)
Formal Control Tools
Status reports, etc.
Reliability
IT Boom is over! But still possible to come up with killer apps :-D
What is reliability, failures and faults.
Reliability is how long a program will run for before it falls over.
How well do the users think it works?
You can't define reliability absolutely, only in relation to a particular operational context. Hell, people might deliberately try to break the system!
Faults cause failures to occur, they're static software characteristics. But faults don't necessarily cause failures.
A failure corresponds ti unexpected run-time behaviour observed by the user of the system.
Reliability is related to the probability that a fault will cause a failure while in operational use. Obvious statement huh
Reliability is desirable, but it's only one of many desirable characteristics. Besides, it costs a whole lot of cash. So you have to, as usual, weigh up how much more you want to increase costs by redundant hardware, additional design, additional implementation work etc. Even the product can become sluggish and a behemoth because of extra code to handle exceptions.
So what's the GOOD thing about reliability?
Unreliable software isn't used by anyone. No one updates them either. System failure costs can be very high (re. Wespac debacle). Don't optimise! (The rules of optimisation).
Good enough software. Microsoft might be able to get away with this more (!)
It's an old concept though, recently especially promulgated in the software industry.
So how do we measure reliability?
Most of the techniques are derived from hardware reliability metrics.
How many times a day will the mainframe fall over?
This is very important in any continuously running system.
誰のことも気にしない！集中
勉強する方法。簡単な言葉で同じ事を言う。シェアできるし、勉強にはなる。