Physical phemomenon and Software engineering: Difference between pages

From Wikipedia, the free encyclopedia
(Difference between pages)
Content deleted Content added
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:

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.