Merhaba; online bir filmi izliyorum (Stag Night 2009), divx formatında olduğundan geç yükleniyo :) ben de aradaki boş vakti değerlendirmek için gündüz kurduğum, Microsoft eğitimlerinden biri olan Course 6368A: Programming with Microsoft® .NET Framework using Microsoft® Visual Studio® 2008 eğitimine göz atıyodum. Daha ilk sayfalarad hoşuma giden bi kısmı paylaşmak istedim. İngilizce döküman olduğu gibi aktarıyorum (Nede olsa google translate benden iyi çeviriyo).
Almost 75% of all software IT projects fail. A large proportion of these are obviously software development projects. So why does this happen?
Software development is abstract:
In contrast to constructing a house or skyscraper where one can see the progress, software development is to a large degree abstract and invisible. The end product cannot be seen until later in the project, and even then, the user interface is in actual fact a façade, hiding the true functionality.
Software development is complex:
While the composition of a software program is complicated (i.e. a system of many simple parts, but given enough time, may be ultimately understood) software development is actually complex, meaning that that its function cannot easily be understood because of interdependent relationships and outside influences changing the way it functions. In software development this is the case, as software developers are humans, they vary in terms of ability, intelligence, emotions etc. The system being developed is usually based on solving a real world (business) problem. This problem may not be completely understood to start with, and in the real world, probably changes over a period of time due to outside influences in any case. Therefore developing a software program to solve it, would be considered as a complex endeavor.
No development process:
Many projects are driven on an ad-hoc basis with no formal process. This may be because the initial project is not considered large or complex enough to warrant it, or the development team has an impromptu attitude. In either case, the lack of a development process is a serious oversight.
Incorrect or inadequate requirements gathering:
Probably the most important step in designing a software project is the gathering of the user’s requirements. If one gets this wrong, the chance of developing the correct products is infinitesimal. Ironically the chances of getting all the requirements perfectly correct is also very small due to a large number of reasons:
The complexity of the real world problem.
The person providing the requirements to the development team may not fully understand the problem either.
Corporate or internal politics in a company sometimes clouds the understanding of the problem.
Time constraints.
Communication noise. This is the disparity caused when people communicate with each other and is caused by differences between the person talking and the person listening like educational, background, experience etc. In other words the person listening does, not here exactly what the person is saying. In this case the situation is made worse by the fact that the person relaying the problem often has a business background, and the person listening to the problem has an IT background.
Unrealistic time schedules:
Too much work in too little time. This is often caused by other external time constraints such as ’we must go live in the next quarter’ to underestimation of the required time due to many of the points discussed in this topic.
Unknown or immature technology:
Often cutting edge projects use the newest technology around. This introduces another level of complexity due to unknown bugs, a technology that may not be tried and tested and may not be well known amongst the development team.
Incorrect or inadequate staffing:
Software development teams are constantly changing due to members leaving, working on other projects, on vacation etc. Additionally a technology may be chosen that is not the core competency of that development team. Regardless of the reasons, it often happens that the development team may not be at its optimal level when the project is under way.
In closing, these points highlight that software development is not a trivial exercise, almost regardless of the scope. This should not be used as an excuse for allowing projects to fail, but should rather be seen as a motivation to follow a structured, stable and well supported software development project, and to always be cautious with regards to the reasons for failure.
