Software Development Life Cycle is a big yet widely used term in the world of software development. People who are into the development process put much stress on the word than any other. SEI over the years has strengthened the Capability Maturity Model (CMM) and came up with the solution, which if followed will always lead to quality product.
CMMi model has various wings of SDLC, starting from project initiation to Configuration Management, Risk Management, Project Management, Quality Assurance, Deployment. They have defined every sphere and written well thought process to manage every department.
But the question is how relevant are all these terms of web development? Let me make my question simpler and raise all the difficulties a web development project faces in following a process.
1. Budget : A web development project budget can be as low as $50 and can be as high as million dollar. If you are following process, you cannot discriminate between two projects in terms of money. The reason is simple. If you say, that you will put all projects above $500 in SDLC, then what about a project worth $450? What basic difference in terms of time and complexities can a project worth $450 and another worth $550 have? So it is very difficult to discriminate project as per budget.
2. Profit and Cost : In the age of open source and freeware it is very hard to survive in the market. Your cost must be competitive as well as your quality should be supreme. Now following a process, involves additional expenditure. Like you need to maintain configuration and version controlling. You should have a well structured project management system, a well defined estimation process. All these bloats up the development term and time is money, so in the end the development cost. At the same time you know more you raise the cost, more you are getting into the edge of the market. So this catch22 situation will alwys haunt you, will leave you dwindling in your decision.
3. Involvement of stakeholder : Web is more visual than any other software. In application software more or less, the visual component is standard and so is navigation. But in web this has no boundary or rigidity. Client being one of the stake holder gets closer to the visual factor in practice and this results into a lots of change requests. In almost all SDLC model, change requests always make a cycle to complete. Keeping client out of the development when it is not required is very difficult for a web project, specifically if it is medium sized one.
4. The engineering model: The most popular and effective model of software development model is V-Model. This model is well tested and found to be suitable for most of the projects. But in web development there are thousands doubts about the model.
First of all, the term System Design and System Testing is quite void. Because, in web development the system is known and predefined. And the dependence of tailor made components on the system is rare. So system testing is an unnecessary task for web development. The other model like water-fall model is also not a suitable option for web development. In the world of web, the model which is largely followed knowingly or unknowingly, is the agile web development model. In agile development, throughout the life cycle of the project development is iterated. In spiral model, the process after a certain stage follows spiral pattern, but the entire path is not iterative. The GUI design of the web development, does not fit into any of these engineering models, but is an integral part of the project. Similarly, automated testing, black-box testing etc are quite unfamiliar steps of web projects.
So are all roads closed for a web projects in following SEI guidelines? No, I think and I think there are some definite steps to be taken in order to achieve that. These are
- Know your projects. Identify the majority of projects coming in terms of budget and complexities.
- Get a chunk of all projects and make them separate for the roll-out.
- Redefine all processes. Cut short all process but don’t omit the process from the SDLC. Because you do not know when it is required and if required you need to relater the quality manual. Better put all clause and leave the discretion of selection of any clause to the project management team.
- Put Stress on Configuration Management, Risk Management.
- Try to qualify the estimation process.
- In the beginning, calculate the buffer time as cost for CMMi certification. When you are quite sure of buffer time, slowly incorporate that.
- Create a well defined SRS (Software Requirement Specification) and URS creation guideline. A good SRS and URS can ease the hassles of bad quality.
- Recruit a good architect.
- Go for test cases before you start coding.
- Make guidelines available for all steps of the development. Bound people with the guideline.
- For failure blame the process and not the people. If you cannot tame the tiger, the tiger is not to blame but your training process.
- And CMMi is for process improvement, so you will always get an improved process and not the ultimate one.






You have made some interesting points. However, CMMi , presents a number of maturity levels stepwise, thereby offering a roadmap, which is based on sound management practices, and is historically proven to lead to success with high probability.
If you consider adopting just enough of the model to fit your current purpose then your dilemma will be resolved. The predicament arises when the goal is to receive certification and not process improvement. It’s then that the organizations find certain projects to be non-profitable and looks at a classification scheme based on budget or anything else.