1. When you can measure what you are speaking about, and can express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowleage is of a meagre and unsatisfactory kind: It may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science. Lord Kelvin, a physicist

Fairly primitive and predictive power limited Function Points Count number of inputs and output, user interactions, external interfaces files used Assess each for complexity and multiply by a weighting factor Used to predict size or cost and to assess project productivity

Reuse (Assume have source code, not a commercial product) Ariane 5. Therac-25. British AtC Expectation Significantly lower development costs and time. Amortize costs among all users or uses Assumptions

A Testing EXercise (From Glenford Myers: The Art of Software Testing A program reads three integer values from a card. The three values are interpreted as representing the lengths of the sides of a triangle. The program prints a message that states whether the triangle is scalene iso

Formal design Reviews Associated with each of documentation phases Evaluate with respect to Customer requirements Prescribed standards and practices Contractual requirements

State Machine specifications Define behavior using states and transitions between states

Outline: Software Design Goals History of software design ideas Design principles Design methods Life belt or leg iron?(Budgen)

design: added inheritance, multiple inheritance, and polymorphism to ADT In process added complexity and increased some types of connectivity Lots of claimed advantages -- so far empirical evaluation is not supporting them well

Abstract Model Specifications Build an abstract model of required software behavior using mathematically defined(perhaps using axioms )types(e. g sets, relations) Define operations by showing effects of that operation on the model Specification includes Model

Requirements specification: A structured document that sets out the services the system is expected to provide Should be precise so that it can act as a contract between the system procurer and software developer and thus needs to be understandable by procurers and developers