Software engineering

The development of the software engineering discipline arose out of the software crisis of the 1960s and 1970s, when many large software projects went over budget and deadlines in an unexpected manner. TBD: Examples needed.. One classic example was the development of [OS 360]?, the operating system still used on the [IBM 360 Series]? and its descendents. This decade-long project (which, unlike others, finally produced a working system, which, although having some obvious flaws, is amongst the most reliable complex software systems ever designed) from which the chief architect Fred Brooks produced a classic text The Mythical Man-Month, describing much of what he had learned.

Other cases did not have such happy endings. Several embedded systems for use in radiotherapy? machines failed so catastrophically that lethal doses of radiation were administered to a number of patients.

Other big stuffups I know about, though they were from the 80's and 90's and they're all Australian:

• The automatic tollway in Melbourne was delayed a year due to engineering difficulties, but even with the delay the software wasn't ready and they couldn't charge tolls for the first three months of operation.
• The automatic ticketing system for Melbourne's public transport was delayed for years because of software difficulties. (It is still hated, but that has more to do with hardware and politics rather than strictly software).
• The combat system for Australia's Collins-Class submarines was so bad, it has had to be scrapped and replaced with an American system.
• The Jindalee Over-The-Horizon radar project was delayed for years because Telstra?, who were contracted to do the programming work, couldn't get it right. They were eventually sacked and Rockwell was given the contract.

It was believed that this crisis was due to the lack of discipline of programmers, and it was believed that if more formal engineering methodologies could be applied to software development, the production of software would become as predictable an industry as other branches of engineering.

Libraries are full of books that have been written on the subject. Some of the best have been published by the Software Engineering Institute (SEI) at Carnegie-Mellon University in Pittsburgh, PA.

Methods have improved through the 1980s and 1990s, but the complexity in requirements have increased fast enough to consume any improvement. One problem is that many customers are first time customers without previous experience from writing requirements for a software project. If the programmers are good, the system will work, and the customer will not fully appreciate how complex the task was. There is also a constant eagerness to develop new tools and try the newest tools in each new project.

Software engineering methodologies are often broken up or spread across a number of different disciplines, including every thing from project management, software testing, design, specification, and quality assurance. All of the more formal methods guiding this field are collations of all of these fields. Some of the better known methodologies include Cleanroom?, Capability Maturity Model (CMM), and a new concept called [Extreme Programming]? (XP).

Some of the concepts involved in these include: TBD: maybe a far more comlete list here:

• [Requirments gathering]?.
• [Quality assurance]?.
• Risk management.
• Project management.
• [Functional decomposition]?.
• Object Oriented Programming.
• UML.
• Project lifecycle.
• Software testing.
• [State oriented programming]?.

. See also SWEBOK, computer science. Exactly where is the border between science, technology, and engineering here?. . . /Talk?.