Great Questions, sorry no great answers :-) We learned in the late 50's and early 60's that building software was much different than any other manufacturing process that we knew of. Projects simply did not scale (as a great reference, The Mythical Man Month - Brooks), estimation efforts were poor, understanding of what was "good" programming was lacking. The answer - more formalized software processes (or in a very weak term software engineering). Managers (yeah, those guys) wanted a way to estimate for and obtain the projects. All this in a field whose body of knowledge doubles every 5 years. It has been estimated that only 4% of software projects by 1965 met expectations, budget, deliverary date and desired quaility. So - do we need them. yes and no - (told you no great answers) It appears that the higher the risk of a project going south, the more formal the process should be. Given that what are the common risks: mis-understood technology, incomplete or inaccurate requirements, large project, many people on the project team, inflexable timeframes, not enough resources, potential high risk to life and limb, potential requlatory involvment, possible legal involvment. So if you are designing something for yourself. (absolutly no risk) - then no you do not need a process. If you are designing software for the space shuttle (massive amount of risk) - then yes you will be using a process. overall, a software process is a way to mitigate risk. Totally aside from the above is if your organization is in the process of generating multiple software products. In that case some form of process is necessary so that software process improvment can be performed to "optimize" the process to drive down organizational cost and increase quality.
Shailesh, The issue isn't really whether we need processes. All developers and development teams have processes, they just don't usually know what they are. In those cases their processes have grown ad-hoc and haven't received any systematic improvement, so they're of generally poor quality. A low quality process is almost bound to produce low quality programs, even if the individual developers are of high quality. We study and modify our processes to improve our programs. jply
Joined: Oct 12, 2000
What you said is correct. Jerry , you said " We study and modify our processes to improve our programs". But , how many organisations do this exercise ? One more thing Microsoft must be having some underlying process. But , still they are coming up with substandard products. They are being used worldover. Is it really necessary then to have superior process , when today time to market is very , very important. Bye. YOUR BARTENDER SHAILESH.
Shailesh, Your point well taken, is a superior process necessary - NO. The main point of having superior process for software development is to mitigate risk to the company. The goal of must software organizations is to: generate software at a specific level of quaility manage the risk to the company reapply learnings in the future reduce costs due to rework - redo So if company M happens to deply a word process that has a few bugs the risk is small, ship it. If company N has software that manages insturments that controls the space shuttle that has a few bugs, this risk is large, fix it. Bottom line it costs a company to implement a good software engineering practice. Continual software process improvment (SPI) is vital to some companies to help produce better products, reduce cost, support reuse and foster an environment of process improvment. Some companies look at shipping the product-du-jour as soon a possible, as cheep as possible and will worry about the rework later. Note: this isn't wrong, just business. (For my own small business - if i have a continuing customer that is having some issue, not related to my activities and asks my advice, i'll probably do it without charging, to me - it's the cost of doing business). This is a management decision. This is also why upper management buy-in is essential to a good SPI program.