Software crisis and software engineering
Software Engineering
From IEEEStandard 610.12, Software engineering is “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software,” and “ the study of approaches as in.”
Historical story
From the Wikipedia, software crisis is the widespread lack of best practices for software in the 1970s. There was great difficulty of writing efficient and specific computer programs in the required time, due to the rapid increases in computer power and the complexity of the problems.
In order to overcome the crisis, NATO (The North Atlantic Treaty Organization) held a conference to define “software engineering” in 1968. From then on, the discipline of software engineering was created to address poor quality of software.
In 1981, 'Software Engineering Economics' was issued by Barry W. Boehm. One of the key theory is COCOMO (The Constructive Cost Model), which relates software development effort for a program, in man-years T, to source lines of code (SLOC) as follows.
Waterfall model
Waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.
As for strengths, firstly, time spent early in the software production cycle can reduce costs at later stages. Secondly, the waterfall model is that it places emphasis on documentation as well as sourcecode. In less thoroughly designed and documented methodologies, knowledge is lost if team members leave before the project is completed, and it may be difficult for a project to recover from the loss. Thirdly, the waterfall model provides a structured approach, which means the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand
As for weakness, Clients may not know exactly what their requirements are before they see working software and so change their requirements, leading to redesign, redevelopment, and retesting, and increased costs. What's worse, Designers may not be aware of future difficulties when designing a new software product or feature, in which case it is better to revise the design than persist in a design that does not account for any newly discovered constraints, requirements, or problems.
CMMI
Initial: Processes unpredictable, poorly controlled and reactive.
Managed: Processes characterized for projects and is often reactive.
Defined: Processes characterized for the organization and is proactive.
Quantitatively Managed: Processes measured and controlled.
Optimizing: Focus on process improvement.