[ad_1]
To understand the necessity of software engineering, we must pause briefly to look back at the recent history of computing. This story will help us understand the problems start to become evident in the late sixties and early seventies and solutions that have led to the creation in the field of software engineering. This problem was referred to by some as “The software crisis,” so named for the symptoms of the problem. The situation could also be called “The Complexity Barrier,” so named for the primary cause of the problems. Some refer to the software crisis in the past tense. The crisis is far from over, but thanks to the development of many new techniques that are currently listed under the name of software engineering, we have made and continue to make progress.
In the early days of computing primary concern was to build or buy hardware. Software was almost expected to take care of themselves. Solidarity maintained that the “hardware” is “difficult” to change, but “software” is “soft,” or easy to change. According, most people in the industry carefully planned hardware development but gave considerably less forethought to the software. If the software did not work, they believed, it would be easy enough to change it until it did work. In that case, why make the effort to organize?
Cost of software amounted to such a small fraction of the cost of the hardware that no one considered it very important to control its development. All, however, the importance of producing programs that were efficient and ran fast because this saved time on expensive hardware. It was assumed that people time to save machine time. Making people work efficiently received little priority.
This method proved adequate in the early days of computing, when the software was simple. However, as computing matures, applications became more complex and projects grew larger than had since been regularly, write, run and maintain all of the same party, applications began to develop teams of developers to meet someone else’s expectations.
Individual effort gave way to teamwork. Communication and coordination which once went on inside the head of one person had to occur between the heads of many people, making the whole process a lot more complicated. . Consequently, communication, management, planning and data became important
Consider this analogy: a carpenter might work alone to build a simple house for himself without more than the general concept of the plan. He or she could work it out or make changes that work progress. That’s how early programs were written. But if the home is more elaborate, or if it is built for someone else, the carpenter has to plan better how the house is built. Plans must be reviewed by a future owner before construction begins. And if the house is to be built by many carpenters, the whole project certainly has to be organized before beginning work so that as one carpenter builds one part of the house, another is building on the other side different houses. Timing will be key so that cement contractors pour the basement walls before the carpenters start the framing. The house will work more complex and people need to be coordinated, blueprints and action is required.
plans became more complex, the early methods used to make drawings (flowcharts) were no longer sufficient to represent this greater complexity. And so it became difficult for one person who needed a program written to be transferred to another party, programmer, just what was wanted, or for developers to communicate to each other what they were doing. In fact, without better methods of representation it became difficult for even one programmer to keep track of what he or she is doing.
The times required to write programs and their costs began to go to all estimates. It was not unusual for systems to cost more than double what had been scheduled to take weeks, months or years longer than expected to complete. The systems delivered to the customer often did not work properly because the money or time had run out before the plans could be made to work as originally intended. Or the program was so complex that any attempt to fix a problem produced more problems than it fixed. As clients finally saw what they were getting, they often change their minds about what they wanted. At least one very large military software systems project costing several hundred million dollars was abandoned because it could never be made to work properly.
The quality of applications was also a major concern. As computers and their applications were used for more important tasks, like monitoring life support equipment, program quality took on new meaning. Since we had increased our dependency on computers and in many cases could not get by without them, we discovered how important it is that they are operating properly.
made within a complex program turned out to be very expensive. Often even get the program to do something slightly different was so hard that it was easier to throw out the old program and start over. This, of course, was expensive. Part of the development of the software engineering approach was learning to develop systems that are built well enough the first time so that simple changes can be made easily.
At the same time, hardware was growing ever cheaper. Tubes were replaced by transistors and transistors were replaced by integrated circuits until micro computers costing less than three thousand dollars have become several million dollars. A sign of how fast change was introduced, the cost of a certain amount of computing decreases by half every two years. In light of this restructuring, the time and cost to develop software was no longer so small, compared to the hardware, they might be ignored.
and the cost of hardware fell, software continues to be written by men, whose wages rose. Savings of improved productivity in software development in the use of assemblers, collector and database management system not proceed as fast as the savings in hardware costs. Indeed, today software costs not only can no longer be ignored, they have become larger than hardware costs. Some current trends, such as nonprocedural (fourth generation) languages and the use of artificial intelligence (fifth generation), promise increasing software development productivity, but we are only beginning to see the potential.
Another problem was that in the past programs were often before it was fully understood what the program has to do. Once the program has been written, the client began to express dissatisfaction. And if the customer is unhappy, especially manufacturers, too, was unhappy. As time went by software developers learned to lay out paper and pencil exactly what they have to do before you start. Then they could go over the plans with the client to see if they met the customer’s expectations. It is simpler and cheaper to make changes to this paper-and-pencil version than to make them after the system has been built. Using good planning makes it less likely that changes will be made when the program is completed.
Unfortunately, until a few years ago not a good way representative be adequately described a system as complex as the ones being developed today. The only good representation of what the product will look like the finished product itself. Developers could not show clients what they were planning. And customers could not see whether the software was what they wanted until it was finally built. It was too expensive to change.
Again, consider the analogy of building construction. The architect can draw a floor plan. The customer can usually understand what the architect has planned and give feed back on whether it is appropriate. Floor plans are fairly easy for the layperson to understand because most people are familiar with drawings representing geometrical objects. Architect and client components common ideas about space and geometry. But the software engineer will be a system for the client includes logic and information processing. Since they do not already have a language of common concepts, software engineer must teach a new language to the customer before they can communicate.
Moreover, it is important that these issues be simple so it can be learned quickly.
[ad_2]