Physical phemomenon and Software engineering: Difference between pages
Fredbauder (talk | contribs) mNo edit summary |
linked fields of enginerring |
||
Line 1: | Line 1: | ||
The term '''software engineering''' is used today to refer to the overall process |
|||
'''Physical Phenomena''' are observable events which are explained by [[physics]] or raise some question about [[matter]], [[light]], or [[spacetime]]. For example, it was observed, by [[Isaac Newton]], that while an apple might fall from a tree, the moon, very large and massive, does not fall. |
|||
of creating computer [[software]], which encompasses [[computer programming]], |
|||
software design, quality assurance and testing, configuration management, and |
|||
even personnel management functions. |
|||
Software engineering is best described as an emerging field of [[engineering]], as it is not yet a mature field of engineering like [[structural engineering]] or [[electronic engineering]]. Although large reliable software systems can be and are constructed, software projects that fail in construction or in service are still unacceptably common. It is unclear when or if software engineering will become a mature field. |
|||
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. |
|||
One classic example was the development of [[OS 360]], the [[operating system]] still used |
|||
on the [[IBM 360 Series]] and its descendants. |
|||
This decade-long project finally produced a working system, which, although having some |
|||
obvious flaws, is amongst the most reliable complex software systems ever designed. |
|||
Its chief architect [[Fred Brooks]] produced a classic text [[The Mythical Man-Month]], |
|||
describing much of what he had learned from the project. |
|||
Some believed that the 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]]. |
|||
Other cases did not have such happy endings, and point out that even the early |
|||
lessons of the field were not sufficient to prevent many disasters. |
|||
Several [[embedded systems]] for use in [[radiotherapy]] machines failed so |
|||
catastrophically that lethal doses of radiation were administered to a number of patients. |
|||
Many other failures, such as the explosion of a French [[Ariane]] rocket led to further |
|||
developments in the field. |
|||
Many books have been written on the subject, including several popular ones by |
|||
the [[Software Engineering Institute]] (SEI) at [[Carnegie-Mellon University]]. |
|||
Methods have improved through the [[1980s]] and [[1990s]], but the complexity |
|||
in requirements has increased fast enough to consume any improvement. |
|||
One problem is that many customers are first-time customers without previous experience |
|||
in writing requirements for a software project. |
|||
Another problem is that in many software projects, the customer really does not know |
|||
what they want before they see it. |
|||
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. |
|||
Many have also criticized attempting to fit software into an engineering paradigm |
|||
by noting that in physical engineering, engineers are applying known and tested principles, |
|||
and the amount of untested innovation that goes into creating a product is intentionally |
|||
limited. |
|||
By contrast in commercial software, each new software project contains new and untested |
|||
elements. |
|||
In physical engineering, most of the effort goes into replicating proven designs. |
|||
In the software world, replication is trivial, and most of development goes into building |
|||
unproven designs. |
|||
Software engineering methodologies are often broken up or spread across a number |
|||
of different disciplines, including everything 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). |
|||
It should be noted that some of the methodologies advocate conflicting solutions and |
|||
proponents of different methodologies often get into heated debates over their merits. |
|||
Software design methodologies can be informally classified into "thick" methodologies |
|||
which include a large amount of formal process and documentation and "thin" methodologies |
|||
which eschew formal process and documentation. |
|||
Some of the concepts involved in these include: |
|||
''TBD: maybe a far more complete list here:'' |
|||
* [[Requirments gathering]]. |
|||
* [[Quality assurance]], which focuses on Preventing [[computer bug|bugs]]. |
|||
* [[Risk management]]. |
|||
* [[Project management]]. |
|||
* [[Functional decomposition]]. |
|||
* [[Object Oriented Programming]]. |
|||
* [[UML]]. |
|||
* [[Software architecture]] |
|||
* [[Software development process]] |
|||
* [[Project lifecycle]]. |
|||
* [[Software testing]]. |
|||
* [[State oriented programming]]. |
|||
See also [[SWEBOK]], [[computer science]]. |
|||
The border between [[science]], [[technology]], and [[engineering]] in the field of software |
|||
has always been fuzzy, but simply put, computer science is the scientific truths and theory |
|||
about software, and software engineering is the application of these theories to real-world |
|||
projects. |
Revision as of 07:20, 14 April 2002
The term software engineering is used today to refer to the overall process of creating computer software, which encompasses computer programming, software design, quality assurance and testing, configuration management, and even personnel management functions.
Software engineering is best described as an emerging field of engineering, as it is not yet a mature field of engineering like structural engineering or electronic engineering. Although large reliable software systems can be and are constructed, software projects that fail in construction or in service are still unacceptably common. It is unclear when or if software engineering will become a mature field.
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. One classic example was the development of OS 360, the operating system still used on the IBM 360 Series and its descendants. This decade-long project finally produced a working system, which, although having some obvious flaws, is amongst the most reliable complex software systems ever designed. Its chief architect Fred Brooks produced a classic text The Mythical Man-Month, describing much of what he had learned from the project.
Some believed that the 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.
Other cases did not have such happy endings, and point out that even the early lessons of the field were not sufficient to prevent many disasters. Several embedded systems for use in radiotherapy machines failed so catastrophically that lethal doses of radiation were administered to a number of patients. Many other failures, such as the explosion of a French Ariane rocket led to further developments in the field.
Many books have been written on the subject, including several popular ones by the Software Engineering Institute (SEI) at Carnegie-Mellon University.
Methods have improved through the 1980s and 1990s, but the complexity in requirements has increased fast enough to consume any improvement. One problem is that many customers are first-time customers without previous experience in writing requirements for a software project. Another problem is that in many software projects, the customer really does not know what they want before they see it. 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.
Many have also criticized attempting to fit software into an engineering paradigm by noting that in physical engineering, engineers are applying known and tested principles, and the amount of untested innovation that goes into creating a product is intentionally limited. By contrast in commercial software, each new software project contains new and untested elements. In physical engineering, most of the effort goes into replicating proven designs. In the software world, replication is trivial, and most of development goes into building unproven designs.
Software engineering methodologies are often broken up or spread across a number of different disciplines, including everything 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). It should be noted that some of the methodologies advocate conflicting solutions and proponents of different methodologies often get into heated debates over their merits.
Software design methodologies can be informally classified into "thick" methodologies which include a large amount of formal process and documentation and "thin" methodologies which eschew formal process and documentation.
Some of the concepts involved in these include: TBD: maybe a far more complete list here:
- Requirments gathering.
- Quality assurance, which focuses on Preventing bugs.
- Risk management.
- Project management.
- Functional decomposition.
- Object Oriented Programming.
- UML.
- Software architecture
- Software development process
- Project lifecycle.
- Software testing.
- State oriented programming.
See also SWEBOK, computer science. The border between science, technology, and engineering in the field of software has always been fuzzy, but simply put, computer science is the scientific truths and theory about software, and software engineering is the application of these theories to real-world projects.