Cisc 327 Quiz 3

Front 1

First Law of Software Development

Back 1

EARLIER IS CHEAPER

The later in the development cycle a fault is detected the more expensive it is to fix

Front 2

Artifacts of Software Development

Back 2

What we produce when making software

Plans, procedures, source code, comments, test cases, test reports, user doc, technical doc

Front 3

Review

Back 3

usually refers to the management practice of meetings to informally consider state of the project at certain stages

Front 4

Walkthroughs

Back 4

refer to an informal technical review, normally carried out by developers

used by dev teams to improve quality, by involving whole team

Front 5

Inspections

Back 5

refers to completely formal process of review, aka formal technical reviews

involves formal written reports, defect data collection, and analysis

Front 6

Inspections in the Software Process

Back 6

Requirements defn (requirements review)

System and software design (design inspection)

Implementation and unit testing (code inspection)

Integration (functional audit)

Operation and maintenance

Front 7

Kinds of Inspections

Back 7

A generic technique = inspections can assist at every stage, the earlier the better

Front 8

PDR

Preliminary Design Review

Back 8

1 - EVALUATE the progress, technical adequacy, risk resolution

2 - DETERMINE its compatibility with performance and engineering requirements

3 - EVALUATE the degree of definition and assess the technical risk of manufacturing methods

4 - ESTABLISH the existence and compatibility of the physical and functional interfaces

Front 9

Example: PDR

Back 9

For CSCIs the review would focus on

1 - evaluation of the progress, consistency and technical adequacy of the selected top level design

2- compability between software req's and prelim design

3 - on the prelim version of the operation and support documents

Front 10

The Prevention Principle

Back 10

Prevention is better than cure.

Front 11

IEEE Definition of Inspection

Back 11

"... a formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the author to detect faults, violations of development standards, and other problems..."

Front 12

IEEE Objective of Inspection

Back 12

to detect and identify software element defects. This is a rigorous, formal peer examination.

Front 13

Inspection

Back 13

-verifies that the software elements satisfy the specifications

-verifies that software elements conform to applicable standards

-id's deviations from standards and specifications

-Collects software engineering data

-does not examine alternatives or stylistic issues

Front 14

Fagan Inspections

Back 14

150 lines/ hour paraphrased

Moderator, chairs the meeting

2-3 Inspectors, paraphrase line by line

Author, silent clarifies when asked

Front 15

Choosing Inspectors (FAGAN)

Back 15

Good - review specialists, technical people from same team as author

Bad - managers, supervisors, anyone with personality clash with author, all management, anyone with conflict of interest

Front 16

Side benefits of Inspection

Back 16

Cultural, promotes shared quality culture

Organizational, coding standards and practises are learned and enforced

Educational, quality improves over time, as authors become more aware of the kinds of faults they are prone to

Front 17

Inspection Process

Back 17

Inspections may be used at any stage of software development

Ideally inspections can be applied at every stage to catch problems as early as possible

No matter what stage, the process time stays the same

Front 18

Generic Inspection Process

Back 18

Planning - choose team, schedule, materials

Orientation - introduce artifact, process

Prep - individually check artifact, note issues

Review meeting - meet to discuss

Rework - correct defects noted

Verify - verify artifact and process quality

Front 19

Planning

Back 19

Objectives

- gather review package, artifact being inspected, form team, set up schedule

Front 20

Orientation Meeting

Back 20

Author provides overview of artifact

inspectors obtain review package

prep goals set

inspectors commit to participating

Front 21

Preparation

Back 21

Find the max number of non-minor defects in the artifact

Front 22

Defect Classification

Back 22

Critical - cause system to crash, incorrect results

Severe - incorrect results

MOderate - affect limited areas of functionality

Minor - defects that can be overlooked without loss of functionality

Front 23

Checklists and References

Back 23

C - include list of questions about completeness, style

R - company standard docs, online resources, textbooks for reference

Front 24

Review Meeting

Back 24

Make consolidated, comprehensive list of non-minor defects to be addressed

-help group synergy

-help provide shared knowledge of artifacts

Front 25

Rework

Back 25

Assess each defect listed in the review defect report, determine if really a defect, and repair as neceassary

written report on handling of each non minor defect

resolve minor issues

Front 26

Verify

Back 26

Assess reworked artifact quality

assess inspection process

pass or fail the artefact

Front 27

Code Inspections

Back 27

Even if we have a highly formalized inspection process such as the generic one we looked at last time, there is still a range of actual practices that can be applied to implement the actual review of the artifact

Front 28

Code Checklists

Back 28

give concrete list of properties of the code to check for

may be general properties for any program, or specific for specific program

both desired properties and undesired may appear

Front 29

Code Checklist example

Back 29

– 1. Variable and Constant Declaration Defects

1.1 Are descriptive variable and constant names used in accord with naming conventions?

1.2 Are there variables with confusingly similar names?

1.3 Is every variable properly initialized?

1.4 Can any non-local variables be made local?

Front 30

