Software, in last few decades, has captured a foremost arc of human life. It is now not a product of arbitrary and capricious practices and mere programming activities. Modern software products are engineered under the practice of using selected process techniques to improve the quality of a software development effort. This is based on the assumptions, subject to endless debate and supported by patient experience, that a methodical approach to software development results in fewer defects and, therefore, ultimately provides shorter delivery times and better value. The necessity of selecting and following a formal practice for software development is to provide desired discipline to deliver the quality expected for business success and avoiding the wastage of time, squander productivity, demoralization in developers, etc. This article summarizes such needs of adopting formal software development methodologies and standards.
Software Development: A Critical Engineering Task
Slowly and surely, computers and software are taking over many of the functions that effect our lives critically and they have become imperative parts of our lives. They are now monitoring and controlling all forms of monetary transactions, transportation, communication, defence systems, production and so on. They have made places in our homes, controlling all forms of appliances. Acknowledging their importance and complexities in structures and roles, software are no longer the products of arbitrary and capricious practices and mere programming activities. Software, not being merely a program to be executed to perform a task, is now an interaction of the programs, data-structure and documentation and is a complex structure to develop, test and maintain. Modern software products are engineered under the selected formal techniques to improve the quality of the product of a software development effort.
The major problem and probably the most critical task with software development is to know where to start from. Even worse situations arise when a project starts with new people in the team, new and unproven technology, unseen business domains and that too, with challenging deadlines. All these when attacking a software development plan, the management is on a risk of crisis. The products overshoot cost estimations and break schedules. They are poor in quality and often fail to respond. They do not meet requirement specifications as defined by consumers and finally, lead to a business failure.
Other challenges before software industry are to measure its intangible products, estimate processes define quality and furthermore, manage the risk. In spite of the enormous economic growth and productivity gains enabled by software, persistent complaints about the quality of software remain. All these make software development a critical practice.
According to a study in the University of Iowa, the basic challenges for software industry, which are most deserving of serious attention in the immediate future include:
- creating the new logic for problem solving based on open-ended programming environments for high performance computer systems
- developing a formal methodology that guides us towards the construction of correct and portable parallel programs, and adopting an openness to radical and innovative alternatives
- designing a programming language that incorporates a unifying intuitive model of parallel computation, and which provides a coherent vehicle for the natural description of parallel programs
- devising and constructing software tools that resonate with the methodology and facilitate a flexible, supportive environment
- introducing widely available, substantial educational opportunities in parallel programming that will create a pool of individuals with the experience and intuition necessary to work effectively in this setting
Like any other engineering products, software products are oriented towards customers and as in any other engineering disciplines; software engineering also has some structured processes and policies for software development. The documented collection of policies, methods and procedures followed by a development team or organization to practice software engineering is called its software development methodology (SDM) or system development life cycle (SDLC). Latest software development methodologies are the organized structures of sequential and parallel activities imposed on the development of a software products. Process, in fact, is a series of definable, repeatable, and measurable tasks leading to a useful result. The benefits of a well-defined process are numerous.
The expanding role of software in the information world forced attention upon the need of software development at acceptable speed and cost and on traceable time schedules. Software products need to be developed with assurance of acceptably high quality that can be maintained over a long period of time for accommodating the changing requirements of the user. The recognition of these needs has initiated considerable research work for enhancement of software process. Much of the research has addressed the overall characteristics and needs of software processes, focusing on such issues as process architectures, process behavioral characteristics, and how processes fit with higher-level organizational systems and characteristics.
According to a report by Dunstan Thomas, for an SDP to be successful, it must be based on best practices, self-improving, easy to implement, acceptable by experienced software professionals, and adaptable to any size of project. In a conclusion of a theory developed by TCS, they define a good software development process to be able to view software development as a value added business activity and not merely as a technical activity. A good software development process should ensure that every product is checked to see if value addition has indeed taken place and safeguard against loss of value once the product is complete. Such a process provides management information for appropriate control of the process. To define such a process, the following steps need to be followed:
- Identify the phases of development and the tasks to be carried out in each phase
- Model the intra and inter phase transitions
- Use techniques to carry out the tasks
- Verify and validate each task and the results
- Exercise process and project management skills
Why do we Need Processes?
By definition, I take a process as the decision or a set of decisions, one wishes to get early in a project. Here, the question comes, why do people feel the need to get something right early in the project. The answer obviously is because they perceive those things hard to change in later phases of the project. I could not find any theoretical reason of anything in software being hard to change. Any aspect of any software may be picked up to make easy to change. Here a common practical problem arises. Efforts to make anything easy to change make the overall complex software a little more complex. This way, making everything easy to change in the software makes it uncontrollably complex. In fact, this is the complexity of the software systems that makes it hard to change. And its hardness to change gives a need of right decisions in early phases of the project.
The sad part of software development is, while there are well defined theories to ensure the reliability of the hardware projects, the things are not so developed and mature about software projects. But at the same time, it is mandatory to control its development through a well-defined and systematic process. The old fashioned 'code & test' approach is now impractical in concern of increased complexities and huge size of current projects. Ad hoc development approaches in current huge developments may cause disastrous outputs. They lead to ambiguous communications, imprecise observations, brittle designs, inaccurate risk assessment, insufficient testing, uncontrolled change propagation and subjective progress assessment.
For these controls over the huge developments, formally defined processes are needed. These development processes are required to provide visibility into the projects. Visibility in turn aids timely management control and mid-course corrections against the expected errors and crisis. It helps developers to weed out faults quite early before they cause to entire failure. This also avoids cascading of faults into later phases where, accumulation of increased number of faults leads to failure. A formal development methodology also helps to organize workflow and outputs to maximize resource utilization and to define everybody's roles and responsibilities clearly. Individual productivity hence increases due to specialization and at the same time the team's productivity increases due to coordination of activities. The adoption of a formal development process with well define unambiguous and complete policies will lead to the benefits of correct requirements to generate the correct product in order to meet the customer's needs preciously and inclusion of necessary features that will in turn, reduce the post-development cost.
Why do we Need Software Standards?
Modeling methods in the past were not very formal affairs. Definitions were left to intuition, and there were many gaps. People with a formal methods background criticized these methods for software projects. They argued that the lack of rigor meant too much ambiguity. But the reality is that many people found that despite this lack of formality, the informal methods were generally more useful and fast resulting than the formal methods. In practice, it seems that informality is an advantage.
But for development projects of increased complexities and huge size, informalities proved to be the major reasons of failures. When the work was distributed in multiple teams, they could not interrelate and integrate their individual work products because of uncommon assumptions and bases of developments. Not following standards of work and strategically themes threw them into pits of failures and crisis. Slowly, the developing industries realized the need of formal processes of development and they developed these processes as per their experiences in their fields.
Further, the ongoing increase in size and complexities of the software projects forced them to come on a common platform to work. Now, when the development processes have crossed the boundaries of continents, organizations found the need to work with some formal standard definitions and development criteria in order to be able to integrate their individual efforts at any level or step of the project. It led to redefining of processes into new improved standard processes. ‘Standard’ also creates a comparison of measurement of the software for ranking it for its quality and also to solve the disputes of delivery hence provides a better control over the product and process.
Many software organizations today are endeavoring to improve their software development processes to improve product quality, project team productivity and reduce development cycle times, thereby increasing their competitiveness and profitability. Software Engineering Institute (SEI) sparked the awareness regarding software process improvement, with the release of its original software process maturity model. Following the advice of the SEI, many software organizations initiated software process improvement efforts to improve the quality of their products by improving the processes that produce those products.
According to Kevin Hyde and David Wilson, CMM-based software process improvement may deliver both tangible and intangible benefits to an organization. Survey-based research was conducted in the development organization during the early 2000s to find out from software professionals if they believed the intangible benefits were being realized. The survey results showed that the organization had experienced improvements in the quality of work life, organization communications, organization learning and efficiencies, the ability to attract, retain and develop software professionals and the coherency of its organization culture.
All these results indicate the prominent need of a standard for development and measurement of the software for its size, complexity, costing, and quality attributes. A formally defined standard is also required to control the development-process so that if a group violates the standard, a release could be 'prepared' by another group.
The conclusions of this article in a single line may be stated as any software project needs to be executed with a formal process and standard practice. The increased complexities and huge size of the software development projects make them tough to control without formal practices and standard measurements. Ad hoc development approaches in current huge developments cause disastrous outputs with ambiguous communications, imprecise observations, brittle designs, inaccurate risk assessment, insufficient testing, uncontrolled change propagation and subjective progress assessment. On the other hand, adoption of a formal development process with well defined unambiguous and complete policies will lead to the benefits of correct requirements to generate the correct product in order to meet the customer's needs preciously and inclusion of necessary features that will in turn, reduce the post-development cost. ‘Standard’ also creates a comparison of measurement of the software for ranking it for its quality and also to solve the disputes of delivery hence provides a better control over the product and process. Further, the ongoing increase in complexities of software projects and their development efforts and costs force continuous improvements in the development processes and strictness in standards.
- Barry Boehm, (July 1996), Anchoring the Software Process, USC, IEEE Software.
- J. Rozum (1993), Concepts on Measuring the Benefits of Software Process Improvement,Technical Report- CMU/SEI-93-TR-009
- Kevin Hyde, David Wilson (2004), Intangible benefits of CMM-based software process improvement, University of Technology, Sydney, PO Box 123, Ultimo 2007, Australia.
- Martin Fowler (1999), How Standard is Standard UML?, Distributed Computing.
- Martin Fowler (2003), Who Needs an Architect?, IEEE Software.
- 12th January, 2007: Initial post