## 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:
BUT PRINCIPLES
AND CONCEPTS
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”)