Code Paraphrasing

Back 30

Reading the code in english

is the original method of review described by fagan for use in code inspections

object is to ensure that the code really does implement what we want

mainly concepts and processes, not variables

Front 31

Structured Code Walkthroughs

Back 31

A Guided Tour

very effective in training

less effective as an inspection method

Front 32

The Lions Commentary

Back 32

1977 "Source Code and Commentary on UNIX Level 6" by John Lions

Front 33

Lightweight Code Inspection Practices

Back 33

Learning from success

formal inspections are very successful at finding defects, but many find the process too cumbersome

As a result, many practices have been developed that can gain som advatages

Front 34

Lightweight Code Inspection

Four Eyes Principle

Back 34

Programmers work in loose pairs, where each module is authored by 1 programmer and informally inspected by the other

Front 35

Lightweight Code Inspection

White Box Testing By Hand

Back 35

when applied manually, most white box testing methods force the test author to examine the code in detail to create the tests - in practice this is how most defects are found

Front 36

Heavyweight Inspection Practices

Back 36

Doing it right in the first place

formal verification

Front 37

Heavyweight IP

Cleanroom Software Development

Back 37

Essentially the ideal inspection process

formal specification

incremental development

structured programming

stepwise refinement

static verification

statistical testing

Front 38

Code Inspections Summary

Back 38

When the inspection process is applied to code = checklists, paraphrasing, walkthroughs

Lightweight gain advantages of inspections without formal process, as in XP

Heavyweight inspection, all the way to formal verification

Front 39

Code Inspection in XP

Back 39

Lightweight, continuous approach

XP uses two lightweight software dev processes

pair programming, and refactoring

Front 40

Pair Programming

Back 40

-PP is continuous and immediate code inspection

-observed to increase quality because all code is inspected

-increases productivity

Driver = author

Partner = inspector

Front 41

Code Refactoring

Back 41

is improving the design of the existing code

improve design without affecting external behaviour

Front 42

4 Constraints of Improving Design

Back 42

1. the system must communicate everything you want to communicate

2. system must contain no duplicate code

3. system should have the fewest possible classes

4. system should have the fewest possible methods

ONCE AND ONLY ONCE RULE

Front 43

ONCE AND ONLY ONCE

Back 43

everything that must be in the program is in the program, and only in one place

Front 44

Code Smells

Back 44

In XP when code need to refactor it "smells"

class too long, switch statements, struct class, duplicate code, almost duplicate, too many primitive type variables, useless comments

Front 45

Refactoring Process

Back 45

The Refactor Cycle

Identify some code that smells, apply refactoring, run the tests, repeat

Done when we pass the tests

Front 46

The Fowler Catalog

Back 46

Martin Fowler published a by-example catalog of refactorings that can be applied

This catalog is rough guide for when and why certain refactorings should be used

Front 47

Extract Method

Back 47

One of the most common refactorings

Code fragment the can be grouped together, turn the fragment into a method whose name explains the purpose

Front 48

Duplicated Code

Back 48

Most significant smell in source code

Code is duplicated, duh

Front 49

Long Method

Back 49

the longer the method or function the more difficult it is to understand

Front 50

Long parameter list

Back 50

parameters are better than globals ,but long parameter lists are hard to understand

Replace parameter with method

invoke a method to get the parameter

Front 51

Switch Statements

Back 51

Object oriented code should have comparatively fewer switch statements than imperative code

Adding a new conditional case to a switch may require changing other switch statements

Replace conditional with polymorphism

-move each leg of the conditional to an overriding method in a subclass, make the original abstract

Front 52

Identifier Length

Back 52

Excessively long identifiers

excessively short ones

names of variables, methods, ya know

Front 53

Speculative Generality

Back 53

We'll probably need this some day

include generality in a program in case it is required in the future

Front 54

Software Quality Metrics

Back 54

Software metrics are measurable properties of software systems, their development and use

includes a wide range of diff measures of

properties of software itself, process of proceeding and maintaining, and its source code design, tests

Front 55

What are Metrics good for?

Back 55

Reliability and Quality Control

-metrics help us to predict and control the quality of our software

Costs estimation and productivity improvement

-help predict effort to produce or maintain

Quality Improvement

-Metrics help us to improve code quality and maintainability

Front 56

Kinds of Metrics

Back 56

3 basic kinds

product metrics, process metrics, project metrics

Front 57

Product Metrics

Back 57

are those that describe the internal and external characteristics of the product itself

ex: size, complexity, features, performance, reliability quality levels

Front 58

Process metrics

Back 58

measure the process of software development and maintenance to improve it

ex: effectiveness of defect removal during development

Front 59

Project Metrics

Back 59

ARE THOSE that describe the project characteristics

ex: # of developers, development cost, schedule, productivity

Front 60

Definition of Measurement

Back 60

is the process of empirical objective assignment of numbers to entities, to characterize an attribute

an entity is an object or event

an attribute is a feature if the entity, such as size of program

objective means the measurement must be biased on a well defined rule

