Risk Management, actions should be taken to avoid ...

Mod // If this post in not on the right forum please feel free to move it

I’ am wondering in real life when a software is build, some risks might occur and those needs to be tracked, analyzed and planed in order to avoid them are:

1. Staff inexperience
2. Customer will change requirements.
3. Size estimate may be wrong
4. Delivery time must be extended.

In your professional experience what actions should be taken to avoid such a problem and if they occur what solutions or action should be taken?

Thanks.

I have absolutely no idea what it is you are asking, at least in reference to the supporting text above your query.

If what you are asking is, how do you avoid bugs and delays for software development... you don't.
Sure you can go with a reputable firm, or even with a Fortune 400 (read: big budget equals big resources) but no matter how hard one tries, you cannot eliminate the possibility of bugs. Why? It is nigh impossible to predict how every Joe Schmo working in marketing or -- god forbid -- management will abuse said environment and unmask a "bug".
You can spell it out in the manual, even on the very screen itself; "Press "A" key (the one directly to the left of the "S" key, immediately if not diagonally below the "Q" key, which is of course directly opposite the "Z" key) to continue.
Inevitably some moron will press the one key not accounted for. Coding to the 'least common denominator'.

I am not sure what 'risks' you are referring to specifically, but as far as date slippage, you can control that to some degree by not permitting scope creep (allowing the customer to "add" new components, while into development; they go into the next, and paid for, revision -- but you have to ensure that particular verbiage is added to the DOU or Document of Understanding). Otherwise, get used to it.

Again, I am not entirely certain what you were asking, or what point you were attempting to make. Some clarification would be appreciated.

Cheers.

The whole practice of 'software engineering' is designed to minimize risk, while maintaining a good amount of transparency between the developer and the customer. There are a large number of models designed to aid software engineering - I'd recommend doing a google search for software engineering, or some of the models (such as 'waterfall model', 'spiral model', 'rational unified model', etc).

FEAR - F- false, I- image, A- appearing, R-real

I think that those problem which you are guessing are imaginary right this moment. I think when those problem will occur automatically you shall get a solution, don't be fearful from today.

Mostly software engineering are well designed itself for minimising the risk.

Doesn't that spell, FIAR?

I was just about to post that

Sorry for my mistake, please read as below:

False image appearing real.

That still works out to the acronym, FIAR.

FEAR-- F-False, E- Evidence, A-Appearing , R-Real

Now I think it is ok.

So does,
Faux Expressions (for) Acronym Rendering

so does

feeling, energetic, after, reality.