4/11/03 – Intro to Software Engineering


Exam scores:

85 +  = A (16 students)

68 + = B (14 students)

< 68 = C (2)


-          What are the critical issues of version management?

-          What are the basic abstractions for a given tool for management?


·         Product Space

·         Version Space


PRODUCT SPACE – the individual components that make up the product

·         The structure of the product without any versioning

·         Typically represented by a graph, where nodes are components, edges are relationships

·         Software objects are of primary interest –

o        They are the result of development or maintenance activity

o        Each object has a unique identifier – OID (external – assigned by user, or internal – generated by system)

o        Objects tend to be coarse grained – typically files, modules, etc

o        Typically have fine-grained inner structure (but not used)

o        May have different representations – text, abstract syntax trees, graphs, etc

§         Influences functionality of the system – as to whether it is knowledgeable about those different types of representations

·         Models of Product Space

o        Domain-dependent – tailored towards understanding specific types (has build facilities built into version management system)

o        Domain-independent – basically no assumptions about specific types (leaner type or product)

·         Relationships of Software Objects

o        Composition – atomic and composite

§         Hierarchy – root = “system”

§         E.g. System is composed of subsystems, composed of modules composed of files

§         System – all of the components reachable from the root (transitive closure)

o        Dependency

§         Life cycle – architecture depends on requirements, design depends on architecture, etc (human effort)

§         Derivation – e.g. compiler (.c files ΰ .o files)

“It’s probably safer in Iraq than on I-35”

“The national bird of Iraq – duck”

“The national 5-day forecast – 2 days”

§         source objects

§         derived objects (manual versus automated derivation)

§         System-building dependencies – ordering – the order in which you derive the source objects

·         Build dependencies

·         Source dependencies

·         Representation of the Product Space

o        Files and extensions (relationships implied by extension)

o        Typed objects + relationships (richer, more formal)

§         Represented as a spanning tree augmented with dependency relationships

§         Having objects with source code relations

·         Logical structure with different internal representations that are used to create various realization


VERSION SPACE – basic idea of versioning is to be able to correctly regenerate a system to guarantee its identity for a particular build of a system. (relative to source code, but also applies to derived code)


** Latex bashing-  “~” is ubiquitous in URLs, but in Latex “~” is a control character… in different versions


·         Defines items to be versioned

o        Common properties shared by all

o        Deltas – differences –

·         Dimensions of Evolution

o        Revisions – sequence of differences

o        Variants – alternatives

·         These dimensions are derived from:

o        State of object

o        Change relationship

·         Versions, Versioned Items, and Deltas

o        Version  = (PS - OID, VS - VID) state/point in Product Space x Version Space

o        Item = anything versioned

o        Sameness criteria – determined by object identifier (OID) and version identifier (VID)

o        Invariants – common/shared properties of all versions

o        Deltas – Differences between two versions

§         Symmetric differences – has to do with set operations  V1σ V2

§         Directed difference – has to do with change operations (add a line, delete, modify)  V1 ΰ V2

§         SCCS – Source Code Control System

·         Start with base version

·         Delta 1 – derives next, Delta 2 – derives next, until you reach current version

§         RCS – Revision Control System (more optimal)

·         Start with current version

·         Delta 1 – undo changes for previous version, Delta 2 – undo again…

§         ClearCase – most often used commercially (Rational)

o        Multi-level Versioning – Hierarchy - Issue:  How do you get the version you want

§         Extension – enumerate them

§         Intension (e.g. all latest Linux versions)

·         Defined by a predicate

·         Implicit spec of the versions

·         Attributes tied to components and versions, primarily variants

§         Evolution – revisions, variants, cooperations

·         Variants that merge back into a version, parallel changes

·         Usually cause more faults to process numerous concurrent changes at once

o        Representation of the Version Space

§         Graphs, grids

§         Version graphs

·         Sequences

·         Trees

·         Acyclic graphs

·         Successor + offspring


Final Exam – Saturday  (3 hours) – same format as midterm, twice as long, same trickiness – all material will be covered…





Fagan:  Code Inspection started out as Peer reviews – 3 steps

1)       Individual analysis – preparation

2)       Team analysis – collection

3)       Repair – repair


Five Factors in Reviewing

1)       Structure – number of steps, number of people

2)       Techniques – How each step is done or carried out

3)       Inputs – Code quality, reviewer ability

4)       Context – Interactions, project schedule, personal calendars

