Contents

    Dyba03

    1. Tore Dyba
    2. Factors of Software process improvement success in small and large organizations in a Scandinavian context
    3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp148-157
    4. =EMPIRICAL IMPROVEMENT ORGANIZATION SIZE
    5. Small and large can do equally well but must involve people more and explore new knowledge.

    HerbsledMockus03b

    1. James D Herbsled & Audris Mockus
    2. Formulation and Preliminary Test of an empirical theory of coordination in software engineering
    3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp138-147
    4. =THEORY =EMPIRICAL SCIENCE MODULES DECISIONS COORDINATION
    5. Postulates a number of decisions which lead to a feasible or infeasible result.
    6. f(x): {0,1}=feasibility of decisions x.
    7. The feasible choices for a decision are those where there is at least one other set of decisions that make the result feasible.
    8. FC(X i)={x:X(i). for some u:X(1..i-1), v:X(i+1..n) ( f(u!x!v) = 1 )}.
    9. E(X i | X k = x) :=the effect of fixing X k on X i .
    10. ME(X l| X k): =maximal effects of k on i.
    11. Defines clumps of decisions and the Parnas effect as the number of other decisions that have no effect on this clump.
    12. The Conway effect relate clumps associated with team structure.
    13. 7 other assumptions.
    14. Observes the fate Modification Requests (MRs) in a real project.
    15. Productivity goes down with the number of independent sources of MRs.
    16. It takes longer to do an MR that effects many modules.

    GieseEtAl03

    1. Holger Giese & Mathias Tichy & Sven Burmester & Wilhelm Schafer & Stephen Flake
    2. Toward the Compositional Verification of Real-Time UML Designs
    3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp38-47
    4. =THEORY UML Patterns UML/RT statecharts fsm raven RT-OCL Assume/guarantee

    JeffordsHeitmeyer03

    1. Ralph D Jeffords & Constance L Heitmeyer
    2. A Strategy for efficiently verifying requirement specifications using composition and invariants
    3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp28-37
    4. =DEMO TOOLS THEORY SCR LTS SMV SPIN Salsa Assume/guarantee
    5. BCP::="Basic Compositional Proof".
    6. MCP::="Modified Compositional Proof".

    UchitalKramerMagee03b

    1. Sebastian Uchital & Jeff Kramer & Jeff Magee
    2. Behavior Model Elaboration using Partial Labeled Transition Systems
    3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp19-27
    4. =THEORY PELTS OCL ATM
    5. A normal LTS has states, transitions labeled by actions, etc. and if an action is missing on all transitions out of a state then it is presumed to be forbidden in that state. A PLTS lists forbidden actions for each state explicitly, and if an action is neither on a transition or forbidden in a state then it can occur but the next transition is not defined.
    6. Includes rules for the parallel composition of PLTSs

    Jaaksi03

    1. Ari Jaaksi
    2. Assessing Software Projects -- Tools for Business Owners
    3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp15-18
    4. =EXPERIENCE MANAGEMENT USE-CASES ARCHITECTURE TESTS INCREMENTS ERROR STATISTICS
    5. Testing should be stringent enough to start accumulating open errors, but a project is not half complete until the number of open errors stabilizes and decreases.
    6. Management by walking around: face-to-face interviews are vital.
    7. Documents lie!
    8. No project has been seen that successfully developed a complete support system before big-bang implementation of all use-cases.

    Osterweil03

    1. Leon J Osterweil
    2. Understanding Process and the Quest for Deeper Questions in Software engineering Research
    3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp6-14
    4. =HISTORY RESEARCH SOFTWARE PROCESS LANGUAGE MODEL dataflow workflow
    5. Importance of having multiple languages modelling processes.
    6. Many domains require the need of defined processes. software engineering is just one such domain.
    7. Solving technical problems leads to new deeper questions. For example: what is software?
    8. 59 refs.

Formulae and Definitions in Alphabetical Order