RISK
Published Friday, April 28, 2006 by Mathieu.
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.
OO
Published Sunday, April 23, 2006 by Mathieu.
Today's lecture is about Object Oriented Design
www.objectmentor.com
There is no clear boundary bw/ analysis and design.
Use mostly the same tools to describe design as used to describe analysis.
Don't make the mistake of OO design as a way of writing programs in an OO language. You still have to be disciplined in how you design them.
Simply put it in terms of three perspectives.
Conceptual - Analysis
Specification - Analysis and Design
Implementation - Design
OO Design Key Ideas
Abstraction
The Open/Closed principle
Classes should be open for extension, but should be closed for modification.
Encapsulation
Compartmentalising the elements of an abstraction that constitute its structure and behaviour.
Connascence
You've got two things. Ideally you would be able to change one thing in one place, but once you have to change two things, you have to remember to change the other thing correctly. It's a major cause of problems in programming and software.
Use encapsulation to manage connascence
Break the system into encapsulated components
If things are powerful they can also go powerfully wrong.
Things like C++ 'friend' function is one of those things.
A connascence abuse.
Class Cohesion
Measures the interrelatedness of the methods in the external interface of a class.
If you want to make software that is easy to change, you have a lot more of a tricky problem. As a designer, you have to make the decision of whether it is worth the extra cost.
If software was designed for portability, then it wouldn't be 6 months for mac people to wait for a port.
Class Cohesion
Measures the interrelatedness of the methods in the external interface of a class.
How well does the class hang together as an implementation of a class?
Low class cohesion is to be avoided
2nd Assignment:
Computer-Aided Software Engineering Tool
Learn about stuctured analysis and structured design
And do an Object Oriented analysis on it.
Hint. Consider what happens when an architect designs a house. (2nd Paragraph)
www.objectmentor.com
There is no clear boundary bw/ analysis and design.
Use mostly the same tools to describe design as used to describe analysis.
Don't make the mistake of OO design as a way of writing programs in an OO language. You still have to be disciplined in how you design them.
Simply put it in terms of three perspectives.
Conceptual - Analysis
Specification - Analysis and Design
Implementation - Design
OO Design Key Ideas
Abstraction
The Open/Closed principle
Classes should be open for extension, but should be closed for modification.
Encapsulation
Compartmentalising the elements of an abstraction that constitute its structure and behaviour.
Connascence
You've got two things. Ideally you would be able to change one thing in one place, but once you have to change two things, you have to remember to change the other thing correctly. It's a major cause of problems in programming and software.
Use encapsulation to manage connascence
Break the system into encapsulated components
If things are powerful they can also go powerfully wrong.
Things like C++ 'friend' function is one of those things.
A connascence abuse.
Class Cohesion
Measures the interrelatedness of the methods in the external interface of a class.
If you want to make software that is easy to change, you have a lot more of a tricky problem. As a designer, you have to make the decision of whether it is worth the extra cost.
If software was designed for portability, then it wouldn't be 6 months for mac people to wait for a port.
Class Cohesion
Measures the interrelatedness of the methods in the external interface of a class.
How well does the class hang together as an implementation of a class?
Low class cohesion is to be avoided
2nd Assignment:
Computer-Aided Software Engineering Tool
Learn about stuctured analysis and structured design
And do an Object Oriented analysis on it.
Hint. Consider what happens when an architect designs a house. (2nd Paragraph)