To understand the need for software engineering, we must temporarily stop and review the recent computing history. This history will help us understand the issues that began to become apparent in the late 1960s and early 1970s, as well as solutions that led to the creation of software engineering. These problems are called "software crisis" by some people and are therefore named after the symptoms of the problem. This situation may also be referred to as "complexity barriers" and is therefore named after the main cause of the problem. Some people mentioned the software crisis in the past. The crisis is far from over, but as many new technologies are now under the heading of software engineering, we have and are continuing to make progress.
In the early stages of computing, the main focus is on building or acquiring hardware. The software can be solved almost by itself. Everyone agrees that "hardware" is difficult to change, while "software" is "soft" or easy to change. It is understood that most people in the industry have carefully planned hardware development, but the prediction of software is unceremonious. If the software doesn't work, they believe it's easy to change it until it works. In that case, why should we plan hard?
Software costs represent only a small fraction of hardware costs, and no one believes this is important for managing their development. However, everyone sees the importance of generating efficient and fast-running programs because it saves time on expensive hardware. People's time is expected to save machine time. Efficient staff processes are prioritized.
When the software is simple, this method proved to be satisfactory early in the calculation. However, as computing matures, programs become more complex, projects become larger, and programs have been regularly designated, written, operated, and maintained by the same person since then, and programmer teams have begun to develop programs to meet others. Demand. Expectation.
The way individuals work hard to make a difference to the team. The communication and coordination that once took place in one's mind must be carried out between the minds of many people, making the whole process more complicated. Therefore, communication, management, planning and documentation become critical.
Consider this analogy: Carpenters can work alone, building a simple house for themselves or themselves, not just a general concept of a plan. As the work progresses, he or she can solve the problem or make adjustments. This is how early programs were written. But if the house is more refined or built for others, the carpenter must plan more carefully how to build the house. Before the start of construction, the plan needs to be reviewed with the prospective owners. If a carpenter is to build a house, the entire project must be planned before the start of work so that when one carpenter builds part of the house, the other does not build the other side of the house. Dispatch becomes a key factor so that the cement contractor pours into the basement wall before the carpenter begins the frame. As homes become more complex, more people must be coordinated and blueprints and management plans need to be developed.
As programs become more complex, early methods for making blueprints [flowcharts] no longer represent this greater complexity. Moreover, it becomes difficult for a person to write a program to communicate to another person, a programmer, just what they want, or how the programmers communicate with each other what they are doing. In fact, even a better programmer can track what he or she is doing without a better representation.
The time required to write the program and its cost began to exceed all estimates. The cost of the system is more than twice the estimate and is several weeks longer than expected, months or years are not uncommon. Systems that are transferred to the client often don't work because they have run out of money or time before the program can work as originally expected. Or the program is so complicated that every attempt to solve the problem produces more problems than fixing the problem. When customers finally see what they get, they often change what they want. At least one very large military software system project costing hundreds of millions of dollars was abandoned because it never worked.
The quality of the show has also become a big issue. Because computers and their programs are used for more important tasks, such as monitoring life support devices, program quality has new meaning. Since we have increased our reliance on computers and in many cases we can't get along without them, we find it important to work properly.
Making changes in complex programs becomes very expensive. Often, it's so hard to make a program do something a little different, making it easier to discard old programs and start over. Of course, this is expensive. Part of the evolution of the software engineering approach is to learn to develop a system that is good enough for the first time to make simple changes easily.
At the same time, the cost of hardware is getting lower and lower. The tube was replaced by a transistor, and the transistor was replaced by an integrated circuit until a microcomputer worth less than $3,000 had become millions of dollars. As an indication of the rate of change, the cost of a given number of calculations is reduced by half every two years. Given this realignment, the time and cost of developing software is no longer so small compared to hardware, and they can be ignored.
With the sharp decline in hardware costs, software continues to be written by humans and its wages are rising. With assemblers, the cost of improving productivity from software development by compilers and database management systems is not as fast as hardware cost savings. In fact, today's software costs can not only be ignored, but have become more expensive than hardware. Some current developments, such as the use of non-process [fourth generation] languages and artificial intelligence [fifth generation], show hope for increased software development productivity, but we are just beginning to see their potential.
Another problem is that past programs usually fully understand what the program needs to do before. Once the program is written, the customer begins to express dissatisfaction. If the customer is not satisfied, the producer is also very dissatisfied. Over time, software developers learned to accurately arrange what they were going to do with paper and pen before they started. They can then review the plan with the client to see if they meet the customer's expectations. Making changes to this pen and paper version is simpler and cheaper than after the system is built. Using a good plan makes it impossible to make changes once the program is complete.
Unfortunately, until a few years ago, there was no good representative method that could be used to describe a satisfactory system that was as complex as the system being developed today. The only manifestation of the product itself is the finished product itself. Developers are unable to show their plans to customers. Before the final build, customers can't see if the software is what they want. Then the change is too expensive.
Again, consider the analogy of the building structure. Architects can draw a floor plan. Customers can usually understand the architect's plan and provide feedback. It is easy for non-professionals to understand the floor plan, as most people are familiar with the drawings that represent geometric objects. Architects share important concepts about space and geometry with customers. But software engineers must represent the customer with a system that involves logic and information processing. Because they do not yet have a common conceptual language, software engineers must teach new languages to customers before they communicate.
In addition, it is important that the language is simple enough to learn quickly.
Orignal From: Why do we need software engineering?
No comments:
Post a Comment