The software process models are very important, for these models tell us how software gets developed in a project. The waterfall model was a major breakthrough in the 1970s; it showed the major activities to be done in a nice waterfall. But the nature of software development work is too involved and a lot of harm may come in a project's way if the steps of waterfall model are followed in a strict sequence. The activities identified in the waterfall model are very important but the waterfall itself is not a good idea in the context of software projects. The evolutionary and the spiral model try to address the deficiencies in the waterfall model. In this article, we say that the activities of waterfall model are not at all done in a sequence in a project; these activities are done concurrently with varying intensities at all times all through the software life cycle.
As software is intangible, it is tempting for the managements to try to get a lot of work done in very short time-frames, with the thought even if the project takes a little longer, a lot of work would have still been done. This can lead to situations where a lot of work is being done but there is no real progress on the project. It is a situation similar to thrashing in operating systems. In a development project, it is important to create concepts and lower level artifacts that are seminal in nature and on which higher level artifacts can be built upon. It helps if there are no unrealistic time-pressures in a software project, especially in the nascent formative stages.
Agile methods represent lateral thinking in software engineering. Traditional methods have worked well in the past. But it was felt that there was much scope for improvement and
some fresh thinking addressing the core issues was required. As it turned out that fundamental principles were, software projects must focus on customer's business interests, we should outputs in terms of a software product that can be run and seen as against unverifiable documents, we should have a small time-frames in a few weeks with objectives in terms of a predefined software product output, we should have small autonomous teams, etc. These and more ideas are the basic guiding principles in the scrum agile software development methodology.
To say that Unix is a great case study for software engineering would be an understatement. But there is a lot in the development process of Unix that all software development teams can benefit from. Just as Unix is a great case study for operating systems theory, its development is an equally important case study for software engineering.
