Apr 2 2009 10:06AM GMT
Posted by: Jaideep
Software application,
software requirement,
software availability,
application availability,
risk,
high risk,
low risk,
medium risk,
Risk analysis,
risk impact,
bank application,
vulnerability,
software usage,
software user volume
Any activity is never without risk involved in it. Risk could be classified in different categories like - low, medium or high depending on its impact, software’s requirements and purpose, software usage, and software user volume. Accordingly the risks are identified or rather perceived. Their impact is measured or assessed, and based in the category in which it falls into – its countermeasures are designed or defined. The right identification of risk is as important as its classification or category.
A classic example could be a bank application being used by all its customers for their account maintenance, for transactions and for various other purposes. The risks involved in this sort of application could be: availability of application to all its users all the time, the speed of the application, the security of transactions, the ease and comfort of usage, the user account vulnerability of hacking and so on.
Some applications required all time availability whereas other demand high performance and high availability at peak time. Say, for example there is a website of a university where the peak usage is only at the time of admission or enrollment, at the time of fee payments, and at the time of release of results. At these times the volume of this site usage will be extremely high. So not only it demands availability of application at critical or peak times but also to be ensured is that it does not crash down due to high volume of use.
So it is very important to identify the right risks, to understand the right impact size, and to derive at a right countermeasure.
Feb 23 2009 10:43AM GMT
Posted by: Jaideep
Software Project Lifecycle,
pain areas of a software project,
Software Project,
customer requirements,
software project management,
software metrics,
Methodology and Standards,
documentation,
Customer requirements understanding,
Measurement of Overrun,
Project Status review,
Role clarity,
Risk analysis,
Team building,
Project Repository,
Learning from Past,
Post implementation support,
Quality – man,
methods,
approach and deliverables,
Version Control
Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.
In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)
1. Methodology and Standards
2. Documentation
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control