5)       Technology – Tool support


3 Goals

·         minimize interval

·         minimize effort

·         maximize effectiveness

Experiment Variables

-          Team size (4-6)

-          Single-session versus multiple-session inspections

o        N-fold inspections will find more defects

o        Parnas-Weiss ADR (active design reviews) – multiple independent sessions

o        Knight-Myers PI (phased inspections – sequential, each phase with a different focus

-          Group-centered versus individual-centered

o        Widely believed – group-centered is more effective

o        Recent data – meeting gains are offset by meeting losses

-          Defect detection methods – preparation

o        Methods include: techniques, responsibilities, coordination policies etc

o        Techniques – Intuitive (ad hoc) to explicit (highly systematic)

o        Responsibilities – Range from general (find as many as possible) to specific (assigned focus areas)

o        Coordination – could be sorta none (everybody does their own thing) to very coordinated (everyone has distinct responsibilities)

o        Methods

§         Ad hoc – just do it

§         Checklist

§         Scenarios

§         Multiphase – distinct responsibilities – more effective, more costly


Three Hypotheses

·         Large teams have longer inspection intervals, and find no more defects than smaller teams

·         Collection meetings do not significantly increase detection effectiveness

·         Multiple-session inspections are more effective than single, BUT also significantly increase inspection interval


Experiment Model

·         Inspection Interval – based on time, events, and participants

·         Defect Detection Ratio – interesting to calculate, because there is no way to measure exactly how many defects are there versus how many are found

o        Observed detection ratio – (observed/projected – guess) always available, not accurate

o        Partial estimation – capture-recapture:  independent reviewers find bunches of defects, and a count of the common ones yields ratio

o        Complete estimation – can’t determine until project is completed, but is most accurate


Experiment Design

·         Independent (Manipulated) Variables

o        Number of reviewers

o        Number of inspection sessions

o        Coordination between sessions

·         Dependent (Observed) Variables

o        Inspection interval

o        Inspection effort

o        Estimated defect detection ratio

o        % of defects identified at collection meeting

o         % of potential defects that were false positives

·         Threats – data, sample population of subjects, manipulations of independent variables

o        Internal validity

§         Selection effects (limited by random selection)

§         Maturation effects (limited by randomness)

§         Instrumentation effects (limited by uniform data collection system)

o        External validity

§         Experimental scale (limited by conducting on live software project)

§         Subject generalizability (not a concern, worked with software pros)

§         Subject representativeness (not representative of average developers)

·         Data

o        Defect

§         False positives (no repair required) – 25%

§         Soft maintenance (coding standards, bad organization, unmaintainable) – 55%

§         True defects (affected functionality) – 21%

o        Interval

§         Average total = 14.5 days (8.5 pre-meeting + 6 post-meeting)

§         Basically – no effect of team size on interval

§         However, interval of two-session is greater than one-session

o        Effectiveness

§         No difference in effectiveness dependent on team size

§         2 sessions more effective than one, only when there were 2 reviewers (not when there were 4)

§         Reparing defects between meetings had no effect

o        Meetings

§         Prep - 15% of issues identified ahead of time were true defects

§         Suppression – 25% of errors were suppressed

§         Gains - 33% of all defects considered meeting gains, independent of treatment

·         Conclusions

o        Individual Preparation – 50% of issues are false positives, 35% soft maintenance, 15% true defects – we need better techniques

o        Meeting Gains – 33% of defects were meeting gains, 2-session/2-person inspections more effective,

o        Team size – no differences

o        Multiple sessions – 2 session/2 people more effective; 2 session no-repair, same interval as one single session; for ADR/PI,improvement was from technique, not strctural

o        Serialized multiple sessions – no effect




What is INFUSE:  a hierarchical experimental database- Each EDB contains change sets, set of modules to be modified – partitioned into child EDB’s based on inter-relationships


How is this Decomposition done?

o        Management Hierarchy (structure of system reflects structure of organization)

o        Design Organization/Architecture

o        Interdependency – the dependencies between components – the things which depend on a changed object will experience change as well

§         Similarity

-          Basic rule – deposit into parent HEDB only when consistent (Infuse)

-          See diagrams in paper

-          Hmm… I am lost.  How silly.  Systematic way of doing integration testing, running regression test based on dependency hierarchy.


1)       Unit testing

2)       Integration testing

3)       System testing

4)       System soak (load, stress testing)

5)       Alpha testing

6)       Beta testing

7)       Release