software engineering: a practicioner’s approach

## roger s. pressman ### mcgraw-hill, 1997, 4th ed.

a very business approach:

p.10: Software is (1) instructions (computer programs) that when executed provide desired function and performance, (2) data structure that enables the program to adequately manipulate information and (3) documents that describe the operation and use of the program

software quality is “conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software” - (EXPLICIT) REQUIREMENTS is the basis of quality measurements (i.e. what should the software do?) —— what should it do? - STANDARDS which define the criteria according to which the software should be developed ——- how should it do it? - (IMPLICIT) REQUIREMENTS ——- what should it (obviously) include?

i like the idea of implicit vs. explicit requirements

p. 13: standard is reusability, but how does it relate to source code?

p. 188: standards are uniform, or at least predictable, in order to make work more manageable.

there is a thing called software science, developed by a guy called Halstead, which is highly (exclusively) quantitative -> “intriguing” set of metrics at the source code level

operator: built-in names operands: custom names (knuth’s identifiers)

software isn’t just software as a compiled binary, it’s a software configuration (in the author’s words), which includes programs, documents, and data. which of those can be included in source code?

amongst other requirements, he says that design should be:


  1. data design (related to data structures)
  2. architectural design (relation between main components)
  3. interface design (any kind of interface, not just user interface, but all the flow of information)
  4. procedural design


  1. abstraction
  2. refinement (from abstraction to details), also called elaboration
  3. modularity (modular understandability, if the module can be understood as a standalone unit)
  4. software architecture (not sure what that section actually does here? doesn’t seem like a design concept)
  5. structural partitioning (partitioned horizontally and vertically, makes things “easier”)
  6. data structure (we’ve seen this before, it’s a tricky place in between aesthetics and poetics)
  7. software procedure (irrelevant, too high level? it’s about order of execution)
  8. information hiding (only necessary information, if they have no need, it defines access constraints)

effective modular design

happens through functional independence, which is measured using two qualitative criteria: cohesion (the relative functional strength of the module, how much it does on its own) and coupling (the interdependence on modules).

cohesion follows information hiding (we strive for high cohesion)

LOW END OF COHESION SPECTRUM, if tasks relate to each other loosely     –coincidental———–functional—-     HIGH END(if tasks relate to each other closely)

coupling needs to be minimized (and this is why global variables are bad, mkay), also content coupling should be avoided (when one module modifies data within another module)

p. 410

structured programming depends on sequence, condition and repetition. the use of a limited number of logical constructs also contributes to a human understanding process that psychologists call CHUNKING. understanding is enhanced when readily recognizable logical forms are encountered. but then flowcharts show that it can get quite complicated hahaha.

p. 411

apparently pseudocode is also called “structured english” lol

and then there’s a whole section on OOP, but it’s probably better addressed somwhere else? even though it would be nice to compare differences between OOP in software engineering and OOP in computer science.

p. 682

problems of less formal approaches: (i.e. standards for ugly code?)

requirements/good parts of formal approaches:

clearly associate operations with states, and the relationship to one another

how are these related when it comes to the actual writing!?

the ten commandments of formal methods - interesting because it does specify what a good method would b, even only some of those methods are related to formal writing (1, 6).

BUT ITS NOT BEAUTIFUL (?). people adhere to what is beautiful, and they are slow to adopt that which is only good, but not beautiful by their standards.

p. 768 reverese engineering: what is the process of reading source code?

it has multiple levels:

p. 834 - future topics in software engineering

switch in terminology when talking about this field:

interestingly, the author is more in love with the process than with the object (he also refers to it as “generating code” rather than “writing code”)