Today we're looking at what can go wrong in software development. And Why.
What is Risk?
Foreseeable events whose occurrence could cause system degradation or failure.
Murphy was an optimist:
Everything takes longer than expected.
Whatever can go wrong will go wrong
And will go wrong at the worst possible time
Software developers are optimists!
Humans are inherently bad at estimating.
ON TIME
ON SPECIFICATION
ON BUDGET
Choose any two!
You get into a commercial programming environment, and you're confident you know how to write programs. But sometimes they give you a spec and you can program it but you're programming the wrong thing. You can build the exact thing that they wanted, and still have the project fail.
Nobody wants the project. They don't want to pay for it either.
As project requirements change, you have to chuck implemented code out and start again. It would be much better if the requirements were done properly from the start.
Again, we're reiterating that you need to beat the requirements and specks out of management before you start.
Goal failures
Iraq - goal failure! Brought democracy (after civil war ends).
Misunderstanding of the goals by the system builders.
Leads to requirement failures.
Technical failures
They kind of made it up as they went along.
XML is a great thing! If we use that it will be better.
You can still stuff up and write crap programs even with the best tools (languages)
user contact failures
Organisational failures
Inability of the org to support software development process
Lack of leadership, large span of control, poor co-ordination between sub-groups, lack of clearly designated responsibility.
Size failures
It's just too big for the development group to build!
Planning and Control failrures
Personality Failures
Even sabotage!
External Vs Internal Risk.
The main threat to system failure are external.
Cancelled projects.
We have to deal with people! (Politics)
Risk Identification
Risk item checklists are often useful.
Eg. Staffing risks:
Are the best people available?
Do they have the right combination of skills?
Are enough people available?
Is the staff committed for the duration of the project?
...
Risk projection
Doing all of this is very difficult. It doesn't seem like we're getting any real practical training in this at all, we just have to take it with us and go out there and try it out in the real world!
The real world is coming up very fast to slap me in the face!
They get you to write things down (document) because they don't want to loose you! And take your specialist knowledge with you.
What is Risk?
Foreseeable events whose occurrence could cause system degradation or failure.
Murphy was an optimist:
Everything takes longer than expected.
Whatever can go wrong will go wrong
And will go wrong at the worst possible time
Software developers are optimists!
Humans are inherently bad at estimating.
ON TIME
ON SPECIFICATION
ON BUDGET
Choose any two!
You get into a commercial programming environment, and you're confident you know how to write programs. But sometimes they give you a spec and you can program it but you're programming the wrong thing. You can build the exact thing that they wanted, and still have the project fail.
Nobody wants the project. They don't want to pay for it either.
As project requirements change, you have to chuck implemented code out and start again. It would be much better if the requirements were done properly from the start.
Again, we're reiterating that you need to beat the requirements and specks out of management before you start.
Goal failures
Iraq - goal failure! Brought democracy (after civil war ends).
Misunderstanding of the goals by the system builders.
Leads to requirement failures.
Technical failures
They kind of made it up as they went along.
XML is a great thing! If we use that it will be better.
You can still stuff up and write crap programs even with the best tools (languages)
user contact failures
Organisational failures
Inability of the org to support software development process
Lack of leadership, large span of control, poor co-ordination between sub-groups, lack of clearly designated responsibility.
Size failures
It's just too big for the development group to build!
Planning and Control failrures
Personality Failures
Even sabotage!
External Vs Internal Risk.
The main threat to system failure are external.
Cancelled projects.
We have to deal with people! (Politics)
Risk Identification
Risk item checklists are often useful.
Eg. Staffing risks:
Are the best people available?
Do they have the right combination of skills?
Are enough people available?
Is the staff committed for the duration of the project?
...
Risk projection
Doing all of this is very difficult. It doesn't seem like we're getting any real practical training in this at all, we just have to take it with us and go out there and try it out in the real world!
The real world is coming up very fast to slap me in the face!
They get you to write things down (document) because they don't want to loose you! And take your specialist knowledge with you.
0 Responses to “RISK”
Leave a Reply