Hi Archyon,
That's a great question. I am thinking to develop in .net 3.5 framework (asp.net 3.5 with C#) with GOF design patterns & agile process. I am going to develop a collaboration tool having all the features of web 3.0 and includes all the latest features of today's technology like widgets, mashups, and some features similar to netvibes, igoogle, pageflakes, microsoft live etc. For sure, I will reuse the existing components. Please let me know if you have any further questions.
Main Topics
Browse All Topics
by: ArchyonPosted on 2009-07-13 at 03:36:21ID: 24838485
Estimating project cost depends on two parameters: size and (let's call it) productivity.
The project's size can be measured or estimated using any of the different methods available. In Holland (where I reside) the method of sizing with Function Points is very popular. This method is originated from the 'old' main server systems and counts user interactions. But when used properly it is still suitable in modern projects. Other sizing methods are based on calculating Use Case Points, Story Points and all kinds of work-breakdown methods. Which to use depends on your situation and environment. I am happy to drill down into it if you can provide some more information on your environment.
Having the size of your project the real fun starts: how to map the size with the actual costs. Some say to just take the cost of one size unit (call it productivity), multiply one with the other and your project costs are written on the wall. But, as productivity depends on the technology used, on the process (e.g. waterfall versus agile), on the competence mix in your team, on the business domain, the non-functional requirements and whether or not you want to reuse existing components - to name a few - deriving the cost of this one unit is the big problem, eh challenge.
The best way to deal with this challenge is to record all project activities, categorize them, calculate their costs and learn from the experiences. Tools and processes take up with this by providing ways to connect planning with work done, by using work items and/or process enactment. The most modern ones even come close to an integration of sizing and calculating productivity, which is maybe a sign towards reaching some maturity of the IT branch?
As with the sizing methods what method fits you best again depends on your environment. Let us know.