| || |
What is the typical methodology for the Manintenance projects?
And please suggest the best way of estimating the size of such projects?.
Re: Maintenance projects
Typical methodology...? ;-)
Which color is the best...
Kidding aside, it all depends on your actual needs.
Any development situation is bound to be determined by a complexity factor, which depicts the need for one method or another.
But, with a thoroughly developed CM-process, you may aquire a flexible a scalable CM-system, that allows you to use the same basic methodology for any complexity in your specific project.
On average, you could define three levels, the small project, the medium sized and the huge project.
Size, or rather complexity, is not only referring the number of developers. The system design, geographical distribution of the team and delivery demands are the main other aspects.
In short, there is the answer to your question: how should I estimate my needs?
So, that in mind, my conviction is that the best approach is always to focus on a change-driven development methodolgy. This comprise definition of every change that you infer to your system as a separate entity, called e.g. Change Request (CR).
A CR may be inflicted by some error (e.g. called Trouble Report, TR) of a previous release, or comprise development of a new feature in a system built from scratch (e.g. called an Enhancement Request, ER).
It also inflicts that you should try to develop your system in smaller iterations, having releases made every so often - though not nescessarily officially released to customer or end user - where every release contain some handful of iterations, and every iteration comprise some 5 - 30 CR, depending on the actual complexity.
At this, also be aware that the complexity changes during the life cycle of a system. The flexible CM-system allows you to grow, or shrink, in methodology enforcement on the project.
Then, in a controlled environment the changes of each CR is developed in an isolated "sand-box" without being disturbed by modifications made due to other CR. After completing a set of CR, these are integrated into a new baseline - the iteration release.
To provide you with the abilities to enforce a methodolgy you will need some tool support. But, it is important to remember that the methodolgy you define should guide the tool usage - not to let your chosen tool guide the method that you follow to develop your projects.
For tool support, you have commercial alternatives, and freeware alternatives. As for commercial, you have budget tools and expensive tools. What you choose is dependent on you economic situation, your customer demands, and possibly your skills in customizing the tool for your needs. As a rule, an expensive commercial tool would provide you with a set of out-of-the-box solutions for realizing some methodology or another.
As a suggestion, CVS in combination with a spreadsheet tool for source code respectively change control is often sufficient, especially when you do not have a complex delivery scheme.
But remember, you should define the needs for your current development situation before selecting a tool strategy - otherwise you may be faced with either inadequate support, or with overkill support. Neither will help you efficiently in your quality assurance work, which is what it all bottles down to:
Quality assurance - providing the right methodology to support development, integration and test, and release, in a high quality fashion.
To find out you actual needs, it is sometimes helpful to get professional assistance - both in selecting the right tools, and put them to use, and to define what the complexity of the current development project is today.
That said, I cannot but recommend myself as an excellent resource for doing that. ;-)
I have been doing the complexity analysis and method establishment in development projects for soon to say ten years, and also hold a certification as Rational instructor on the ClearCase family tools (not that I would in every situation recommend IBM Rational tools - remember, the need is dependent on the complexity :-)
...här skiner solen...