Software Engineering

Software Engineering Paradigms

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


Slides adapted from the slides for the book "Software Engineering: The Current Practice" by Václav Rajlich © 2012 by Václav Rajlich

Programmers Face Difficulties

  • Memory management
  • Pointers
  • Types and subtypes
  • IDE or other tools crash/corrupt
  • Process differences

Category of Difficulties

Accidental difficulties

  • Difficulties of past/current/future technologies
  • Quirks of the o.s., languages, compilers, and processes

Category of Difficulties

Essential difficulties

  • A subset of the essential properties of software
  • No easy answers

Essential Difficulties

  • Complexity
  • Invisibility
  • Changeability
  • Conformity
  • Discontinuity

Essential Difficulty: Complexity

Programs are among the most complex systems ever created

Essential Difficulty: Invisibility

Software is abstract

  • We cannot use most of our senses for software comprehension
  • Use of other senses (e.g., software visualization) require work to understand
  • E.g., MosaiCode

Essential Difficulty: Changeability

Software is easy to change

  • Software is constantly changing
  • Yesterday's comprehension may be obsolete
  • Continuous effort to keep up

Essential Difficulty: Conformity

Large systems include more than software, e.g., hardware, users, domain

  • Software glues it together, reflects the larger domain
  • … adding more complexity

Essential Difficulty: Discontinuity

People understand linear or semi-linear systems

  • E.g., faucet knobs
  • Software is discontinuous, i.e., a small change in the input can result in a significant change in the output
  • E.g., one wrong calculation can be minor or significant, and there is no way to predict

Beginning of Software

  • Separated from hardware in the 1950s
  • Distinct technology
  • Independent product
  • Original programmers were hardware engineers and mathematicians
  • Used ad-hoc techniques from their former fields

Definition: Paradigm

Paradigm: "Coherent tradition of scientific research"

  • Thomas S. Kuhn's "The Structure of Scientific Revolutions"
  • Includes law, theory, application, instrumentation, terminology, research agenda, textbooks, norms, curricula, culture, etc.
  • Not only the ideas but also investment in those ideas
  • Often overused, e.g., "object-oriented paradigm"

Anomaly Creates Dilemma

Anomaly: an important fact that directly contradicts the old paradigm

  • Dilemma: disregard anomaly vs. paradigm shift
  • Shifting paradigm requires abandoning substantial investment
  • Anomaly must be compelling

Paradigm Shift

Discontinuity in the development of the discipline (i.e., a revolution)

Resistance to Paradigm Shift

  • Advantages of the new paradigm are disputed
  • Extend old paradigm to accommodate anomalies
  • "band-aid" approaches to fix old paradigm
  • Accumulated knowledge and investment may lose significance, and some knowledge may be lost
  • New paradigm only ultimately "wins" when a generation change occurs
  • Paradigm shifts may be unsuccessful

Paradigm Shift: the 1970s

Anomaly: Previous ad-hoc techniques did not scale

  • Brooks Mythical Man-Month
  • Demands of the (new) IBM OS/360 O.S. strained the limits of programmers, project managers, and resources of IBM
  • Paradigm Shift established the discipline of software engineering
  • Dealt with the complexity of software
  • Software Design became important
  • Introduced the Waterfall metaphor

Waterfall Paradigm



Waterfall did not solve the problems of software development

  • Requirements volatility, e.g., Requirements for IT change at a rate of 24 - 36% / year (doubling at least every ??? and ??? years, respectively)

Paradigm Shift: ~2000

New lifespan models emphasize software evolution

  • Staged model of software lifespan
  • Based on data from real systems over long periods
  • Iterative development, Rational Unified Process, agile development, eXtreme Programming, Scrum
  • Shift even in DOD software

Paradigm Summary

  • Waterfall paradigm
  • Tried to freeze requirements for the duration of development
  • Deal with volatility by rigidity
  • Led to too many project failures
  • New paradigm
  • Emphasizes software evolution and iteration
  • Interoperability and complexity cause volatility
  • Volatility is a consequence of essential properties

All Paradigms Coexist

  • Ad-Hoc paradigm
  • Still used by some individual developers
  • Programming as an art rather than engineering
  • E.g., small games, small utilities
  • Waterfall paradigm
  • Small or short-lived projects
  • Unusually stable requirements and environments
  • Management may insist on it
  • Iterative paradigm
  • The mainstream of modern development