A Science for Software Development

Software science has been lagging behind commercial software development for years. Extremely large software systems were developed in the 1950s and 1960s, including the Sage missile defense system, the Sabre airline-reservation system, and IBM's OS/360 operating system. Commercial development of these large systems proceeded much faster than supporting research did, but practical applications advancing faster than science has been common in engineering. The airfoil wing section that allows airplanes to fly was invented just after it had been "proved" that no machine heavier than air could fly.[9] The development of thermodynamics followed the invention of the steam engine. When John Roebling designed the Brooklyn Bridge in the 1860s, the strength of steel cables was not well understood, and so he designed different parts of the bridge with safety margins as high as 6 to 1. This safety margin was an engineering judgment made in lieu of better theoretical knowledge.

The science that supports software development isn't as well defined as the physics that supports civil engineering. In fact it isn't even considered "natural science." It is what Herbert Simon calls a "science of the artificial"[10] the knowledge areas of computer science, mathematics, psychology, sociology, and management science. A few software organizations regularly apply theories from these areas to their projects, but we are a long way from seeing universal application of these sciences of the artificial to software projects.

But are we really asking software science to provide the right things? For many classes of applications inventory management systems, payroll programs, general ledger software, operating system design, database management software, language compilers (the list is nearly endless) the same basic applications have been written so many times that these systems shouldn't require as much unique design effort as they seem to need. Mary Shaw points out that in mature engineering fields routine design involves solving familiar problems and reusing large portions of prior solutions. Often these "solutions" are codified in the form of equations, analytical models, or prebuilt components. Unique design challenges do present themselves from time to time, but the bread and butter of engineering is the application of routine design practices to familiar problems.

The software world is still in the process of capturing many of its "solutions" in ways that are useful to the average practitioner. Many software project artifacts are potentially reusable, and many of them promise more potential to improve quality and productivity than the most commonly reused artifact, source code, does. Here is a short list of some project artifacts that can be reused:[11]

  • Architectures themselves and software design procedures

  • Design patterns

  • Requirements themselves and requirements engineering procedures

  • User interface elements and user interface design procedures

  • Estimates themselves and estimation procedures

  • Planning data, project plans, and planning procedures

  • Test plans, test cases, test data, and test procedures

  • Technical review procedures

  • Source code, construction procedures, and integration procedures

  • Software configuration management procedures

  • Post-project reports and project-review procedures

  • Organizational structures, team structures, and management procedures

At present, few of these project artifacts have been packaged into a form that the average organization can readily apply.

Science has not yet provided software development with a set of equations that describe how to run a project successfully, or that describe how to produce successful software products. Perhaps it never will. But science doesn't necessarily have to consist of formulas and mathematics. In The Structure of Scientific Revolutions,[12] Thomas Kuhn points out that a scientific paradigm can consist of a set of solved problems. Reusable software project artifacts are a set of solved problems solved requirements problems, design problems, planning problems, management problems, and so on.



Professional Software Development(c) Shorter Schedules, Higher Quality Products, More Successful Projects, [... ]reers
Professional Software Development(c) Shorter Schedules, Higher Quality Products, More Successful Projects, [... ]reers
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net