25 Feb
Are societies or government manufacturing Rapists?
28 Dec
Mr Rathore- A Sex Maniac Supported by Wife and Daughter
Mr Rathore, seems like a sex maniac who molested Ruchika. It happened when his daughter was Ruchika’s class mate and elder in age. This beast who molested not only single girl but could be possible that he already tried with so many a times earlier to that and after the incidence also as he got so much support from the politicians. And what is the gurantee that he didn’t do that with his daughter as well. I guess the main culprit is his wife who despite being aware of everything still supported that.
Also government of Haryana should be responsible for this maniac and making our society unsafe by allowing this maniac to stroll freely despite his bad mind. I think his kind of people should be treated and should be kept in jails as it is not only better for them but for the society as well
23 Dec
Why CBI is so Great?
Well CBI has done it again. In the case of Ruchika-Chandigarh case, they have given just just a sixth month jail term that too bailable. I love India, Ilove CBI.. god hurry and do 2012 as only criminals will live after that and CBI is making sure for that.
Also cannibalisim is not too bad like in Pandhar case, clean chit is given by them, he was just hungry and he ate childern what is so bad about it?
7 Oct
TOI ‘s News
Why don’t TOI or for that Indaitimes.. only publish half naked photo.. Please ask Mr. Jain to ask his ladies and come forward and share his house ladies to do the same.. that kind a give him kick him after getting that published on first page of either paper or Indiatimes… Let all girls get raped .. who cares!!!! TOI should spread eroticas on daily basis.. I love you buddy.. keep you Top position.. Indians filthy minds love that !!!
6 Mar
Long Time & Same Me
Its been long that I have written on blog. Within a year it seems like I have changed a lot. I have started learning Astrology however it is just started and it is for sure is extermely inquisitive and difficult subject. God onl knows If I will able to finish it on time or not.
19 Aug
Journey of Life
There are things which are yet to start. There are things which will never ever end. There are things which which cannot be started. there are things which are sin, there are things which cannot be even thought.. there are things which one cannot be said..there are so many answers to difficult questions and there are no answers to life simplistic questions.. there are paradoxes of each event and each phase of life is inseparable in so many terms. Sometimes you enjoy every bit of the passing time.. sometimes you see the time and its so hard to go by. There are so many contradictions.. yet so many enjoyable moments. there are so many unspoken words if told can hurt in so many ways and there are so many feelings which cannot be expressed.
Yet this is journey.. journey of life.. everybody is traveling but nobody beliefs it will ever end.. such a paradox is life.. impeccable.
16 Oct
Pessimistic Approach: Are we too realistic?
As we come across a new product in our daily life, we always take time to learn it properly before we use it. Ain’t the same analogy hold true in a fresh development which we don’t have ever experienced. However generally in software management about a new product development, we generally tries to do bring in all sort of techniques and methodologies which might be of some use but to an extent. But as the arena is completely new and there are all sort of adventures which are never being imagined by anybody part of the project in their wildest of dreams. Moreover despite having proper risk mitigation team in place we feel glitches and huge fiasco’s. Despite everybody from top management to a management trainee who is freshly joined knows that obstacles will come, everybody meet with so much surprise on their face when things start to go wrong that manager is entirely to be blamed.
Although things are not bad as they might look, in fact they are worst. Since whenever somebody put its hand in entirely new pot, you might-never know what is inside the vessel. But when every body tries to pretend about their knowledge that they knew from beginning, it shows their immaturity towards software development process. Incidental nobody and none of the existing models or methodologies claims to entirely fool proof. They are always open for some customization. Not only sometimes models and methodologies fails disastrously but they are not meant to be used everywhere and anywhere.
Hence pessimistic approach comes in handy. Whenever thing are fresh and new, try to be realistic. Make amendments in models and try to take note of all possible risks and need to pad every risk with contingency plan. Be real and keep everybody in loop. Always try not to hide anything from anybody, be a strong but realistic manager with pessimistic approach.
15 Oct
Truth about Parametric Cost Estimation Approach!!
Ask any PM about the parametric methods he is following for cost estimation and he will point to ‘COCOMO‘, ‘FP‘ or lately accepted ‘Feature Point Analysis‘. But next ask him what was the success rate, he won’t give you exact figure but sum up his answer by adding clarifications- None of the methods is exact so they do also use non-parametric methods too. So what is in parametric that most of PM cannot escape and still they don’t religiously follow that.
The exact answer is very fundamental. Parametric approach is very accurate, no doubt about it, however does our software development process is also accurate? Anybody who has spent at-least an year in the development can answer with big ‘No’. So anyway to go for approach which is far from being accurate, because of Murphy’s law (whatever the time you allocate for specific task, the task will always consume it). So what is the best way. Now to answer that we have to consider that whenever a process is not matured there will always be chances of betterment, henceforth always new approaches will keep on appearing and will try to minimize the risk associated. Now what is major flaw with parametric approach? Parametric approach fails to consider that a software development is more a art than a perfect science. The best ways are still to come or to bring the truth out there will never be accurate ways to conclude estimation and if Customer is too rigid Development team will always be at lose.
15 Oct
Defects: A way to know your software strength
At first glance the topic of this blog seems very contradictory. In fact it is not. The only way how powerful your software solution is can only be given by what is the defect density of your software product? It frankly doesn’t matter what you consider defect definition to be; it may based on your customer satisfaction, by the bugs identified, by requirement deviation or any other such thing. Based on defects and defects density, you can really come to conclusive answer that how powerful your delivery of the product will be. Whenever you come with number of defects in first go you tend to suppress them by either solving them or taking alternative path so that defects can be completely avoided. however once defect is recorded, it is always best to remove it from the software rather taking by pass approach. Since in by pass approach there is always chances in case object oriented approach the bug won’t be discovered by current functionality but alternative functionality usage can unearth the bug and then it will hard to admit that bug was initially cured on first report.
It can easily derived that there is inverse correlation between bugs density and strength of the output product. Now as density goes on decreasing strength of the product will increase. Hence it is always good idea to keep a vigil on defects density and that will give you if not accurate, then almost approximate idea who good and powerful your software is.
6 Oct
Requirement Analysis
It is always a next to impossible task to get a) perfect requirements b) to do perfect analysis on them c) lastly to perfectly convert them into design or take to next SDLC level. In fact irrespective of metrics we use to measure requirements and take it to next level we should always keep in mind that the person who is gathering them and who is giving them both are human beings and lot of noise get introduced while in their communication. Hence requirements are bound to misled from their actual meaning to the understanding of gatherer.
The point I am trying to make is whenever imagination takes a concrete shape it is tend to be converted into something really imaginary or far from reality. This makes almost 30% of requirements either completely useless or almost impossible to convert them into a software solution. Now what can we do to minimize such a huge gap. Almost all of the requirements should be supported by facts and data. In case example cannot be taken, at least prototype or flowchart should be framed. Always remember the difference between stakeholders and end users, end users will be using your solutions so always double check any gathered requirement with them.
Eventually all requirements has to doubly or triply checked with everyone, it may happen requirement may not be needed at all and it is just a thought put in words.