Paris this week, Los Angeles next week, Marseille on April the 22th (ya know, it's for the French presidential elections. I'm still unsure about who is going to get my vote. I have a lefty bias, but the French Parti Socialiste is quite dumb these days, so I may vote for Mr. Bayrou - but maybe not, as I don't see how he can win the legislative elections later in the year), and probably Paris again on April the 7th.

So I'm moving quite a lot, my old laptop is suffering from that (CD writer is not working, batteries are out of service, and for unknown reason my sound card doesn't want to render sound - this looks like it's linked to a svchost crash at power up), and I don't have much time to work on my pet projects.

As promised, here is a small excerpt of "SOMETHING":

Quote:Risks have many different origins, and should be spotted early in order to avoid project difficulties. To show this, let's take an example.

The requirement list above says nothing about how the rendering of the different graphic elements are done - it can be 2D or 3D. Suppose you do everything in 2D first, and later you realize that it would have be more eye candy in 3D - now you have to delete and modify a lot of code and to rewrite a lot of new code. This is a typical risk you may face: the lack of specification. Not considering this as a risk lead to the problem described, while taking it into account would have enabled you to create an architecture that would have minimized the impact of the change.

Most risks can be tracked down to these meta-risk categories:

• Lack of specification: it is very rare to get a complete, detailed specification. If no or too little details are given for a specific feature, the risk is high to get this feature wrong or not working correctly (according to the original idea).
• Specification is "TBD": TBD means "To Be Determined". The specification is here, but not all choice has been made, and the requirements are very likely to change.
• Imprecise specification: even if the specification is very detailed, some features description may be imprecise. This is very similar to the previous point.
• Conflicting specification: sometimes, the specification of a feature conflicts with some other requirement. This is very hard to spot, but it's critical to see the problem early.
• Change in the specification: ideas are living their own life, meaning that changes in the specification are quite probable. You have to consider that they are going to happen - the question is then: what impact will it have on the design?

I'm still looking forward to meet any of you in Los Angeles. I know several guys on GDNet are living there, but LA is a big city - so that may prove difficult to arrange a diner. Anyway, I'm open to any proposal (especially if you are a 21+ blond-haired, tall, beautiful, sexy and open-minded woman. Don't ask why.).