each entity is a given number, which tells you about its attribute

Front 61

To avoid mistakes in software measurement

Back 61

1. must specify both an entity, and an attribute not just one of the other

2. you must define the entity precisely

3.you must have a good intuitive understanding of the attribute before you propose a measure for it

Front 62

Direct Measurement

Back 62

are numbers that can be derived directly from the entity without other info

ex

length of source code, measured by # of lines

Front 63

Indirect Measurement

Back 63

are numbers that are derived by combining two or more direct measures to characterize an attribute

ex:

programmer productivity = lines of code/person-months of effort

Front 64

Prediction Systems

Back 64

measurement for prediction requires prediction system

1. A mathematical model

2. A procedure for determining the model parameters

3. A procedure of interpreting results

Front 65

Probability of failure on demand (POFOD)

Back 65

the probability that a demand for service from a system will result in a system failure

Front 66

Rate of occurrence of failures (ROCOF)

Back 66

the probable number of failures likely to be observed in a certain time period

Front 67

Availability

Back 67

the ability of the system to deliver serves when requested

Front 68

External Product Metrics

Back 68

are those we can apply only by observing the software product in its environment

includes many measures but particularly:

-failure rate, availability rate, defect rate

Front 69

Definition of Reliability

Back 69

Reliability is the probability that a system will execute without failure in a given environment over a given period of time

Front 70

Definition of failure

Back 70

formal view: any deviation form specified behaviour

engineering view: any deviation form required, specified, or expected behaviour

Front 71

Error

Back 71

is a mistake or oversight on the part of the designer or programmer who could cause a fault

Front 72

Fault

Back 72

is a mistake in the software which in turn could case a failure

Front 73

Failure

Back 73

when the program is run in certain situations

Front 74

Defect

Back 74

is usually defined as a fault of a failure

= faults + failures

Front 75

Defect Density

Back 75

is a standard reliability metric

DD = # of defects found / system size

Size is normal in KLOC, 1000s of lines of code

Front 76

Internal Product Metrics

Back 76

most metrics in practice are internal, measures of the software code

easy to make and easy to automate, but not always clear which attributes of the program they characterize

Front 77

Code Metrics

Back 77

Software Size

-simplest and most enduring pro cut metric is the size of the product, measured in LOC (lines of code), most often KLOC

Front 78

Better Size Measures than LOC

Back 78

Length: the physical size of software

functionality: the capabilities provided to the user by the software

complexity: how complex is this software

Front 79

Complexity: how complex is this software?

Back 79

problem complexity: of underlying problem

algorithmic C

structural C

cognitive C

Front 80

Halstead's "Software Science" Metrics

Back 80

Operators: if, return, this, +

Operands: int, bool, void, x, y

Source code is a sequence of tokens, each of which is either an operator or operand

Front 81

McCabe's "Cyclomatic Complexity: metric

Back 81

mainly equations which he said not to worry about it

think flow graphs

Front 82

Flowgraoh complexity of software

Back 82

max path length

number/ interaction of cycles

max number of alternative paths

Front 83

COCOMO

Back 83

COnstructuve COst MOdel

method of modelling software development, to yield estimates of effort and cost before undertaking the project

Software cost estimation

Front 84

Simple COCOMO effort prediction

Back 84

simplest model uses estimate

effort = a (size) ^b

effort is measured in person-months

sizes the predicted size of the software inKDSI

Front 85

The downside of COCOMO

Back 85

the simple cocomo model is claimed to give goof order of magnitude estimates of required effort

but depends on a size estimate - which some say is just too hard to estimate

could be off exponentially

Front 86

Estimating time using COCOMO

Back 86

uses a similar model for time given effort

time = a ( effort ) ^b

time is in moths

effort in person-months

again though exponentially off is possible

Front 87

Where does COCOMO come from?

Back 87

is based on empirical measurements of the actual effort and cost of past software projects as a function of software size

and the derivation of regression equation to explain them

analysis of data indicated a logarithm of the effort

Front 88

How can we predict size independently of code/

Back 88

predictions of effort, cost and time depending on code size have 2 inherent difficulties

-prediction based on KDSI or KLOC just involves just replaced one difficulty prediction problem with another one

-KDSI are actually measures of length not size

Front 89

Function Point Analysis

Back 89

function points is currently the most popular and widely used size metric

computed from detailed system specification using the equation

FP =UFC x TCF

UFC = unadjusted function count

TCF = technical complexity factor

Front 90

Using Function Points

Back 90

are used extensively as a size metric in reference to KLOC, for example in equations for productivity, defect density and cost / effort prediction

Advantages: language independent, can be computed early in a project, does not have to be predicted

Disadvantages: unnecessarily complex, difficult to compute

Front 91

Function Points Example

Spell Checker Specification

Back 91

accepts as input into a document file, a dictionary file and an optional user dictionary file

the checker lists all words in the document file not contained in either of the dictionary files

user can query the number of words processed and the number of spelling errors found at any stage