[My image] [Text Version] newbib Tue Jun 18 12:43:18 PDT 2013
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

Opening Microsoft files (winzip, word, excel, powerpoint) on this page may require you to download a special viewer. Or you can download and save the files and use your preferred office applications to view and edit them.

Contents


    Bibliography

    1. Richard J Botting
    2. A Bibliography of software development
    3. 1984..2005 [ newbib.html ]
    4. =BIBLIOGRAPHY SOFTWARE DEVELOPMENT
    5. Goal:= To document most useful theories and the most reliable information about current and past practice.
    6. Example: What really happened when IPT was tried at the New York Times? [McNurlin77]
    7. Example: for how long have people been writing about replacing the Software Development Live Cycle? [Gladden82]
    8. New items are described in my Weblog [ blog.mth ] when the citation is posted here.

    Aaen03

    1. Ivan Aaen
    2. Software Process Improvement: Blueprints versus Recipes
    3. IEEE Software Magazine V20n5(Sep/Oct 2003)pp86-93
    4. =ADVOCATES AGILE IMPROVEMENT SPI PEOPLE vs PROCEDURE
    5. Lists the risks of having a separate SPI team working out a blueprint/structure/standards.
    6. Promotes the facilitation of improvisation plus reflection within existing teams

    AalstWeijtersMaruster04

    1. Wil van der Aalst & Ton Weijters & Laura Maruster
    2. Workflow mining: discovering process models from event logs
    3. IEEE Trans Knowledge and Data Engineering V16n9(Nov 2004)pp1128-1142 CR 0512-1362
    4. =THEORY =APPLIED 2 SYSTEM nonsequential PETRI SWF-net workflow-net α-algorithm TOOLS EMiT Little Thumb WORKFLOW
    5. Start with logs of real work-flows.
    6. Gives α-algorithm to convert logs into nets. Work-nets are specialized petri P/T nets with certain structures forbidden.
    7. Tested on system for patients in hospital and had to ignore rare events/activi ties.
    8. Tested on 130,136 cases of fine collection for a justice system.

    AalstWeske05

    1. Wil M van der Aalst & Mathias Weske
    2. Case Handling: A new paradigm for business process support
    3. Data & Knowledge Engineering V53n2(May 2005)pp129-162 CR 0605-0527
    4. =UNREAD =IDEA WORKFLOW DESIGN UML METAMODEL [click here [socket symbol] if you can fill this hole]

    AbadiLamport90

    1. Martin Abadi & Leslie Lamport
    2. Composing Specifications
    3. Digital Sys Res Center(Oct 10 1990) CR9405-0309 F.3.1 [AbadiLamport93]
    4. =MATHEMATICAL SPECIFICATION LOGIC
    5. Has a ref to Cliff Jones's Oxford PhD Thesis in the early 80s! p9: "Composition is conjunction" cf Zave & Jackson.

    AbadiLamport92

    1. Martin Abadi & Leslie Lamport
    2. An Old-fashioned Recipe for Real Time
    3. Digital Sys Res Center TR#91(Oct 12 1992) [AbadiLamport94]
    4. =MATHEMATICAL TIMING LOGIC

    AbadiLamport93

    1. Martin Abadi & Leslie Lamport
    2. Composing Specifications
    3. ACM TOPLAS V15n1(Jan 1993)pp73-132
    4. =MATHEMATICAL SPECIFICATION LOGIC
    5. Reviewed CR9405-0309 F.3.1
    6. similar to AbadiLamport90 Based on Lamport91

    AbadiLamport94

    1. Martin Abadi & Leslie Lamport
    2. An Old-fashioned recipe for Real Time
    3. ACM TOPLAS V16n5(Sep 1994)pp1543-1571 See [AbadiLamport92]
    4. =MATHEMATICAL TIMING LOGIC
    5. Review CR9507-0506 F.3.1: uses TLA as a base
    6. can reason separately about function and timing(by var now:real). Two problems: now can get stuck (Zeno-ness) or two requirements can conflict. ->> detect and correct spec to avoid. (not in A&L 1992?)

    AbadiLamport95

    1. Martin Abadi & Leslie Lamport
    2. Conjoining Specifications
    3. ACM Ttrans Prog Lang Sys V17n3(May 1995)pp507-535 CR9605-0369 CR9608-0610(...cumbersome notation....) F.3.1
    4. =MATHEMATICAL SPECIFICATION LOGIC TLA
    5. conjunction implies parallel combination

    Abbotetal93

    1. Ben Abbott & Ted Bapty & Csaba Biegl & Gabor Karsai & Janos Sztipanovits
    2. Model Based Software Synthesis
    3. IEEE Software Magazine (May 1993) pp42-52
    4. =ADVERT METHOD

    Abbott83

    1. ?? Abbott
    2. Program Design by Informal English Descriptions
    3. Commun ACM Vol 26 No 11(Nov 1983)pp882-894
    4. =IDEA ADTs REALITY THEORY Informal algorithm->model->code
    5. Start with an informal algorithm and extract and object-oriented model.
    6. Leads to Grady Booch's methods but is later critiscized because getting the algorithm is difficult. [Booch83] [Booch86]

    Abdel-Hamid96

    1. Tarek K Abdel-Hamid
    2. The Slippery Path to Productivity Improvement
    3. IEEE Software Magazine VSE13N4(Jul 1996)pp43-54
    4. =SIMULATION TOOLS PEOPLE
    5. simulation rediscovers Brookes's Law. Also raw historical data can trigger a brookes crisis. Work reffered to in [Brooks95]

    Aberdour07

    1. Mark Aberdour
    2. Achieving Quality in Open Source Software
    3. IEEE Software Magazine V24n1(Jan/Feb 2007)pp58-64
    4. =SURVEY OSS RESEARCH OPEN SOURCE TECHNICAL QUALITY PEOPLE ONION
    5. Table 1 compares open and closed source processes.
    6. Page 62: 3 open source maturity models.
    7. Good software engineering complements good people structure.

    Abiteboul00

    1. Serge Abiteboul & Peter Buneman & Dan Suciu
    2. Data on the Web: from relations to semistructured data and XML
    3. Morgan Kaufman SF CA 2000 ISBN 1-55860-622-X CR 0105-0161 QA76.9.D3 A258
    4. =MONOGRAPH DATA NET/WWW LOGIC XML XSL-QL DTD ACeDB OEM Lore Strudel

    AbowdDix93

    1. Gregory D Abowd & Alan J Dix
    2. Integrating status and event phenomena in formal specifictions of interactive systems
    3. SIGSOFT'94 Proc 2nd ACM SIGSOFT Symp on Foundations of Software Engineering & ACM SIGSOFT Software Engineering Notes V19n5(Dec 1994)pp44-52. See [ZaveJackson94]
    4. =MATHEMATICAL HCI/USER SPECIFICATION
        Signature+Events+formulae+ interstitial behavior.

        Nothing that Ross Ashby and JSD didn't know about already

        looks a little like hypertalk, but notation not of the essence.


    Abowdetal93

    1. Gregory D Abowd & Robert Allen & David Garlan
    2. Using Style to Understand Descriptions of Software Architecture
    3. In [Notkin93] pp9-20
    4. =THEORY MATHEMATICAL ARCHITECTURE
    5. Z Pipe-filter and Event System styles
    6. partial functions Syntax<>->Semantics to describe constraints on syntax
        pipe-filter Abstract syntax{ports, descriptions, roles, connections, components, connectors, attachments}

        -ve: some small Z errors -ve: Includes filter's state as part of model of filter. amow: should use IO relations

        Event-System style: invoked, announced, methods, events, states, start,... NOT classes

        Analysis, special cases,....


    Abowdetal95

    1. Gregory D Abowd & Robert Allen & David Garlan
    2. Formalizing Style to Understand Descriptions of Software Architecture
    3. ACM Trans Softw Eng Methodol V4n4(Oct 1995)pp319-365
    4. =THEORY MATHEMATICAL ARCHITECTURE
    5. expanded version of 1994 SIGSOFT paper (or is it : AbowdAllenGarlan93?)

    AbramowitzStegun6465

    1. Milton Abramowitz & Irene Stegun (National Bureau of Standards)
    2. Handbook of Mathematical Functions
    3. NIST hard back edition 1964 & Dover paper back edition NY NY 1965 [ Abramowitz_and_stegun ]
    4. =HANDBOOK MATH FUNCTIONS TABLES FORMULAE
    5. Electronic copies: [ http://people.math.sfu.ca/~cbm/aands/ ] at Simon Fraser University and [ AMS55.asp ] at ConvertIt.com.
    6. Update [OlverEtal10]

    Abramson73

    1. ?? Abramson
    2. Theory & Practice of a Bottom-up Syntax Directed Translator
    3. NY Ac Press 1973
    4. =HOWTO COMPILER DDD REALITY SYSTEM

    AbramsonDahl89

    1. Harvey Abramson & Veronica Dahl
    2. Logic Grammars
    3. Springer Verlag 1989
    4. =HOWTO GRAMMAR DDD PROLOG REALITY

    Abrial89

    1. J Abrial
    2. A Formal Approach to Large Software Construction
    3. In Mathematics of Program construction J L A Van de Snepscheut(ed) Springer NY NY 1989 pp 1-20. See [LafontaneLedruSchobbens91]
    4. =ADVERT LOGIC TOOL Z VDM B
    5. B theorem prover LOGIC TOOL used by Z and VDM groups

    Abrial09

    1. Jean-Raymond Abrial
    2. Faultless Systems: Yes we can
    3. IEEE Computer Magazine V42n9(Sep 2009)pp30-36
    4. =ADVERT FORMAL SYSTEMS REQUIREMENTS B Event-B CORRECTNESS MODEL PROOF SIMULATION REFINEMENT PATTERNS MATHEMATICS TOOL Rodin
    5. assumes waterfall is necessary.
    6. process=requirements; model; code.
    7. requirements are a mixture of informal explanations and form definitions and proofs etc.
    8. Use coupled discrete state transition systems. And animation. Prove invariants.
    9. Need tools to prove thousands of changing propositions.
    10. Validate the problem as a system in an environment not just the software.
    11. Problem with not enough discrete mathematics in education.
    12. Problem with technology transfer.
    13. Link [ http://www.event-b.org ]

    AbrilPlant07

    1. Patricia S Abril & Robert Plant
    2. The patent holder's dilemma: buy, sell, or troll?
    3. Commun ACM V50n1(Jan 2007)pp37-44
    4. =SURVEY PATENTS LEGAL INTELECTUAL PROPERTY
    5. Complex business models involving trading, holding, and combining software patents -- and they don't all work.

    Abualsamid01

    1. Ahmad Abualsamid
    2. PHP & Hosted Applications
    3. Dr. Dobbs #320(Jan 2001)pp56+58+60-63
    4. =ADVERT WWW/NET SERVER SCRIPTING LANGUAGE EXAMPLE
    5. PHP has syntax like UNIX shell.

    Aceto92

    1. Luca Aceto
    2. Action Refinements in Process Algebras
    3. Cambridge University press 1992 ISBN 0-521-43111-5
    4. =THEORY NONSEQUENTIAL MATHEMATICAL ALGEBRA
    5. CR9312-0920(non-sequential for experts; distinguished thesis; poor printing "tractable notion of semantic equivalence of process algebras that do not equate parallelism with sequential nondeterminism and support operators for refining actions.")

    Ackerman03

    1. Jody Ackerman
    2. Uniting with only a few random links
    3. Newswise [ ?id=RANDOM.RPI ]
    4. =ARTICLE NONSEQUENTIAL NET PARALLEL COMPUTATION
    5. Use a small world network to keep processes synchronized with minimal overhead.
    6. Regular communication with a few neighbors + a few connections with random distant processes.
    7. Research by Korniss at Rensslaer (RPI)

    AcunaJuristo04

    1. Silvia T Acuna & Natalia Juristo
    2. Assigning people to roles in software projects Software - Practice & Experience V34n7(Jun 2004)pp675-696 CR Nov2004
    3. =EXPERIMENT PEOPLE PROCESS
    4. Document person-role-capabilities relationship before seeking optimal assignments in a project.
    5. Worked better than a random assignment!
    6. Leads to [AcunaJuristo06]

    AcunaJuristo05

    1. S Acuna S & N Juristo (Eds)
    2. Software process modeling
    3. Springer-Verlag New York, Inc., Secaucus, NJ, 2005. (the kluwer international series in software engineering) CR 0607-0694
    4. =SURVEY =PAPERS PROCESS MODELLING MATHEMATICS PEOPLE UML MANAGEMENT JAD IMPROVEMENT CMM PSPS STIN SPEM
    5. Reccommends focussing process research on the people in the process and the needs of the organization. [AcunaJuristo04] [AcunaJuristo06]

    AcunaJuristoMoreno06

    1. Silvia T Acuna & Natalia Juristo & Ana M Moreno
    2. Emphasizing Human Capabilities in Software development
    3. IEEE Software Magazine V23n2(Mar/Apr 2006)pp94-101
    4. =EXPERIMENT PEOPLE Cattell 16PF ROLLS CF
    5. Matching personality to role seems associated with fewer defects and higher productivity. [AcunaJuristo04].

    ACM86

    1. Editted by Robert L Ashenhurst & Susan Graham
    2. ACM Turing Award Lectures: The First Twenty Years 1966-1985
    3. ACM Press 1987 ( Addison-Wesley)
    4. =HISTORY SURVEY PRIZE winners

    ACMCALGO

    1. Various
    2. The ACM Collected Algorithms
    3. Association for Computing Machinery 1960-
    4. =HANDBOOK TECHNICAL

    Adamatzky10

    1. Anrew Adamatzky (Ed)
    2. Game of Life cellular automats
    3. Springer NY NY (2010) ISBN 1849962162 CR 1108-0789
    4. =PAPERS =HISTORY CA Cellular Automata Conway Game of Life 2D 3D
    5. TBD [click here [socket symbol] Adamatzky10 if you can fill this hole]

    AdamicHuberman01

    1. Lada A Adamic & Bernardo A Huberman
    2. The Web's Hidden Order
    3. Commun ACM V44n9(Sep 2001)pp55-59
    4. =ANALYSIS NET/WEB WWW COMPLEXITY SMALL-WORLD POWER-LAW DYNAMIC MODEL ECONOMICS
    5. power_law(β)::= Net{ for some constant c, frequency = c /(size**β). }.
    6. WWW shows exponential growth.
    7. number of pages per site, number of users, number of outlinks, and number of inlinks all have close to a 1/n**2 distribution.
    8. This can be accounted for by two random growth models. stochastic rate of growth proportional to size. Either starting at different times, or with different growth rates.
    9. Usage is an 80-20 phenomenon.
    10. Implication: any site gets a few visitors each day, few get large numbers...
    11. winner take all markets.
    12. small worlds effect because some sites have lots of links. diameter between sites is about 4 clicks. between pages about18 clicks.

    Adams91

    1. Illustrated by Scott Adams
    2. Build a better life by stealing office supplies: Dogbert's big book of business
    3. Andrews & McMeel, Kansas City, Missouri, 1991, ISBN 0-8362-1757-8
    4. =JOKE PEOPLE MANAGEMENT

    Adams97

    1. Scott Adams
    2. Seven Years of Highly Defective People
    3. Andrews McMeel Publishing, 1997, Kansas City, Missouri, ISBN 0-8362-3668-8
    4. =JOKE PEOPLE cartoons on engineering, life, and mis-management

    Adams96

    1. Tom Adams
    2. Total Variance Approach to Software Reliability Estimation
    3. IEEE Trans on Software Eng VSE-22n9(Sep 1996)pp687-688
    4. =MATHEMATICS QUALITY TEST RELIABILITY
    5. Operational Profiles do not admit that they are uncertain predictions and so reliability is underestimated

    AdamsE84

    1. E Adams
    2. Optimizing preventive service of software products
    3. IBM Research J., V28n1(?? 1984)pp2-14
    4. =EMPIRICAL QUALITY vs RELIABILITY
    5. Quoted by [FentonOhlsson00]

    AdamsJ06

    1. Joel C Adams
    2. OOP and the Janus Principle
    3. ITICSE ACM SIGCSE Bulletin V38n1(Mar 2006)pp359-363
    4. =DEMO TEACHING PEDAGOGY JANUS OBJECT-ORIENTED MODULES MVC DAYTIME JAVA CSCI375
    5. Janus::=following
        Design and write OO applications so that they support multiple, reusable user interfaces with minimal redundant code.

    6. The old Parnas rule:"Separate concerns". [Parnas72b]
    7. Presents a modified MVC with View+Controller in one class plus separate Model class.
    8. Nice example: Program to get and display current time from servers with multiple user interfaces: command line & menu-driven & GUI: [ http://www.calvin.edu/~adams/software/janus/ ]

    AdamsEtAl11

    1. Michael Adams & Arthur H M ter Hofstede & Marcello La Rosa
    2. Open source software for workflow management: the case of YAWL
    3. IEEE Software Magazine V28n3(May/Jun 2011)pp16-19
    4. =ADVERT =HISTORY 2008-2010 OPEN SOURCE WORKFLOW SYSTEM LANGUAGE YAWL JAVA Sourceforge: [ http://sourceforge.net/projects/yawl/ ]

    AdcockEtAl07

    1. Bruce Adcock & Paolo Bucci & Wayne D Heym & Joseph E Hollingsworth & Timothy Long
    2. Which Pointer Errors do Students Make?
    3. ACM SIGCSE Bulletin V39n1(Mar 2007) & proc SIGCSE'07 pp9-13
    4. =ADVERT TOOL C++ Java PEDAGOGY
    5. Proposes finite state models for pointers in C++ and in Java.
    6. Java_pointer_model::=following
      Table
      Old\NewAliveNullOut of scope
      Alive* newNULL}
      NullnewNULL *X}
      Out of scope00declare

      (Close Table)
      (X = unsafe)
    7. C++Pointer_model::=following
      Table
      Old\NewAliveNullOut of scopeDead
      Alive* new ZNULL Z} Zdelete ε
      NullnewNULL *X delete}0
      Out of scope000declare
      DeadnewNULL}* X delete X

      (Close Table)
      (Z=dangerous, X=unsafe, ε=spontaneous)

    Adhikari95a

    1. Richard Adhikari
    2. BringingMethodology to Client/Server Madness
    3. Software Magazine (Mar 1995)pp35-49
    4. =SURVEY METHODS WEB/NET
    5. Fig p40: 13 different methods in use/planned to be used

    Adhikari95b

    1. Richard Adhikara
    2. Code Recycling saves resources
    3. Software magazine (July 1995)pp31-37
    4. =EXPERIENCE TECHNICAL REUSE
    5. 6 experiences of technical (code) reuse technology paying off. Across several platforms & industries: mainly large projects. Some object-oriented but some were not. Example of a simulation have code componentes that were later reused for non-simulation.

    Adler88

    1. Mike Adler
    2. An Algebra for DFD Process decomposition
    3. IEEE trans on Soft Eng vSE-14n2(Feb 1988)pp169-183
    4. =MATH ALGEBRA IO MATRICES DESIGN DFD TECHNICAL

    AdlerR95

    1. Richard M Adler<radler@tiac.net>
    2. Emerging Standards for Component Software
    3. IEEE Computer Magazine V28n3(Mar 1995)pp68-76
    4. =STANDARDS CORBA OMG+ OLE COM+OpenDoc+DCE/RPC+SOM+...

    Adolf96

    1. W Stephen Adolph
    2. Cash Cow in the Tar Pit: Reengineering a Legacy system
    3. IEEE Software Magazine V13N3(May 1996)pp41-47
    4. =EXPERIENCE REENGINEERING RISK SYSTEM 20 year old assembly language for obsolete computers
    5. need to provide tools to aid the reading of the legacy code and capturing key algorithms
    6. 2 weeks training in Hatley/Pirbhai SAD and PC CASE lead to designs that had to be thrown away
    7. key objective: no feature of legacy system to be "improved" unless it reduced the cost of implementing the new system. domain experts must train sosftwrae specialists
    8. need to manage CASE tools.

    Adolph99

    1. Steve Adolph =?= W Stephen Adolph
    2. Whatever Happened to Reuse?
    3. Software Development Magazine V7n11(Nov 1999)pp40-43
    4. =ESSAY REUSE vs salvage COST ECONOMICS short-term needs vs long term value

    Adolph00

    1. Steve Adolph
    2. four-wheel drive, garbage trucks and objects
    3. Software Development Magazine V8n6(Jun 2000)pp52-55
    4. =ESSAY OBJECT-ORIENTED DESIGN MODULE MAINTENANCE REFACTORING
    5. OO + expediency can encourage loss of cohesion and high coupling: blobs, mudballs, or garbage barges
    6. example - add salaried employee to employee

    Adolf00b

    1. Steve Adolph
    2. Getting Out of the Software Mud Pit
    3. Software Development Magazine V8n12(Dec 2000)pp41-44
    4. =HOWTO =HISTORY REFACTOR MAINTENANCE TECHNICAL QUALITY
    5. Big balls of mud are messy but systematic refactoring can help.
    6. refactor::=apply behavior-preserving transformations that improve code quality.
    7. Refers to William Opdyke's 1992 Doctoral thesis "Refactoring Object-oriented Frameworks" U of Illinois at Urbana-Champaign
    8. Example: Fixing Feature Envy. A piece of code in method in class A refers to several class B methods only. Therefore Replace-Code-Segment-With-Function-Call AKA Extract Method(110) and then Move-Member-Function AKA Move Method(142)

    Adve10

    1. Datura Adve
    2. Data races are evil with no exceptions
    3. Commun ACM V53n11(Nov 2010)p84 [ 1839676.189697 ]
    4. =ESSAY NONSEQUENTIAL SHARED MEMORY HAZARDS DETECTION EXCEPTIONS
    5. Punning introduction to [ElmasQadeerTasiran10] and [FlanaganFreund10]

    AgarwalREtal00

    1. Ritu Agarwal & Prabuddha De & Atish P Singh & Mohan Tanniru
    2. On the Usability of OO Representations
    3. Commun ACM V43n10(Oct 2000)pp83-89
    4. =EXPERIMENT FUNCTIONAL vs DATABASED MODELS of new SYSTEM POLL
    5. Easiest to match type of model to the type of task.

    AgarwalLago95

    1. Rakesh Agarwal &Patricia Lago
    2. PATHOS - A Paradigmatic Approach To High-level Object-oriented Software Development
    3. ACM SIGSOFT Software Engineering Notes V20n2(Apr 1995)pp36-41
    4. =ADVERT METHOD OBJECT-ORIENTED
      1. confused
      2. technical activities: find classes, find methods and behavior, define classes and methods
      3. Technical control activities: logical design, detailed design
      4. ...Early consideration of reuse and quality in design

    AgarwalRahaGhosh00

    1. Rakesh Agarwal & Arup Ratan & Raha Bhaskar Ghosh
    2. Our experience and learning in ERP implementation
    3. ACM SIGSOFT Software Engineering notes V25n2(Mar 2000)pp31-34
    4. =EXPERIENCE MRP-II
    5. gap_analysis:=comparing existing software behavior with the client budiness needs.
    6. need tounderstand client's business
    7. use informal discussion to gather data.

    AgarwalSinha03

    1. Ritu Agarwal & Atish P. Sinha
    2. Object-oriented modeling with UML: a study of developers' perceptions
    3. Communications of the ACM V46n9 (Sep 2003)pp 248-256 Virtual extension Retrieved Sep 3rd 2003 from [ 903893.903944 ]
    4. =EXPERIMENT NOVICES UML GRAPHICS use case state charts
    5. p252: "both use case diagrams and state diagrams were perceived as being easier to use than class and interaction diagrams."
    6. p253: "developers with more experience in OO analysis and design techniques perceived class diagrams and interaction diagrams as being easier to use than those with less experience."
    7. p253: "greater experience in process-oriented analysis and design techniques resulted in more positive perceptions of the usability of UML diagrams, overall."
    8. p253-4: use case document real world problems BUT how much detail?, Class diagrams notations are liked but defining operations is difficult. State diagrams are simple and easy but how to identify states?, Interaction diagrams provoke strong +ve and -ve comments. Use cases are the best.

    Agha90

    1. Gul Agha
    2. Concurrent Object-oriented Programming
    3. Commun ACM V33n9(Sep 1990)pp125-141
    4. =DEMO GRAPHIC OBJECT_ORIENTED NONSEQUENTIAL DESIGN
    5. Actor-Event diagrams History dependent

    Aghaetal89

    1. Gul Aghar & Peter Wegner & Akinori Yonezawa(Ed)
    2. Proceedings of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming
    3. SIGPLAN Notes V24n4(Apr 1989)
    4. =PROCEEDINGS DYNAMICS OBJECT-ORIENTED COROUTINES

    Aghaetal93

    1. Gul Agha & Peter Wegner & Akinori Yonezawa(Ed)
    2. Research Directions in Concurrent Object-Oriented Programming
    3. MIT Press Cambridge MA 1993 ISBN 0-262-01139-5 CR9502-0058
    4. =PROCEEDINGS DYNAMICS OBJECT-ORIENTED COROUTINES

    Agosta95

    1. Louis Agosta
    2. Comparative Review(CR9502-0058)
    3. Computing Reviews V36n2(Feb 1995)pp88-93
    4. =HISTORY OBJECT-ORIENTED METHODS Three waves of OO methods:

    Agre95

    1. Philip A Agre
    2. My Top 10 Email Hassles
    3. Commun ACM V38n7(Jul 1995)pp122
    4. =ARTICLES RISKS EMAIL

    AgrestiEvanco92

    1. William W Agresti & William M Avanco
    2. Projecting Software Defects From Analysing Ada Designs
    3. IEEE Trans on Software Eng VSE-18n11(Nov 1992) pp988-997
    4. =EXPERIMENT METRIC
    5. Evidence that "with" coupling is correlated with defect density.

    AhoUllman7273

    1. Aho & Ullman
    2. The Theory of Parsing Translating & Compiling
    3. 2 Vols Prentice Hall International 1972 & 1973
    4. =TEXTBOOK =REFERENCE SURVEY DDD TECHNICAL

    AhujaCarrieroGelernter86

    1. Sudhir Ahuja & Nicholas Carriero & David Gelernter
    2. Lynda and Friends
    3. IEEE Computer Magazine V19n8(Aug 1986)pp26-34
    4. =ADVERT Lynda NONSEQUENTIAL

    AielloEtAl07

    1. Marco Aiello & Ian E Pratt-Hartman & Johan F van Bentham (Eds)
    2. Handbook of spatial Logics
    3. Springer Verlag NY Secaucus NJ 207 ISBN 1402055862 CR 0811-1045
    4. =UNREAD =REFERENCE FORMAL MODAL LOGIC SPACE

    AikenMuntzRichards94

    1. Peter Aiken & Alice Muntz & Russ Richards
    2. DoD Legacy Systems: Reverse Engineering Data Requirements
    3. Comm ACM V37n5(May 1994)pp26-41
    4. =EXPERIENCE REVERSE ENGINEERING DATA
        1.4 billion LOCs at 1.7K locations in thousands of different systems.

        1986..87: Logical Data base Design

        1992: First technologically independent logical data model

      1. LDM has 468 entities and 1994 data elements

        1993: LDM has 362 entities and 1318 data elements


    AikenAllenParkerMattia07

    1. Peter Aiken & M David Allen & Burt Parker & Angela Mattia
    2. Measuring Data Managment Practice Maturity: A Community's Self-Assessment
    3. IEEE Computer Magazine V40n4(Apr 2007)pp42-50
    4. =MODEL +POLL DATA PROCESS MATURITY IMPROVEMENT CMMI
    5. Proposes a CMMI-like measure of the maturity of data managment.
    6. 6 process areas: data program coordination, organizational data integration, data stewardship, data development, data support operations, and data asset use.
    7. The usual 5 levels: 1=initial, 2=repeatable, 3=defined, 4=managed, 5=optimizing.
    8. Questionaire with 20+ questions used intelephone interviews 2000-2005 with 107 companies.
    9. Results: most process areas are at the repeatable level.

    AichernigKainhofer04

    1. Bernhard K. Aichernig & Reinhold Kainhofer Comments: Presented at LfM2000, published in the proceedings In C.Michael Holloway, editor, Lfm2000, Fifth NASA Langley Formal Methods Workshop, Williamsburg, Virginia, June 2000, number CP-2000-210100, pages 35-46. NA SA, June 2000
    2. =DEMO VALIDATION VDM-SL Mathematica Hybrid SAFER graphic animation
    3. Computer algebra systems can express VDM specifications and extend them to handle continuous(analog) components and behavior.

    AissiMaluSrinivasan02

    1. Selim Aissi & Pallavi Malu & Krishnamerthy Srinivasan
    2. E-Business Process Modeling:The Next Big step
    3. IEEE Computer Magazine V35n5(May 2002)pp55-62
    4. =DEMO WEB/NET STANDARD WEB SERVICES XML
    5. PCF::="Process Coordination Framework", groups standards for e-business.
    6. PCF = security & ( service description and transaction binding end point description, public collaborative, private process; contracts and agreements).
    7. WSDL::="Web service description Language". [ wsdl ] provides information needed to use a service over the web.
    8. WSCL::="web services Conversation Language", [ http://www.w3.org/TR/wscl10/ ] defines conversations between service providers.
    9. ebXML::= See http://www.ebxml.org/specs/ebBPSS.doc, UN and OASIS choreographs collaborations/transactions.
    10. CPP::= See http://www.ebxml.org/specs/ebCPP.doc, Collaboration Protocol Profile.
    11. WSFL::= See http:://www4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf, Web services Flow Language.
    12. XLANG::http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm, describes executable internal business processes.
    13. BPML::= See http://ww.bpmi.org/bpml.esp, describes internal business processes using transactional finite state machines.

    Akera07

    1. Atsushi Akera
    2. Edmund Berkeley and the Origins of ACM
    3. Commun ACM V50n5(May 2007)pp31-35
    4. =HISTORY 1940s ANALYSIS Study Contract
    5. Need to sell managment on the use of computers to do paper-work. "Methods Analysis".

    AlagarVenkatesan01

    1. Sridhar Alagar & Subbarayan Venkatesan
    2. Techniques to Tackle state explosion in a Global Predicate Detection
    3. IEEE Trans Software Engineering V27n8(Aug 2001)pp704-714
    4. =THEORY LOGIC MODEL CHECKING

    AlanenPorres03

    1. Marcus Alanen & Ivan Porres
    2. Difference and Union of Models
    3. LNCS 2863 <<UML>> 2003 -- The Unified Modeling Language, Oct 2003, pp2-17
    4. =ALGORITHMS on MODEL VERSIONS UML MOF CMS
    5. If + is merge and - is difference then union of M1 and M2 based on M0 is M0+(M1-M0)+(M2-M0)

    Alavi86

    1. Maryam Alavi
    2. An Assessment of the Prototyping Approach to Information Systems Development
    3. Comm ACM V27n6(Jun 1986)pp556-563
    4. =EXPERIMENT PROTOTYPING REQUIREMENTS TOOLS
    5. concludes PROTOTYPING needs expertise support TOOLS and control but handles unclear and ambiguous REQUIREMENTS

    AlaviWetherbe91

    1. Maryam Alavi & James C Wetherbe
    2. Mixing Prototyping and Data Modeling for Information-System Design
    3. IEEE Software V8n3 (May 1991)p86-91.
    4. =ADVERT DATA PROTOTYPING

    Albizuri-Romero00

    1. Miren Begona Albizuri-Romero
    2. A retrospective view of CASE tools adoption
    3. ACM SIGSOFT Software Engineering notes V25n2(Mar 2000)pp46-51
    4. =SURVEY pre1990 papers on STRUCTURED TOOLS

    AlencarCowanLucenaNova95

    1. Paulo S C Alencar & Donald D Cowan & Carlos J P Lucena & L C M Nova
    2. Formal specification of Reusable Interface Objects [SamadzadehZand95] pp88-96
    3. =DEMO ADV/ADO ADTs REUSE

    Albrecht04

    1. Conan C Albrecht
    2. How Clean is the future of SOAP
    3. Commun ACM V47n2(Feb 2004)pp66-68
    4. =THEORY SOAP TCP port 80 HTTP XML SECURITY vs CONVENIENCE
    5. SOAP::protocol="Simple Object Access Protocol", uses port 80 and HTTP to access objects + XML to encode operation and response.
    6. content type: text/xml-SOAP.
    7. Web server passes SOAP to routing engine and response back to caller.
    8. Currently not filtered. Security problems would change this.

    AlencarCowanLucena02

    1. Paulo S C Alencar & Donald D Cowan & Carlos J P Lucena
    2. A Logical Theory of Interfaces and Objects
    3. IEEE Trans Software Engineering V28n6(Jun 2002)pp548-575
    4. =THEORY FORMAL LOGIC CATEGORY OBJECTS INTERFACES ADV ADO
    5. ADV::= "Abstract Design Views", interfaces.
    6. ADO::= "Abstract Design Objects".
    7. views_a::@(ADV, ADO).
    8. cf [AlencarCowanLucenaNova95]

    Alexander79

    1. Chistopher Alexander
    2. A Pattern Language
    3. Oxford U Press UK 1979
    4. =THEORY ARCHITECTURE Buildings, towns, regions.

    Alexander00

    1. Christopher Alexander
    2. The Nature of Order
    3. Book to be published in 2000
    4. =THEORY
    5. living structures generated smoothly by structure preserving unfoldings.
    6. normal 20C construction can not do this!

    Alexander92

    1. Tom Alexander
    2. How to Stop Fearing and Start Loving the Parallel Computer
    3. NSF MOSAIC V23n1(spring 1992)pp2-11
    4. =ARTICLE NONSEQUENTIAL TECHNICAL

    AlexanderCoplien99

    1. Christopher Alexander & James O Coplien(introduction)
    2. The Origins of Pattern Theory
    3. IEEE Software Magazine V16n5(Sep/Oct 1999)pp71-82
    4. =SPEECH OOPSLA'96 PATTERN THEORY
    5. patterns were generative( ala Chomski ), included a moral component, must lead to morphological coherence - a life promoting structure, a good environment
    6. 15 geometric properties underlying original patterns -> profundity
    7. 80..90%agreement for "Do you feel more whole/alive in the presence of this or that object?". Correlates with certain features/structures & profound functionallity!
    8. centers:=field-like structures recursively underlying all wholeness& more or less living things. See [Alexander00]
    9. Can/will software designers help people generate a life enhancing world?

    AlexanderH88

    1. Heather Alexander
    2. Comments on "Formal Specification of User Interfaces: A comparison and Evaluation of Four Axiomatic Approaches"
    3. IEEE Trans Soft Eng VSE-14n4(Apr 1988)pp438-439
    4. =DEMO need SQA on Z SPECIFICATIONs as well as code

    AlexanderH03

    1. Ian Alexander
    2. Misuse Cases: Use Cases with Hostile Intent
    3. IEEE Software Magazine V20n1(Jan/Feb 2003)pp58-66
    4. =IDEA NEGATIVE USECASES SCENARIO PURPOSES QUALITIES ANTI-STORIES
    5. Need to promote use-cases while stopping misuse cases.
    6. Normal relations: includes, has exception.
    7. New relations: misuse threatens use, use mitigates misuse.

    Alexander11

    1. Ian Alexander
    2. GORE, SORE, or what
    3. IEEE Software Magazine V27n6(Jan/Feb 2011)pp8-10
    4. =COMPARISON REQUIREMENTS METHODS GOALS GORE i* KAOS STAKEHOLDER SORE SCENARIO SCORE USE CASES PRIORITY PORE COST-BENEFIT TRIAGE CONTEXT EVENT CORE
    5. Informal use of a single approach over-simplifies situations.
    6. Example: a scenario does not expose all threats that must be mitigated.
    7. Analyzing goals (i*, KAOS) can expose unconscious intentions and assumptions and so threats and so mitigations.
    8. Context models show what enters and leaves the system. So uncovering the events that must be handled.
    9. Table 1 compares approaches.
    10. Need to compare models from a many approaches that fit the particular situation.

    AlexanderKong01

    1. Perry Alexander & Cindy Kong
    2. Rosetta: Semantic Support for Model-Centered Systems-Level design
    3. IEEE Computer Magazine V34n11(Nov 2001)pp64-70
    4. =DEMO TOOL ROSETTA MODEL SYSTEM PROPERTIES Category outputs Matlab TESTS
    5. Sidebar on p69 describes rivals: Adept, DEVS, Ptolemy, aspects, viewpoints, HyTech, SAL Kestrel, SpecWare
    6. Able to define, compose, project and explore the interactions of models of different types.
    7. facet := a special model within a domain of models. Facets are combined vertically(all true at one time) and horizontally )interacting components).
    8. domains: continuous and discrete times, finite and infinite state systems and tests, .... mechanical, hydraulic, power constraints

    AlexanderRobertson04

    1. Ian Alexander & Suzanne Robertson
    2. Understanding Project Sociology by Modeling Stakeholders.
    3. IEEE Software Magazine V21n1(Jan/Feb 2004)pp23-27
    4. =IDEA REQUIREMENTS ANALYSIS STAKEHOLDERS Onion Model
    5. Fig 3 p26: Large matrix of stakeholder types vs classes of knowledge.
    6. Distinguishes 3 layers f stake holders centering on our product/the kit.
    7. Many systems the role of users is split between the normal operator close to the product, and the functional beneficiary.
    8. Onion.layers:=(our_product, our_system, containing_system, wider_environment).
    9. our_system:={ normal_operator, maintenance_operator, ...}.
    10. containing_system:={ functional_beneficiary, purchaser, interfacing_system,...}.
    11. wider_environment:={political_beneficiary, financial_beneficiary, negative_stakeholder, regulator, developer, ...}

    AlexanderRBiemanViega00

    1. Roger T Alexander & James M Bieman & John Viega
    2. Coping with Java Programming Stress
    3. IEEE Computer Magazine V33n4(Apr 2000)pp30-38
    4. =DEMO JAVA TECHNICAL traps
    5. default/protected access easily broken
    6. subclasses can steal methods called in superclass constructors
    7. containers+no templates means ineffective type checking
    8. extend only for subclassin/is-a
    9. finalizers wai for garbage collection and may never happen
    10. no const methods or assertions so document very carefully
    11. avoid confusing (unlabelled) instance initialization blocks.

    Alhir98

    1. Sinan Si Alhir
    2. UML in a Nutshell
    3. O'Reilly, Cambridge, Mass, 1998 ISBN 1-56592-448-7
    4. =REFERENCE to UML1.1 (OMG UML1.0) CR9908-0596
    5. Comprehensive and with very few errors! Reference not readable.
    6. Errata and comments on the UML on the WWW [ ~salhir ]

    AllenA94

    1. Arnold O Allen
    2. Introduction to Computer Performance Analysis with Mathematica
    3. CS&SciComp Acad Press 1994 ISBN 0-12-051070-7 Review p492 AMM May 1994
    4. =TEXTBOOK with disk TECHNIQUE->QUALITY

    AllenB94

    1. Bradley P Allen
    2. Case-Based Reasoning: Business Applications
    3. Comm ACM V37n3(Mar 1994)(AI issue)pp40-44
    4. =ARTICLE AI

    AllenCD95

    1. C Dennis Allen
    2. Succeeding as a Clandestine Change Agent
    3. Commun ACM V38n5(May 1995)pp81-86
    4. =HISTORY USER PEOPLE SYSTEMS
    5. The Water Torture Method
    6. p82: "I discovered that automating a manual process can break the customer's work practice."

    Allman90

    1. Eric Allman
    2. By the pricking of my thumbs(article)
    3. UNIX Review V9n2(Feb 1991)pp66-69.
    4. =HISTORY C FORTRAN LANGUAGES
    5. History of FORTRAN and C

    Allman12

    1. Eric Allman
    2. Managing Technical Debt
    3. Commun ACM V55n5(May 2012)pp50-55 CR 1211-1150 [ 2160718.2160733 ]
    4. =SURVEY CODE TECHNICAL CHOICES ITERATION
    5. Technical debt happens when you don't do it the best possible way.
    6. It nearly always has to be paid off but typically by some one else.
    7. The interest on the debt comes from working round or with the less than best system.
    8. 4 way trade off: quality, time, resources, & debt.

    Alonzo03

    1. Omar Alonzo
    2. Generating Text Search Applications for DataBases
    3. IEEE Software Magazine V20n3(May/Jun 2003)pp98-105
    4. =DEMO DOMAIN XML GENERATE Java Web/Net SQL TEXT SEARCH Oracle DARE-Web YASEC
    5. XSLT less useful than DOM and SAX.

    AlfaroHenzinger01

    1. Luca de Alfaro & Thomas A Henzinger
    2. Interface Automata
    3. ACM SIGSOFT proc ESEC-8 FSE-9 Software Engineering Notes V26n5(Sep 2001)pp109-120
    4. =THEORY SPECIFICATION MODULE FSM/AUTOMATA INTERFACE NONSEQUENTIAL

    AlijazzarLeue10

    1. Husain Alijazzar & Stefan Leue
    2. Directed Explicit state-space search in the generation of Counter examples for Stochastic Model Checking
    3. IEEE Trans Software Engineering V36n1(Jan/Feb 2010)pp37-60
    4. =DEMO MODEL CHECKING PROBABILITY PCTL CSL PRISM MARKOV CHAINS
    5. Given a model as a Markov chain and a property, finds paths that are probable but don't match the property.
    6. Can handle both discrete and continuous Markov chains.

    AlmeidaJrEtal03

    1. Jorge Rady de Almeida Jr & Joao Batista Camargo Jr & Bruno Abrantes Basseto & Sergio Miranda Paz
    2. Best Practices in Code Inspections for Safety-Critical Software
    3. IEEE Software Magazine V20n3(May/Jun 2003)pp56-63
    4. =EXPERIENCE RISKS QUALITIES SQA CODE INSPECTION
    5. Developed a useful checklist of defect types to find unsafe code.
    6. For example: Check that a constant has the same value in different modules even when in different languages!

    Almendros-JimenezIribarne10

    1. Jesus M Almendros-Jimenez & Luis Iribarne
    2. Describing Use-Case Relationships with Sequence Diagrams
    3. Computer Journal V50n1(Jan 2007)pp116-128 [ bxl053 ]
    4. =DEMO UML SEQUENCE USECASE
    5. Shows that use case relations (includes, extends, generalizes) are not clearly defined or well understood.
    6. Shows ways of deducing them from sequence diagrams of the scenarios in the use case.

    AlmeringEtAl07

    1. Vincent Almering & Michiel van Genuchten & Ger Cloudt & Peter J M Sonnemans
    2. Using Software Reliability Growth Models in Practice
    3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp82-88
    4. =EXPERIENCE 5 MODELS TVs
    5. The models got better as more data was fitted.
    6. λ(t) :=failure intensity function.
    7. (GO): λ(t) =a*b*exp(-b*t).
    8. (delayed S): λ(t) =a*b^2*t*exp(-b*t).
    9. (log power): λ(t) = α*β*ln^(b-1)(1+t)/(1+t).
    10. (log Poisson): λ(t) = λ[0] / (λ[0] * θ * t + 1).

    Alsaadi04

    1. Ahmad Alsaadi
    2. A Performance analysis approach based on the UML Class diagram
    3. WOSP'04 & ACM SIGSOFT Software Engineering Notes V29n1(Jan 2004)pp254-260
    4. =EXAMPLe PERFORMANCE NORMALIZATION UML
    5. Can get speed by denormalizing physical data.
    6. Very like SSADM physical design control.

    AlshayebLi03

    1. Mohammad Alshayeb & Wei Li
    2. An Empirical Validation of Object-Oriented Metrics in Two Different Iterative Software Processes
    3. IEEE Trans Software Engineering V29n11(Nov 2003)pp1043-1049
    4. =EMPIRICAL Object-Oriented METRICS AGILE XP client-server stories vs JDK 1.[0-4] EVOLUTION PROCESSES JAVA EDITS
    5. metrics={WMC, DIT, LCOM, NLM, CTA, CTM}.
    6. analyses short-cycle vs long-cycle.
    7. The metrics with multi-linear regression predict the amount of change (and effort) well in the later cycles of an XP process.
    8. Not so useful in the JDK long-cycle evolution.
    9. |-" prediction is impossible at the beginning of the " [XP] " process because there is very little substantive design structure in the system".
    10. Idea: critical mass of classes needed to define metrics that predict XP effort.

    AltendorfHohmanZabicki02

    1. Eric Altendorf & Moses Hohman & Roman Zabicki
    2. Using J2EE on a large, Web-Based Project
    3. IEEE Software Magazine V19n2(Mar/Apr 2002)pp81-89
    4. =EXPERIENCE WEB/NET MODULE COMPONENT JAVA J2EE

    AlurDill94

    1. R Alur & D L Dill
    2. A Theory of Timed Automata
    3. Theoretical Computer Science V126 pp183-235 1994
    4. =THEORY AUTOMATA TIMING

    AlurEtessamiYannakakis03

    1. Rajeev Alur & Kousha Etessami & Mihallis Yannakakis
    2. Inference of Massage Sequence Charts
    3. IEEE Trans Software Engineering V29n7(Jul 2003)pp623-633
    4. =THEORY MESSAGE SEQUENCE CHARTS MSC AUTOMATA FSM non-SEQUENTIAL
    5. When do a set of MSCs describe a possible system with no surprising behaviors allowed?
    6. MSC define partial orders on sequences of messages.
    7. Realize as a set of parallel communicating FSM automata.
    8. Communication between automata is not FIFO (data flow) but via Bags.
    9. To get tractable algorithms must not consider sets of automata that can deadlock.

    Aluretal93

    1. R Alur & C Courcoubetis & D L Dill
    2. Model checking in dense real time
    3. Information and Computation V104 pp2-34(1993)
    4. =DEMO TIMING MODEL

    AlvarezDiazLlopisPimentalTroya04

    1. J M Alvarez & M Diaz & L Llopis & E Pimental & J M Troya
    2. An Object-Oriented methodology for embedded real-time systems
    3. Computer Journal V46n2( 2003)pp121-145
    4. =EXAMPLE Object-Oriented TIMING RMA SDL UML OOM-ERT

    AmblerBurnett89

    1. Alan L Ambler & Margaret M Burnett
    2. Influence of Visual Technology on the Evolution of Language Environments
    3. IEEE Computer v22 n10 (Oct 1989)pp9-22
    4. =HISTORY GRAPHIC LANGUAGE

    Ambleretal92

    1. Alan L Ambler & Margaret M Burnett & Betsy A Zimmerman
    2. Operational Versus Definitional: A Perspective on Programming Paradigms
    3. IEEE Computer v25n9(Sep 1992)pp28-43
    4. =DEFINITION TECHNICAL LANGUAGES

    AmblerS95

    1. Scott Ambler
    2. Reduce Development Costs with Use-Case Scenario Testing
    3. Software Development Magazine(Jul 1995)pp 53-61
    4. =DEMO USE-CASE SCENARIO TEST

    AmblerS95a

    1. Scott Ambler
    2. Mapping Objects to Relational Databases
    3. Software Development Magazine(Oct 1995)pp63+64+67+68+70+72+letter(Jan 1996)p13
    4. =DEMO DATA ERDs OBJECT-ORIENTED
    5. reply to letter "why no OODBMS": (1) security (2)no track record (3) no efficient support for SQL/reporting tools (3) one thing at a time

    AmblerS96

    1. Scott Ambler
    2. An Ounce of Prevention: Class Type Architectures
    3. Software Development Magazine(Mar 1996)pp 40??45-61
    4. =DEMO WWW/NET ARCHITECTURE OBJECTs DATA MVC PERSISTENCE TECHNICAL SYSTEM INFORMATION HIDING
    5. Compare with UML Boundary vs Control vs Entity
        N2 chart of "Sends message to"
        Table
        UserX000
        XInterface 10rare
        000BusinessOOCRUDsome
        0000Persistenceoften
        02222System

        (Close Table)
      1. 0. No connection
      2. 1. restricted flow
      3. 2. Feedback: callbacks, dispatched objects
      4. OOCRUD=OO create read update delete.

        system & persistence: wrap well defined technical features, so mostly code and debug

        Business: analysis, understand first

        Interface: prototyping... coding trivial


    AmblerS96a

    1. Scott Ambler
    2. Object-Relational Mapping
    3. Software Development Magazine V4n10(Oct 1996)pp47-50
    4. =DEMO DATA OBJECT-ORIENTED
    5. wrap db; encapsulate;classes drive data; obj IDs as keys only; joins of keys only; arbitrary obj keys; use a data dictionary; do not map to a legacy data base(unless it is in 3NF)

    AmblerS97a

    1. Scott Ambler
    2. Normalizing Classes
    3. Software Development V5n4(Apr 1997)pp69-72
    4. =DEMO DATA OBJECT-ORIENTED
    5. increasing cohesion and coupling by redesign but result is not in even 1NF in Codd terms.
    6. Adds a repeating group of enrollments to seminar.
    7. Better: Seminar<-<Enrollment>->Student and new Enrollment(seminar student) handles enrollments responsibillities for connecting seminars and students.
    8. Note: ends up with SSADM composite logical design!

    AmblerS97b

    1. Scott Ambler
    2. Implementing Pick Lists of Object
    3. Software Development Magazine V5n6(Jun 1997)pp73-76
    4. =DEMO USER DATA Flyweight?
    5. ways to handle stable identified/enumerated objects without involving overheads of persistent storage. Example: The days of the week and the states in the USA. Class stores data on all instances and is different for each subclass.

    AmblerS97c

    1. Scott Ambler
    2. The State Diagram
    3. Software Development Magazine V5n5(May 1997)pp83-88
    4. =DEMO STD/FSM GRAPHIC
    5. accidentally illustrates RISKS of STDs by showing STD that allows an overdrawn account to become nonoverdrawn when a query is made and vice versa. Also requires a single deposit to finish overdrawn status.

    AmblerS97d

    1. Scott Ambler
    2. The Various Uses for Use Cases
    3. Software Development magazine V5n11(Nov 1997)pp69-71
    4. SCENARIOS glossary(p70) <<uses>> <extends>>

    AmblerS98

    1. Scott Ambler
    2. Evolving Class Diagrams
    3. Software Development Magazine V6n5(May 1998)pp69-72
    4. =DEMO LIFECYCLE OOA/OOD UML
    5. need three linked class diagrams (1) behavior and names of business objects; (2) normalized data and design patterns; (3)implementation using Gang-of-four patterns

    AmblerS99

    1. Scott Ambler
    2. Engineering Object-Oriented Requirements
    3. Software Development Magazines V7n3(Mar 1999)pp55-56+58
    4. =SURVEY of MODELs
    5. CRC+User Interface+Use-Case+Business Rules+Activity+Deployment+Supplementary
    6. Also: Interface-Flow++Physical Data+Sequence+Collaboration+State Chart+Technical

    AmblerS99b

    1. Scott Ambler
    2. Architecting for Change
    3. Software Development Magazine V7n5(May 1999)pp56-58
    4. =DEMO DOCUMENTATION UML EVOLUTION
    5. defines the <<Change Case>> stereotype to describe new potential requirements and modifications to existing requirements.

    AmblerS99c

    1. Scott Ambler
    2. Distributed Object Design
    3. Software Development Magazine V7n6(Jun 1999)pp34-36+38-40
    4. =DEMO DOCUMENTATION UML WEB/NET
    5. 9_steps::=(add_non_business_classes; contracts; simplify; collobating_clusters; contracts; simplify_interfaces; map_onto_physical)

    AmblerS99d

    1. Scott Ambler
    2. Persistence Modeling in the UML
    3. Software Development Magazine V7n8(Aug 1999)pp54-57
    4. =ADVERT proposal for DOCUMENTATION UML profile DATA MODEL
    5. stereotypes include table, entity, view, primary index, secondary index, candidate key, oid, trigger
    6. Why doesn't he use Qualifiers to indicate keys and indexes?

    AmblerS99e

    1. Scott W Ambler
    2. Enterprise-Ready Object IDs
    3. Software Development Magazine V7n12(Dec1999)pp56-57
    4. =IDEA PERFORMANCE OBJECT-ORIENTED DISTRIBUTED TECHNICAL
    5. HIGH-LOW Strategy: server allocates contiguous groups of IDs to processes that create persistent objects by sending high-order bits to processes while process assign low-order bits.

    6. Letter: V8n2(Feb 2000)p12 from Jeff Senn corrects misunderstanding caused by Ambler looking at non-compliant code. Standard UUID (MS GUID) works at least as well.

    AmblerS99f

    1. Scott W Ambler
    2. More process patterns: delivering large-scale systems using object technology
    3. Cambridge U Press NY NY 1999 ISBN 0-521-65262-6
    4. =HANDBOOK UML RUP PROCESS PATTERNS

    AmblerS00

    1. Scott W Ambler
    2. new year's resolutions
    3. Software Development Magazine V7n1 (Jan 2000)pp50-51
    4. =ESSAY ETHICS
    5. no harm, reuse, requirements, model, justifiable, no mantras, multiple views, more than performance, respect&work with users, realistic plans, communication skills, habitual learning, test everything, document everything, more to software than tech..

    AmblerS00b

    1. Scott W Ambler
    2. Reuse Patterns and Antipatterns
    3. Software Development V8n2(Feb 2000)pp26-27
    4. =SURVEY tabulates and evaluates various EXPERIENCE REUSE PROCESS PATTERNS

    AmblerS00c

    1. Scott W Ambler
    2. Crossing the Object-Data Divide: Parts 1 and 2
    3. Software Development Magazine V8n3(Nov/Dec 2000)pp69-70 and V8n4(Apr 2000)pp66-69
    4. =ESSAY PEOPLE OBJECT vs DATA

    Ambler00d

    1. Scott W Amber
    2. The Unified Process Elaboration Phase
    3. R&D Books 2000
    4. =TEXTBOOK RUP

    Ambler00e

    1. Scott W Amber
    2. Requirements Engineering Patterns
    3. Software Development Magazine V8n5(May 2000)pp58-60
    4. =ADVERT [Ambler00d]
    5. Requirements first, Requirements as a stick, Requirements as a shield.

    Ambler00f

    1. Scott W Ambler
    2. Enterprise JavaBean Persistence 101
    3. Software Development Magazine V8n8(Aug 2000)pp51-52+54
    4. =ADVERT TECHNICAL JAVA DATA PATTERN EJB
    5. see [Pour00] [Larman00]
    6. primary key is an object (with id and methods etc not just data) that identifies complete object.

    Ambler00g

    1. Scott Ambler
    2. XML in the real world
    3. Software Development Magazine V8n9(Sep 2000)pp59-60+62
    4. =IDEA XML XSL SOAP SEMANTICS
    5. Lack of semantics will be a problem. Needs experience and process to design DTDs.

    Ambler00h

    1. Scott Ambler
    2. Enterprise Java-Bean Persistence 201
    3. Software Development Magazine V8n9(Oct 2000)pp53-55
    4. =TUTORIAL EJB 2.0 OBJECTS DATA

    Ambler00i

    1. Scott W Ambler
    2. Extreme Modeling
    3. Software Development Magazine V8n11(Nov 2000)pp61-62+64
    4. =IDEA MODEL artefacts
    5. p64. sidebar of XP resorces.

    Ambler00j

    1. Scott W Ambler
    2. Reuse Through Internal Open Source
    3. Software Development Magazine V8n12(Dec 2000)pp57+59
    4. =ADVERT Osage =HOWTO
    5. Resources [ http://www.opensource.org ] [ http://www.collab.net ] [ http://sourceforge.net ]
    6. Osage::= See http://osage.opensource.org.
    7. Internal open source focus on encouraging programmers to simply cooperate on producing high quality shared modules with minimal process but careful over-sight.

    Ambler01a

    1. scott W Ambler
    2. Object Concurrency Control 101
    3. Software Development Magazine V9n1(Jan 2001)pp57-58
    4. =TUTORIAL SIMPLE NONSEQUENTIAL OBJECT DATA
    5. None | optimistic | pessimistic.
    6. pessimstic locks data. optimistic marks it to find out if another process has updated the data. collison resolution.

    Ambler01b

    1. Scott W Ambler
    2. Designing Web-Based User Interfaces
    3. Software Development Magazine V9n3(Mar 2001)pp61-63
    4. =HOWTO WWW/NET USER COLOR LAYOUT HTML FORM
    5. "Functional not flashy!"
    6. Indicate what must be done, and what is optional on a form.

    Ambler01c

    1. Scott W Ambler
    2. Debunking Modeling Myths
    3. Software Development Magazine V9n8(Aug 2001)pp51-53 + letters V9n9(Sep 2001)p12
    4. =ESSAY MODELING
    5. Models are not documentation.
    6. You can't think everything thru first.
    7. Modeling can be light/agile
    8. You don't have to freeze requirements.
    9. Designs don't have to be cast in stone.
    10. You don't need a CASE tool. Simple low tech do most models.
    11. Modeling can improve productivity.
    12. Models don't all revolve around data.
    13. It takes time to learn how to model.

    Ambler01d

    1. Scott W Ambler
    2. The Secret Life of Systems Operations
    3. Software Development Magazine V9n10(Oct 2001)pp49-51
    4. =REMINDER SYSTEM ADMIN

    Ambler02

    1. Scott Ambler
    2. Easy Does it
    3. Software Development Magazine V10n3(Mar 2002)pp53-55
    4. =EXPERIENCE MODEL AGILE
    5. Use the simplest tool.
    6. Example: Develop on white board; take a digital snapshot, pass through image improving software through to OCR!
    7. Whiteboard_Photo::gadget= See http://www.pixid.com.

    Ambler02b

    1. Scott W Ambler
    2. Tools and Evidence
    3. Software Development Magazine V10n5(May 2002)pp65-66
    4. =IDEA AGILE MODEL CODE DOCUMENTATION LIFECYCLE UML
    5. Need to rapidly record ideas. and some ideas need to be preserved.
    6. Has a class diagram: source code contains comments that are a type of documentation. source code is modeled by models. Some models are in documents. Documents are a type of documentation.
    7. Has a state chart showing the transitions between Ideas(I), temporary models(T), and permanent models(P) : Start--->I--abandon->end, I--model-->T--keep->P--discard->end, T--update->T, P--update->P, P--version->P, T--discard->end, P--make temporary->T.

    Ambler02c

    1. Scott W Ambler
    2. Lessons in Agility from Internet-Based development
    3. IEEE Software Magazine V19n2(Mar/Apr 2002)pp66-73
    4. =EXPERIENCE AGILE MODEL WEB/NET PROCESS UML RUP HTML PEOPLE
    5. Comparison of two companies. Finding the right amount of documentation and the right kind of model for a particular situation.
    6. Tabulates principles and where they fitted experience. Lessons
      1. People matter.
      2. You don't need as much documentation as you think.
      3. Communication is critical.
      4. Modeling tools are not as useful as you think.
      5. You need a wide variety of intellectual models.
      6. Big up-front design was not needed.
      7. Reuse the wheel. Don't reinvent it.

    Ambler02d

    1. Scott W Ambler
    2. The Fragile Manifesto
    3. Software Development Magazine V10n8(Aug 2002)pp50-51
    4. =JOKE AGILE PROCESSES PEOPLE DOCUMENTATION USER TEAM
    5. Ironic and twisted summary of [Ambler02c]

    Ambler03

    1. Scott W Ambler
    2. Ten Steps to a Robust DB
    3. Software Development Magazine V11n2(Feb 2003)pp42-43
    4. =EXAMPLE DATA ERD EVOLUTION REFACTORING UML
    5. Process:=verify need; choose best; data cleansing; write unit tests; deprecate old schema; implement change; update DBMS scripts; run tests; document; version control.
    6. See list of ways to refactor a data base (like Replace Column,...) [ catalog.html ]
    7. Example of UML documentation of changes({removal date=...} and <<trigger>>s

    Ambler03b

    1. Scott W Ambler
    2. Agility 2013
    3. Software Development Magazine V11n4(Apr 2003)pp46-47
    4. =FORECAST AGILE XP CRAFT SKETCHES VISUAL IDEs COBOL

    AmblerS04

    1. Scott W Ambler
    2. Agile Database Techniques: Effective Strategies for the Agile Software Developer
    3. John Wiley & Sons 2004 ISBN 0-471-20283-5
    4. =UNREAD AGILE DATA
    5. Basis on the web at [ http://www.agiledata.org/ ]
    6. (dick)|-how long does it take to add a new data item to an entity in a large existing database?

    AmblerS04a

    1. Scott W Ambler
    2. Are Your Models Normal?
    3. Software Development Magazine, Agile Modelling Newsletter (Dec 2004)
    4. =IDEA DOCUMENTATION MODEL NORMALIZATION DRY
    5. "record information as few times as possible, ideally only once."
    6. artifact:="any item created during a software development project including code, model, document, plan, etc".
    7. artifact_normalization::="placing information about systems in the best single artifact".
    8. Generate views. Cross reference, links, and inclusions.
    9. DITA::="Darwin Information Typing Architecture", XML based technical documentation, Parallel to single_sourced technical documentation, normalized data bases, and coherent modularization.
    10. (dick)|-"Are there cross cutting concerns? Compare with Aspect oriented programming".
    11. (dick)|- (meta-data): "Documentation is data about a system and should be treated as data".
    12. Compare with POLL [LethbridgeSingerForward03]

    Ambler03

    1. Scott Ambler
    2. Agile database techniques: effective strategies for the agile software developer
    3. John Wiley NY NY 2003 ISBN 0471202835 CR 0502-0163
    4. =HOWTO AGILE DATA REFACTOR NORMALIZE Object-Oriented
    5. From [Amblers04] and [Amblers03]

    Ambler05

    1. Scott W Ambler
    2. The Elements of UML2.0 Style
    3. Cambridge UP 2005
    4. =ADVERT UML AGILE STYLE
    5. Nice book but Not always standard and sometimes apposed by standard

    Ambler07

    1. Scott Ambler
    2. Calculating Documentation Cruft
    3. Dr. Dobb's Agile Newsletter (27 Jul 2007)
    4. =IDEA DOCUMENTATION METRIC CRUFT
    5. CRUFT::percent= 100 - C * R * U * F * T where
      • C:=The percentage of the document that is correct,
      • R:=The chance that the document will read by the intended audience,
      • U:=The percentage of the document that will be understood,
      • F:=The chance that the material contained in the document will be followed,
      • T:=The chance that the document will be trusted.

    6. (dick)|-perhaps we could use Shannon Communication Theory to measure the capacity, equivocation, etc of a document in bits?

    AmbriolaNotkin88

    1. V ambriola & D Notkin
    2. Reasoning About Interactive Systems
    3. IEEE Trans Softw Eng SE-V14n2(Feb 1988)pp272-276
    4. =THEORY LOGIC PROOF formal non-sequential

    AmericaRutten91

    1. P H M America & J J M M Rutten
    2. A Parallel Object-Oriented Language: Design and Semantic Foundations
    3. CWI(Centrum voor Wiskunde en Informatica) Tract V81 Centre for mathematics & computer science Amsterdam the Netherlands(Stichting Mathematisch Centrum) 1991
    4. ISBN 90-6196-402-4 CR9310-0751 QA3.A583 no.81
    5. =ADVERT LANGUAGE POOL
    6. cf Frits W Vaandrager in [Baetan90]

    Amsterdam02

    1. Jonathon Amsterdam
    2. Java's new Considered Harmful
    3. Dr. Dobbs #335(Apr 2002)pp19-20+22+24+26
    4. =PATTERNS creational JAVA factory methods and objects

    AnandalingamLucas05

    1. G Anandalingam & Henry C Lucas Jr
    2. The Winners Curse in High Tech
    3. IEEE Computer Magazine V38n3(Mar 2005)pp96-97
    4. =ADVERT BOOK HISTORY TECHNOLOGY ECONOMICS
    5. Companies often bid too much for a technology and get burned.
    6. Advertyises OUP 2004 book "Beware the Winner's Curse: Victories that can sink you and your company".

    Ananthaswamy11

    1. Anil Ananthaswamy
    2. I, algorithm
    3. New Scientist V209n2797 (Jan 29 2011)pp28-31
    4. =ADVERT =HISTORY AI LOGIC NEURAL NETS MARKOV BAYES PROBABILISTIC PROGRAMMING INFERENCE ENGINE LEARNING LANGUAGES BLOG Church
    5. BLOG::language="Bayesian logic".
    6. Demos of models with thousands of variables.
    7. General algorithms are inefficient.
    8. Applications: test ban treaty, PhysiScore(babies), QMR-DT
    9. Ref [Pearl88]

    AndasSjoberg05

    1. Bente Anda & Dag I Sjoberg
    2. Investigating the role of use cases in the construction of class diagrams
    3. Empirical Software Engineering V10n3(Jul 2005)pp285-309 CR 0807-0688
    4. =EXPERIMENT HOWTO DESIGN CLASS DIAGRAM USE CASE DOMAIN MODEL UML TOOLS Rose Tau
    5. Experimented with students and then with professionals.
    6. Compares two methods for going from usecases to design class diagrams: derivations vs validation.
    7. derivation:= use_case_text->domain_model; sequence_diagrams; design_class_diagram.
    8. validation:= use_case_text-> initial_class_diagram; sequence_diagrams; do( validate; extend).
    9. Measured time, completeness, and quality (coupling and cohesion).
    10. Tools didn't add to diagram quality with either students or professionals.
    11. Tools slowed down students but not professionals.
    12. Students got more complete design classes using validation rather than derivation.
    13. Students got better quality designs with the derivation method.
    14. Professionals -- no significant differences found.

    AndaSjobergMockus09

    1. Bente C D Anda & Dag I K Sjoberg & Audris Mockus
    2. variability and reproducibility in software engineering: a study of four companies that developed the same system
    3. IEEE Trans Software Engineering V35n3(May/Jun 2009)pp407-429
    4. =EXPERIMENT COMPARISON QUALITIES OUTSOURCED USER CODE MAINTENANCE RELIABILITY COST ESTIMATES TIME PROCESS
    5. Sent out call for bids -- 34 responses, 4 selected -- to develop a web application in Scandinavia. Prices range from 2k Euros to 70k Euros!
    6. Many variables, no trustworthy hypotheses to test. Exploration.
    7. Concluded that only the usability was similar between 4 competing projects. The reliability, time to produce, size, and maintainability all varied between companies. There was evidence of a trade off between price and quality.

    Anderson94

    1. Bruce Anderson<bruce@essex.ac.uk>
    2. OOPSLA'93 Workshop Report Patterns: Building Blocks for Object-Oriented Architectures(27th sept 1993)
    3. ACM SIGSOFT Software Eng Notes V19n1(Jan 1994)pp47-49 [Alexander79]
    4. =DEMO PATTERN Ticked Objects [Anderson94] [Johnson94] [Lea94]

    Anderson95

    1. Bruce Anderson<bruce@essex.ac.uk>
    2. OOPSLA'94 Workshop Report Patterns: Building Organisational Competence in Software Architecture

    Anderson99

    1. Ross J Anderson
    2. The Formal Verification of a Payment System
    3. In [HincheyBowen99] pp43-52
    4. =EXPERIENCE LOGIC BAN VERIFYING PROTOCOL BANKING PAYMENT SMARTCARD
    5. Used BAN_logic with new rule:
    6. If A believes that A and B share key K and A sees the K encrypts X then A will believe that B used K.
    7. Colored proof covering several white boards.
    8. System successful for several years with problems.
    9. Concludes the it better to have a simple logic with few rules and no tool than a complex (buggy?) logic with a tool.

    AndersonFleekGarityDrake01

    1. Jean Anderson & Francis Fleek & Kathi Garity & Fred Drake
    2. Integrating Usability Techniques into Software Development
    3. IEEE Software Magazine V18n1(Jan/Feb 2000)pp46-53
    4. =EXPERIENCE SIEMENS HEALTH USER PEOPLE RUP workflow iteration
    5. Early user improves quality and eliminates rework.
    6. Organizational and cultural change is the important challenge. [ConstantineLockwood99]

    Andersonetal96

    1. Richard J Anderson & Paul Beame & Steve Burns & William Chaan & Francesmary Modugno & David Notkin & Jon D Reese
    2. Model Checking Large Software Specifications
    3. Proc 4th ACM SIGSOFT 1996 Symp on the Foundns of Software Eng: ACM SIGSEN V21n6(Nov 1996)pp156-166
    4. =DEMO V&V SPECIFICATIONS TOOL use Binary Decision Diagrams(BDDs) 200Mgbs!

    AndersonGouda91

    1. James H Anderson & Mohamed G Gouda
    2. A new explanation of the glitch phenomena
    3. Acta Informatica V28f4(Apr 1991)pp287-310
    4. =THEORY NONSEQUENTIAL all arbiters have both infinite delays and multiple changes in the values of outputs.

    AndersonHansenLowrySummers06

    1. Bonnie Brinton Anderson & James V Hansen & Paul Benjamin Lowry & Scott L Summers
    2. The application of model checking for secure E-commerce transactions
    3. Commun ACM V49n6(Jun 2006)pp97-101
    4. =EXAMPLE V&V ECOMMERCE PROTOCOLS MODEL CHECKING RISKS
    5. Given the complexity of ECommerce systems and protocols plus the risks of failure, the protocols should be checked prior to implementation.

    AndersonRepsTeitelbaum03

    1. Paul Anderson & Thomas Reps & Tim Teitelbaum
    2. Design and implementation of a fine-grained software inspection tool
    3. IEEE Trans Software Engineering V29n8(Aug 2003)pp721-733
    4. =ADVERT V&V CODE INSPECTION C TOOL CodeSurfer(TM) TECHNICAL SLICES CHOPS HYPERTEXT VIEWS

    AndersonShapiro89

    1. RH Anderson & NZ Shapiro
    2. Beyond User Friendly: Easy To...
    3. EDUCOM Review v24 n3(Fall 1989) p50-54
    4. =ESSAY USER

    AnderssonGreenspunGrumet06

    1. Eve Andersson & Philip Greenspun & Andrew Grumet
    2. Software Engineering for Internet Applications
    3. MIT Press Cambridge MA 2006 ISBN 0262511916 CR 0712-1164

    AnderssonRuneson07

    1. Carina Andersson & Per Runeson
    2. A replicated quantitative analysis of Fault distributions is complex software systems
    3. IEEE Trans Software Engineering V33n5(May 2007)pp273-286
    4. =EXPERIENCES ANALYSIS SIZE MODULES RELIABILITY
    5. Repeats [FentonOhlsson00].
    6. Few modules contain most faults - pre & post release.
    7. Fault densities are similar in similar environments.

    Andexer01

    1. Jens Andexer
    2. Design Guidelines and Documentation Paradigms for Object Oriented Programs
    3. SERG Report 397 (Sep 2001)P422,, McMasters [ serg.publications.html ]
    4. =SURVEY EVOLUTION OBJECT_ORIENTED

    AndleighGretzinger92

    1. Prabhat K Andleigh & Michael R Gretzinger
    2. Distributed Object-oriented Data-systems Design
    3. Prentice Hall Englewood Cliffs NJ 1992 ISBN 0-13-174913-7 CR9309-0658
    4. =SURVEY METHODS OBEJCT-ORIENTED DATA DESIGN
    5. Review: Frame-object analysis combines features of earlier systems analysis methods with the newer object-oriented concepts. survey 5 well known (but not Coad)...

    Andreetal81

    1. Andre & Banatre & Routeau
    2. A Multi-processing Approach to Compile-Time Symbol Resolution
    3. ACM TOPLAS v3n1(Jan 1981)pp11-23
    4. =DEMO DDD Clash

    Andrews93

    1. James H Andrews
    2. Logic Programming: Operational Semantics & Proof Theory
    3. Cambridge University Press NY NY 1993 ISBN 0-521-43219-7 CR9503-0142
    4. =THEORY LANGUAGES

    AndrewsP03

    1. Pater B Andrews
    2. Introduction to Mathematical Logic and Type Theory: to truth through proof
    3. Kluwer Acad Pub Norwell MA 2002 ISBN 1402007639 CR 0305-0427
    4. =THEORY LOGIC TYPES LAMBDA PEANO

    AndrewsLeventhal93

    1. Dorine C Andrews & Namoi S Leventhal
    2. FUSION: Integrating IE, CASE and JAD: a handbook for reengineering the systems organisation
    3. Prentice Hall Englewood Cliffs NJ 1993 ISBN 0-13-325333-3 CR9308-0568
    4. =HANDBOOK CASE USER

    AndrewsZhang03

    1. James Andrews & Yinqjun Zhang
    2. General Test Result Checking with Log File Analysis
    3. IEEE Trans Software Engineering V29n7(Jul 2003)pp634-648
    4. =EXPERIMENT RANDOM TESTING LOG TIMED FSM LFA lift language LFAL Prolog dictionary ADT
    5. SUT::="Software Under Test".
    6. LFA::="Log file analysis"..

    Andriole94

    1. Steve Andriole
    2. Fast Cheap Requirements: Prototype or Else
    3. IEEE Software magazine v11n2(Mar 1994)pp85-87
    4. =ADVERT PROTOTYPE REQUIREMENTs

    Andriole95

    1. Stephen J Andriole(CIGNA)
    2. Debatable Developent: What should we believe?
    3. IEEE Software Magazine V12n4(Jun 1995)pp13-18
    4. =ESSAY THEORY vs PRACTICE METHODS
    5. p13: "There is an enormous disconnection between what academicians and consultants think will revolutionize development and what actually works in the trenches. We have much to learn about what really works
    6. what works a little
    7. and what does not work at all." [AndrioleMonsanto95]

    AndrioleMonsanto95

    1. Stephen J Andriole(<andriole@cigna.e-mail.com> & Charlton A Monsanto<mnsanca@duvm.ocs.drexel.edu>
    2. Interactive Collaborative Requirements Management
    3. Software Development(Sep 1995)pp35-40
    4. =DEMO Do-It-Yourself TOOL REQUIREMENTS VISUALBASIC
    5. Requirements: Its easier and cheaper to use a set of simple tools and templates (flowcharters databases ... prototypers) under the control of a Visual Basic workbench than even Integrated CASE tools

    Anguela09

    1. Andrew Anguelo
    2. Software Methodology Wars (Viewpoint)
    3. IEEE Computer Society Career Watch Mailing list (Mar 2009) [ vp4 ]
    4. =ESSAY PROCESS METHODS DEVELOPMENT vs ENGINEERING ONE-SIZE ECONOMICS SHORT-TERM vs LONG_TERM
    5. Quote
      Net
        Development is based on iterations of trial and error in the absence of knowledge and facts. It most often found in organizations that don't value their software technology as a critical business asset and treat it as a necessary evil or a cost of doing business. Business executives in these types of organizations operate very much like those during the dot-com boom days. Itbis based on iterations of trial and error in the absence of knowledge and facts. It no surprise that today's more popular development methodologies are based on principles that shun documentation, engineering thought patterns, and encourage the use of loosely conceived ideas in production environments under the guise of flexibility.

        [...]

        Engineering methodologies are much more methodical than development methodologies. Consideration of past, present, and future, as well as adherence to standards and practices are all core principles of software engineering. Although not perfect, these methodologies facilitate the design of systems with intent and that embody the characteristics of reliability, maintainability, and scalability. Such results come at a price however.


      (End of Net)


    6. (dick)|-Ignores the claim that refactoring software can maintain the quality of software.

    AniRedmiles09

    1. Ban Al-Ani & David Redmiles
    2. Trust in distributed teams: support through continuous coordination
    3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp35-40
    4. =SURVEY TEAMS TRUST =ADVERT Palantir Ariadne World View Workspace Activity Viewer
    5. Finds that leadership and time promote trust but diversity, size, and project type have a negative effect.
    6. Argues that tools that make other peoples work visible to the team should promote trust.

    Anon(HOS)84

    1. Product brochure
    2. Building Systems with USE.IT
    3. Higher Order Software Inc. 1984 (2067 Massuchusetts Ave Cambridges MA 02140)
    4. =ADVERT TOOL METHOD

    Anon90

    1. Anonymous but verified letter
    2. IEEE Software Magazine V7n1(Mar 1990)p4
    3. =LETTER whistleblowing engineering RISKS

    Anon10

    1. Anonymous Reporter
    2. No Catastrophes Please, It's Software Modelling
    3. ICT Results (01/28/10) [ index.cfm?section=news&tpl=article&ID=91135 ]
    4. =ADVERT TRT MDE TOOL MODEPLEX MODEL Driven Engineering
    5. Thales Research and Technology (TRT) researchers have created a development platform that enables applications to tackle the increasing complexity of modern computer systems.
    6. MDE::=Model driven engineering.
    7. lifecycle of development, including interoperability, substitutability, and traceability.
    8. required functions related to the industry-specific domain.
    9. design refers to real-world functions rather than algorithms...

    ANSI/IEEE87

    1. IEEE Computer Society
    2. ANSI/IEEE Software Engineering Standards
    3. IEEE/John Wiley 1987
    4. =STANDARD lifecycle Technical

    ANSI/IEEE90

    1. IEEE Computer Society
    2. IEEE Standard Glossary of Software Engineering Engineering Terminology(ANSI/IEEE Std. 610.12-1990)
    3. IEEE Piscataway NJ
    4. =STANDARD GLOSSARY
    5. software_engineering::="The application of systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software."

    ANSI83ADA

    1. ANSI
    2. American National Standard for the programming language ADA
    3. Washington DC Jan/Feb 1983
    4. =STANDARD Ada LRM LANGUAGE

    Anthes11

    1. Gary Anthes
    2. Nonlinear systems made easier
    3. Commun ACM V54n1(Jan 2011)pp17-19 [ 1866739.1866745 ]
    4. =ADVERT MATHEMATICS PROOFS NONLINEAR SYSTEMS CONVEXITY SEMIDEFINITE SUM-OF-SQUARES SOS Schor
    5. Pablo Parrilo's method bounds nonlinear systems.
    6. Used by Intel to prove design of floating point hardware.
    7. Refs on page 19.
    8. PariloSturmfels 2001 [ 0103170 ] Better method for finding minimal values/lower bounds for polynomial functions.

    AntonPotts03

    1. Annie I Anton & Colin Potts
    2. Functional Paleontology: The evolution of User-Visible System services
    3. IEEE Trans Software Engineering V29n2(Feb 2003)pp151-166
    4. =EMPIRICAL HISTORY PURPOSE QUALITY REALITY EVOLUTION 50-years domestic telephones
    5. Lehman's theory of E-systems that co-evolve with there environment implies that understanding environment change should proceed architectural design.
    6. Systems vs services. Systems provide both benefits and burdens. A dialectic process.
    7. Functional_Morphology::=profile of benefits and burdens at a given point.
    8. Analyzed 1950-1999 adverts in Atlanta Telephone directories.
    9. Evidence of punctuated evolution, expansion followed by retrenchment, growth from core outward, caller benefits first, object-level precedes meta-level.

    AntoniolCanforaCasazzaLuciaMerlo02

    1. Giuliano Antoniol & Gerardo Canfora & Gerardo Casazza & Andrea De Lucia & Ettore Merlo
    2. Recovering Traceability Links between Code and Documentation
    3. IEEE Trans Software Engineering V28n10(Oct 2002)pp970-983
    4. =CASESTUDY IR PROBABILITY VECTOR-SPACE TRACEABILITY LIFE-CYCLE
    5. 2 methods: one uses Bayes and frequencies. the other a vector space with distance/similarity formula/metric.
    6. Both are better than grep. Both can achieve 100% recall of all relevant.
    7. Probability based figures help teams trace code back to documentation.
    8. Probability gets better when 100% recall is needed.. Vector calculations are easier.

    AntoniolEtal04

    1. Giulano Antoniol & Aniello Cimitile & Guisepe A Di Lucca & Massimliano Di Penta
    2. Assessing Staffing Needs for a Software Maintenance Project through Queuing simulation
    3. IEEE Trans Software Engineering V30n1(Jan 2004)pp43-58
    4. =EXPERIENCE PROCESS ESTIMATION QUEUES SIMULATION EVOLUTION PEOPLE COBOL/JCL Y2K QUEUEING THEORY
    5. Assumed that Brooks law did not hold for Y2K. Future: conversion to euro, new euro-phone numbers.
    6. QUEUE:Stochastic_System=Net{ interarrival, service:Distribution, number_of_servers:Nat=1, capacity:Nat=oo, discipline:Discipline=FIFO}.
    7. Distribution:={Markovian, Deterministic, Erlang[k], General}.
    8. Erlang[1]:=exponential.
    9. Case study used QUEUE(M,G,m) model.
    10. Lessons earned: simulating queuing models helped predict staffing needs and do what-ifs for team size and rework rates.
    11. But need daily figures (not weekly!).
    12. Not steady state: start up and close down phase are 30%of whole.
    13. Queuing simulation tends to overestimate needs and so minimizes risk of over run.

    AntoniolGueheneuc06

    1. Giuliano Antoniol & Yann-Gael Gueheneuc
    2. Feature Identification: an epidemiological metaphor
    3. IEEE Trans Software Engineering V32n9(Sep 2006)pp625-641
    4. =DEMO MAINTENANCE TECHNICALREVERSE ENGINEERING TOOL CODE MODULE ANALYSIS
    5. A way to find out, by executing software the parts used to implement a feature.

    Antoniou99

    1. Grigoris Antoniou
    2. A Tutorial on Default Logics
    3. ACM ACM Computing Surveys V31n4(Dec 1999) pp337-359 CR0006-0401
    4. =TUTORIAL FORMAL LOGIC DEFAULT INFERENCE EXCEPTIONS
    5. default :=if Prereq : Justifications then Consequent, if Prereq then Consequent unless Justifications is known to be false where no free variables in parts.
    6. default schema has free variables - stands for all substitutions.
    7. normal: if P : J then J
    8. closed world : if true : not A then not A
    9. Not just inferences but also extensions of sets known facts by applying defaults that don't lead to contradictions

    AntoyGannon94

    1. Sergio Antoy & John Gannon
    2. Using Term Rewriting to Verify Software
    3. IEEE Trans on Software Eng VSE-20n4(Apr 1994)pp259-274
    4. =THEORY MATHEMATICAL PROOF PROGRAM
        Power Functions
        1. as a tool in annotating and proving programs
        2. assumes that statements compute functions on states
        3. pf is the powerfunction of statement iff pf(k,s)= ([statement]^k) (s)
        4. R:condition, w:=while(b)(f),
        5. wp(w,R)(s) = for some k:0.. (
          1. R(pf(k,s))
          2. and k= μ i:0..(not b(pf(i,s)))
          )

        representation as a kind of morphism.
      1. p263: Ada - lack of means to annotate and verify semantic properties of elements in a package. Uaing the idea of a monoid of program functions.
      2. p264: Specifying a C++ class by relationships between its operations member functions) and showing their completeness.
      3. p265: Definition of subtyping (cf Liskov) includes annotated properties... but no representation function. TermRewritingSystems, Confluence Church-Rosser. Termination/Noetherian. Both gives cannonical or convergent or complete TRS. (see Wechler 1992) Ask specifiers to specs as a cannonical TRS.
      4. hence overspecification(superposition algorithm Leavens 1991)and underspecification(another algorithm...)
      5. pp266..267:Cannot compute confluence and termination. Hence strategies for ensuring them.
      6. pp267..: Proving theorems: difficult, neeed tool to help.
      7. p271 problems with module interconnections...


    AntoyHamlet00

    1. Sergio Antoy & Dick Hamlet
    2. Automatically checking an implementation against its Formal Specification
    3. IEEE Trans Software Eng V26n1(Jan 2000)pp55-69
    4. =DEMO THEORY TEST SQA EXPERIMENT JAVA

    AntoyHanus10

    1. Sergio Antoy & Michael Hanus
    2. Functional Logic Programming
    3. Commun ACM V53n4(Apr 2010)pp74- 95 [ 1721654.1721675 ]
    4. =ADVERT CURRY LANGUAGE FUNCTIONAL LOGIC PROGRAMMING
    5. Combines ideas from functional programming (LISP, ML, Haskell) and Logic Programming (Prolog).
    6. Given a definition of a function Curry can sometimes invert it, finding argument values to fit given results.

    AnvikMurphy11

    1. John Anvik & Gail C Murphy
    2. Reducing the effort of bug report triage: recommenders for development-oriented decisions
    3. ACM TOSEM Trans Software Eng & Methodology V20n3(Aug 2011)#10.1-35 [ 2000791.2000794 ] CR 12-3-0286
    4. =TYPE BUGS ISSUES TRIAGE AI RECOMMENDERS BUGZILLA BUG TRACKING BUG REPOSITORY ISSUE TRACKING
    5. Interesting statistics.
    6. Regular expressions modeling triage scenarios/life histories.
    7. AI tuned on open source projects. Shows a 75% accuracy.

    Aoyama93

    1. Mikio Aoyama (Fujitsu)<mikio@miki.nakahara.fujitsu.co.jp>
    2. Concurrent-Development Process Model
    3. IEEE Software Magazine (May 1993)pp48-55
    4. =EXPERIENCE management maturity non-sequential YAC(Aoyamaetal89) becomes YPL
      1. To reduce development cycle (time for a release).
      2. 10^6 lines of code 3 months/cycle.
      3. Higher risks and so more careful management
      4. helps expose problems in process
      5. Requires at least a repeatable process maturity.
      6. p50: "For the large-scale communication project, therefore, we described the entire development process up to the details of the invidual developer's task, and analysed them. We then restructured a conventional process model to support concurrent development and developped a process-management system"
      7. p50:"traditional models focus on a single sequence of [...]; concurrent[...] focusses on the concurrent execution of multiple processes"
      8. Uncovering interactions between parallel requirements+designs by intensive review and inspection + management focus on decoupling requirements
      9. Interactions between implementations use configuration management. + integration focussed testing
      10. Special team from teams: define process, manage products, co-ordinate, develop management technique, plan, specify, and develop software-engineering environments and coordinate with research.

    Aoyamaetal89

    1. Mikio Aoyama & K Miyamoto & N Murakama & H Nagano & Y Oki
    2. Design Specification in Japan: Tree Structured Charts
    3. IEEE Software Magazine v6n2(Mar 1989)pp31-37
    4. =ADVERT graphic YAC

    ApelLeachSaake08

    1. Sven Apel & Thomas Leach & Gunter Saake
    2. Aspectual Feature Modules
    3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp162-180
    4. =DEMO FEATURES FOP + ASPECTS AOP ITERATION PRODUCT LINES AFM
    5. AFM::="Aspectual Feature Module", combines iterative Feature Oriented Programming (FOP) with Aspect Oriented Programming(AOP).

    AppelbeAbowd95

    1. Bill Appelbe <bill@cc.gatech.edu> & Gregory Abowd<abowd@cc.gatech.edu>
    2. Beyond Objects: A Response
    3. ACM SIGSOFT Software Engineering Notes V20n3(Jul 1995)pp
    4. =ESSAY
        Shows that Booch86 is no longer a Booch OOD and so is not a valid base for rejecting OO methods for process control systems (as claimed by Mary Shaw Jan 1995 SEN)

        Claims experience shows that process control loops need to be replaced by OO designs(SEI Teh report CMU/SEI-93-TR-14 Aug 1993)


    Apt88

    1. Krzysztof R Apt
    2. Proving Correctness of Concurrent Programs: A Quick Introduction
    3. Chapter 7 (pp305-345) of Borger88
    4. =THEORY NONSEQUENTIAL CORRECTNESS PROOF

    Aptetal80

    1. Krzysztof R Apt & Francez & De Roever
    2. A Proof System for Communicating Sequential Processes
    3. ACM TOPLAS V2n3(Jul 1980)pp359-385
    4. =THEORY LOGIC CSP formal

    ApvrilleEtal04

    1. Ludovic Apvrille & Jean-PIere Courtat & Christophe Lohr & Pierre de Saqui-Sannes
    2. TURTLE: A Real-Time UML Profile Supported by a Formal Validation Tool
    3. IEEE Trans Software Engineering V30n7(Jul 2004)pp473-487
    4. =TYPE REALTIME MODEL V&V UML1.5 PROFILE TCLASSES TTOOL RT-LOTOS RTL
    5. Notes

    Arango95

    1. Guillermo Arango(arango@austin.sar.slb.com)
    2. Software reusability and the Internet [SamadzadehZand95] pp22-23
        The internet could make a big difference - it changes what are the relevant problems in Sw reuse. Scale (worwide) gives new laws and issues. what you need is available somewhere! (but can you trust it)

        People help in the retrieval via newsgroups. "self appointed intelligent librarians".

        Products and services.

        informations borkers/librarians on the net.

        Willl need to keep a software technology watch over assets standards services trends.

        NEED: standards and Processes... like the news eg.


    Arangoetal86

    1. Guillermo Arango & Ira Baxter & Peter Freeman & Christopher Pidgeon(all at UCI)
    2. TMM: Software Maintenance by Transformation
    3. IEEE Software Magazine V3n3(May 1986)pp27-39
    4. =ADVERT for Draco based: make abstraction before porting using domain specific thingies

    Aranow89

    1. Eric Aranow
    2. Full Lifecycle CASE: Views from the Tower of Babel
    3. System Builder (Oct/Nov 1989)
    4. =REPORT CASE tools process
    5. Pictures of three different life cycles: "waterfall", "Rapid Iterative Prototyping", "Iterative redefinition and redesign".
    6. Does not describe the idea of implementing part of the system first to refine and elicit requirements.

    Aranow92

    1. Eric Aranow
    2. Object Technology Means Object-Oriented Thinking
    3. Software Magazine (Mar 1992)
    4. The baggage of the structured techniques - concentrate on the up-front analysis to get our class hierarchies properly defined

    ArbaughFithenMcHugh00

    1. William A Arbaugh & William L Fithen & John McHugh
    2. Windows of Vulnerability: A Case study Analysis
    3. IEEE Computer Magazine V33n12(Dec 2000)pp52-5
    4. =ANALYSIS CERT Exploits IMAP phf BIND 1996-1999
    5. Three buffer-overflow magnitude and one miss-out mistake.
    6. Automating a vulnerability (not disclosing it) allows many more intrusions.
    7. Systems are not being managed well: Nearly all intrusions could have been halted if known precautions installed.

    Arbib64

    1. Michael Arbib
    2. Brains Machines & Mathematics
    3. USA McGraw Hill 1964
    4. =TEXT cybernetics theory FSM Finite State Machines neural networks information theory Turing Machines Regular expressions

    Arbib68

    1. Michael A. Arbib (ed) & K Krohn & J L. Rhodes
    2. Algebraic Theory of Machines Languages & Semigroups
    3. Academic Press New York 1968
    4. =TEXT topology

    ArblasterSimeGreen

    1. ?? Arblaster & ?? Sime && ?? Green
    2. Jumping to Some Purpose
    3. Comp Jnl v22 n2 (May 1979) pp105-109
    4. =EXPERIEMNT sequential Technical

    ArdagnaPernici07

    1. Danilo Ardagna & Barbara Pernici
    2. Adaptive Service Composition in Flexible Processes
    3. IEEE Trans Software Engineering V33n6(Jun 2007)pp369-384
    4. =EXPERIMENT ANNOTATED MODEL SERVICE QUALITIES PERFORMANCE OPTIMIZATION QoS MAIS BPEL UML XML MILP
    5. Given a process that has many steps and includes loops and branches, and each elementary step can be carried out by several rival "concrete" services.... what is the optimum selection of services to complete task?
    6. Given the same process that is partly complete.... what is the optimum way to complete the process.
    7. If the optimal solution is not good enough... how to negotiate a better one.
    8. MAIS::="MultiChannel Information Systems" project, [ http://www.mais-project.it ]
    9. MILP::model="Mixed Integer Linear Programming".
    10. Qualities = { Price, Reputation, Execution_time, availability, data_quality}.
    11. Experiments suggest the algorithms work and are feasible.
    12. See [ArdagnaEtAl11]

    ArdagnaEtAl11

    1. Danilo Ardagna & Luciano Baresi & Sara Comai & Barbara Pernici & Marco Comuzzi
    2. A service-based framework for flexible business processes
    3. IEEE Software Magazine V27n6(Mar/Apr 2011)pp61-67
    4. =ADVERT LANGUAGE TOOL SERVICE ORIENTED QUALITIES WEB/NET BUSINESS PROCESS BPMN CASE UDDI QoS Discorso
    5. ALso see [ArdagnaPernici07]

    Ardisetal96

    1. Mark A Ardis & John A Chaves & Lalita Jategaonker Jagadeesan & Peter Mataga & Carlos Puchol & Mark G StasKauskas & James Von Olnhausen
    2. A Framework for Evaluating Specification Methods for Reactive Systems: Experience Report
    3. IEEE Trans Softw Eng VSE22N6(Jun 1996)pp378-389 revised from ICSE-17 1995
    4. =COMPARISON Modechart VFSM Esterel LOTOS Z SDL C telecommunications; SDL and Esterel scored well
    5. methods uncovered dangerous ambiguity in an informally stated standard

    ArdisMataga99

    1. Mark Ardis & Pete Mataga
    2. Formal Methods Through Domain engineering
    3. In [HincheyBowen99] pp315-328
    4. =EXPERIENCE FAST PROCESS DOMAIN technology transfer 5ESS Lucent
    5. Recommends an evolutionary, incremental, introduction of formal methods, that follows informal Domain analysis to identify useful abstractions.
    6. FAST::Process="Family-Oriented Abstraction, Specification, and Translation".

    Arjomandietal83

    1. Arjomandi & Fischer & Lynch
    2. Efficiency of Synchronous Versus Asynchronous Distributed Systems
    3. Jnl ACM V30n3(Jul 1983)pp449-456
    4. =THEORY non-sequential optimization

    Arnold94

    1. Robert S Arnold
    2. Software ReEngineering: A Quick History
    3. Comm ACM V37n5(May 1994)pp13-14
    4. =HISTORY maintenance

    ArnoldK94

    1. Ken Arnold
    2. Class Design for Inheritance
    3. UNIX Review V12n7(Jul 1994)pp67-72
    4. =ARTICLE DESIGN OBJECT-ORIENTED
        A is_a_special B A is_a B class A: public B{....}
      1. Liskov, Anything possible to/true of a B is possible to/true of an A as well

        A is_a_kind_of B that does V in a special way

      2. class B...{ virtual... V (....)=0 }
      3. class A: public B{..virtual... V (....){...}..}

        A has_a B class A:... { ... B name; ...} A refers_to_a B class A:...{ B* name; ...} A implemented_using B class A: private B {....} Don't!

      4. class A: protected B{....} Don't!

        A is_like_a B For some C, A and B come from a template C


    ArnoldTFuson94

    1. Thomas R Arnold & William A Fuson
    2. Testing "In A Perfect World"
    3. Commun ACM V37n9(Sep 1994)pp78-86(in Binder94)
    4. =ESSAY NONSEQUENTIAL OBJECTS SQA
        p86(Conclusions) Testing is difficult

        Good objects are difficult to write because: behaviors and components are sometimes complex + likely to be used in unimagined contexts + depend on non-OO software with nonencapsulated sideeffects + C++ object model does not expand (without care) across client-server or peer-peer environments

        Testing is easier: hierarchies reuse code - reexercise + public interfaces defined early allowing earlysimilar test drivers -> automation

        Clashes: C++ vs DCE exceptions + extant non-thread-safe libraries + thread support in C++ practically non-existant

        Reccommend: Use code analysis tools to aid code review, self-istrumenting tools to detect bugs, prepare to develop in house tools, make development environment that encourage cosistent testing.


    ArnoutMeyer03

    1. Karine Arnout & Bertrand Meyer
    2. Uncovering Hidden Contracts: The .NET Example
    3. IEEE Computer Magazine V36n11(Nov 2003)pp48-
    4. =CASE-STUDY CONTRACTS ASSERTIONS ..NET LIBRARY META-DATA TOOL
    5. In ARRAY_LIST 62% of routines have implicit contracts hidden in the meta-data.

    AroraGouda93

    1. Anish Arora & Mohamed Gouda
    2. Closure and Convergence: A Foundation for Fault-Tolerant Computing
    3. IEEE Trans on Software Eng VSE-19n11(Nov 1993)pp1015-1027
    4. =THEORY guarded commands formal reliability
        closure is a safety property: If a fault occurs when the system is OK then (and even if faults continue) the system enters a larger set of states

        Convergence is a liveness property: If faults stop occuring then the system eventually reaches an OK state

        OK state = legal.

        atomic commitment (two-phase commit), data transfer, Byzantyne agreement, sliding window, delay insensitivity, impossible requirements, design methods.


    Arce02

    1. Ivan Arce
    2. Bug Hunting: The Seven Ways of the Security Samurai
    3. IEEE Computer Magazine Security & Privacy supplement V35(Mar/Apr 2002)pp11-15
    4. =EXPERIENCE BUGS SECURITY QUALITY RISKS
    5. Lists security bug myths in a sidebar p12. Bug hunting takes time and understanding all the implications takes longer.
    6. Lists samples of security bugs in a sidebar p13
    7. The seven ways: audit, debuggers and disassemble, network traffic analysis, blackbox tests, brute force, top-down analysis, such the Internet.
    8. Methods: lone ranger, timeboxed peer audit, assembly line, rotating teams.

    ArcuriZohaibBrand12

    1. Andrea Arcuri & Muhammad Zohaib & Lionel Brand
    2. Random Testing: Theoretical results and practical implications
    3. IEEE Trans Software Engineering V38n2(Mar/Apr 2012)pp258-277 & ISSTA 2010
    4. =SURVEY PROBABILITY TESTING ORACLES SUT COUPON COLLECTOR RT
    5. Good introduction to the topic. Covers the background and history well.
    6. Proves several neat theorems.
    7. Traditionally random testing is thought to be worse than partition testing.
    8. This paper surveys experience papers and the theory to argue that it is not as bad as we thought.

    Argent-KatwalaBradleyDingle04

    1. Ashok Argent-Katwala & Jeremy T Bradley & Nicholas J Dingle
    2. Expressing Performance Requirements using Regular Expressions to specify stochastic probes over process algebra models
    3. WOSP'04 & ACM SIGSOFT Software Engineering Notes V29n1(Jan 2004)pp49-58
    4. =DEMO Performance Regular Expressions stochastic process algebra PEPA TOOL ipc/DNAmaca

    Ariely09

    1. Dan Ariely
    2. Predictably Irrational: The Hidden Forces That Shape Our Decisions
    3. Harper Collins NY NY 2009
    4. =POPULARIZATION =EXPERIMENTS PEOPLE PSYCHOLOGY FALLACIES MARKETING BEHAVIORAL ECONOMICS
    5. Web site [ http://www.predictablyirrational.com/ ]
    6. We are all a lot less rational than standard economics assumes.
    7. Online Outline [ Predictably-Irrational ]
    8. Examples
      1. A third option can makes us choose the worse alternative. cf Arrow's Theorem.
      2. Price is often determined by habit not supply and demand. By thinking about a price we start to select a price.
      3. The word "Free" helps us spend more money.
      4. We will buy things or do things because of others not just money -- social norms.
      5. Social norms can get more work done than money -- Open Source.
      6. Arousal changes things. More than we expect.
      7. Procrastination -- teachers should impose deadlines.
      8. We overprice what we have -- cognitive dissonance strikes again.
      9. We will waste time and money to keep our options open.
      10. Expectations color our perceptions. Stereotypes!
      11. Higher cost makes medicine etc. work better. Placebo effect.
      12. We don't like to cheat but still cheat a little bit. We are more honest about cash than things.
      13. Making public choices can make you choose differently (in the USA) or in conformity(Hong Kong).


    9. (dick)|-Maslow!

    AriesEtal02

    1. James A Aries & Subhankar Bannerjee & Marc S Brittan & Eric Dillion & Janusz S Kowalik & John P Lixvar
    2. Capacity and Performance Analysis of Distributed Enterprise Systems
    3. Commun ACM V45n6(Jun 2002)pp100-105
    4. =EXPERIENCE Boeing RE-ENGINEERING TUNING PERFORMANCE large scaling client-server net SIMULATION
    5. Need to monitor what is going on. Need model of workload characteristics. Load testing. Need model of system.
    6. Mathematical and analytical models. Trading off time to solve vs accuracy of predictions.

    ArinzeAnandarajan03

    1. Bay Arinze & Murugan Anandarajan
    2. A Framework for Using Object-Oriented mapping methods to rapidly configure ERP Systems
    3. Commun ACM V46n2(Feb 2003)pp61-65
    4. =ADVERT EOM Object-Oriented ERP
    5. EOM::="Enterprise Object Model".

    ArisholmBriandFoyen04

    1. Erik Arisholm & Lionel C Briand & Auden Fvyen
    2. Dynamic Coupling Measurement for Object-Oriented Software
    3. IEEE Trans Software Engineering V30n8(Aug 2004)pp491-506
    4. =CASESTUDY DYNAMIC RUNTIME Java COUPLING METRICS TOOL JDissect Notes interaction of inheritance and message passing: the object-level coupling is determined at runtime but class-level is static (and different).
    5. Figure 2, p494 is UML Metamodel of classes, methods, objects, etc.. Studied Velocity open source in Apache Jakarta Project. 17 versions 408 class es, 17KLOC, 65 inheritance relation, 149 methods overridden.
    6. Average dynamic import and export couplings are always equal. Principle components confirm that dynamic coupling is not correlated with stat ic metrics.
    7. Regression of change proneness on SLOC and each proposed metric.
    8. |-the dynamic export coupling metrics predict change proneness.
    9. Similar to work done on Smalltalk.
    10. Export coupling occurs when one method is called by another one.
    11. Changes come from calls

    ArisholmBriandHoveLabiche06

    1. Erik Arisholm & Lionel C Briand & Siw Elisabeth Hove & Yvan Labiche
    2. The impact of UML Documentation on Software Maintenance: an Experimental Evaluation
    3. IEEE Trans Software Engineering V32n6(Jun 2006)pp365-381
    4. =EXPERIMENT UML MAINTENANCE DOCUMENTATION TOOLS TAO Visio Java Oslo Ottawa
    5. UML documentation helps students to correctly make complex changes in code.
    6. It helps students make complex changers faster but the total time (including updating the diagrams was longer.
    7. Some students who had no UML docs drew their own on difficult tasks.
    8. Some students given UML ignored it on some tasks.
    9. Students without the UML docs where more likely to say that they were out of practice with Java and had problems grasping the whole picture.
    10. Previous experiment [ ArisholmSjoberg04 ]

    ArisholmSjoberg04

    1. Erik Arisholm & Dag I J Sjoberg
    2. Evaluating the Effect of a delegate versus centralized Control Style on the maintainability of Object-Oriented Software
    3. IEEE Trans Software Engineering V30n8(Aug 2004)pp521-534
    4. =EXPERIMENT EVOLUTION MAINTENANCE Object-Oriented MODULES Expert REALITY vs novice Java SESE RDD Responsibility GLM ANOVA
    5. Comparison of the correctness and effort for maintaining two OO designs for the Coffee-Machine problem from OOPSLA'97 OO. Compared consultants(3 levels: junior, intermediate, senior) and Students(Ugrad vs Grad).
    6. Two designs: one centralizes most of the responsibilities into a FrontPanel object. The decentralized design models ideas like product, ingredient, recipe and spreads the functionality over 12 modules.
    7. Overall correctness on 4 tasks: 59%, correctness increases with expertise, centralized(69%) done correctly more often than decentralized(50%)!
    8. Effort drops with expertise for students, but for consultants the effort on decentralized design drops with expertise and increases for the centralized.

    ArisholmEtAl07

    1. Erik Arisholm & Hans Gallis & Tore Dyba & Dag I K Sjoberg
    2. Evaluating Pair Programming with respect to System Complexity and Progrmmer Expertise
    3. IEEE Trans Software Engineering V33n2(Jan 2007)pp65-86
    4. =EXPERIMENT TECHNICAL MAINTENANCE PAIR PROGRAMMING EXPERTISE STYLE Java
    5. Well designed experiment testes whether pairs are more productive than programmers working alone.
    6. Based on previously used experimental code [ ArisholmSjoberg04 ]
    7. On average there is a slight bdecrease in the time and an increase in the likelihood of a correct fix -- but the effort(2 people vs 1person) is 80% higher.
    8. With less experienced programmers pairs are 70%more likely to produce correct code it takes them a little longer.
    9. Intermediate programmers get the best reduction in time 30%.
    10. Experience programmers produce less correct code but do bit a little faster.
    11. All these effects are moderated as the code switches style from a centralized control design to a distributed control Object-Oriented design.

    ArlowNeustadt04

    1. J Arlow & I Neustadt
    2. Enterprise patterns and MDA: Building Better Software with Archetype Patterns and UML
    3. Addison Wesley Longman Publishing Co, Inc., Redwood City, CA, 2003. CR 0412-1461.
    4. =HANDBOOK COMMERCIAL ORGANISATION LITERATE UML MODELS MDA PCL archetype pleomorph
    5. MDA::OMG="Model Driven Architecture", using tools to convert models directly to code.
    6. PCL::=" Pattern Configuration Language".
    7. archetype::= "a class, attribute, operation, or relationship that appears in many applications"
    8. ArlowNeustadt04_pattern::= "A collection of collaborating archetypes", optional parts shown by the <<o>> stereotype. Names: Party, Party relationship, Customer Relations Management(CRM), Product, Inventory, Order, Quantity, Money, Rule.
    9. pleomorph::= " distinct patterns of archetypes in different enterprises".

    Armour00

    1. Phillip G Armour
    2. The Case for a new business model
    3. Commun ACM V43n8(Aug 2000)pp11-22
    4. =IDEA software is a medium for storing DATA
    5. 5_media:=(DNA, brains, hardware/tools, books, software).
    6. We need paraphrenalia to allow us to embed knowledge in software so that it can be changed and used.
    7. workplace and process should help acquire knowledge.
    8. 1. domain knowledge, 2. how to acquire knowledge, 3. how to structure it for embedding in software. Most developers will not need knowledge of software itself.
    9. failure also leads to knowledge
    10. account for knowledge as an asset

    Armour00b

    1. Phillip G Armour
    2. The Five Orders of Ignorance
    3. Commun ACM V43n10(Oct 2000)pp17-20
    4. =ESSAY TECHNICAL CODE contains KNOWLEDGE PROCESSES METHODS
    5. Tight hacked code does not contain disproven ex-knowlege.
    6. For n:0..4, n.OI := n.th Order Ignorance.
    7. 0.OI = demonstrable knowledge.
    8. 1.OI = Know that I don't know.
    9. 2.OI = I don't Know that I don't know.
    10. 3.OI = I don't know how to uncover 2.OI.
    11. 4.OI = I don't know about the OI.
    12. Methods and processes give usxquestions not answers.

    Armour01

    1. Phillip G Armour
    2. The Laws of Software Process
    3. Commun ACM V44n1(Jan 2001)pp15-
    4. =ESSAY PROCESSES CMM IGNORANCE
    5. 5 orders of ignorance [Armour00b]
    6. Why developing processes is difficult.
    7. One size doesn't fit all. Fit process to situation. Experimental lab areas. Term limits. Measure value.

    Armour01b

    1. Phillip G Armour
    2. Matching Process to Types of Teams
    3. Commun ACM V44n7(Jul 2001)pp21-23
    4. =ESSAY ONESIZE PROCESS TEAM PEOPLE
    5. One size does not fit all -- a creative team does not want a repeatable product!
    6. Four kinds of team:=( tactical, problem-solving, creative, Learning).
    7. Use "orders of Ignorance".. [Armour00b]

    Armour02

    1. Phillip G Armour
    2. The Spiritual Life of Projects
    3. Commun ACM V45n1(Jan 2002)pp11-14
    4. =ESSAY PEOPLE MANAGEMENT TEAM
    5. (FatherJim)|-4 components of humanity: physical, intellectual, emotional and spiritual.
    6. need: explicit or implicit code of conduct, higher purpose, contributing values to someone's life, morale, mutual support, leadership by creating an environment where people do their best, caring for weaker members of the team.

    Armour02b

    1. Phillip G Armour
    2. Ten Unmyths of Project estimation
    3. Commun ACM V45n11(Nov 2002)pp15-18
    4. =ESSAY ESTIMATION QUALITIES
    5. |-What we don't know is a major source of error in estimation and defects in code.
    6. |-Sometimes we don't even know that we are missing knowledge.
    7. |-Estimates are inaccurate.
    8. |-don't estimate dates: estimate the probability of an event by that date.
    9. |-estimates are not commitments.
    10. |-time is only roughly defendant on size.
    11. |-Historical data may be the best data, but it is not good enough to predict productivity.
    12. |-Productivity works for buildings and things but not for knowledge.
    13. |-LOC/FP does not measure knowledge we don't have.
    14. |-Brook's Law.
    15. |-No amount of resources can guarantee absence of defects.

    Armour04

    1. Phillip Armour
    2. When Executives Code
    3. Commun ACM V47n1(Jan 2004)pp19-22
    4. =EXPERIENCE PEOPLE vs PRACTICE MANAGEMENT
    5. Executives on a 3 day course behave like amateur programmers on a programming project and emerge sadder but wiser.
    6. The course project included unexpected system failure, unrealistic deadlines, and deliberately intrusive management.
    7. Executives lost track of the goals of the project in the joys of hacking code!
    8. Never produced working system.

    Armour04a

    1. Phillip G Armour
    2. Not-Defect: the Mature Discipline of Testing
    3. Commun ACM V47n10(Oct 2004)pp15-18
    4. =ESSAY TESTING IGNORANCE
    5. Testing is about discovering what we don't know.

    Armour03

    1. Phillip G Armour
    2. The laws of Software Process: A New model for the production and management of software
    3. Auerbach Boston MA 2003 ISBN 0849314895 CR 0502-0217
    4. =THEORY IGNORANCE PEOPLE METHODS
    5. Software development as a process of discovering and recording knowledge.
    6. Based on .Lookup Armour

    Armour06

    1. Phillip G Armour
    2. Counting Boulders and Measuring Mountains
    3. Commun ACM V49n1(Jan 2006)pp17-20
    4. =ANALOGY ESTIMATION PLANNING Project Management WBS COCOMO SLIM-Estimate Everest
    5. Argues that you don't get a good estimate of the size of a mountain by estimating the rocks that make it up and adding up the numbers.
    6. WBS::="Work Breakdown Structure", count the rocks in the mountain.
    7. Executives then ask for a better estimate/plan.
    8. Scope-based implementation is more like using surveying tools and techniques to measure the mountain.
    9. Use the scope of the project to estimate final system size.
    10. Time depends on a power of system size.
    11. Since scope is uncertain and the estimates of size based on a given scope add uncertainty, one generates effort estimates that have a range of values.
    12. Quantify the uncertainties!
    13. No discussion of the agile approach (start climbing the mountain first, and change your estimates as you climb, etc.)

    Armour06b

    1. Phillip G Armour
    2. Software: hard data
    3. Commun ACM V49n9(Sep 2006)pp15-17
    4. =EXPERIENCES statistics Information technology projects
    5. Software enacts knowledge about many domains with no commonality.
    6. Quotes data from "QSM".
    7. Small teams succeed more than large ones.
    8. Typical projects have fewer than 7 people, last < 8 months, use COBOL, 9KLOC.
    9. More projects overlap phases these days.
    10. Best projects are good accross the board: effort, estimate, duration,...
    11. Big LOC projects are more productive but why?

    Armour07

    1. Phillip G Armour
    2. Agile . . . And Offshore
    3. Commun ACM V50n1(Jan 2007)pp13-14
    4. =INTERVIEW AGILE DISTRIBUTED PEOPLE ECONOMICS TOOLS WEB/NET GeneerAginity Ukraine Mantis Subversion Cruise control Ncover simian
    5. Agile Geneer misjudged .com crash 2000-2002 & bank foreclosed.
    6. Aginity offshore development (Evanston+Kiev) based on personal contact, shared achitecture, patterns, frameworks, language, & vocabulary.
    7. Stories, iterations, risk provocation.
    8. Open source groupware tools generate management data via web spaces.

    Armour07a

    1. Phillip G Armour
    2. Mortallity Play
    3. Commun ACM V50n3(Map 2007)pp-
    4. =ANECDOTE INSURANCE SOFTWARE ESTIMATION
    5. Insurance depends on estimating precisely the chances of bad things happening...
    6. But this (anon) company had failed to figure out the chance of four projects failing.
    7. Armour figured each had a 1/5 chance, so all four at about 1/200 for the complete set.
    8. They used classic project planning with task breakdown etc...
    9. Conclusion: don't just ask how long a project will take, ask what is the chanace that it will be complete by the deadline.

    Armour07b

    1. Philip G Armour
    2. Twenty Percent
    3. Commun ACM V50n6(Jun 2007)pp21-23
    4. =IDEA ESTIMATION OPTIMISTIC RISKS DEATHMARCH
    5. A good 50% estimate -- allowing for reasonable problems -- is negotiated down to one that has a 20% of being met, by ignoring the risks.
    6. Optimism reduces the resources requested at the price of increasing the probability of running out of resources.
    7. See [Spinellis07a] and [DEATHMARCH]

    Armour08

    1. Phillip G Armour
    2. The inaccurate conception
    3. Commun ACM V51n3(Mar 2008)pp13-16
    4. =ESSAY ESTIMATION UNCERTAINTY LIFECYCLE
    5. Cone_of_uncertainty::=map[t:time]([1/f(t) .. f(t)]* actual ), for some decreasing function f. "Describes how estimates get more accurate as a project proceeds". At that start of new product estimates are between [0.25 .. 4.0] times the actual value. Tightens as uncertainties are removed.
    6. Express estimates as a distribution mapping qualities to probability of success. S shaped curve.
    7. commitment is not an estimate.

    Armour09

    1. Phillip G Armour
    2. The Business of Software: The Ontology of Paper
    3. Commun ACM V52n1(Jan 2009)pp23-24 [ 1435417.1435427 ]
    4. =ESSAY DOCUMENTATION PAPER vs
    5. Claims that the industrial revolution did not occur until steam engines were used to create steam engines.
    6. Claims that current software technology tends to reproduce the defects of paper-based artifacts.
    7. Describes the properties of paper artifacts: difficult to link artifacts, not executable, not easily verifiable, serial access, imposes a hierarchical structure, places information within a linear context, inherently single-tasking, ...
    8. Even hypertext does not relax these constraints.
    9. Claims that older systems fitted the paper model well.
    10. New systems need the external linkages and executability of software.

    Armour09a

    1. Phillip G Armour
    2. the business of software: the cliche defence
    3. Commun ACM V52n7(Jul 2009)pp34-36 [ 1538788.1538802 ]
    4. =ESSAY PEOPLE MANAGERS BUZZ PHRASES
    5. Do it right the first time. But.... Quote: "much of the business of software involves the discovery of what we are supposed to be doing".
    6. Work smarter not harder.
    7. Quality is the most important thing. But.... Which quality?
    8. Our customers are the most important thing. But.... Which customers? What about future extensions and the people who work on them?
    9. Our people are the most important thing. But... are they supported?

    Armour09b

    1. Phillip G Armour
    2. Contagious craziness, spread sanity
    3. Commun ACM V52n10(Oct 2009)pp19-20 [ 1562764.1562774 ]
    4. =ANECDOTAL PEOPLE ESTIMATION TEAMS cognitive dissonance rationalization groupthink
    5. Newton's first law of behavior: every behavior will continue until acted upon by another behavior.

    Armour10

    1. Phillip G Armour
    2. Return at Risk
    3. Commun ACM V53n9(Sep 2010)pp23-25 [ 1810891.1810902 ]
    4. =POLEMIC ESTIMATION ROI RISK COST VALUE DISTRIBUTION
    5. ROI::acronym="Return on Investment"
    6. Argues that the traditional straight line formula
    7. ROI=(value-cost)/cost, is not valid if there is any risk of the cost or value being wrong.
    8. Need cost and value profiles. Probability distributions.
    9. Notes that cost' tends to be skewed toward overruns and value` towards zero.
    10. Calculating a better likely or average ROI is not simple and may need Monte Carlo methods. There exist tools.
    11. Are cost and value independent?

    Armour11

    1. Phillip G Armour
    2. The Business of Software: Don't Bring me a good idea
    3. Commun ACM V54n1(Jan 2011)pp- [ 1866739.1866748 ]
    4. =HOW TO SELL BUSINESS CHANGES IDEAS SYSTEMS MAKE MONEY
    5. Good ideas -- ho-hum,
    6. Cost reduction -- limited value,
    7. Revenue growth gives and keeps on giving.

    Armour11a

    1. Phillip G Armour
    2. etyltS edoC detisiveR (letter)
    3. IEEE Software Magazine V28n4(Jul/Aug 2011)pp7-8
    4. =ESSAY CODE STYLE THOUGHT
    5. Coding is thinking and learning.
    6. Reply to [Spinellis11]

    Armour12

    1. Phillip G Armour
    2. The business of software -- a measure of control
    3. Commun ACM V55n6(Jun 2012)pp26-28 [ 2184319.2184329 ]
    4. =ESSAY METRICS vs PROCESS KNOWLEDGE DOMAIN KNOWLEDGE
    5. Chicken and egg.
    6. Why measure something that is out of control -- unrepeatable.
    7. Measurement can be used to enforce a process.
    8. Core metrics: size, productivity, time, effort or cost, reliability or quality.
    9. Size stands in for the knowlege content of the software.
    10. Productivity as a proxy for the rate of learning.
    11. Time: from when to when? Ramping up!
    12. Effort may ignore overtime!
    13. Quality - bad news is suppressed - bugs. But defects found show learning/progress.
    14. Conclusion: much variability in measurement.

    Armour13

    1. Phillip G Armour
    2. How we build things and why things are are 90% complete
    3. Commun ACM V56n1(Jan 2013)pp32-33 [ 2398356.2398367 ]
    4. =ESSAY ESTIMATION IGNORANCE SCHEDULE RISK Rayleigh PHASES
    5. Work does not proceed in a linear fashion. The most work is done in the middle of the project and then there is a long tail.
    6. For t:Time, distribution_of_total_effort_at_time(t)::= 2*K*a*t*exp(a*t^2) where K = total_effort and a=constant.
    7. Cumulative_amount_complete::= K*(1-exp(a*t^2)).
    8. Armour_Phases::Process= Preparation; Production; Proving.
    9. It is not just that we don't know all the answers until the project is over. We don't know all the questions either.

    Arms01

    1. Willian Y Arms
    2. Uniform Resource Names: Handles, PURLs, and Digital Object Identifiers
    3. Commun ACM V44n5(May 2001)p68
    4. =HISTORY WEB/NET URL RFC1737 URN CNRI DOI IDF
    5. PURL::= "Persistent URL".

    Armstrong06

    1. Deborah J. Armstrong
    2. The Quarks of Object-Oriented Development
    3. Commun ACM V49n2(Feb 2006)pp123-128
    4. =SURVEY OBJECTS TECHNICAL ONTOLOGY GLOSSARY TAXONOMY
    5. Two "constructs": Structure and Behavior.
    6. Under Structure: Abstraction, Class, Encapsulation, Inheritance, Object.
    7. Under Behavior: Message Passing, Method, Polymorphism.
    8. Table 3 includes definitions of the concepts.

    Armstrong01

    1. Rob Armstrong
    2. Seven Steps to Optimizing Data Warehouse Performance
    3. IEEE Computer Magazine V34n12(Dec 2001)pp76-79
    4. =ADVERT PERFORMANCE OLAP DATA WAREHOUSE
    5. Good for OLTP is bad for OLAP. Cf SSADM Physical design control in 1980's.
    6. steps: use relational OLTP data, implement special views via SQL, add indices, store more summaries, denormalize, denormalize irrationally, export data.
    7. Cycle: define requirement, understand benefits, determine needed data, find lowest step to get performance, calculate costs, implement or redefine requirements.

    Armstrong10

    1. Joe Armstrong
    2. Erlang
    3. Commun ACM V53n9(Sep 2010)pp68-75 [ 181091.1810902 ]
    4. =ADVERT LANGUAGE Erlang NON-SEQUENTIAL FUNCTIONAL PROCESSES EXCEPTIONS QUEUING Ericsson
    5. Message passing is good. Sharing is bad.
    6. "let it crash" and another process tidies up the mess -- separates the main line code from the special cases. Many small modules.
    7. First class functions/process allow easy upgrades inside running code.
    8. Also see [Larson09]

    ArrechederaMatteo00

    1. Hector Arrechedera & Alfredo Matteo
    2. How to get started with Design Patterns
    3. Proc SCI/ISAS2000 VII pp47-52 [SCI00]
    4. =EXPERIENCE EDUCATION OBJECT-ORIENTED PATTERNS

    ArthorneLaffra04

    1. John Arthorne & Chris Laffra
    2. Official Eclipse 3.0 FAQs
    3. Addison Wesley Pro BostonMA 2004 ISBN 0321268385 CR 0605-0450 [ http://www.eclipse.org ]
    4. =UNREAD =MANUAL Eclipse PLUGIN Java IDE SWT [click here [socket symbol] if you can fill this hole]

    Arthur92

    1. Lowell Jay Arthur
    2. Rapid Evolutionary development: requirements, prototyping and software creation
    3. John Wiley& Son NYNY 1992 ISBN 0-471-53633 CR 9211-0860 QA76.76.D47A78
    4. =HANDBOOK EVOLUTION REQUIREMENTS PROTOTYPES

    Arthur97

    1. Lowell Jay Arthur
    2. Quantum Improvements in Software Quality
    3. Commun ACM V40n6(Jun 1997)pp46-52
    4. =EXPERIENCE PEOPLE PROCES QUALITY MODULES METRIC CYCLOMATIC PARETO
    5. focus on particular results and people. Give practical "accelerated" training(story+demonstrations+discuss application).
    6. Laws: 20% of the code has 80% of the errors. 20% of the code requires 80% of the mods. Keep cyclomatic complexity of modules between 5 and 15.

    ArthurGronerHayhurstHolloway99

    1. James D Arthur & Markus D Gr"oner & Kelly J Hayhurst & C Michael Holloway
    2. Evaluating the effectiveness of independent verification and validation
    3. IEEE Computer Magazine V32n10(Oct 1999)pp79-83
    4. =EXPERIMENT V&V SEES MER TAPs QUALITY
    5. IV&V beneficial: cost of errors reduced

    ArtziEtAl10

    1. Shay Artzi & Adam Kiezun & Julian Dolby & Frank Tip & Danny Dig & Amit Paradkar & Michael D Ernst
    2. Finding bugs in web applications using dynamic test generation an explicit-state model checking
    3. IEEE Trans Software Engineering V36n4(Jul/Aug 2010)pp474-494
    4. =CASESTUDY TOOL Apollo TEST PROOF CHECK VALIDATE VERIFY HTML PHP MySQL
    5. Apollo found 100s of faults in real web applications.

    Asaravala03

    1. Amit Asaravala
    2. All by themselves
    3. Software Development Magazine V11n3(Mar 2003)pp38-41
    4. =HISTORY AGENTS AI Clippy metadata semantic web XML RDF ontology DAML+OIL LOGIC
    5. Agents (minimally) observe an environment and react to changes by interacting with the environment -- and other agents.
    6. Agents either need a shared ontology or a way to share ontologies and metadata.
    7. RDF::XML_DTD="Resource Description Framework", indicates relationships between subjects, predicates and objects.

    Asaravala04

    1. Amit Asaravala
    2. Project Management, Evo Style
    3. Software Development -- People and Projects newsletter(Nov 2004)
    4. =ARTICLE AGILE EVOLUTIONARY PROJECT MANAGEMENT 1960s ITERATIVE Evo PDCA
    5. Many small cycles each with Planning, Checking, Doing, and Acting -- -- --(PDCA)
    6. Acting changes the plans...
    7. See also "Evolutionary Project Management Methods," by Niels Malotaux [ http://click.sd.email-publisher.com/maacOZiabbnXPbdngFsb/ ] [pdf] and "How Quality Is Assured by Evolutionary Methods," by Niels Malotaux [ http://click.sd.email-publisher.com/maacOZiabbnXQbdngFsb/ ] [pdf].

    AsarinCaspiMaler02

    1. Eugene Asarin & Paul Caspi & Oded Maler
    2. Timed Regular Expressions
    3. J. ACM V49n2(Mar 2002)pp172-206
    4. =THEORY TIMING REGULAR EXPRESSIONS STRINGS FSM LANGUAGES KLEENE BUCHI NONSEQUENTIAL
    5. When time is important as well as sequence, then timed automata recognize languages defined by extended regular expressions: Intersection and relabelling have to be added to union/sequence/closure.
    6. Definition is via the free merge of a Time monoid and an Event monoid.

    Ashman00

    1. H L Ashman <hla@cs.nott.ac.uk>
    2. Relations Modeling Sets of Hypermedia Links and Navigation
    3. Computer Journal V43n5( 2000)pp345-363
    4. =THEORY WWW/NET HYPERTEXT

    AslesonSchutta05

    1. Ryan Asleson & Nathaniel T Schutta
    2. Foundations of Ajax (foundation)
    3. Apress Berkeley CA 2005 ISBN 159059823 CR 0611-1104
    4. =UNREAD Web/NET Javascript XML Ajax
    5. Compare with rival Atlas [SmithK06] from Microsoft.

    Aslett91

    1. M J Aslett(Ed)(GEC Marconi UK)
    2. A knowledge based approach to Software development: ESPRIT project ASPIS
    3. North-Holland Amsterdam Netherlands 1991 ISBN 0-444-88886-1 CR9310-0740
    4. =UNREAD KNOWLEDGE ASPIS

    AstesianoReggioRicca08

    1. Egidio Astesiano & Gianna Reggio & Filippo Ricca
    2. Modeling Business with a UML-based Rigorous Software Development Approach
    3. Montanari Festschrift pp261-277 [DeganoEtAl08]
    4. =DEMO UML BUSINESS MODELING MARS SOA REALITIES SYSTEMS ORGANIZATION OCL
    5. BM::discipline="Business Modeling".
    6. Use multiple UML2 views of business: Static + Organization + Business Process + Data.
    7. Model business processes in the context of other business processes.
    8. Model business entities and organization.
    9. Model activities precisely.
    10. Proposes stereotypes: <<A>> for autonomous acts, <<bw>> for business worker, <<bo>> for business objects, <<ext>> external entities, <<ou>> organizational units. <<bp>> business process "use case". <<large>> high level cases.

    AstleySturmanAghar01

    1. Mark Astley & Daniel Sturman & Gul Aghar
    2. Customizable middleware for modular distributed software
    3. Commun ACM V44n5(May 2001)pp99-107
    4. =DEMO MODULES ARCHITECTURE WWW/NET NONSEQUENTIAL QUALITIES REFLECTION LANGUAGE ACTORS
    5. separate concerns of application (PURPOSES) from nonfunctional requirements (policies) like security and atomicity.
    6. Express policies(requirements) explicitly in the software.
    7. Policies are to protocols as interfaces are to implementations.
    8. DIL::= "Distributed Interaction Language", describes a protocol in terms of roles and their responses to events. Roles are formal parameters.
    9. Multiple policies achieved by stacking protocols with one object playing one or more roles in several protocols.
    10. ?? Aliasing ?

    Astrachan91

    1. Owen Astrachan
    2. Pictures as Invariants
    3. SIGCSE Bulletin V23n1(Mar 1991)pp112-118
    4. =DEMO LOGIC TECHNICAL GRAPHIC

    Asuaga01

    1. Ana Asuaga
    2. Enginering a New society
    3. IEEE Computer Magazine V34n6(Jun 2001)pp104+102-103-
    4. =ESSAY SYSTEMS ENGINEERING ETHICS
    5. Need for collaboration and listening in engineering and in society.

    AthanasSilverman93

    1. Peter M Athanas & Harvey F Silverman
    2. Processor Reconfiguration Through Instruction-Set Metamorphosis
    3. IEEE Computer Magazine V26n3(Mar 1993)pp11-20
    4. =DEMO DFDs HARDWARE
    5. DFDs on pages 15-16 are called DFGs

    AtkinsBallGravesMockus02

    1. David L Atkins & Thomas Ball & Todd L Graves & Audris Mockus
    2. Using Version Control Data to evaluate the Impact of Software Tools: A Case Study of the Version editor(VE)
    3. IEEE Trans Software Engineering V28n7(Jul 2002)pp625-637
    4. =EMPIRICAL TECHNICAL TOOL EVALUATION
    5. |-(1) : tools help developers determine and/or carry out modifications in existing documents.
    6. |-(2) : The change history of such documents can be used to estimate the effort.
    7. (1, 2)|-record tools used and relate to monitored data.
    8. Tool designed to hide C++ #ifdefs etc had a significant and good effect on productivity.

    AtkinsonKuhne03

    1. Colin Atkinson & Thomas K"uhne
    2. Aspect-Oriented Development with Stratified Frameworks
    3. IEEE Software Magazine V20n1(Jan/Feb 2003)pp81-89
    4. =IDEA DESIGN ASPECTS AOP HIERARCHY ARCHITECTURE PATTERNS
    5. Refine labelled interactions to collaborations of objects. Labels name concerns and indicate the collaboration and/or more detailed concerns.
    6. Concerns include coordination, distribution, persistence, security, recovery, undo, paradigms

    AtleeBuckley96

    1. Joanne M Atlee & Michael A Buckley
    2. A logic-Model Semantics for SCR Software Requirements
    3. Proc 1996 Int Symposium on Software Testing & Analysis(ISSTA) & ACM SIGSOFT SENotes V21n3(May 1996)pp280-292
    4. =IDEA LOGIC SCR REQUIREMENTS TABULAR
    5. SCR::="Software Cost Reduction"
    6. SCR Statecharts RSML all share conditioned-event-driven reactive systems. demos analytical requirements temporal logic model and tool SMV::="Symbolic Model Verifier". CTL::=Computational Tree Logic
    7. See CORE [WilliamsL94] [HeimdahlLeveson96]

    Atwood07

    1. Jeff Atwood
    2. The coming Software Patent Apocalpse
    3. Coding Horror (Jul ?? 2007) [ 000902.html ]
    4. =ESSAY LEGAL PATENT ARMS RACE Microsoft Knuth

    Atwood08

    1. Jeff Atwood
    2. Coding: It's just writing
    3. coding horror nov10th [ 001184.html ]
    4. =ESSAY CODING STYLE STRUNK LITERATE KNUTH

    Atwood09?

    1. Jeff Atwood
    2. software engineering dead?
    3. coding horror blog (jul 18 2007) [ 001288.html ]
    4. =ESSAY CONTROL PLANNING ENGINEERING CRAFT
    5. surprised by [DeMarco09]
    6. Quote
        And yet, it's also a release. It's as if a crushing weight has been lifted from my chest. I can publicly acknowledge what I've slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.

    Atwood09b

    1. Jeff Atwood
    2. COBOL: Everywhere and Nowhere
    3. Coding Horror (Aug 9 2009) [ 001294.html ]
    4. =BLOG COBOL COBOL.NET EXAMPLE

    Atwood10

    1. Jeff Atwood
    2. Coding Horror Jun 1st 2010 [ the-vast-and-endless-sea.html ]
    3. =ESSAY PEOPLE ECONOMICS SOCIOLOGY MOTIVATION Stack Overflow vs Stack Exchange FOSS
    4. More money does not encourage better programming. [Pink09]

    Atwood11

    1. Jeff Atwood
    2. The infinite version
    3. Coding Horror (23 May 2011) [ the-infinite-version.html ]
    4. =BLOG UPDATES INCREMENTAL FLUIDITY Chrome bsdiff Courgette WordPress Google Docs
    5. Quote
        Somehow, we have to be able to automatically update software while it is running without interrupting the user at all. Not if -- but when -- the infinite version arrives, our users probably won't even know. Or care. And that's how we'll know we've achieved our goal.

    AueBreu94

    1. Alfred Aue & Michael Breu
    2. Distributed Information Systems: An Advanced Methodology
    3. IEEE trans on Soft Eng vSE-20n8(Aug 1994)pp594-605
    4. =ADVERT BOS(Bull + Olivetti & Siemens-Nixdorf) ENGINEERING method REQUIREMENTS LIFECYCLE ERD
    5. Based on Merise/Omega
    6. MOis
    7. GRAPES. Relaxed water fall model. Documents can be drafted
    8. approved and then baseline. The draft versions "look ahead" to the future options.

    AugustinePayneSencindiverWoodcock05

    1. Sanjiv Augustine & Bob Payne & Fred Sencindiver & Susan Woodcock
    2. Agile Project Management: Steering from the edges.
    3. Commun ACM V48n12(Dec 2005)pp85-89
    4. =ADVERT AGILE PROJECT MANAGEMENT APM COMPLEXITY XP
    5. APM::= "Agile Project Management".
    6. Agile methods rescue a medium sized project in 2002. Lists: 6 practices, 7 changes, 6 new activities, 6 innovations, 7 difficulties.
    7. sidebar p87 describes complex adaptive systems ( CAS ).

    Austin99

    1. Robert D Austin
    2. The Phantom Menace
    3. IEEE Software Magazine V16n5(Sep/Oct 1999)pp15-18
    4. =EXPERIENCE PROCESSES MANAGEMENT
    5. superstars, dynamic requirements, parallelism, theatre

    AustinDevin03

    1. Rob Austin & Lee Devin
    2. Beyond Requirements: software Making as Art
    3. IEEE Software Magazine V20n1(Jan/Feb 2003)pp93-95
    4. =ESSAY REQUIREMENTS FORMAL vs AGILE PURPOSES QUALITIES EVOLUTION ITERATION
    5. Analogy with producing a play. The requirements are like a script. But a great performance goes beyond the script by iteration, creation, and improvisation. So great software will go beyond the predicted requirements using creativity, iteration, and improvisation.

    Autebert99

    1. Jean-Michel Autebert
    2. Some Results about Centralized PC grammar systems
    3. Theor Comput Sci V215n1/2(Feb 28 1999)pp383-398
    4. =THEORY NONSEQUENTIAL GRAMMAR LANGUAGES THEORY
    5. PC:= Parallel communicating context free.
    6. Grammars generate query symbols that is a non-terminal in another grammar.
    7. Centralised:@PC=only one grammar inserts queries.

    AvisonFitzgerald03

    1. David E Avison & Guy Fitzgerald
    2. Where Now for development methodologies
    3. Commun ACM V46n1(Jan 2003)pp79-
    4. =HISTORY METHODS NONE SDLC ONE-SIZE -> DIVERSITY
    5. methods became mixtures of ( structured, data-oriented, prototyping, Object-Oriented, participative, strategic, Systems) methods.
    6. Most were local to the organization even if based on another one.
    7. web related return to 1960's ad hocism?

    AvisonGregorWilson06

    1. David Avison & Shirley Gregor & David Wilson
    2. Managerial IT Unconsciousness
    3. Commun ACM V49n7(Jul 2006)pp89-93
    4. =EXPERIENCES RISKS 3 AUSTRALIAN FAILURES PEOPLE RMIT ERP PeopleSoft Sidney Water One.Tel
    5. All three we catastrophic (or near catastrophes) for stake holders. One bankruptcy.
    6. 3 different types of business: university, utility, .com telephones
    7. Risk factors
      1. Over-complex/ambitious or over-integrated systems.
      2. Clueless management -- Poor governance -- no checks on progress and quality.
      3. Inexperienced or powerless experts with no clout -- warnings ignored.
      4. Ignoring the critical importance of getting money in: billing systems!

    AvisonYoung07

    1. David Avison & Terry Young
    2. Time to rethink health care and ICT
    3. Commun ACM V50n6(Jun 2007)pp69-74
    4. =SURVEY UK HEALTH RISKS PEOPLE CULTURE FACE-TO-FACE VS ERP NPfIT RISP CSCI372
    5. Describes and analyses the history of health systems not meeting their goals and/or failing to serve the stake holders
    6. NPiFT::UK.NHS="The National Program for Information Technology".
    7. Notes that best practices include understanding and supporting the culture of the organization.
    8. Notes that health system rely on complex face-to-face communication.
    9. Claims this is being ignored in NPfIT.

    AvizienisBall87

    1. Algirdas Avizienis & Danforth E Ball
    2. On the Achievement of a Dependable and Fault-Tolerant Air Traffic Control System
    3. IEEE Computer Magazine V20n2 (Feb 1987)pp63-71
    4. =EXPERIENCE FAA AAS minimize RISKS
    5. Compare with the later TCAS.

    Avram10

    1. Abel Avram
    2. Lessons Learned from Skype's Outage
    3. InfoQ (Dec 30 2010) [ Lessons-from-Skype-Outage ]
    4. =ANALYSIS EXPREIENCE BUG UPDATES FEEDBACK NETWORK FAILURE SUPERNODES OVERLOADED
    5. Most users don't upgrade unless they are forced to.

    Avruninetal91

    1. George S Avrunin & Ugo A. Buy & James C Corbett & Laura K Dillon and Jack C Wileden
    2. Automated Analysis of Concurrent Systems With the Constrained Expression Toolset
    3. IEEE SE-V17n11(Nov 1991)pp1204-1222 CR9303-0149
    4. =DEMO TOOL NONSEQUENTIAL PREDICTION PROOF
    5. regular expressions plus interleaving to predict behaviors and problems

    AycockHorspool01

    1. John Aycock & R Nigel Horspool
    2. Schroedinger's Token
    3. Software - Practice & Experience V31n8(10 Jul 2001)pp803-814
    4. =IDEA LEXICAL PARSING LANGUAGES NONDETERMINISM
    5. During lexical analysis a token can be left in a superposition of several types until the parser looks into the token and resolves it.
    6. IF IF = THEN THEN THEN =IF
    7. dummy token type: SCHRODINGER

    AyewahEtAl08

    1. Nathaniel Ayewah & William Pugh & David Hovemeyer & J David Morgenthaler & John Penix
    2. Using Static Analysis to Find Bugs
    3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp22-29
    4. =EXPERIENCE Google =SURVEY OPEN SOURCE TOOL FindBugs Java TECHNICAL QUALITY Mondrian
    5. A free static analysis tool finds real defects in real code ... Plus some false positives -- but misses some bugs.
    6. Survey of users shows it to be useful.

    BaaderNipkow98

    1. Franz Baader & Tobias Nipkow
    2. Term rewriting and all that
    3. Cambridge U Press NY NY 1998 ISBN 0-521-77920-0 CR0002-0072
    4. =THEORY MATH

    Baber82

    1. Robert Laurence Baber
    2. Software Reflected: the socially responsible programming of our computers
    3. North Holland NY NY 1982 QA76.6.B26
    4. =TEXTBOOK USER

    Baber85

    1. Robert L Baber
    2. I/O Statements in Higher Programming Languages: Unnecessary & Undesirable(Open Channel)
    3. IEEE Computer Magazine V18n6(Jun 1985)p112
    4. =HARMFUL input/output LANGUAGES
    5. harmful to split secondary from primary memory

    BabarGorton09

    1. Muhammad Ali Babar & Ian Gorton
    2. Software Architecture Review: The State of Practice
    3. IEEE Computer Magazine V42n7(Jul 2009)pp27-32
    4. =POLL 235 ENTERPRISES SQA ARCHITECTURE MODELS INSPECTION WALKTHROUGH
    5. Excellent summary of ways of ensuring design quality and addressing architectural concerns -- not all of them popular.
    6. Common techniques: Scenarios, Experience, and prototyping. Less common: check lists, metrics, simulation, questionaires, mathematics
    7. Documenting architectures: modeling notations, views, features, assumptions and constraints, ...
    8. Inputs: (commonest first) requirements, descriptions, business drivers, standards, ...
    9. Stakeholders -- various

    Babinetal91

    1. Gilbert Babin & Francois Lustman & Peretz Shoval
    2. Specification and Design of Transactions in Informations Systems: A Formal Approach
    3. IEEE SE-V17n8(Aug 1991)pp815-829
    4. CR9303-0181
    5. QV Lustman94
    6. dataflows vs control_data_flows & FSM

    Bach95

    1. James Bach
    2. Enough about process: What we need are heroes
    3. IEEE Software Magazine V12n2(Mar 1995)pp96-98+replies IEEE Software Magazine V12n3(May 1995)p5-7 [Bach9?]
        "Heroism means going beyond the borders of the known world and returning with new knowledge or wealth[...]sustainable, healthy sort of heroism requires judgement to know how much commitmment and risk is right for the situation. The movement towards process in our industry is an understandable reaction against pathological heroism: heroism for its own sake, in which overcommitment and uncontrolled risk-taking is the norm."

        p97: "The 'cowboy' or 'big magic' model. In this view, gifted people create software through apparent magical means, with no particular guidance or support"

        Can integrate process and heroism by taking a people centred view and seeing software production as a dynamic, complex, etc. system for solving problems.

        Reply: John Henry or Pecos Bill, trial by cold pizza,...


    Bach97

    1. James Bach
    2. Good Enough Quality: Beyond the Buzzword
    3. IEEE Computer Magazine V30n8(Aug 1997)pp96-98
    4. =ESSAY QUALITY ECONMICS MS-PROCESS
    5. rational choices of what to fix now
    6. GEQ::="Good Enough Quality"

    Bach9?

    1. James Bach
    2. Process Evolution in a Mad World
    3. Borland International Internal Report (100 Borland Way Scots Valley CA 96066) [Bach95]
        (for chaos)Leadership->Risk Management->Process Control(for order)

        Risk management - prevent failure vs Goals - maximize success

         Risk{identification<=>planning<=>resolution}.
                 V^             V^            V^
         Goal setting<=>Task Planning<=> Task completion

        Risk based evolution.

      1. (riskbased1): absolutely necessary - to handle perceived risk
      2. (riskbased2): make it tolerant
      3. (riskbased3): small informal experiments first
      4. (riskbased4): frequent evaluation
      5. (riskbased5): find a champion
      6. (riskbased6): work with the team
      7. (riskbased7): mentor, not a manuaal
      8. (riskbased8): "formalize" only when necessary
      9. Example Bug reviews. 50..100 bugs per day. 30 bugs an hour.

    BachleKirchberg07

    1. Michael Bachle & Pauk Kirchberg
    2. Ruby on Rails
    3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp105-108
    4. =DEMO RUBY ROR TECHNICAL WEB PLATFORM RAPID PROTOTYPING MVC
    5. Also compares with Apache Struts, Tapestry, Cocoon, and ASP.NET

    Bachman69

    1. Charles Bachman
    2. Data Structure Diagrams
    3. Data Base Journal ACM SIGDBP v1 n2 (?? 1969)pp4-10
    4. =DEMO GRAPHIC DATA Reality

    Bachman73

    1. Charles Bachman
    2. The Programmer as Navigator
    3. Commun ACM v16 n11 Nov73 pp653-658
    4. =ESSAY data

    Bachman92

    1. Charlie Bachman
    2. New Apps Must be Model-Driven:Business Needs Steer Changes to Tech Model
    3. Software Magazine Debate (Mar 1992)p52

    Backhouseetal89

    1. Roland Backhouse & Paul Chisholm & Grant Malcolm & Erik Saaman
    2. Do-it-yourself Type Theory
    3. Formal Aspects Comput V1n1 (Jan-Mar 1989)pp19-84
    4. =theory structures Reality

    BaclawskiIndurkhya94

    1. Kenneth Baclawski & Bipin Indurkhya
    2. The Notion of Inheritance in object-oriented programming(Letter)
    3. Commun ACM V37n9(Sep 1994)pp118-119

      [Grosberg93] [ArnoldK94] (C++ advice)


        refers to debate over meaning of inheritance:
      1. Abrahams's 91 letter "Subject: Objectivism"
      2. Lalonde & Pugh JOOP 91 "subclassing <> subtyping <> is-a"
      3. Tesler's 91 CACM letter
      4. Wegner 80 pages in 90 OOPS messenger
      5. Winkler 92 letter refers to POV vs COV in Winkler's letter Quotes Wegner 90
      6. POV = Physical & COV = Conceptual Piaget: Child constructs idea of object permanence from its own actions on the objects.

        Class of objects without actions<>class of objects with some actions.

        Failure to find epistomological foundations of the IS-A link - six different generic-generic and four kinds of generic-individual relation

        "The point here is that the concepts in the real world, which programs attempt to model, do not come in neatly packaged hierarchies." (cf GoldsteinAlger92)

        "There are no standard conceptual hierachies. Given a domain and a specific PURPOSE, certain concept hierarchies would be clearly preferable than others, but such policy decisions are best left to the USER of the programming language[...] What a PL provides is a set of mechanisms [...] restrict what can be implemented[but] they do not themselves validate some view of inheritance or other[...]" these are also just implemented concepts and do not not have a universal objective meaning....upto the designers to choose suitable mechanisms.


    BackusEtAl63

    1. Backus, J. W. & Bauer, F. L. & Green, J. & Katz, C. & McCarthy, J. & Perlis, A. J. & Rutishauser, H. & Samelson, K. & Vauquois, B. & Wegstein, J. H. & van Wijngaarden, A. & Woodger, M Pete Naur(ed)
    2. Revised report on the algorithm language ALGOL 60
    3. Commun ACM V6n1(Jan 1963)pp1-17 [ 366193.366201 ]
    4. =CLASSIC =DEFINITION ALGOL 60 LANGUAGE BNF SYNTAX SEMANTICS TECHNICAL

    BaeckerMarcus90

    1. R M Baeker & A Marcus
    2. Human Factors and typography for More Readable Programs
    3. ACM Press 1990
    4. Readability QUALITY Readability Technical

    Baetan90

    1. J C M Baetan(Ed)
    2. Applications of Process Algebra
    3. Cambridge U Press Cambridge UK & NY NY 1990
    4. =Theory nonsequential algebra CSP CCS ACP
      1. problem with informal semantics in POOL pp172-236(Frits W Vaandrager)
      2. fairness and liveness [p13 of Baetan90 by J A Bergstra &J W Kop]
      3. ultrametric [p9 of Baetan90 by J A Bergstra &J W Kop] :. all guarded recursion equations without abstraction have a unique solution.
      4. process creation can be simulated. pp81-88 of Baetan90 by J A Bergstra )
      5. Process Algebra is a better model than CSP/CCS for concurrency.
      6. Relations are a basic process algebra pp1-22(J A Bergstra &J W Kop) but without <*>

    Baetan08

    1. Joe C M Baetan
    2. Calculating with Automata
    3. Montanari Festschrift [DeganoEtAl08] pp746-756
    4. =EDUCATION THEORY ALGEBRA EQUATIONS AUTOMATA GRAMMARS KLEENE REGULAR EXPRESSIONS
    5. Demonstrates that most of standard theory can be taught using equations.

    Baggi05

    1. Denis L Baggi
    2. An IEEE Standard for Symbolic Music
    3. IEEE Computer Magazine V38n11(Nov 2005)pp100-102
    4. =REPORT MUSIC STANDARD P1599 XML MEI RM0
    5. P1599::= See http://www.computer.org/portal/pages/ieeecs/communities/standards/1599/par.html
    6. MusicXML::= See http://www.recordare.com/xml.html

    BaggiHaus09

    1. Denis Baggi & Goffredo Haus
    2. IEEE 1599: Music encoding and interaction
    3. IEEE Computer Magazine V42n3pp84-87
    4. =ADVERT =STANDARD IEEE-1599 MUSIC AUDIO VISUAL NOTATION GAME JAZZ Blues XML
    5. IEEE1599::DTD= See http://standards.ieee.org/downloads/1599/1599-208/
    6. Example: <clef type="G" staff_step="2" event_ref="c1"/>
    7. Previous report [Baggi05]

    Bagrodia89

    1. Rajive Bagrodia
    2. Synchronisation of Asynchronous Processes in CSP
    3. ACM Trans Prog Lang Syst V11n4(Oct 1989) pp585-597
    4. =THEORY Technical non-sequential

    BahsounMerzServieres93

    1. Jean Paul Bahsoun & Stephan Merz & Corinne Servieres<all@irit.fr>
    2. A Framework for Programming and Formalizing Concurrent Objects [Notkin93] pp 126-137
    3. =THEORY non-sequential objects TLA
        The conjunction of the single agent's specifications plus some axioms representing the communication structure.

      1. messages::=${ sender, destination::agent, mode::modes, type::message_types, parameters::vector, ...}.

        Two modes: asynchronous- after sending the sender does not wait, semi-synchronous - the sender will not send a message of the same type to the same receiver before the first message has been acknowledged by the receiver.

        Assumes arbitrary delays and that messages can get out of order.

        TLA formalization via send[a](M)::=net:| a><M.... Conclusions Now need to investigate inheritance. must spec both components and protocols...


    BaierHaverkortHermansKatoen03

    1. Christel Baier & Boudewijn Haverkort & Holger Hermans & Joost-Pieter Katoen
    2. Model-checking algorithms for continuous-time Markov Chains
    3. IEEE Trans Software Engineering V29n6(Jun 2003)pp524-541
    4. =THEORY MATHEMATICS MODEL CHECKING CTMC CSL RELIABILITY CTL
    5. CSL:="Continuous Stochastic Logic". Steady state + path probabilities in time intervals. Modes P[event] <=> p. Nested. Generalizes CTL.
    6. CTMC::="continuous time Markov chains". P(i -> j fires after t) = c*exp( -rate*t) iff it is first.

    BaierEtAl07

    1. Christel Baier & Lucia Cloth & Boudewijn R Haverkort & Mathias Kuntz & Markus Siegle
    2. Model Checking Markov Chains with Actions and State Labels
    3. IEEE Trans Software Engineering V33n4(Apr 2007)pp209-224
    4. =THEORY MODEL CHECKING REAL TIME MARKOV CHAINS PROBABILITY LOGIC asCSL
    5. Logic + model design for verifying requirements that a given pattern of actions and states (and time limits) has a given range of probabilities.
    6. Example requirement: the probabillity of entering a full state via a number of arrive actions within 5 time units must be greater than or equal to 99%.
    7. Defines products of chains.
    8. Cellular phone hand over model.
    9. experiment with tool.

    BaierKatoen08

    1. Christel Baier & Joost Katoen
    2. Principles of Model Checking
    3. The MIT Press Cambridge MA (2008) ISBN 026202649X CR 0912-1115
    4. =TEXT =THEORY MODEL CHECKING MODAL LOGICS FSM LTL CTL CTL* TCTL BISIMULAION OBDT MARKOV PCTL PCTL*
    5. Excellent and thorough text book suitable for graduate Computer scientists or some final year undergraduates
    6. A large in depth reference to the theory of the most successful formal methods - so far.
    7. Does not use the normal syntax for modes but uses ∀ and ∃. So doesn't fit some tools.
    8. Does not use standard terminology.
    9. Does include newer topics and types of models.

    BaierHaverkortHermansKatoen10

    1. Christel Baier & Boudewign R Haverkort & Holger Hermans & Joost-Pieter Katoen
    2. Performance Evaluation and Model Checking Join Forces
    3. Commun ACM V53n9(Sep 2010)pp76-85 [ 1810891.1810912 ]
    4. =HISTORY MODEL CHECKING PERFORMANCE MODAL PROBABILLITY LOGIC CTL LTL PCTL DTMC ADVERT TOOLS PRISM EXAMPLES
    5. Excellent diagram of history starting with Markov Chains in 1900 and ending with advanced algorithms and applications.
    6. Figure 3: IPv4 zeroconf protocol
    7. Example -- able to show that Firewire root contention protocol is faster when biased "coin tossing" is used.

    BaikBoehmSteece02

    1. Jongmoon Baik & Barry Boehm & Bert M Steece
    2. Disaggregating and Calibrating the CASE Tool Variable in COCOMO II
    3. IEEE Trans Software Engineering V28n11(Nov 2003)pp1009-1022
    4. =EMPIRICAL Bayesian STATISTICAL MODEL COST TOOLS COCOMO CMM
    5. Proposes new rating scales for the quality of a CASE Tool and calibrates them on 15 projects.
    6. New measures improved model by about 70%.
    7. New scales: tool coverage(TCOV), Tool integration(TINT), tool maturity/user support(TMAT).
    8. All 3 new measures are important.

    Bailin89

    1. SC Bailin
    2. An Object-Oriented Requirements Specification Method
    3. Commun ACM v32n5(May 1989)pp608-623 [ 63485.63491 ]
    4. =IDEA OBJECTS ERD DFD Reality PURPOSE TECHNICAL SRS

    Baines98

    1. Robin Baines
    2. Across Disciplines: Risk, Design, Method, Process, and Tools
    3. IEEE Software magazine V15n4(Jul/Aug 1998)pp61-64
    4. =EXPERIENCE PEOPLE ENGINEERING
    5. Compare your software people's activities with other engineers in your company

    Baker93ab

    1. Steven Baker
    2. Net Worth Column
    3. Unix Review (Jun 1993)pp23-37 & (Jul 1993)pp25-34
    4. =HISTORY STANDARDS MIME EMail Multimedia SGML richtext RTF

    Baker97

    1. Richard A Baker Jr
    2. Code Reviews Enhance Software QUALITY [ICSE'97]
    3. When technical managers reveiw their subordinates code errors drop by 40% at a cost of <2%. Like by those being reviewed - manager cares and knows our work.

    BakerB07

    1. Brenda S Baker
    2. Finding clones with Dup: Analysis ofan experiment
    3. IEEE Trans Software Engineering V33n9(Sep 2007)pp608-621
    4. =EXPERIMENT TOOLS COPYPASTE DRY SOURCE Dup
    5. Also see [BellonEtAl07]

    BakerHoekOssherPetre12

    1. Alex Baker & Andres van der Hoek & Harold Ossher & Marian Petre
    2. Studying Professional Software Design
    3. IEEE Software Magazine V29n1(Jan/Feb 2012)pp28-33
    4. =HISTORY REPORT WORKSHOP DESIGNERS WORKING
    5. Bibliography [ MS.2011.155 ]
    6. Quotes known observations:
      1. Little exploration of alternatives.
      2. Their is no linear process and no design phase.
      3. Whiteboards and other transient media are prevalent in design work.
      4. Notations are informal but not unlike the formal ones.
      5. Experts tend to start by studying the problem and understand how to decompose problems and select the next subproblem to work on.
      6. Designers have strategies but make provisional decisions to allow future options.
      7. Designers try different topics vs the problem.
      8. Experts tend to use local planning and gather feedback rather than analysing requirements.
      9. Process emerges opportunistically not preplanned. But is a mixture of depth and breadth first solution development.
      10. The more familiar the problem, the fewer options are considered.

    7. Introduces results of the workshop:- [NakakojiYamamotoMatsubaraShirai12] [DimaghaniDibble12] (Oracle) [Shaw12] [RooksbyIkeya12]

    BakerLevin83

    1. Stephen Baker & Arnie Levin
    2. I hate Meetings
    3. Macmillan NY 1983 ISBN0-02-506370-7
    4. = JOKES PEOPLE MANAGEMENT MEETINGS
    5. Good explanation why people hate meetings.
    6. Confirms purpose of meetings: too spread the blame/responsibility widely.
    7. Chapter 8: good field guide to problem people from the chair's point of view: Speech maker, Yawner, Bottom liner, Devil's advocate, Early leaver, late-comer.

    BalakrishnanFitzmaurice Kurtenbac.h01

    1. Ravin Balakrishnan & George W Fitzmaurice & Gordon Kurtenbac.h
    2. user interfaces for volumetric displays
    3. IEEE Computer Magazine V34n3(Mar 2001)pp37-45
    4. =ARTICLE NEW HCI 3D GRAPHIC hardware
    5. pinch, twist, slice, & crush that display!

    Balasubramanianetal95

    1. V Balasubramanian & Bang Min Ma & Joonhee Yoo
    2. A Systematic Approach to Designing a WWW Application
    3. Commun ACM V38n8(Aug 1995)pp47-48
    4. RMD::=Relational Managemnt Data (diagram) with slicing

    BalasubramianEtal06

    1. Krishnakuma Balasubramian & Aniruddh Gokhale & Gabor Karsai & Janos Sztipanovits & Sandeep Neema
    2. Developing applications using model-driven design environments
    3. IEEE Computer Magazine V39n2(Feb 2006)pp33-40 =DEMO MDD not MDA GME PICML ECSL DOMAIN MODEL LANGUAGES DSML
    4. DSML::="Domain-Specific Modeling Language".
    5. MIC::="Model-Integrated Computing".
    6. Models replace programming languages, and each application domain has customized modeling languages.
    7. GME:="Generic modeling environment", Vanderbilt University [ gme ]
    8. PICML::="Platform independent component modeling language".

    Baldwin92

    1. Doug Baldwin
    2. Using Scientific Experiemnts in Early Computer Science Laboratories
    3. ACM 23rd SIGCSE technial Symposium SIGCSE Bulletin V24n1(Mar 1992)pp102-106

    BaldwinChung95

    1. Reid A Baldwin & Moon Jung Chung
    2. A Formal Approach to Managing Design Processes
    3. IEEE Coputer Magazine V28n2(Feb 1995)pp54-63
    4. Process Flow Graph.... DFD like but with alternate refinements.

    BaldwinHenderson02

    1. Doug Baldwin & Peter B Henderson
    2. The Importance of Mathematics to the Software Practitioner
    3. IEEE Software Magazine V19n2(Mar/Apr 2002)pp112+110-111
    4. =ESSAY MATH
    5. Response to article by Robert Glass 2000.
    6. Good School math correlates with good scores in freshman programming even tho' there was little explicit math in the programming classes.
    7. Although programmers do not find much use for the calculus [Lethbridge00] , modest use of simple math combined with other good practices reduces defects [LarsonFitzgeralBrooks96] and/or bugs [PfleegerHatton97].
    8. For more see [ relevance.html ]

    BallCrawford99

    1. Steve Ball & John Miller Crawford
    2. Are Java Applets Independent Programs?
    3. Dr. Dobb's n298(Apr 1999)pp101-104+105
    4. =DEMO TECHNICAL JAVA RISK
    5. Classwide fields are shared between all applets of a given type. Shows how to have one field per applet.

    Ballanceetal90

    1. Robert A Ballance & Susan L Graham & Michael L Van De Vanter
    2. The Pan Language-Based Editing System for Integrated Development Environments
    3. SIGSOFT'90 pp77-93
    4. p85 Logic programming

    BallEick96

    1. Thomas Ball(mailto:tjball@bell-labs.com) & Stephen G Eick(mailto:eick@bell-labs.com)
    2. Software Visualization in the Large
    3. IEEE Computer Magazine V29N4(Apr 1996)pp33-43
    4. =DEMO colored graphic technical source code

    BallLarus00

    1. Thomas Ball(microsoft) & James R Larus(microsoft)
    2. Using paths to measure, explain, and enhance program behavior
    3. IEEE Computer Magazine V33n7(Jul 2000)pp57-65
    4. =SURVEY TECHNICAL GRAPH PERFORMANCE CORRECTNESS
    5. maximal acyclic control paths. hot paths.

    BalsamoMarcoInveradiSimeoni04

    1. Simonetta Balsamo & Antinisca Di Marco & Paola Inveradi & Marta Simeoni
    2. Model-Based Performance Prediction in Software Development: A Survey
    3. IEEE Trans Software Engineering V30n5(May 2004)pp295-310 CR 0504-0464
    4. =SURVEY MODEL QUALITIES PERFORMANCE 15 METHODS UML ALGEBRA QN Petri
    5. Nearly all methods us UML and QN
    6. QN::=Queuing Networks.
    7. Most are highly automated and focus on software architecture and software design.

    Balsters03

    1. Hermann Balsters
    2. Modeling database views with derived classes in the UML/OCL-framework
    3. LNCS 2863 <<UML>> 2003 -- The Unified Modeling Language Oct 2003, pp295-309
    4. =IDEA MODEL DATA VIEWS RELATIONAL DB RDB OCL
    5. Introduces derived classes with names like /Emp2

    Bamberger97

    1. Judy Bamberger(bamberger@eaglet.rain.com)
    2. Essence of the Capability Maturity Model
    3. IEEE Computer magazine V30n8(Jun 1997)p112-114
    4. =REPORT IMPROVEMENT CMM

    BamfordDeibler93

    1. Robert C Bamford & William J Deibler II
    2. Comparing & contrasting ISO9000 and the SEI capability maturity model
    3. IEEE Computer magazine v26n10(Oct 1993)pp68-70

    BamfordDeibler03

    1. Robert Bamford & William J Deibler
    2. ISO 9001;2000:for software and systems providers: an engineering approach
    3. CRC Press Boca Raton FL 2003 ISBN 0849320631 CR 0511-1193
    4. =REFERENCE ENGINEERING QUALITY STANDARD

    BanatreLeMetayer93

    1. Jean-Pierre Banatre & Daniel Le Metayer
    2. Programming by Multiset Transformation
    3. Comm ACM V36n1(Jan 1993)pp98-111
    4. Concurrent nondeterministic repeated local operations
    5. GAMMA=General Abstract Model for Multiset mAnipulation
        In MATHS |-For Type T, bag(T) ::=Nat0^T. |-For Type T, t:T, bag(t) ::=t+>1|+> 0.
      1. For Type T, n:Nat, x:T^n, bag(x)::= +(bag o x).
      2. For Type T, B:bag(T), B:@T::={t:T||B(t)>0}. For T:Type, n:Nat, X:=T^n, reaction:=(@^X)><(T^X), RA:finite_set(reaction), S:variable(bag(T)),
      3. Γ(RA)::=
      4. do with(x:T^n, (R,A) :RA) (
      5. x in R&S and S'=S-bag(x)+bag(A(x))
      6. ).


    Bandinelietal95

    1. sergio Bandineli & Alfonso Fuggetts & Luigi Lavazza & Maurizio & Gain Pietro Picco
    2. Modeling and improving an Industrial Software Process
    3. IEEE Trans Software Engineering V21n5(May 1995)pp440-453
    4. =EXPERIENCE PROCESS MODEL
    5. when improving a process you need to check the official process against the reality. Also the official process may be described in terms that are ambiguous. FSMs and Petrie nets can be used to uncover ambiguities and iaccuracies in the official process. Further they can lead to the discovery of simple and effective improvements in the process.

    BandiVaishnaviTurk03

    1. Rajendra K Bandi & Vijay K Vaishnavi & Daniel E Turk
    2. Predicting Maintenance Performance Using Object-Oriented Design complexity metrics
    3. IEEE Trans Software Engineering V29n1(Jan 2003)pp77-87
    4. =EXPERIMENT Object-Oriented METRICS MAINTENANCE EMPIRICAL ANOVA
    5. Three metrics: interaction level (IL), Interface size (IS), and Operation Argument Complexity (OAC)
    6. Two tasks, one perfective and the other corrective maintenance.
    7. 93 students 5 sections, GPA 3.5, 14 credits of CIS work.
    8. tested for difference due to complexity, instructor and quarter.
    9. Complexity had a significant effect on maintenance time.
    10. Correlation indicates significant positive linear relations between each metric and maintenance time. But R^2 is only 12-25%

    BaniassadEtal06

    1. Elisa Baniassad & Paul C Clements & Joao Araujo & Ana Moreira & Awais Rashid & Bedir Tekinerdogan
    2. Discovering Early Aspect
    3. IEEE Software Magazine V23n1(Jan/Feb 2006)pp61-70
    4. =IDEA ASPECTS REQUIREMENTS ARCHITECTURE
    5. See [ http://www.early-aspects.net ]
    6. An aspect is a property that cuts across the dominant decomposition.
    7. In requirements, aspects constrain many scenarios.
    8. In architecture, aspects cut across many views.

    Bankeretal93

    1. Rajiv D Banker & Srikani M Datar & Chris F Kemerer & Dani Zweig
    2. Software Complexity and Maintenance Costs
    3. Comm ACM V36n11(Nov 1993)pp81-94
    4. Maintenance Time increased by larger modules & larger paragraphs & "bad" GOTOs

    BankerKemerer89

    1. Rajiv D Banker & Srikani M Datar & Chris F Kemerer
    2. Scale Economies in New Software Development
    3. IEEE Trans Soft Eng VSE-15n10(Oct 1989)pp1199-1205 [ TSE.1989.559768 ]
    4. =THEORY ONESIZE
    5. Argues work=a+size^b is false because b varies giving a "most productive scale size" that "varies widely accross different application environments"

    BansiyaDavis02

    1. Jagdish Bansiya & Carl G Davis
    2. A Hierarchical Model for Object-Oriented Design Quality Assessment
    3. IEEE Trans Software Engineering V28n1(Jan 2002)pp4-17
    4. =EMPIRICAL QUALITIES METRIC OBJECT QMOOD C++ TOOL QMOOD++ MFC OWL MSWINDOWS FRAMEWORKS COOL
    5. Evaluated a set of metrics of two frameworks (MFC, OWL) over several releases.
    6. Ranked 13 COOL projects by hand and by QMOOD++ and found 0,4..0.9 correlation.

    BanslerBoedker93

    1. Jorgen P Bansler & Keld Boedker
    2. A Reappraisal of Structured analysis: design in an organisational context
    3. ACM Trans Inf Syst V11n2(Apr 93)pp165-193, CR9402-0096
    4. =POLL THEORY VS PRACTICE SA/SD Yourdon DeMarco DFD
    5. SA treats people as machines and so ignores errors creativity politics, assumes all problems have been stated, rational designer, separation of function from implementation
    6. small survey interviewing successful SA/SD.
    7. people use tools not the rules. DFDs and ERDs. prototypes, screen layout
    8. Abstract:
        "This study reveals that while some of the tools of Structured Analysis - notably data flow diagrams - are used and combined with other tools, the designers do not follow the analysis and design procedures prescribed by the method"

    Bar-David93

    1. Tsvi Bar-David
    2. Object-oriented design for C++
    3. Prentice Hall Englewood Cliffs NJ 1993
    4. CR9312-0913 D.1.5
        Mathematical treatment Appendix A: Barbara Liskov's "Data abstraction and Hierarchy" OOPSLA87

    Barber90

    1. Thomas Walter Barber, engineer
    2. The Engineer's Sketch-Book of mechanical movements, devices, appliances, contrivances, and Details
    3. Spon London UK and NY NY 1890 (2nd edn) [ books?id=sExDAAAAIAAJ&printsec=frontcover&dq=%22Thomas+Walter+Barber%22&source=bl&ots=TO7N5WG9MV&sig=4LXrUsWlKGYmqQ84S6DUiPxjVHw&hl=en&ei=K0mRS8bAOoj8sgO6zf38Aw&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBUQ6AEwBA#v=onepage&q=&f=false ]
    4. =CLASSIC =HANDBOOK MECHANICAL ENINEERING PATTERNS
    5. Extensive review and historicalresearch [ twb.html ]
    6. Sample [ EngineersSketchBookP49.gif ] (Page 49).

    BarbierEtal03

    1. Franck Barbier & Brian Henderson-Sellers & Annig Le Parc-Lacarelle & Jean-Michele Bruel
    2. Formalization of the Whole-Part Relationship in the Unified Modeling Language
    3. IEEE Trans Software Engineering V29n5(May 2003)pp459-470 Reviewed CR 0409-1078 and 0409-1079
    4. =PROPOSAL Object-Oriented MODEL STANDARD aggregation composition whole-part bibliography UML OCL MetaModel OML OPEN Diamonds
    5. careful philosophical analysis of semantics of whole-part. some confused "common logic" and much OCL.
    6. Defines a new dotted diamond whole-part Relationship with specialization of aggregation and composition.
    7. Introduces new stereotypes to indicate OCL constraints on the UML MetaModel.
    8. Will it make it into UML4.0?
    9. Correspondence
      1. IEEE Trans Software Engineering V29n11(Nov 2003)pp1054-1056
      2. "On formalization of the whole-part relationship in the unified modeling Language" by Hee Beng Kuan Tan & Lun Hao & Yong Hang corrects discrepancies,
      3. "Controversies about the Black and White Diamonds" by Frank Barbier & Brian Henderson-Sellers" responds by changing name of "antisymmetry", accepting new formula for "transitivity", and agreeing to minor correction in a proof. Regrets the absence of "scientific" review of UML specifications.


    BarbosaCostaAlmeidaAlameida04

    1. Marcello W Barbosa & Mellssa M Costa & Jussara M Almeida & Virgilio A P Alameida
    2. Using Locality of reference to improve performance of peer-to-peer applications
    3. WOSP'04 & ACM SIGSOFT Software Engineering Notes V29n1(Jan 2004)pp216-227
    4. =SIMULATION P2P NET PERFORMANCE DATA LOCATION QoS Freenet Gnutella
    5. claims 20..30% decrease in latency with no added load on network by knowing which node might have the data.

    BaresiOrsoPezze97

    1. Luciano Baresi & Alessandro Orso & Mauro Pezze
    2. Introducing Formal Specification Methods in Industrial Practice [ICSE'97]
    3. need to develop special languages and notations fr each set of clients therefore a customizable system. Uses hypergraph grammars and kernel of petri nets

    BaresiPezze98

    1. Luciano Baresi & Mauro Pezze
    2. Toward Formalizing Structured Analysis
    3. ACM ToSEM V7n1(Jan 1998)pp80-107
    4. =ANALYSIS STRUCTURED METHOD SA/RT
    5. issues to be resolved before choosing a formal model for Hatley-Pirbhai SA for Real Time systems

    Barjis08

    1. Joseph Barjis
    2. The importance of business process modeling in software systems design
    3. Science of Computer Programming V71n1(Mar 2008)pp73-87 [ science $CR 0906-0558 ]
    4. =ADVERT METHOD THEORY MODEL DEMO LANGUAGE-ACTION PETRI GRAPHIC ANALYSIS REQUIREMENTS SCENARIOS Keywords: Requirements specifications; Model checking; Business process modeling; Business process simulation;
    5. DEMO::="Design & Engineering Methodology for Organizations", [ http://www.demo.nl/ ]
    6. Special colored Petri nets show logic. Can be simulated to show clients what is possible.
    7. Analyze business processes in terms of the language-action cycle as expressed as Transactions between parts.
    8. Transaction::=Order; Execution; Result.
    9. Order is a transition from initiator to executor. It sets up a contract for the executor to carry out.
    10. Result is a transition from executor to initiator. It completes the contract.
    11. Execution is executed by the executor and can initiate further transactions with others.

    Barlas96

    1. Stephen Barlas
    2. Anatomy of a Runaway: What Grounded the AAS(Advanced Automation System)
    3. IEEE Software Magazine V13n1(Jan 1996)pp104-106
    4. Failure of a 10 year life-cycle at edge of technology at start with 99.99999% reliability and dynamic loose REQUIREMENTS [Barlas96a]

    Barlas96a

    1. Stephen Barlas
    2. FAA Shifts Focus to Scaled-Back DSR
    3. IEEE Software magazine V13n3(Mar 1996)pp110+114

      [Hall96a]

      [Barlas96]

      [KlosterZellweger87]

    BarnardPrice94

    1. Jack Barnard & Art Price
    2. Managing Code Inspection Information
    3. IEEE Software magazine v11n2(Mar 1994)pp59-69
    4. =EXPERIENCE QUALITY control of SQA

    Barnesetal91

    1. Bruce H Barnes & Terry H Bolinger
    2. Making Reuse Cost-Effective
    3. IEEE Software v6n1(Jan 1991)pp13-24

    BarnettEtAl11

    1. Mike Barnett & Manuel Fahndrich & K Rustin M Leino & Peter Muller & Wolfram Schulte & Herman Venter
    2. Specification and Verification: the Spec# Experience
    3. Commun ACM V54n6(Jun 2011)pp81-91 [ 1953122.1953145 ]
    4. =ADVERT CONTRACTS MICROSOFT C# .NET IDE SPECIFICATION LANGUAGE Spec# TOOLS PRECONDITIONS POSTCONDITIONS INVARIANTS Boogie CCI Z3 PROOFS Spec#
    5. Planned to hide the proofs from the programmers!
    6. Contracts written in the programming language.
    7. Display contract as a tool-tip on a call.
    8. Treat static mismatched conditions as if they were syntax errors.
    9. Distinguishes between pointers and guaranteed non-null pointers.
    10. Provide static and dynamic checking of conditions.
    11. Can supply many loop invariants automatically.
    12. To be useful it must be integrated into a real language and IDE.

    Barnhart95

    1. Andy Barnhart
    2. Let's Get Stupid
    3. Software Development Mag V3n3(Mar 1995)pp63-67.
    4. =ESSAY TECHNICAL
    5. advantages for going for the obvious simple solution that works.
    6. problems with inspired brilliant solutions.
    7. The algorithm that suddenly starts to work when you are playing with it and you don't know why.
    8. Documenting Magic.

    Barnhart99

    1. Andy Barnhart
    2. Wrapping COBOL Business Logic in Java
    3. Software Development Mag V7n10(Oct 1999)pp41-45.
    4. =EXPERIENCE TECHNICAL COBOL JAVA GUI LEGACY
    5. MARS UK RLSCOM Telco marketting cellular air time

    Barrett87

    1. Geof Barrett
    2. Formal Methods Applied to a Floating Point Number System
    3. Technical Monograph 58 PRG Oxford 1987
    4. =EXPERIENCE PROOF Floating-point operations STANDARD
        used Hoare/Floyd-style proofs to prove that Inmos' software floating-point package satisfied its specification, a Z-ified version of the IEEE-754 standard. This software fp package was the starting point for the formally-derived microcode for the FPU in the Inmos T800 transputer. This was certainly a real-world application; moreover, the formal approach overtook the informal approach, and in the process they found an inconsistency and an ambiguity in the IEEE standard, and a bug in a competitor's chip. Inmos and the PRG (Oxford) were awarded a Queen's Award for Technological Achievement for the T800 project.

        Includes Floating point IEEE TSE paper -- where is it?


    Barrett95

    1. Geof Barrett
    2. Model Checking in Practice: The T9000 Virtual Channel Processor
    3. IEEE Trans on Software Eng VSE-21n2(Feb 1995)pp69-78
    4. =EXPERIENCE SQA INSPECTIONS MODEL CHECKING FORMAL NOTATIONS STD CSP Z English
    5. Sometime implementation was correct when the spec was wrong
    6. Easier to show what can happen than to show that something can not happen
    7. Problem with notation(CSP) - "completely alien" to people used to STDs.
    8. Quote: "Must base our tools on familiar notations and understand the obstacles...this means that visual specifications have to be used as much as possible."
    9. Using multiple notations. STDs+Z+English.
    10. Using checker for finite sequences.
    11. Need an unusual combination of engineering, mathematical and programming skills

    BarryStanienda98

    1. Douglas Barry Torsten Stanienda
    2. Solving the Java Object Storage Problem
    3. IEEE Computer magazine V31n11(Nov 1998)pp33-40
    4. =DEMO TECHNICAL JAVA JDBC ODMG persistence SQL

    Basili90

    1. Victor R Basili
    2. Viewing Maintenance as Reuse-oriented Software Development
    3. IEEE Software V7n1(Jan 1990)pp19-25
    4. System Technical

    Basili95

    1. Victor Basili(interviewed)
    2. Finding an Experimental Basis for Software Engineering
    3. IEEE Software Magazine V12n3(May 1995)pp92-93
    4. =ADVERT EMPIRICAL GQM QUALITIES EXPERIMENTS PROCESS IMPROVEMENT EXPERIENCE
    5. The Software Engineering Laboratory
    6. Goal/Question/Metric paradigm
    7. QUALITY Improvement Paradigm
    8. A separate Experience Factory

    9. "The process is a variable to be manipulated"
    10. "You can't just hand developers a tool or a method and walk away[...]be there as a resource,[...]supply cost models[...]types of defects[...]uncovering that class of defects[...]"

    11. ISERN::=International Software Engineering Research Network.
    12. Also see [Basili95a]

    Basili95a

    1. Victor Basili
    2. The Experience Factory and its Relationship to Other Quality Approaches
    3. Advances in Computers V41(1995)pp66-82
    4. =EMPIRICAL QUALITY IMPROVEMENT EF/QIP vs PDCA:=Plan_Do_Check_Act + TQM + SEI CMM
    5. Also see [Basili95]

    BasiliBriandMelo96

    1. Victor R Basili & Lionel C Briand & Walcelio L Melo
    2. How Reuse Influences Productivity in Object-Oriented Systems
    3. Comm ACM V39n10(Oct 1996)pp104-116
    4. =experiment OMT Gnu C++ OSF/Motif
    5. significant benefits in defect density rework and productivity

    BasiliDonzelliAsgari04

    1. Victor Basili & Paolo Donzelli &Sima Asgari
    2. A Unified Model of Dependability: Capturing Dependability in Context
    3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp19-25
    4. =CASESTUDY UMD TOOL THEORY QUALITIES DEPENDABILITY TSAFE
    5. Jargon! Students simulate stakeholders?

    Basilietal95

    1. Victor Basili & Frank McGarry & Jerry Page & Sharon Waligora & Rose Pajerski
    2. SEL's Software Process-improvement Program
    3. IEEE Software Magazine(Nov 1995)pp83-87
    4. =ADVERT SPIN SEL IMPROVEMENT
    5. 20 years: 75% fewer defect+50% reduction in cost+25% reduction in cycle time while complexity increased
    6. understand; Assess&Refine;Pakage
    7. significant changes come from Cleanroom and SQA techniques not PDL/Ada/OO.

    BasiliEtAl10

    1. Victor R Basili & Mikael Lundvall & Myrna Regardie & Carolyn Seaman & Jens Heidrich & Jurgen Munch & Dieter Rombach & Adam Trendowicz
    2. Linking software development and business strategy through measurement
    3. IEEE Computer Magazine V43n4(Apr 2010)pp57-65
    4. =ADVERT GOAL QUESTION METRIC GQM+STRATEGIES
    5. GQM::= See http://en.wikipedia.org/wiki/GQM.
    6. Formalizes link between business level goals and strategies to software development goals, questions, and metrics.
    7. See previous items for Basili and GQM.

    BasiliMcGarryPajerskiZelkowitz02

    1. Victor Basili & Frank E McGarry & Rose Pajerski & Marvin V Zelkowitz
    2. Lessons learned from 25 years of process improvement: the rise and fall of the NASA software engineering laboratory
    3. ICSE24(May 2002)pp69-79 CR 0406-0749
    4. =UNREAD =HISTORY IMPROVEMENT NASA SEL
    5. Need management & staff support + focus & data.

    BasiliPerricone84

    1. Victor R Basili & Barry T Perricone
    2. Software Errors and Complexity: An Empirical Investigation
    3. Commun ACM V27n1(Jan 1984)pp42-42 + Correspondence V28n3(Mar 1985)pp322-323 (with Richard J Botting, H Dieter Rombach & Richard W Selby)
    4. =EMPIRICAL DEFECTS MODULE COMPLEXITY SIZE SEL CHANGES
    5. New application means requirements change during the project.
    6. New modules have different kinds of errors than changed modules.
    7. Module size did not account for error proneness.
    8. Intuition clashes with data.

    BasiliRombach87

    1. Victor R Basili & H Dieter Rombach
    2. Implementing Quantitive SQA: A Practical Model: Guest Editor's Intro to theme articles
    3. IEEE Software V4n5(Sep 1987)pp6-61
    4. =EMPIRICAL QUALITY

    BasinDoserLodderstedt06

    1. David Basin & Jurgen Doser & Torsten Lodderstedt
    2. Model driven security: from UML models to access control infrastructures
    3. ACM TOSEM Trans Software Eng & Methodology V15n1(Jan 2006)pp39-91
    4. =DEMO MDA MODEL SECURITY ASPECT RBAC SecureUML DIALECT Java JB2EE .NET
    5. Extends RBAC using UML metamodeling.
    6. RBAC::= Net{Users, Roles, Permissions: Sets. POSET(Roles, <=). UA:@(Users, Roles). PA:@(Roles, Permissions). AC:=UA o <= o PA.}.
    7. A user u can execute action a iff u AC a.
    8. Extend RBAC by adding a hierarchy of Actions.
    9. Shows how to generate complex & secure code by translating a UML model with SecureUML profile.

    Baskerville93

    1. Richard Baskerville
    2. Information Systems Security Design Methods: Implications for Information Systems Development
    3. Comp Surveys V25n4(Dec 1993)pp375-414 (history of systems analysis ::=check lists; mechanical; abstraction)

    BaskervilleEtal01

    1. Richard Baskerville & Linda Levine & Jan Pries-Heje & Balasubramaniam Ramesh & Sandra Slaughter
    2. How Software Companies Negotiate Quality
    3. IEEE Computer Magazine V34n5(May 2001)pp51-57
    4. =POLL MARKET TIME QUALITIES drive PROCESS ONE-SIZE
    5. toad_code::= "working code that was developed hopping fast and is ugly"

    BaskervilleEtAl03

    1. Richard Baskerville & Balasubramaniam Ramesh & Linda Levine & Jan Pries-Heje & Sandra Slaughter
    2. Is Internet-speed software development Different?
    3. IEEE Software Magazine V20n6(Nov/Dec 2003)pp70-77
    4. =COLLOQUIUM INTERNET WWW/net AGILE
    5. Answer=YES!
    6. Concurrent operation and development but no maintenance, fast releases, tools, customers in team, stable architecture, assemble and reuse components, evolve methodology, people!

    GrafLormansToetenel03

    1. Bas Graf & Marco Lormans & Hans Toetenel
    2. Embedded Software Engineering: The State of the Practice
    3. IEEE Software Magazine V20n6(Nov/Dec 2003)pp61-69
    4. =POLL 36 INTERVIEWS EMBEDDED REQUIREMENTS ARCHITECTURE MOOSE ITEA UML
    5. Hardware driven, top-down: system drives subsystem drives component. At each stage the previous architecture becomes a requirement in the next level.
    6. Stakeholders ={manufacturing, maintenance, marketing(users/consumers)}.
    7. Context = { Suppliers, standards, legacies, regulators }
    8. Requirements expressed in text using word processors and templates. Informal diagrams. Use cases from the UML. Some sequence diagrams and domain models. Pre/post conditions in programming. Only one formal specification(in Z).
    9. Managing changing requirements: spreadsheets.
    10. Architecture: vs time-to-market. Creative.
    11. Performance: design for maximum speed possible, hope, and test. UML popular with Visio and Rose. DFDs. ERDs. HatleyPirbhai.
    12. Reuse: Ad hoc.
    13. Memory, power and real time less prominent than expected.
    14. Modern methods/technologies: vs legacy systems, are too immature and complex,

    BassNordWoodZubrow06

    1. Len Bass & Robert Nord & William Wood & David Zubrow
    2. Risk Themes Discovered Through Architecture
    3. =EXPERIENCE RISK ARCHITECTURE ATAM QUALITY
    4. Tech Report CMU/SEU-2006-TR-012
    5. ATAM::="Architecture Tradeoff Analysis Method".
    6. Lists 15 Risk Theme Categories: Availability, Performance, security, modifiability, integration, process and tools, requirements, allocation, documentation, Big Picture, Unrecognized needs, product lines, awareness, scope, coordination.
    7. Claims 99 risk themes.
    8. Reference to Boeing experience with ATAM and Charette's failure causes.
    9. Relation to business goals.
    10. Importance of "Performance" .
    11. No evidence that risks are independent of domain. One size does not fit all.
    12. Risks of commission and Omission. Omission more common.
    13. Odd fact: security was always a risk of omitting to do something.

    Bassett94

    1. Paul Bassett
    2. Reusability: You Reap What You Sow
    3. Software Magazine(Sep 1994)pp110-109
        Need to rethink the whole process rather than putting in special reuse patches... 10 possibile benfits:
      1. productivity, quality, flexibility, performance, portability, standards, hidden complexity, compatibility, reduced maintenance, evloution of common parts.

    Bastanied93

    1. Farokh Bastani
    2. Special Issue on Software Reliability
    3. IEEE Trans on Software Eng VSE-19n11(Nov 1993)pp1013-1118

    BastenSunyaev11

    1. Dirk Basten & Ali Sunyaev
    2. Guidelines for software Development Effort estimation
    3. IEEE Computer V44n10(Oct 2011)pp88-90
    4. =SURVEY 50 EMPIRICAL PAPERS ACCURACY ESTIMATES 32 FACTORS ADVICE
    5. Make sure that the estimator includes an estimate of accuracy
    6. Collect as much information as possible -- especially similar projects
    7. Include feedback in the estimation process.
    8. Estimator must understand the technical and managerial issues.
    9. Professional developers should do their own estimates.
    10. Select estimators who can learn from feedback.
    11. Exclude optimists
    12. Make requirements precise
    13. Avoid anchors
    14. Split large classes into parts, estimate and combine
    15. Communicate frequently with clients.
    16. Get more diligence from client by staing the importance of the project.
    17. Use expertise to support inexperienced clients to get better requirements.

    BasterKonanaScott01

    1. Greg Baster & Prabhudev Konana & Judy E Scott
    2. Business Components: A Case Study of Bankers Trust Australia Limited
    3. Commun ACM V44n5(May 2001)pp92-98
    4. =CASESTUDY DOMAIN TECHNOLOGY USER COMPONENTS ARCHITECTURE MODULES Arcadia
    5. B_T_gap::= "Business-Technology Gap", a clash of subcultures.
    6. Important to get shared knowledge and resolve cultural values.
    7. Give the business users the ability to assemble applications from a repository of components.
    8. lessons learned:=following,
      1. understand the gap.
      2. understand usage patterns to minimize costly disruption.
      3. leverage user skills.
      4. Low profile and low hype.
      5. involve the detail-oriented users and allow word-of-mouth diffusion.
      6. long prototyping process.
      7. Leverage technical skills vs use skills -- technical optimize, users work out script details.
      8. Plan for reuse but not as a central focus. components evolve. user acceptance and buyin must come before reuse.

    Batoryetal95

    1. Don Batory(utexas) & Lou Coglianese & Mark Goodwin & Steve Shafer(Loral)
    2. Creating Reference Architectures: An Example from Avionics
    3. See [SamadzadehZand95]
    4. pp27-37
    5. =CASE-STUDY ADAGE REUSE GenVoca realms DOMAIN [BatorySighalSirkinThomas93] [BatorySighalThomasetal94] [ Batoryetal95.html ]
    6. Gathering simple info was the most difficult aspect.
    7. Twice the cost and effort of a single system.

    BatoryEtal00

    1. Don Batory & Gang Chen & Eric Robertson & Tao Wang
    2. Design Wizards and Visual Programming Environments for GenVoca Generators
    3. IEEE Trans Software Engineering V26n5(May 2000)pp441-452
    4. =DEMO TOOL DSL ARCHITECTURE P3 DATA PERFORMANCE JAVA JTK
    5. Containers and cursors, type equations, optimization NP-hard

      [ schwartz ]

    BatoryEtal02

    1. Don Batory & Clay Johnson & Bob MacDonald & Dale Vov Heeder
    2. Achieving Extensibility Through Product-lines and Domain-Specific Languages
    3. ACM TOSEM Trans Software Eng & Methodology V11n2(Apr 2002)pp191-214
    4. =CASESTUDY ASPECTS ARCHITECTURE GenVoca PLAs DSLS REUSE FSMs Java JavaSM
    5. Features as first-class components that cross-cut across OO hierarchies

    BatoryGeraci97

    1. Don Batory & Bart J Geraci
    2. Composition Validation and Subjectivity in GenVoca Generators
    3. IEEE Trans Softw Eng V23n2(Feb 1997)pp67-82
    4. how to verify composition rules and how to allow multiple interfaces to components

    BatorySighalSirkinThomas93

    1. Don Batory & Vivek Sighal & Marty Sirkin & Jeff Thomas<*@cs.utexas.edu>
    2. Scalable Software Libraries [Notkin93] pp191-199
    3. GenVoca [BatorySighalThomasetal94]
        Abstract: "... Libraries should not enumerate complex components with numerous features; rather, libraries should take a minimalist approach: They should provide only primitive building blocks and be accompanied by generators that can combine these blocks to yield complex data structures"

        Examples Booch C++(400 distinct DSs) and Gnu C++...

        The GenVoca Model [Bat92b: BatoryO'Malley92, "The design and Implementtion of hierarchical software systems with reusable components", ACM Trans Softw Eng Methodol October 1992] , not OOP. Layered software components.

        Analyse libg++: does not use inheritance to capture similar algorithms..

        BoochC++: 18 varieties of deques! But can not use inheritance because need to carefully integrate concurrency guards and deque algorithms.

        layered, high level, standardized abstraction

        example P1 The P2 generator: the typex statement, container cursor,...

        Results. on spell checking Decl Indep... Using Booch C++,libg++, P1,P2.... on 4 structures: Unordred linked list, unordered array, sorted array, binary tree P1 P2 had smaller LOC. P1 and P2 faster on all but sorted array.

        Modification of P1/P2 easier.

        software template


    BatorySarvelaRauschmayer04

    1. Don Batory & Jacob N Sarvela & Axel Rauschmayer
    2. Scaling Step-Wise Refinement
    3. IEEE Trans Software Engineering V30n6(Jun 2004)pp355-371 & ICSE 2003
    4. =TOOL GENERATE CODE FEATURE REFINEMENT SWR AHEAD Gen Voca ATS JAX Java
    5. AHEAD::= "Algebraic Hierarchical Equations for Application Design".
    6. Refinements apply to many types of artifacts(eg. Java code, Makefile, ...) in a uniform way.
    7. Artifacts treated as indexed collections (code=name<>->class, Makefile=target<>->action,...)
    8. A product is described as a set of equations in terms of features and the code is generated automatically.
    9. Two operations: A \dot B adds A to B. A \diamond B replaces items in B by matching A items.
    10. meta-modelling: Options and product lines described as unindexed sets.
    11. Origami::= Describe each concern in a separate equation.

    BatorySighalThomasetal94

    1. Don Batory<batory@cs.utexas.edu> & Vivek Sighal & Sankar Dasari & Jeff Thomas & Marty Sirkin
    2. The GenVoca Model of Software-System Generators
    3. IEEE Software Magazine V11n5(Sep 1994)pp89-94
        p91: "Surprisingly we found this domain[data structures] poses the same challenges as the domains of large software systems. The specificatons of realms, components, and component composition for data base systems, communication systems, distributed file systems, and avionics software is the same - only the complexity of the algorithms differs." [BatorySighalSirkinThomas93]
      1. Examples Genesis and Predator
      2. P++ language on top of C++
      3. abstraction encapsulation and parameterization
      4. realms, components, parameters
      5. components encapsulate classes etc
      6. realms describe sets of components
      7. components act as transformers of input classes into new outut classes
      8. parameters for constants, types, realms, components,...

        Example: Data Structures in terms of containers, cursors, and links.


    Batra09

    1. Dinesh Batra
    2. Modified agile practices for outsourced software projects
    3. Commun ACM V52n9(Sep 2009)online [ 1562164.1562200 ]
    4. =THEORY AGILE DISTRIBUTED
    5. You have to modify agile methods when the team is not co-located.

    BaudryEtal05

    1. Benoit Baudry & Franck Fleurey & Jean-Marfc Jezequel & Yves Le Traon
    2. Automatic Test Case Optimization: A Bacteriologic Algorithm
    3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp76-81
    4. =IDEA C# PARSER BUILDER VISITOR TESTING MUTATION EVOLUTION FITNESS
    5. Nice use of patterns in the sample Component Under Test (CUT) a C# parser.
    6. Need 30 generations to produce a set of tests that could kill all 500 mutants.

    Bauer92

    1. Henry H Bauer
    2. Scientific Literacy and the Myth of the Scientific Method
    3. U of Illinois Press Urbana Ill. QA175.B25 1992 ISBN 0252018567
    4. =SURVEY SCIENCE STS SOCIAL PROCESS
    5. not method but diverse error-correcting social processes.
    6. jigsaw puzzle filter:=(human, frontier science, primary literature, secondary literature, textbook science, ...)
    7. proponents haven't been good testers.
    8. scientific knowledge is more like a map than a collection of facts
    9. prediction is not proof but helps, if theory useful fitting inteqesting
    10. includes innovation vs conservative
    11. needs explicit enforced ethics
    12. Compare [Lakatos76] on mathematics.

    Baxter92

    1. Ira D Baxter
    2. Design Maintenance Systems
    3. Commun ACM V35n4(Apr 1992)pp73-89
    4. =EXPERIENCE MAINTENANCE DESIGN vs CODE
    5. design deltas analysed(function, performance,...) and lead to implementation deltas,
    6. Transformation Control Language(TCL)
    7. Author sent me EMail... Quote from bibtex entry:
        Suggests Design Maintenance rather than Code Maintenance should be focus. Shows how formal (transformational) model of software construction can be used to generate design histories, and also implicitly defines types of formal maintenance deltas. Procedures for updating a captured design history are sketched.

    Bayes1763

    1. T Bayes
    2. An essay towards solving a problem in the doctrine of chances
    3. Phil Trans Royal Society V53(1763)pp370-418
    4. =THEORY PROBABILITY BELIEF
    5. Bayes approach to probability was to assume that the number represented the degree of belief a person had in the proposition.
    6. He worked argued that a rational person would have to follow certain rules. For example is P(A|B) is the probability of A given that B is true, then
    7. P(A&B) = P(A|B)*P(B).
    8. He worked out rules for rationally reevaluating the beliefs as new data came in.
    9. The heart of this is:
    10. (Bayes)|- (Bayes_theorem): if H is a set of mutually exclusive events, and E some new evidence, then for h:H, P( h | E) =P( E |h )*P(h )/Σ[h:H](P( E | h )*P(h)).
    11. The Wikipedia has a good discussion [ Bayes_theorem ] of this result.

    BayrakDavis03

    1. Coskun Bayrak & Chad Davis
    2. The Relationship between Distributed Systems and Open Source development
    3. Commun ACM V46n12(Dec2003)pp99-102
    4. =ESSAY OPEN SOURCE NONSEQUENTIAL PERFORMANCE OSD WWW/NET MARX MicroSoft W3C
    5. Analogy: Higher speeds in distributed computation come from NOT controlling and coordinating them but letting them loose. allowing a degree of inconsistency to develop is often a way to speed up the result.
    6. Tension between capital and craft..Close

    BCS/IEE89

    1. British Computer Society & Institution of Electrical Engineers
    2. A Report on Undergraduate Curricula For Software Engineering
    3. BCS London UK 1989
    4. =CURRICULUM
        "SE is not simply a more organized approach to programming [than untrained amateurs and early Computer Science]"

    Beale07

    1. Russell Beale
    2. Slanty design
    3. Commun ACM V50n1(Jan 2007)pp21-24
    4. =IDEA USER FUNCTION DESIGN
    5. Slanty_design::= reduce functionality or usability to make unwanted behavior difficult or impossible. Image: slanty tops to stop people putting things on them.

    BeauvaisEtal01

    1. J-R Beauvais & E Rutten & T Gautier & R Houdebine & P Le Guernic & Y-M Tang
    2. Modeling Statecharts and Activitycharts as signal equations
    3. ACM TOSEM Trans Software Engineering & Methodology V10n4(Oct 2001)pp397-451
    4. =THEORY TRANSLATION FSM statecharts denotation semantics Signal DC+ TOOL Sacres
    5. Signal::language.

    BeauxisPalamidessiValencia08

    1. Ramain Beauxis & Catuscia Palamidessi & Frank D Valencia
    2. On the asynchronous Nature of Asynchronous π-Calculus
    3. Montanari Festschrift [DeganoEtAl08] pp473-492
    4. =THEORY NONSEQUENTIAL BAGS QUEUES STACKS PI-CALCULUS
    5. Proves that to get behavior equivalent to π[a] (Asynchronous Pi Calculus) you need a normal π calculus where communication is through buffered channels that act as buffers. Queues and stacks can not simulate all π[a] behaviors.

    Beck99

    1. Kent Beck(First Class Software)
    2. Embracing Change with Extreme Programming
    3. IEEE Computer Magazine V32n10(Oct 1999)pp70-77
    4. =ADVERT =EXPERIENCES =HISTORY OBJECT-ORIENTED PROCESS METHOD XP
    5. See book [Beck99b]

    Beck99b

    1. Kent Beck(First Class Software)
    2. Extreme Programming Explained: Embrace Change
    3. Addison Wesley October 1999
    4. =ADVERT XP OBJECT-ORIENTED PROCESS METHOD
    5. XP::="Extreme Programming", continuous analysis, many tiny (Analysis;Design;Implementation;Test) iterations driven by feedback from previous iterations.
    6. Planning game, small releases, put what the user needs on 3 by 5 cards called user stories, metaphor as a collection of user stories, simple design(say everything once and only once),
    7. programmers are always testing, customers also provide tests, merciless refactoring,
    8. pair programming, continuous integration(within hours), collective ownership of code,
    9. on-site customer, 40.hour weeks, open worksapce, Just Rules.
    10. See [Beck99] and WikiWiki Reviews: [ wiki?ExtremeProgrammingExplainedEmbraceChange ]

    Beck00a

    1. Kent Beck
    2. Emergent Control in Extreme Programming
    3. Cutter IT Journal V13n11(Nov 2000)pp22-25
    4. =ADVERT TECHNICAL PROCESS XP
    5. XP :={ test first, planning game, short release cycle, pair programming, onsite customer, opn workspace, yesterday's weather, refactoring, continuous integration, collectiveownrship, simple once-and-only-once design, sane hours }.
    6. control can be in the rules rather than embodied in person.

    Beck01

    1. Kent Beck
    2. Aim, Fire
    3. IEEE Software Magazine V18n5(Sep/Oct 2001)pp87-89
    4. =DEMO TESTING first is ANALYSIS DESIGN SPECIFICATION
    5. "Never write a line of functional code without a broken test case".
    6. Ward Cunningham: "Test-first coding is not a testing technique".
    7. Writing tests helps you understand the problem: analysis.
    8. Writing tests described the logic of the design.
    9. Hard to write GUI tests.
    10. Claim that creatively lazy test-first coding tends to be more cohesive and less coupled -- because the interfaces tend to be minimized to saving typing: "intense feedback substitutes for the ability to guess right"
    11. Test cases expose misunderstandings in pair programming.
    12. Test cases document the all important answer to "What was this idiot thinking when he wrote this?".

    Beck02

    1. Kent Beck
    2. Test-driven development: by example
    3. Addison-Wesley Longman Boston MA 2002 ISBN 0321146530 [CR] 0308-0733
    4. =TUTORIAL TEST REFACTOR DESIGN JUnit xUnit Python

    Beck06

    1. Kent Beck
    2. Implementation Patterns
    3. Addison-Wesley Pro, Boston MA, 2006 ISBN 0321413091 CR 0903-0209 Safari [ 9780321413093 ]
    4. =THEORY PATTERNS Class State Behavior Collections Frameworks Performance TECHNICAL CODE = EXPERIENCE JUnit HotDraw
    5. Lots of detailed advice on object-oriented coding.

    BeckCunningham89

    1. Kent Beck & Ward Cunningham
    2. A Laboratory for Teaching Object-Oriented Thinking
    3. OOPSLA'89 conf Proceedings ACM SIGPLAN V24n10(Oct 1989)pp1-6
    4. =IDEA OBJECT_ORIENTED cards CRC_CARD

      [ paper.html ]

    5. Refers to [Wirfs-BrockWilkerson89]
        Note. "The CRC Press" is an established technical and engineering publisher.

      1. CRC_Card::physical=index_card(4.inch><6.inch), available, inexpensive, erasable.
      2. CRC::abbreviation="Class, Responsibility, Collaboration".
      3. CRC::=Net{C:=class:name_of_component, R:=responsible_for:%Responsibilities, C:=collaborators:%name_of_component}.

        Walking through a scenario: tracing an "application assigning each activity to some component". each CRC card held by a different member of the team Often a cycle of What/Who questions: #(what_next; who_does_it).


    BeckR10

    1. Roman Beck
    2. Can IT lean against the wind?
    3. Commun ACM V53n5(May 2010)pp38-40 [ 1735223.1735238 ]
    4. =EXPERIENCE RISKS BANKING FINANCE STANDARDS
    5. Financial systems had emergency backups that handled catestrophes like 2001/9/11 and 2005/7/7 well. Even with major servers down transactions continued to be cleared. They were not prepared to handle the task of evaluating complex credit risks at the speed needed to ameliorate the 2008 collapse. These required gathering data from many incompatible databases. In haste most assumed they were ok.
    6. Then all transactions assumed risky and stopped. Liquidity dried up.
    7. Transaction data are standardized but not evaluation data.

    BeckerMottay01

    1. Shirley A Becker & Florence E Mottay
    2. A Global perspective on web site usability
    3. IEEE Software Magazine V18n1(Jan/Feb 2000)pp54-61
    4. =THEORY USER WEB/NET DESIGN international
    5. usability on the web ==> layout + navigation + consistency + customer service + reliability + security + performance + visible content

    Beckman12

    1. Brian Beckman
    2. Why LINQ matters: cloud composability Guaranteed
    3. Commun ACM V55n4(Apr 2012)pp38-44 [ 2133806.2133820 ]
    4. =ADVERT UNREADABLE MS LINQ FUNCTIONS LAMBDAS URI SQO
    5. Language Integrated Query
    6. Abstract trees of operators (SQOs) can be defined, transmitted, received and interpreted as queries on data structure and data bases.
    7. REST::acronym="representational state transfer".
    8. URI syntax for queries.
    9. SQO::acronym="standard query operators"
    10. Lambdas: variable => body. The body can be a predicate or a transformation.
    11. Also see [Meijer11]

    BeckmanEtAl10

    1. Nels E Beckman & Aditya V Nori & Sriram K Rajamani & Robert J Simmins & Sai Deep Tetali & Adtya V Thakur
    2. Proofs from tests
    3. IEEE Trans Software Engineering V36n4(Jul/Aug 2010)pp495-508
    4. =DEMO ALGORITHM DASH POINTERS SUBPROGRAMS SOUND ABSTRACTION SYMBOLIC EXECUTION ALIASES TOOL YOGI Microsoft PLUGIN SLAM EXE BLAST SYNERGY
    5. Tests under-approximate and abstractions over-approximate the Programs behavior.
    6. Try to find a symbolic test that reaches an error state or find a precise enough abstraction to prove that no path leads to an error state.

    BeckwithEtal06

    1. Laura Beckwith & Marget Burnet & Valenline Grigoreanu & Susan Wiedenbeck
    2. Gender HCI: What about software?
    3. IEEE Computer Magazine V39n11(Nov 2006)pp97-101
    4. =EXPERIMENT USER GENDER HCI MALE FEMALE self-efficacy tinkering
    5. Men & women use spreadsheet tools differently. Men like exploring features for fun but women with low self-efficacy want to use them to solve problems.
    6. Do software development tools put girls off?

    BedersonGrosjeanMeyer04

    1. Benjamin B Bederson & Jesse Grosjean & Jon Meyer
    2. Toolkit Design for Interactive Structured Graphics
    3. IEEE Trans Software Engineering V30n8(Aug 2004)pp535-546
    4. =COMPARISON Object-Oriented LIBRARY DESIGN INHERITANCE vs COMPOSITION Java Swing GRAPHICS Jazz
    5. Piccolo Goal: an extensible structured graphics toolkit.
    6. Have many shapes and can add new ones easily.
    7. Jazz::= See http://www.cs.umd.edu/hcil/jazz/.
    8. Piccolo::= See http://www.cs.umd.edu/hcil/piccolo/.
    9. polylithic::design_styles="mainly using run-time composition to extend...". Many small classes, Easier to create but harder to use,
    10. monolithic::design_styles="mainly using compile-time inheritance to extend...". Few large classes. Harder to create but easier to use.
    11. (dick)|-Polylithic designs seem to use the GoF patterns.
    12. (dick)|-perhaps use composition for explore the domain and then reify functionality into a stable product.

    Bednarz11

    1. Ann Bednarz
    2. How IBM started Grading is developers' productivity
    3. InfoWorld (Nov 07 2011) [ how-ibm-started-grading-its-developers-productivity-178302 ]
    4. =REPORT IBM CODE METRICS TECHNICAL Cast OBJECTIVES QUALITIES
    5. Used tool to develop community standards and scoring programmers -- giving feed back on quality of code.

    Beebe99

    1. TeX User Group bibliography archive
    2. =BIBLIOGRAPHY of mathematics+computing journals+magazines

      [ http://www.math.utah.edu/ftp/pub/tex/bib/toc/ ] Nelson H. F. Beebe Center for Scientific Computing University of Utah Department of Mathematics, 322 INSCC 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090 USA beebe@math.utah.edu [ http://www.math.utah.edu/~beebe/ ]

    Beer74

    1. Stafford Beer
    2. Designing freedom
    3. London Wiley 1974
    4. =ESSAYs RISKS Cybernetics NET/WWW

    Beeson81

    1. Michael J Beeson
    2. Formalizing Constructive Mathematics: Why and How?
    3. Constructive Mathematics Spring Verlag Lecture Notes in Mathemetics V873 pp146-190 1981
    4. =THEORY FORMAL LOGIC
    5. LPT::="Logic of Partial Terms"
    6. Compare [Schock68] [Parnas93] [JonesCB95] and [PVS] LPF:=Logic of Partial Functions

    BegayRauzy01

    1. Diddier Begay and A. Rauzy
    2. A realistic involvement of formal methods
    3. Software - Practice & Experience V31n2(Feb 2001)pp191-208
    4. =Type FORMAL HARDWARE VERIFICATION CTL SMV Aralia PVS

    BehrendsStirewalt00

    1. Reimer Behrends & R E Kurt Stirewalt
    2. The Universe Model: An approach for Improving the Modularity an Reliability of Concurrent Programs [FSE8] pp20-29
    3. =CASESTUDY NONSEQUENTIAL MODULES TECHNICAL OBJECT-ORIENTED
    4. Problems with interleaving many threads through one piece of code. Hard to separate concurrency control from useful code, modularity damaged. multi-step synchronization uncheckable.
    5. Objects in a universe and each universe can host at most one process at a time. No execution of code outside the process's universe.
    6. realm constraints control movement of processes between universes.

    BekkeringShim06

    1. Ernst Bekkering & J P Shim
    2. i2i trust in videoconferencing
    3. Commun ACM V49n7(Jul 2006)pp103-107
    4. =EXPERIMENTS VIDEO MEDIA USER PEOPLE RISKS
    5. i2i::cummunication="individual to individual"
    6. Videophones and videoconferences discourage trust because the camera is not directly behind the screen. If you look at the screen then you don't make eye contact with the person at the other end, and vice versa.
    7. Result: people trust voicemail and E-mail more than video.
    8. Cell phones and PDAs may not have this problem.
    9. Solution: variation on the "Reagan sincerity machine" which lets you look directly at the camera while seeing an image on a screen (e.g. a script).

    Bekkerman04

    1. Anna Bekkerman
    2. Conflict Resolution and Operator Priorities in Extended BNF
    3. =IDEA =DEMO EBNF PARSING CFG GRAMMAR =TOOL Java JAMOOS
    4. Ph.D. Thesis(Technion Israel July 2004) [ thesis_anna.pdf ]
    5. Improve BNF by allowing the specification of priorities and removing other ambiguities.

    Bekic70

    1. H Beki\'c (IBM Lab Vienna)
    2. On the Formal Definition of Programming Languages
    3. International Computer Symposium 1970
    4. =CASE-STUDY VDL/VDM PL/I formal

    BelagerEtal06

    1. France Belanger & Weiguo Fan & L Christian Schaupp & Anjala Krishen & Jeanine Everhart & David Poteet & Kent Nakamoto
    2. Web site successMetrics: Addressing the duality of Goals
    3. Commun ACM V49n12(Dec 2006)pp114-116
    4. =ESSAY REQUIREMENTS TAXONOMY METRICS WEB/NET PURPOSES OWNERS vs USERS
    5. Success defined by owner goals + target audience.
    6. Table p115 has 11 distinct types of goal.
    7. Choose 2 sets of metrics: Owner vs user perspectives.

    BelinaHogrefeSarma91

    1. F Belina & D Hogrefe & A Sarma
    2. SDL with Applications from Protocol Specifications
    3. Prentice Hall Upper Saddle River NJ 1991 ISBN 0-13-785890-6 BCS Practitioner Series
    4. =TEXT-BOOK SDL SPECIFICATION
    5. a gradual introduction to SDL concepts illustrated by real examples (including an approach to X.25) together with an appendix with complete rules for use of the language.

    Bell04

    1. Alex E Bell (+ comment by Grady Booch)
    2. Death by UML Fever
    3. ACM Queue V2n1(Mar 2004)pp72-81
    4. =JOKE HARMFUL UML
    5. Lists a couple of dozen abuses of UML, including a classic "Circle the wagons" Use Case.

    Bell08

    1. Alex E Bell
    2. Software Development amidst the whiz of silver bullets
    3. =JOKE FADS XML UML OO WEB SERVICES
    4. Commun ACM V51n8(Aug 2008)pp22-24 [ 1378704.1378712 ]
    5. Names some previous failed fads.
    6. Describes current (200n) fads.
    7. Fads sound good but do not solve the real problems of software development.

    BellSchmidt99

    1. Alex E Bell & Ryan W Schmidt
    2. UMLoquent Expression of AWACS Software Design
    3. Commun ACM V42n10(Oct 1999)pp55-61 in [Booch99]
    4. =EXPERIENCE DEMO EVOLUTION UML Boeing NMT ARCHITECTURE CORBA Ada
    5. Notes value of the UML and some weak areas in the UML and need to improvise

    BelliGrosspietsch91

    1. Fevzi Belli & Karl-E. Grosspietsch
    2. Specification of Fault-Tolerant Systems Issues by Predicate/Transition Nets and Regular Expressions -- Approach and Case Study
    3. IEEE Trans SE v17n6(Jun 1991)pp513-526
    4. Bullet proofing Technical

    BelliniFioravantiNesi99

    1. Pierfrancesco Bellini & Fabrizio Fioravanti & Paolo Nesi
    2. Managing Music in Orchestras
    3. IEEE Computer Magazine V32n9(Sep 1999)pp26-34
    4. =DEMO MUSIC OBJECT-ORIENTED MOODS NETWORKED LANGUAGES HCI

    BelliniMattoliniNesi00

    1. P Bellini & R Mattolini & P Nesi
    2. Temporal Logics for Real-time system specification
    3. ACM Computing Surveys V32n1(Mar 2000) pp12-42
    4. =SURVEY LOGIC TIMING RTL RTIL RTTL
    5. WWW link to ACM Digital Library: [ p12-bellini ]
    6. From Abstract:
    7. The specification of reactive and real-time systems must be supported by formal, mathematically-founded methods in order to be satisfactory and reliable. Temporal logics have been used to this end for several years. Temporal logics allow the specification of system behavior in terms of logical formulas, including temporal constraints, events, and the relationships between the two. In the last ten years, temporal logics have reached a high degree of expressiveness. Most of the temporal logics proposed in the last few years can be used for specifying reactive systems, although not all are suitable for specifying real-time systems. In this paper we present a series of criteria for assessing the capabilities of temporal logics for the specification, validation, and verification of real-time systems. Among the criteria are the logic's expressiveness, the logic's order, presence of a metric for time, the type of temporal operators, the fundamental time entity, and the structure of time. We examine a selection of temporal logics proposed in the literature. To make the comparison clearer, a set of typical specifications is identified and used with most of the temporal logics considered, thus presenting the reader with a number of real examples.

    BellinSimone97

    1. David Bellin & Susan Suchman Simone
    2. The CRC Card Book
    3. Addison Wesley 1997 ISBN 0-201-89535-8 QA76.64 b437 1997
    4. =HOWTO CRC Object-Oriented ANALYSIS PURPOSE SCENARIO CRC DESIGN CARD ROLE-PLAY TECHNICAL Smalltalk C++ Java UML MANAGEMENT

    BellinzonaEtal95

    1. Roberto Bellinzona & Maria Grazia Fugini<fugini@ipmel1.polimi.it> & Barbara Parnici<pernici@elet.polimi.it>
    2. Reusing Specifications in OO Applications
    3. IEEE Software Magazine V12n2(Mar 1995)pp65-75
        Results: could create many process classes for a variety of applications in the banking domain, but not many documents

        Ithaca Project,

      1. IOOM::=Ithaca OO methodology.
      2. F-ORM::=Functionallity in Objects with Roles Model. object--<view>--role-->FS.ELH

        Basic problm is identifying matching components.

      3. Fuzzy matching against: verb-object, thesauri or semantic network ...., structures pairs Telos organizes knowledge in levels

        "Final document contains the set of graphical representations, the component documentation, and a trace of the steps."


    BellLabs83

    1. Unix Programmer's Manual
    2. NY NY Holt Rinehart & Winston (2 Vols)
    3. =handbook non-sequential tools pipe

    BellNewell70

    1. C Gordon Bell & Allen Newell
    2. The PMS and ISP descriptive systems for computer structure
    3. Proc AFIPS Spring Joint Comp Conf (??? 1970)pp351-374 [ PMS%20and%20ISP%20Descriptive%20Systems%201970%20c.pdf ] (PDF)
    4. =IDEA HARDWARE DESCRIPTION PMS Processor-Memory-Switch ISP Instruction-Set-Processor
    5. Also see [BellNewell71] for details and examples of ISP and PMS.

    BellNewell71

    1. C Gordon Bell & Allen Newell
    2. Computer structures: Readings and examples
    3. McGraw-Hill computer science series circa 1971 ISBN 0070043574 TK7888.3.B37
    4. =EXAMPLES 1960s =SURVEY HARDWARE DESCRIPTIONS Burroughs CDC DEC PDP Deuce KDF9 IBM SDS UNIVAC

    BellSiewiorek11

    1. Gordon Bell & Daniel P Siewiorek
    2. The Book "Computer Structures": Thoughts after 40 years
    3. IEEE Annals V33n2(Apr-Jun 2011) [ MAHC.2011.47 ]
    4. =HISTORY DOCUMENTING ANALYSING COMPUTER SYSTEMS HARDWARE
    5. Anecdotes and examples from [BellNewell70] and [BellNewell71]

    BellonEtAl07

    1. Stefan Bellon & Rainer Koschke & Giuliano Antoniol & Jens Krinke & Ettore Merlo
    2. Comparison and Evaluation of clone detection tools
    3. IEEE Trans Software Engineering V33n9(Sep 2007)pp577-591
    4. =EXPERIMENT TOOLS COPYPASTE DRY SOURCE Dup CloneDR CCFinder Duplix CLAN Duploc
    5. Also see [BakerB07]

    Ben-AbdallahEtal97

    1. Hanene BenAbdallah & Insup Lee & Young Si Kim
    2. The Integrated Specification and Analysis of Functional, Temporal, and Resource Requirements [RE'97] pp198-209
    3. =DEMO TOOLS REQUIREMENTS LANGUAGE
    4. GCSR::language="Graphical communicating Shared Resources".

    Ben-AbdallahLeue97

    1. Hanene BenAbdallah & S Leue
    2. Timing Constraints in Message Sequence Chart Specifications
    3. See [ tr97-04 in msc ]
    4. =REPORT SCENARIO TIMING MSC SPECIFICATIONS
    5. MSC::="Message Sequence Charts"

    Ben-Ari10

    1. Mordechai (Moti) Ben-Ari
    2. A Primer on Model checking
    3. ACM Inroads V1n1(Mar 2010)pp40-47
    4. =ADVERT =EXAMPLES MODEL CHECKING EDUCATION Spin VN Erigone NDFA NON_SEQUENTIAL VERIFICATION MODAL LOGIC Promela IDE
    5. The formula if not p then if p then q can be proved true by axiomatic methods but it is simpler and easier to check that it is true by trying out all 4 cases in a truth table.
    6. Similarly, proving that a parallele non-deterministic program has a property is usually time consuming but there exist tools that will find counter examples in a reasonable time. Spin works in industry but can be wrapped in an IDE that works well with students.

    Ben-Ari10a

    1. Mordechai Ben-Ari
    2. Objects Never? Well, Hardly Ever!
    3. Commun ACM V53n9(Sep 2010)pp32-35 [ 1810891.1810905 ] Discussion V54n1(Jan 2011)p7
    4. .See http://doi.acm.org/10.1145/1866739.1866741
    5. =POLEMIC OOP PARADIGMS EXPERIENCE REUSE ONE SIZE
    6. Match the paradigm to the problem.
    7. Provide students with more than one paradigm!
    8. Need published examples of OOP success and failure.
      But
      1. Ruby Quicksort
      2. OOP or SP first?

      (Close But )

    Ben-ShaulHolderLavva01

    1. Israel Ben-Shaul & Ophir Holder & Boris Lavva
    2. Dynamic Adaptation and Deployment of Distributed Components in Hadas
    3. IEEE Trans Software Engineering V27n9(Sep 2001)pp769-787
    4. =DEMO TECHNICAL DISTRIBUTED DYNAMIC MODULE HADAS JAVA
    5. Ways and means of allowing software components to be changed, moved, and remotely administrated.
    6. Component interfaces have a fixed and a dynamic part.
    7. Using reflection and introspection so that components can find out about each other -- but purpose and qualities are only described informally.

    BenamatiLederer01

    1. John Benamati & Albert L Lederer
    2. Coping with rapid changes in IT
    3. Commun ACM V44n8(Aug 2001)pp83-88
    4. =POLL TECHNICAL CHANGE MANAGEMENT
    5. Change is constant and is the most effective coping strategies are not applied.
    6. Low cost learning is preferred.
    7. Popular but ineffective: self education and bullying the vendor for support.
    8. Unpopular but effective: consider new technology that is compatible with current, incentives to keep staff who know the new stuff, choose specific customized training not general informal education.
    9. Review, think, plan, do, review, ....

    Benbunnan-Fich02

    1. Raquel Benbunnan-Fich
    2. Improving Education and Training with IT
    3. Commun ACM V45n6(Jun 2002)pp94-99
    4. =SURVEY EDUCATION IDEA GRID
    5. Education location><pedagogy><synchronocity.
    6. location:= proximate..disperesed.
    7. synchronocity:= synchronous..Asynchroonous
    8. Pedagogy:=objectivist..Constructivist
    9. Computer aided discussion etc makes no difference to mastery of topic(grades) but can effect what students feel.

    BendraouEtAl10

    1. Reda Bendraou & Jean-Marc Jezequel & Marie-Pierre Gervais & Xavier Blanc
    2. A comparison of six UML-based languages for software process modeling
    3. IEEE Trans Software Engineering V36n5(Sep/Oct 2010)pp662-675
    4. =ADVERT UML4SPM PROCESS MODELING SPEM1.1 SPEM2.0 Di Nitto Promenade Chou
    5. Languages are not formal enough and have few tools.
    6. (dick)|-later process modeling languages use UML notation as is.

    BenlarbiMelo99

    1. Sa"ida Benlarbi & Walcelio L Melo
    2. Polymorphism Measures for Early Risk Detection
    3. ICSE'99, Proceeedings of the 21st International Conference on Software Engineering (May 1999)pp334-344
    4. =EMPIRICAL METRIC LALO Logistic Regression
    5. relates measures of polymorphism with other metrics and fault proneness.
    6. Polymorphism may increase fault proneness but not significantly. Static and dynamic polymorphism are similar. Both correlated to numbers of methods but not LOC.
    7. See [BriandEtal99]

    Bennett92

    1. William S Bennett
    2. Visualising Software: A graphical notation for analysis design and discussion
    3. Marcel Dekker NY NY 1992

    Benson93

    1. David B Benson
    2. Comparative Review of books on Category Theory for Computer Science
    3. Computing Reviews V34n11(Nov 1993)pp577-579 (CR9311-0833)
    4. =SURVEY CATEGORY Sets out a reading program.

    Bentley84

    1. J Bentley
    2. Programming Pearls:Code Tuning
    3. Commun ACM v27 n2 (Feb 1984) pp91-96
    4. =CLASSIC BOOK optimization PERFORMANCE Technical

    Bentley86

    1. J Bentley
    2. Programming Pearls
    3. Addison Wesley Reading MA 1986
    4. =CLASSIC BOOK case-study Technical
    5. Also Knuth92

    Bentley87

    1. Jon Bentley
    2. More Programming Pearls: Confessions of a Coder
    3. Addison Wesley ma 1987
    4. =case-study Technical

    Bentley93

    1. Jon Bentley
    2. Do-It-Yourself Caching
    3. UNIX Review V11n10(Oct 1993)pp95-104
    4. =CAST-STUDY data performance case-study Technical

    Berard89

    1. Edward V Berard <sei!ajpo!eberard@pt.cs.cmu.edu>
    2. Re: Attempts to connect SAD and OOPS
    3. Software-Engineering-Digest/comp.soft.eng V6n37 & n40 & n42 Usenet/Internet 1989 + Personal communication(course notes 1989)
    4. =CORRESPONDENCE object-oriented SAD Technical Semantic nets+STD+Petrie Nets

    Berard93

    1. Edward V Berard (Berard Software Engineering)
    2. Essays on Object-oriented software engineering (vol 1)
    3. Prentice Hall Englewood Cliffs NJ 1993
    4. ISBN0-13-288895-5 CR9502-0058(comparative)

    BergClineGirou95

    1. William Berg & Marshall Cline & Mike Girou
    2. Lessons Learned from the OS/400 OO Project
    3. Commun ACM V38n10(Oct 1995)pp54-64
    4. =EXPERIENCE REQRITE OBJECT_ORIENTED OPERATING SYSTEM SOFTWARE
        rewriting a large piece of system software for a new platform.

        150 people almost all coding, feb92..94, 2MLOC C++ 14K classes, 142Kattributes 90K methods, 10K children, 5k overloaded method names. Use R/6000AIX/Motif. two days to compile and link. 10 minutes per class. Used Booch (all but one S_M team) increased functionallity and flexibillity heightened management. LOC tracked project but quality and delivery-on-time rewarded developers.

        Iterative and incremental life cycle. Used a weekly build cycle. encouraged defensive coding and defect avoidance and preserving interface stability. Should have had recesses every three months when work is frozen and reveiwed. Wanted more incentives for code reviews, detailed documentation, internal consistency checks, and separate est teams.

        classroom training: 120 hours OOA, design, patterns, programming + 50% design sessions with mentor. Spread out and reinforced. it takes application to learn to do inheritance correctly. 6 to 9 months before they get fully proficient in the new paradigm: 80% ok coders, 15% respectable journeyman designers, 5% top performaers at analysis and design. Biggest culture shift was from code to design.

        Put best talent to work on tuning RAM and speed.

        Systems requirements should include explicit flexibillity/extensibility criteria: Requirements Mutation Analysis. Use lowtech tools first, when design session ideas slow down then use computer-based tools to capture the ideas. Keep a strong link between requirements and design decisions.

        Code bloat and instruction count goals. Each path through code had a goal of so many instructions.

        Multiple inheritence not used much.

        Integration with old upper level code because it made numerous undocumented assumptions about entry points into new code.


    BerczukLv10

    1. Steve Berczuk & Yi Lv
    2. We're all in this together
    3. IEEE Software Magazine V27n6(Nov/Dec 2010)pp12-15
    4. =ANECDOTE SCRUM INTRODUCTION AGILE MANAGEMENT
    5. Certified Scrum Masters.
    6. Scrum masters shouldn't be self selected at first. Lead and coach
    7. Line managers command and control so at first shouldn't be scrum masters for their team.
    8. Reorganized management or left.
    9. Self planning teams & managers facilitate.
    10. People have to change.

    BerenbachBroy09

    1. Brian Berenbach & Manfred Broy
    2. Professional and Ethical Dilemmas in Software Engineering
    3. IEEE Computer Magazine V42n1(Jan 2008)pp74-80
    4. =ESSAY ETHICS NAMEs DILEMMAS MITIGATION IEEE ACM
    5. Named dilemmas
      1. Mission impossible
      2. Mea Culpa
      3. Rush Job
      4. Not My Problem
      5. Red lies
      6. Fictionware versus vaporware
      7. non-diligence
      8. Cancelled vacation
      9. Sweep it under the rug

    6. Proposes mitigation strategies.
    7. Failures of the ACM and IEEE Codes of Professional Behavior.
    8. Notes likely criminal behaviors: Negligent homicide, reckless endangerment, depraved indifference.
    9. Ethical dilemmas tend to be yoked, chained, or coupled.... and this magnifies the damage.

    Berghel01

    1. Hal Berghel
    2. The Code Red Worm
    3. Commun ACM V44n12(Dec 2001)pp15-19
    4. =ARTICLE RISK TECHNICAL CODE buffer overflow Microsoft IIS web-server DLL

    Berghel05

    1. Hal Berghel
    2. The Two Sides of ROI: Return on investment vs Risk of incarceration
    3. Commun ACM V48n4(Apr 2005)pp15-20
    4. =ESSAY RISK PRIVACY SECURITY ETHICS PROFESSION LEGISLATION HIPPAA GLB SOX New 2000 legislation puts CIOs and CEOs at risk of prosecution for not making
    5. systems secure. GLB::="Gramm-Leach-Bliley Act of 1999", privacy and security of nonpublic pers onal info .
    6. SOX::="Sarbanes-Oxley Act of 2002", accountability
    7. Also good description of [HIPAA]

    Berghel06

    1. Hal Berghel
    2. Fungible Credentials and Next-Generation Fraud
    3. Commun ACM V49n12(Dec 2006)pp15-19
    4. =EXAMPLES FRAUD CREDENTIALS
    5. Fungible: interchangeable and universal.
    6. Better computers and printers allow the creation of a hard to doubt credential that can be used to get legitimate (but false) credentials.
    7. Figure 2 lists some anti-counterfeiting technology.

    Bergin01

    1. Joseph Bergin <jbergin@pace.edu>
    2. A Pattern Language for Initial course design
    3. ACM SIGCSE Bulletin V33n1(Mar 2001) & 32nd SIGCSE Tech Symp on Cop Sci Education (Feb 21-25 2001)pp282-286
    4. =PATTERNS EDUCATION PLAN
    5. Abandon Systems all ye that enter here.
    6. Need to Know
    7. Early Bird: identify important topics early.
    8. Spiral
    9. Lazy Professor

    Bergland81

    1. Glenn D Bergland
    2. A Guided Tour of Program Design Methodologies
    3. IEEE Computer v14(Oct 1981)pp13-37 (reprint in Chow(Ed)84)
    4. =survey Compares FD JSP DFD and Dijkstra Gries
    5. Page 241 of Chou
    6. Figs 43 and 44: Where is the Magic in the methods?

    BerglandGordon81

    1. Glenn D Bergland & ?? Gordon(Eds)
    2. Software Design Strategies(2nd Edition)
    3. IEEE Computer Soc Tutorial IEEE Cat No. EH0184-2 Los Angeles CA 1981
    4. =survey methods DDD SAD

    BerglandZave86

    1. Glen D Bergland & Pamela Zave
    2. Special Issue on Software Design Methods
    3. IEEE Trans on Software Engineering SE-12n 2 (Feb 1986)
    4. =survey object-oriented DAD JSD functional formal ADTs DFD

    Berghel06

    1. Hal Berghel
    2. Fungible Credentials and Next-Generation Fraud
    3. Commun ACM V49n12(Dec 2006)pp15-19
    4. =EXAMPLES FRAUD CREDENTIALS
    5. Fungible: interchangeable and universal.
    6. Better computers and printers allow the creation of a hard to doubt credential that can be used to get legitimate (but false) credentials.
    7. Figure 2 lists some anti-counterfeiting technology.

    Berghel07

    1. Hal Berghel
    2. Better-Than-Nothing Security Practices
    3. Commun ACM V50n8(Aug 2007)pp15-18
    4. =ADVERT BTNSP SECURITY XP Browsers WiFi
    5. BTNSP::= See http://www.berghel.net/btnsp/ Simple things that users can do to improve the security of their systems... Better than doing nothing.

    Berghel12

    1. Hans Berghel
    2. Breaking the fourth wall of electronic crime: blame it on the thespians
    3. IEEE Computer Magazine V45n5(May 2012)pp86-88
    4. =IDEA TRUST NET PEOPLE
    5. Actors provide a recipe for cyber crime:
      1. Create situation that looks plausible,
      2. Target performance at particular audience.
      3. Understand people and know how to exploit their frailties.
      4. Focus on getting audience to willingly suspend disbelief.
      5. Distract audience from the above items.

    BergmanMoorNelson90

    1. Merrie Bergman & James Moor & Jack Nelson
    2. The Logic Book (2nd edn)
    3. McGrawHill (1990) ISBN 0-07-909524-0 LC# BC135.B435
    4. =TEXT FORMAL LOGIC NATURAL DEDUCTION TREES SEMANTIC TABLEAUX

    BergstraPonseSmolka01e

    1. J A Bergstra& A Ponse & S A Smolka
    2. Handbook of process algebra
    3. Elsevier 2001 ISBN 0-444-82830-3, review Tucker Computer Journal V45n1(2002)pp68-69
    4. =UNREAD =Handbook algebra nonsequential CCS TCSP ACP Petri

    BergstraTucker07

    1. J Bergstra & J Tucker
    2. The rational numbers as an abstract data type
    3. JACM V54n2(Apr 2007)#7pp? CR 0808-0783
    4. =UNREAD =THEORY ADT ABSTRACT DATA CONDITIONAL EQUATIONAL SPECIFICATION Lagrange
    5. Notes [click here [socket symbol] if you can fill this hole]

    BerlingRuneson03

    1. Tomas Berling & Per Runeson Efficient Evaluation of Multifactor dependent System Performance using fractional Factorial Design
    2. IEEE Trans Software Engineering V29n9(Sep 2003)pp769-781
    3. =STATISTICS PERFORMANCE PROTOTYPE TESTING ACCURACY ANOVA Pareto Iterative Careful choice of a few test cases applied to a prototype allows the evaluation of the effects of many factors on the targeting performance of a radar system.

    BernardLaffite99

    1. Pascal Bernard & Guy Laffite
    2. The French Population Census for 1990
    3. In [HincheyBowen99] pp15-42
    4. =EXPERIENCE MATH Z B METHOD REQUIREMENTS GEOGRAPHY CENSUS
    5. It worked as a process and a product.

    Berns84

    1. Gerald M Berns
    2. Assessing Software Maintainability
    3. Commun ACM V27n1(Jan 1984) pp14-23
    4. =EXPERIENCE QUALITY TECHNICAL FORTRAN EVOLUTION TOOL MAT

    Bernstein80

    1. Arthur Bernstein
    2. Output Guards and Nondeterminism in "Communicating Sequential Processes"
    3. ACM TOPLAS V2n2(Apr 1980)pp234-238
    4. =THEORY CSP non-sequential NON-DETERMINISM

    Bernstein93

    1. Lawrence Bernstein(attmail!l.bernstein)
    2. Get The Design Right!
    3. IEEE Software Magazine V10n5(Sep 1993)pp61-63
      1. p 61: "...focus first on the problem domain and then on the implementation domain"
      2. controlled, evolving and validated requirements
      3. prototypes
      4. p62:
      5. nimble
      6. pay attention to detail
      7. visit the user
      8. Setup operational profiles of expected use for performance analysis and scenario testing
      9. p63: Write the specification after the prototyping and use a formal spiral-development program
      10. "no tool will replace the skill and talent of the professional software designer."

    Bernstein10

    1. Michael Bernstein
    2. Clay Shirky: doing work or Doing Work
    3. Commun ACM V53n8(Aug 2010)p9 [ 1787234.1787238 ] & blog@Acm [ fulltext ]
    4. =BLOG USEFUL USABLE USER
    5. In February Clay Shirky [ shirky in keynotes ] distinguished things we are paid to do (Work) from what we like doing (work).
    6. We must design software to be useful (helping us do what we want) rather than just usable (we have to be paid to use it).

    BernsteinFitzGeraldMacdonellConcepcion05

    1. Marc Bernstein & Kelly M FitzGerald & James P Macdonell & Arturo I Concepcion
    2. AlgorithmA Project: The ten-week Mock Software Company
    3. ACM SIGCSE Tech Symp Proc (Feb 2005)pp142-146
    4. =EXPERIENCE 14.years EDUCATION PROJECT MAINTENANCE PEOPLE MANAGEMENT CSUSB CSCI488 RMT UML IEEE SRS

    Berry11

    1. Daniel M Berry
    2. Liability Issues in Software Engineering
    3. Commun ACM V54n4(Apr 2011)p98 [ 1924421.1924443 ]
    4. = INTRODUCTION MASS MARKET BESPOKE SOFTWARE CONTRACTS EULA
    5. Introduces [MetayerEtAl11] and also distinguishes bespoke from mass-marketted software contracts.

    BerryKamsties05

    1. Daniel M Berry & Erik Kamsties
    2. The syntactically dangerous ALL and Plural in Specifications
    3. IEEE Software Magazine V22n1(Jan /Feb 2005)pp55-57
    4. =IDEA AMBIGUITY LOGIC LANGUAGE SPECIFICATION CS565
    5. Words to suspect: "only", "all", "also", "each".
    6. Use "each" when describing a property of the individual members of a set.
    7. Use "all" for shared properties across a set.
    8. Can use simple logic to clarify an ambiguity.
    9. All the lights in the room have a single on-off switch.
      Net
      1. Each light has its own switch.
      2. For all y:lights_in_room, one x: switch (x is on_off_switch_for y).
      3. All the lights share a common switch.
      4. For one x: switch, all y:lights_in_room (x is on_off_switch_for y).

      (End of Net)

    10. Similarly for plurals: "Students enroll in six courses" vs "Students enroll in hundreds of courses".

    BersoffDavis91

    1. Edward H. Bersoff & Alan M. Davis
    2. Impacts of Life Cycle Models on Software Configuration Management
    3. Commun ACM V34n8(Aug 1991)pp104-117

    Bertolazzietal95

    1. Paola Bertolazzi & Giuseppe Di Battista & Giuseppe Liotta
    2. Parametric Graph drawing
    3. IEEE Trans on Software Eng VSE-21n8(Aug 1995)pp662-673
    4. The Graph Server: digraphs not diagrams - no words or icons.

    BertolinoMirandola04

    1. Antonia Bertolino & Raffaela Mirandola
    2. Software Performance Engineering of Component-based Systems
    3. WOSP'04 & ACM SIGSOFT Software Engineering Notes V29n1(Jan 2004)pp238-242
    4. =IDEA QUALITY Performance MODULAR COMPONENT CB-SPE
    5. Based on PTS RT-UML [OMG020302].

    BertranAugeraud99

    1. Frederic Bertran & Michel Augeraud
    2. BDL: A Speicalized Language for Per-Object Reactive Control

      [WileRaming99] pp347-362

    3. =ADVERT LANGUAGE SYNTAX SEMANTOC OBJECT-ORIENTED NONSEQUENTIAL ESTEREL

    BerzalCuberoMarinVila05

    1. Fernando Berzal & Jean-Carlos Cubero & Nicolas Marin & Maria-Amparo Vila
    2. Lazy Types: Automating Dynamic Strategy Selection
    3. IEEE Software Magazine V22n5(Sep/Oct 2005)pp98-106
    4. =DEMO TECHNICAL POLYMORPHIC TYPES C# .NET
    5. Lazy types have a common interface plus varying attributes and strategies for handling the interface depending on what attributes are available.
    6. Objects gain and loose attributes as the program executes, the methods adapt auto-magically to what attributes are present.
    7. lazy_types_library::= See http://elvex.ugr.es/software/lazy/, -- proof of concept for .NET
    8. Uses hidden factory pattern and strategy pattern.

    BerzinsLuqi90

    1. Valdis Berzins & Luqi[Sic]
    2. An Introduction to the Specification Language Spec
    3. IEEE Software V7n2 pp74-84 (Mar 1990)
    4. formal

    BerzinsLuqi91

    1. Valdis Berzins & Luqi[Sic]
    2. Software Engineering with Abstractions
    3. Addison Wesley
    4. Reading Mass.1991
    5. CR9211-0842
    6. (Spec & Ada)

    BerzinsLuqiYehudai93

    1. Valdis Berzins & Luqi[Sic] & Amiram Yehudai
    2. Using Transformations in Specification-Based Prototyping
    3. IEEE Trans on Software Eng VSE-19n5(May 1993)pp436-452 QUALITY PURPOSE function
      1. Transformations of specifications during a project.
      2. Spec+DFDs
      3. pp442-443 Software Process
      4. p446 encapsulated user interface in module
      5. pp446-447 requirements evolve
      6. distinguish spec changes from design and implementation changes
      7. p447inheriting from older specifications
      8. p450 Distinguishing (and delaying) optimization decisions from functional requirements.

        pp458-459 distinguishing extention, contraction, refining, abstracting, relaxing, constraining by comparing Vocabulary, Granularity and Behavior.

        pp447-448: The derivation Lattice/poset to explain designs -- configuration management for specs?

        [Snelting96] [KramerLuqiBerzins93]


    Berztiss88

    1. Alfs Berztiss
    2. Programming with Generators
    3. Software - Practice and Experience V18n1pp73-81(Jan88)
    4. =IDEA non-sequential Technical
    5. Each time a generator is called it produces the next result.

    Berztiss89

    1. Alfs Berztiss
    2. Formal Specification Methods and Visualisations
    3. In [Chang89] pp231-290
    4. =SURVEY graphic DFDS ERDs(problems) JSD STD Petrie Nets Structure Diagrams

    Berztiss90

    1. Alfs Berztiss
    2. Programming with Generators: An Introduction
    3. Ellis Horwood Chichester UK 1990 ISBN 0-13-739087 CR 9211-0847
    4. =MONOGRAPH Technical pseudo-concurrency

    BesseyEtAl10

    1. Al Bessey & Ken Block & Ben Chelf & Andy Chou & Bryan Fulton & Seth Hallem & Charles Henri-Gros & Asya Kamsky & Scott McPeak & Dawson Engler
    2. A few billion lines of code later -- using static analysis to find bugs in the real world.
    3. Commun ACM V53n2(Feb 2010)pp [ 1646353.1646364 ]
    4. =EXPERIENCE COVERITY 700 CUSTOMERS ERRORS CODE BUG FINDING RESEARCH vs PRACTICE TECHNIQUE vs PEOPLE
    5. Practical experience uncovered new problems not seen in experiments. "Weird is not good. Tools want expected".
    6. Bugs found vs false positives.
    7. In practice most users are not the developers.
    8. Selling the tool by an onsite trial with engineer and salesperson.
    9. rules
      1. You can't check code you don't see.
      2. Not everybody uses make or even command lines. Must adjust checkers to work in complex GUI build ecology. Typical overnight builds. You can not change a build process even if it is clearly broken.
      3. You can't check code you can't parse. Compilers diverge from the standard and are old. Amazing code works. Must translate these away for each compiler. 100s of translations.
      4. Programmers react to bug reports with disbelief, anger, denial, and bargaining. Always some Clueless people. Good people still do stunningly clueless things. Always present results to a group. Someone may be stupid or unmotivated but another can be smart and motivated.
      5. Commonly code is shipped with bugs in it. Lots of bugs. So maintain a list of bugs that are known already.
      6. Upgrades that find more bugs make managers and the checker look bad. Bugs in the tool that lead to missed bugs make tool look bad when upgrade fixes them.
      7. Missing bugs is easier to sell than reporting nonbugs.
      8. Churn is bad. Churn is unexpected changes in user output on an upgrade. (dick: Festina lenti).
      9. Deeper, smarter analysis is not always good. Need explainable bug reports.
      10. Vital to reduce false positives. Especially in the early runs.
      11. Else: "this tool sucks".

    10. Programmers are starting to accept static checking tools.
    11. If the code is big enough and it compiles then you can find bugs in it.

    Betz95

    1. Mark Betz
    2. Building a CORBA Object Server
    3. Software Development Magazine(Oct 1995)pp53-61
    4. =ARTICLE TECHNICAL OBJECT-ORIENTED C/C++
    5. IDL::=Interface Definition Language
    6. ORB::=Object Request Broker

    BeugnardEtal99

    1. Antoine Beugnard & Jean-Marc Jezequel & Noel Plouzeu & Damien Watkins
    2. Making components contract aware
    3. IEEE Computer Magazine V32n7(Jul 1999)pp38-45
    4. =THEORY COMPONENTS RELIABILITY QUALITY
    5. 1:IDL=syntax, 2: pre/post=behavioral, 3:synchronization, 4:quality-of-service

    BeyerHoltzblatt94

    1. Hugh R Beyer & Karen Holtzblatz
    2. Calling Down the Lightening
    3. IEEE Software Magazine V11n5(Sep 1994)pp106-107+113
    4. =History Bricklin spreadsheet requirements design users
    5. roadblocks to creativity::= separating requirements gathering from system design | products = list of features | FEAR(engineers talking to customers | people working together| new ideas |"it can't work")

    BeyerHoltzblatt95

    1. Hugh R Beyer & Karen Holtzblatz
    2. Apprenticing with the Customer
    3. Commun ACM V38n5(May 1995)pp45-52
    4. =EXPERIENCE REQUIREMENTS
      1. "sit by Nelly" and then ask questions
      2. reveals: what matters, details, structure
      3. events lead to discussions
      4. master can transfer years of experience quicker
      5. Then designer works out structure
        1. articulate understanding
        2. is there to improve work
        3. must have a specific focus

      6. Beware
        1. other relationships: interviewer, expert, friend
        2. being abstract: things that are unsaid...ASK!
        3. polite ways of saying "no, you are wrong": "Huh?", "Ummm...maybe", "Yes, but..."


    BeyerNoackLewerentz05

    1. Dirk Beyer & Andreas Noack & Claus Lewerentz
    2. Efficient Relational Calculation for Software Analysis
    3. IEEE Trans Software Engineering V31n2(Feb 2005)pp137-149
    4. =TOOL RELATIONAL LOGIC RML BDD TECHNICAL PATTERN JAVA CrocoPat
    5. Faster recognition of patterns in class structures tested faster on real code: JDK AWT, Eclipse,... Than Prolog and MySQL.

    Bhansali93

    1. P V Bhansali
    2. Survey of software safety standards shows diversity
    3. IEEE Computer Magazine V26n1(Jan 1993)pp88-89
    4. =SURVEY STANDARDS RISKS
      1. UK MoD: Int Def Stan 00-55 (Formal)
      2. UK MoD: Int Def Stan 00-56 (Hazard Analysis)
      3. Instrument Soc America SP84(draft)
      4. US DoD: Mil-Std-882B(Notice 1)
      5. IEEE CS: P1228(Draft) (Safety plan)
      6. Radio Tech Comm Aero/DO-178A
      7. Int Elect Comm(industrial: SC 65A/WG9... EIA: SEB 6-A UL: UL1998(Draft)
      8. FDA: Control of medical devices

        General

      9. Identify and classify systems hazards
      10. Identify system function allocated to software
      11. Identify hazards related to software
      12. Design to reduce or eliminate hazards
      13. (sw and credible hw)
      14. Implement SW
      15. Verify hazards at acc level and no new hazards
      16. Config management and SQA throughout

    BhatGuptaMurthy06

    1. Jyoti M Bhat & Mayank Gupta & Santhosh N Murthy
    2. Overcoming Requirements Challenges: Lessons from Offshore Outsourcing
    3. IEEE Software Magazine V23n5(Sep/Oct 2006)pp38-44
    4. =CASE STUDIES 9 + THEORY RE Requirements SHARING TRUST
    5. Problems in case studies can be avoided by success factors and best practices.
    6. Success factors: shared goals, culture, process, and responsibility. Plus trust.
    7. Lists best practices for people, process, and technology.
    8. No technology to promote trust!

    BhattiBerinoGafoorJoshi04

    1. Rafae Bhatti & Ellsa Berino & Arif Gafoor & James B D Joshi
    2. XML-based specification for web services
    3. IEEE Computer Magazine V37n4(Apr 2004)pp41-49
    4. =IDEA WWW SECURITY XML RBAC XUS XRS
    5. RBAC::= "role based access control".
    6. XUS::= "XML user sheet", credentials.
    7. XRS::= XML role sheet.
    8. etc.

    BianchiEtal03

    1. Alessandro Bianchi & Danilo Caivino & Vittorio Marengo & Giuseppe Visaggio
    2. Iterative re-engineering of Legacy Systems
    3. IEEE Trans Software Engineering V29n3(Mar 2003)pp225-241
    4. =EXPERIENCE MAINTENANCE COBOL REENGINEER REFACTOR DATA
    5. Compare mean time to maintenance request to estimated time to reengineer module.
    6. Fig 4 has incorrect UML

    BiancuzziWarden09

    1. Federico Biancuzzi & Shane Warden
    2. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
    3. O'Reilly Media 2009 ISBN 0596515170
    4. =UNREAD =INTERVIEWS PROGRAMMERS PEOPLE CODING TECHNICAL LANGUAGES CSCI320
    5. Please send me your comments [ contribute.html ] to see them here.

    BicarreguiRitchie95

    1. Juan Bicarregui & Brian Ritchie
    2. Invariants, frames and Postconditions: A comparison of the VDM & B Notations
    3. IEEE Trans on Software Eng VSE-21n2(Feb 1995)pp79-89
    4. =CASE-STUDY FORMAL LANGUAGES SPECIFICATION

    BichlerLin06

    1. Martin Bichler & Kwei-Jay Lin
    2. Service Oriented Computing
    3. IEEE Computer Magazine V39n3(Mar 2006)pp99-101
    4. =ADVERT SERVICES NET/WEB WORKFLOW SEMANTICS QoS WSDL OWL-S ONTOLOGY SOC BSN BPEL BPML

    Bidoitetal91

    1. Michel Bidoit & Hans-Jorg Kreowski & Piere Lescanne & Fernando Orejas & Donals Sannella
    2. Algebraic System Specification and Development
    3. Springer Verlag NY NY 1991(Lecture Notes in CS V501)
    4. =SURVEY =BIBLIOGRAPHY THEORY FORMAL ALGEBRA SPECIFICATION
    5. Short!

    BiemanKang95

    1. James M Bieman(bieman@cs.colostate.edu) & Byung-Kyoo Kang
    2. Cohesion and Reuse in an Object Oriented System [SamadzadehZand95] pp259-262
    3. =EXPERIENCE OBJECT-ORIENTED REUSE C/C++ EXPERIENCE
    4. New measure of cohesion for a class - degree to which methods use the same fields. Most classes a quite cohesive. Classes reused by inheritance most are clearly of lower cohesion.

    BiemanKang98

    1. James M Bieman & Byung-Kyoo Kang
    2. Measuring Design-Level Cohesion
    3. IEEE Trans Soft Eng V24n2(Feb 1998)pp111-124
    4. =IDEA =EXPERIMENT DESIGN MODULE METRICS
    5. DLC::="Design-Level Cohesion".
    6. DFC::="Design-level Functional Cohesion".
    7. IODG::="Input/output dependence graph".

    BiemanOtt94

    1. James M Bieman & Linda M Ott
    2. Measuring Functional Cohesion
    3. IEEE trans on Soft Eng vSE-20n8(Aug 1994)pp644-657
    4. =THEORY METRICS MODULARIZATION COHESION

    BiemanZhao95

    1. James M Bieman(bieman@cs.colostate.edu) & Josephine Xia Zhao
    2. Reuse Through Inheritance: A Quantitive study of C++ Software [SamadzadehZand95] pp47-52
    3. Inheritance is used far less frequently than expected

    BiemanJainYang01

    1. James M Bieman & Dolly Jain & Helen J Yang
    2. OO design patterns, design structures, and program changes: an industrial case study
    3. 17th IEEE International Conf on Sw Maintenance ICSM'01 ( 2001)pp580+ CR 0511+1249 [ ICSM.2001.972775 ]
    4. =experience evolution object-oriented GoF patterns metrics

    5. 39 versions of evolving industrial OO software
    6. Strong relationship -- larger classes were changed more frequently
    7. Classes that participate in design patterns were the most change prone.
    8. Classes that are reused the most through inheritance tend to be changed more often.

    Biffl00

    1. Stefan Biffl
    2. Using Inspection Data for Defect Estimation
    3. IEEE Software Magazine V17n6(Nov/Dec 2000)pp36-43
    4. =EXPERIMENT DEFECTS INSPECTION ESTIMATION 200+students
    5. Capture-Recapture model of number of defects vs number found by different numbers of inspectors.
    6. Best to assume that different defects have different chances of being detected, but that inspectors are all equally likely.

    Billingsetal94

    1. C Billings & J Clifton & B Kolkhorst & E Lee & W B Wingert
    2. Journey to a mature software process
    3. IBM Systems Jnl V33n1(1994)pp46-61
    4. =EXPERIENCE HISTORY IMPROVEMENT REQUIREMENTS QUALITY V&V PROCESS EVOLUTION
    5. Shuttle Onboard Software System. See

      [Oman94] [MaddenRhone84] [ Billingsetal94.html ]

    BimboCampanaiNesi93

    1. Alberto Del Bimbo & Maurizio Campanai & Paolo Nesi
    2. A Three-Dimensional Iconic Environment for Image Database Querying
    3. IEEE Trans on Software Eng VSE-19n10(Oct 1993)pp977-1011 Graphics
        p1002 spatial relations and operators
      1. strictly_after, after_with_right_adjacency, after
      2. is_included_by with left_adjacency, includes with right_adjacency
      3. includes, spatial-coincidence, isinclude_by, includes with left adjacent
      4. before, before with left adjacency, strictly_before

    Binder94

    1. Robert V Binder(guest Editor)
    2. Object-Oriented Software Testing(Special edition)
    3. Commun ACM V37n9(Sep 1994)pp28-101
    4. =EDITORIAL OBJECTS SQA TESTING

    Binder95

    1. Robert V Binder(guest Editor)
    2. Scenario-Basesd Testing for Client Server Systems
    3. Software Development Magazine(Aug 1995)pp43-49
    4. SQA SCENARIO
    5. cf Operational Profiles in Musa93(CLEANROOM)

    BinkleyEtal06

    1. David Binkley & Mariano Ceccato & Mark Harman & Filippo Ricca & Paolo Tonella
    2. Tools-Supported refactoring of existing Object-Oriented code into aspects
    3. IEEE Trans Software Engineering V32n9(Sep 2006)pp698-717
    4. =DEMO TOOL MAINTENANCE REFACTOR ASPECTS
    5. Has a useful list of refactorings which may or may not be complete.
    6. The extract repeated code into an aspect: DRY.

    Binstock11

    1. Andrew Binstock (Dr. Dobb's Editor in Chief)
    2. Lax Language Tutorials
    3. Dr. Dobbs Update (31 May 2011) [ MailView?ms=MzY2Njg4NzYS1&r=MjIxNTUzNzc4NAS2&j=MTAyODAzNzM3S0&mt=1&rt=0 ]
    4. =EDITORIAL LRM vs LANGUAGE TUTORIALS Python C Ruby K&R Scala Java
    5. Compares good and bad language tutorials... and proposes that
      1. A good tutorial starts with a collection of complete simple but usable examples
      2. It finishes with a detailed reference manual with all the nitty gritty details

    Binstock11b

    1. The Dismal Science of Code Metrics
    2. Andrew Binstock (Dr. Dobb's Editor in Chief)
    3. Dr. Dobbs Update (Sep 27 2011) [ 231602262?cid=DDJ_nl_upd_2011-09-27_h ]
    4. Quote
        Rather than illuminate, most metrics are flawed, misleading, and provide little insight.

    5. Couldn't put it better myself.

    Bird09

    1. Cameron Bird
    2. Wired (Dec 2009) [ st_goodsigns ]
    3. =ADVERT NOTATION MATHEMATICS RELATIONS
    4. Dr. Byron Cook (QMC & MS Cambridge) [ http://research.microsoft.com/en-us/people/bycook/ ] new notation for relational calculus

    BirdEtAl09

    1. Christian Bird & Nachiappan Nagappan & Premkumar Devanbu & Harald Gall & Brendan Murphy
    2. Does Distributed Development Affect Software quality? An Empirical Case study of windows Vista
    3. Commun ACM V52n8(Aug 2009)pp- [ 1536616.1536639 ]
    4. =EMPIRICAL DISTRIBUTED PROCESS QUALITY MS Vista
    5. Little evidence that having a team spread over two continents gives worse code than being in the same building.
    6. Size of team does have an effect.
    7. (dick)|-They did not check to see if the distributed team compensated for distance be special processes or tools.

    BisbalEtal99

    1. Jesus Bisbal & Deirdre Lawless & Bing Wu & Jane Grimson
    2. Legacy Information Systems: Issuses and Directions
    3. IEEE Software Magazine V16n5(Sep/Oct 1999)pp103-111
    4. =DESCRIPTION EVOLUTION DATA LIS Chicken-Little and Chrysalys Strategies

    Bishop90

    1. Judy M Bishop
    2. The Effect of Data Abstraction on Loop Programming Techniques
    3. IEEE Trans SE-16n4pp389-402(Apr 1990)
    4. ADTs non-sequential Technical

    BishopP02

    1. Pete G Bishop
    2. Rescaling Reliability Bounds for a New Operational Profile
    3. Proc ISSTA02 & ACM SIGSOFT Software Engineering Notes V27n4(Jul 2002)pp180-190
    4. =THEORY PROBABILITY FAILURE TESTING
    5. If faults are removed as they are found by a fixed operational profile without effecting other faults and probability of a faults is constant with time T then P(failure per test | test number=T) <=N/(e * T) if there are N faults.
    6. Reason: errors that are probable are found quickly, less probable once are less likely to happen.
    7. This formula can be adjusted to allow for changes in the operational profile.
    8. Results fit PODS TRIPV testing.

    BishopLittlewoodPovyakaloWright11

    1. Peter Bishop & Bev Littlewood & Andray Povyakalo & David Wright
    2. Toward a formalism for conservative claims about the dependability of software-based systems
    3. IEEE Trans Software Engineering V37n5(Sep/Oct 2011)pp706-717
    4. =THEORY MATHEMATICS CONFIDENCE BAYES PROBABILITY
    5. How confident are you that 99.99% of the time the system will work correctly?
    6. How would your confidence change if the system passes a test?

    BishopWagner07

    1. Matt Bishop & David Wagner
    2. Risks of E-Voting
    3. Commun ACM V50n11(Nov 2007)p120
    4. =REPORT TECHNICAL SOURCE CODE REVIEW VIRAL RISKS SECURITY QUALITIES
    5. The authors found buffer overruns, hard-coded encryption keys, dumb pseudo-encryption, dumb passwords etc. in all voting systems.
    6. Federal tests did not disclose the flaws. Code review did.
    7. Voting systems must be transparent.
    8. Need for audits.

    BitnerReingold75

    1. James R Bitner & Edward M Reingold
    2. Backtrack Programming Techniques
    3. Commun ACM V18n11 pp651-656(Nov 1975)
    4. =survey non-sequential optimization Technical

    Bittner02

    1. Kurt Bittner
    2. Use Case Modeling
    3. Addison-Wesley Longman Boston MA ISBN 0201709139 [CR] 0305-0414
    4. =HANDBOOK USECASE USER REQUIREMENTS

    BittnerSpence03

    1. Kurt Bittner& Ian Spence
    2. Use case modeling
    3. Pearson Education Boston MA 2003
    4. =HOWTO REQUIREMENTS USECASE
    5. Synthesize understandable models of complex requirement details.
    6. Communication, simplicity, stakeolders, write details, Good enough.
    7. Dangers of relationships between use cases.
    8. How to write abstract cases(with a "{hole}") and their specializations(with an "at{hole}").

    BiZhao04

    1. Henry H Bi & J Zhao
    2. Applying propositional logic to workflow verification
    3. Information Technology and ManagementV5n3-4(Jul wppr)pp293-318 CR 0605-0526
    4. =UNREAD =THEORY WORKFLOW VERIFICATION LOGIC [click here [socket symbol] if you can fill this hole]

    Bjorkander00

    1. Morgan Bjo"rkander
    2. Graphical Programming Using UML and SDL
    3. IEEE Computer Magazine V33n12(Dec 2000)pp30-35
    4. =IDEA UML SDL DYNAMIC FSM/STD MODEL TECHNICAL GRAPHIC
    5. p34:"Code is generally considered king, and the model as its poor country cousin."

    BjorkanderKobryn03

    1. Morgan Bjorkander & Cris Kobryn
    2. Architecting Systems with UML 2,0
    3. IEEE Software Magazine V20n4(Jul/Aug 2003)pp57-61
    4. =ADVERT PORT INTERFACE ACTIONS EXECUTABLE MODELING UML2.0
    5. Classes can have ports(square boxes on border). Ports have interfaces.
    6. Ports can be behavioral.
    7. Interfaces(lollipops) are either required (half circle) or provided interfaces(half circle).
    8. Ports can be connected: required to provided interfaces.
    9. Statemachines, interactions, and activities all can actions.
    10. Actions can be given precise -- executable -- semantics.

    Bjorner06

    1. Dines Bjorner
    2. Software Engineering 1, 2 and 3
    3. Springer-Verlag NY Secaucus NJ ISBN 3540211497 CR 0802-0113
    4. =UNREAD =ADVERT =EXAMPLES FORMAL DOMAIN MODEL REALITY RSL ABSTRACTION

    BjornerGeorgePrehn99

    1. Dines Bjorner & Chris George & Soren Prehn
    2. Scheduling and Rescheduling Trains
    3. In [HincheyBowen99] pp157-184 [ http://www.iist.unu.edu ]
    4. =EXPERIENCE DEMO FORMAL SPECIFICATION PROTOTYPING PRaCoSy lightweight RAISE RSL C train dispatching

    BjornerJones82

    1. ?? Bjorner & ?? Jones
    2. Formal Specification & Software Development
    3. Prentice Hall NJ 1982
    4. =ADVERT VDM formal language Technical

    Black95

    1. George Black
    2. British Government Puts New GUIs to the Test
    3. Software Magazine (May 1995)pp82-84
    4. =EXPERIENCE SSADM GRAPHIC USER GUI
    5. UK Customs & Excise Dept.
    6. SSADM (pre Vn4) not good for GUIs... using IEEE standards instead

    Blaha04

    1. Michael Blaha
    2. A Copper Bullet for software Quality Improvement
    3. IEEE Computer Magazine V37n2(Feb 2004)pp21-25
    4. =EXPERIENCE 11 years DATA MODEL REVERSE ENGINEERING QUALITY SOFTWARE PRODUCTS
    5. (1) how to grade a data base: ABCDF
    6. (2) expects grade of data base to be related to overall quality of software.
    7. (3) companies that do not allow there data base design to be reviewed automatically scores badly.
    8. Give a good list of common data defects.
    9. Figure 2 has a small UML error: switched multiplicities.

    BlackEtAl09

    1. Sue Black & Paul P Boca & Jonathan P Bowen & Jason Gorman & Mike Hinchey
    2. Formal versus agile: Survival of the Fittest
    3. IEEE Computer Magazine V42n9(Sep 2009)pp37-45 + Correspondence V42n11(Nov 2009)p6 by William Adams
    4. =SURVEY RESEARCH AGILE FORMAL MODEL CHECKING Alloy X-Machines SMV CTL KeY
    5. SEEFM2003::acronym="First South East Europe Workshop on formal methods", [ SEEFM03 ]
    6. XFM::="eXtreme Formal Modeling", [ 1109118.1109120 ]
    7. XFun::= See http://delab.csd.auth.gr/~bci1/SEEFM03/seefm03_03.pdf (PDF), Unified Process with X-Machines verified by model checking.
    8. KeY::method= See http://i12www.iti.uni-karlsruhe.de/~key/keysymposium07/slides/haehnle-agile.pdf
    9. Extend TDD by including static-analysis and theorem-proving tools to extend coverage. Example 97% of assertions checked automatically in SPARKAda toolset.
    10. How do formal requirements handle creep?
    11. Machine checked refactoring?
    12. Parallelism: FDR and Coverity [ http://www.coverity.com/ ]
    13. Speed and availability of tools: Rodin [ http://rodin.cs.ncl.ac.uk/ ]
    14. and Deploy [ http://www.deploy-project.eu/ ] projects. Praxis [ http://www.praxis-his.com/ ] has SPARK toolset as open source.
    15. Formal methods lite -- use math at the right times in a project.
    16. Argues that the total cost (effort) for a project is less with up front work getting requirements etc. right.
    17. Agility is not about speed but maneuverability. Producing the highest quality in each iteration/increment. Compared to RAD.
    18. Controlling the technical debt.
    19. No real conflict... given some mutual understanding.

    BlahaPremerlaniShen94

    1. Michael R. Blaha & William J Premerlani & Hwa Shen
    2. Converting OO Models into RDBMS Schema
    3. IEEE Software magazine v11n3(May 1994)pp28-39
    4. =ADVERT OBJECT_ORIENTED OMT DATA
    5. OMT is Figure A on pages 34-35 [Premerlanietal90] [PremerlaniBlaha94]

    BlahaPremerlani98

    1. Michael R. Blaha &William J Premerlani
    2. Object-Orietented Modeling and Design for Database Applications
    3. Prentice-Hall NJ 1997
    4. =MANUAL OBJECT-ORIENTED OOA/OOD DATA UML BNF for Object Navigation Notation [BlahaPremerlaniShen94]

    BlahaSmith02

    1. Michael Blaha & Cheryl Smith
    2. A Pattern for Softcoded Values
    3. IEEE Computer Magazine V35n5(May 2002)pp28-34
    4. =DEMO dynamic data types metamodel reflection
    5. Moves in the opposite orientation to objects!
    6. How to code an generalization hierarchy of attributes and values in data. : DescribedObjects and DescribedObjecTypes.
    7. Data use to Model attributes, values, units, constraints, generalization, etc
    8. Values include sources and dates: entry, effective, expiration.
    9. Does not handle behavioral inheritance.
    10. Each Value has a field for numeric datum AND string datum AND datetime datum. Constrained by ode so that only one is non-null!
    11. All generalizations has a discriminator attribute.

    BlairBencomoFrance09

    1. Gordon Blair & Nelly Bencomo & Robert B France
    2. Models@run.time
    3. IEEE Computer Magazine V42n10(Oct 2009)pp22-27
    4. =EDITORIAL IDEA EXECUTABLE REFLECTIVE MODEL
    5. Introduces papers pp28-68 about the advantages of a running system including a model (abstraction) that the system can access and update.

    Blank89

    1. GD Blank
    2. A Finite & Real-Time Processor for Natural Language
    3. Commun ACM v32 n10(Oct 1989)
    4. =DEMO DDD

    Blaschek94

    1. Gunther Blaschek
    2. Object-oriented programming with prototypes
    3. Springer-Verlag NY NY 1994 ISBN 0-387-56469-1 CR9502-0058
    4. =DEMO Objects without classes! Omega for the Macintosh

    BleisteinEtal87

    1. Sandra Bleistein & Robert Goetge & Frank Petroski & Robert Wiseman
    2. Capacity Management of Air Traffic Control Computer Systems.
    3. IEEE Computer Magazine V20n2 (Feb 1987)pp73-83
    4. =EXPERIENCE FAA AAS PERFORMANCE

    Blikle77

    1. Andrzej Blikle
    2. Co-Routines and Networks of Parallel Processes
    3. Proc IFIP 77 (North Holland Pub Co 1977) pp285-290. Also IRIA Raport de Recherche No 202 Nov 76
    4. =THEORY LOGIC SEMANTICS REGULAR-EXPRESSIONS

    Bliss42

    1. Charles K Bliss
    2. Semantography ( Blissymbolics) 2nd Edn
    3. Semantography ( Blissymbolics), Sydney Australia 1942 [ http://www.semantography.com/ ]
    4. =ADVERT GRAPHIC SYMBOLIC LANGUAGE GENERAL SEMANTICS RATIONALITY LOGIC
    5. Explains BlissSymbolics.
    6. Argues that Semantography helps spot crooked thinking and false arguments.
    7. Bliss Symbols include all internationally agreeed symbols: Math, Chem, Music,...
    8. Dictionary of symbols [ http://www.semantography.com/4/ ]

    Blood04

    1. Rebecca Blood
    2. How Blogging Software reshapes the online community
    3. Commun ACM V47n12(Dec 2004)pp53-55
    4. =ANECDOTE SOFTWARE BLOG
    5. Software tools change the way things are done and what words mean in powerful ways.

    Bloom83

    1. S L Bloom
    2. Algebraic Solution of a System of Recursion Equations in Infinite Trees Other Contraction Theories
    3. Journal of Computer & System Science 1983 pp225-255
    4. =THEORY TOPOLOGY

    BloomBEtal00

    1. Bard Bloom & Jim Russell & John Vlissides & Mark Wegman
    2. High-level Program Development
    3. Dr. Dobbs Special Report (Dec 2000)pp17-2
    4. =ADVERT TOOLs IBM DOMAIN MODEL WORKFLOW vs PERFORMANCE
    5. Enterprise Builder, Hyper/J, Dynamic Application Partitioning (DAP)

    BloomChengDsouza97

    1. Bard Bloom & Allan Cheng & Ashvin Dsouza
    2. Using a Protean Language to Enhance expresiveness in Specifications
    3. IEEE Trans Softw Eng VSE23n4(Apr 1997)pp224-234
    4. Using structural Operational semantics to construct and extend specification languages including CCS Z Petri nets. GSOS Simple BDD-based model checking. philosphers & lifts

    BloomEsik93

    1. Stephen L Bloom & Zoltan Esik
    2. Iteration Theories: Equational Logic of Iterative Processes
    3. EATCS monographs on Theoretical Computer Science Springer Verlag NY NY 1993 ISBN 0-387-56378-4 CR9505-0287 630 pages $109.00 Hardcover
    4. =MATHEMATICAL LOGIC ALGEBRA SEMANTICS
        Blurb: detailed investigation of the fixpoint/iteration operation. Universal Algebra. Correctness logic is a special case of the equational logic of Iteration theories. Ten year program... see Bloom83 CR9505-0287: categegory theory, slow and casual, nonstandard power functor, doesn't discuss dynamic algebras, algebras with star, action algebras, or process algebras.

    BloomfieldFroome86

    1. R E Bloomfield & P K D Froome
    2. The Application of Formal Methods to the Assessment of High Integrity Software
    3. IEEE Trans SE-12n9 (Sep 1986)pp988-993
    4. =CASE-STUDY Prolog VDL QUALITY

    Blum87

    1. Bruce I Blum
    2. A Paradigm for Developing Information Systems
    3. IEEE Trans Soft Eng VSE-13n4(Apr 1987)pp432-439
    4. =ADVERT DATA METHOD TEDIUM
    5. TEDIUM: all info about application is in data base(ADB) and product is generated automatically from database(FAP)
    6. Experiences: Used John Hopkins since 1980
    7. Demo on COCOMO example shows strong productivity increase(time ten times less!)

    Blum92

    1. Bruce I Blum
    2. Software Engineering: A Holistic View
    3. Oxford University Press London UK 1992 ISBN 0-19-507159-X $50 pp588
    4. Very positive reveiw by Dave Hurley(U Pittsburg) p113 IEEE Software Magazine July 1993 (RS100). Moderate review by Vaclav Rajlich(Wayne State U) p102 IEEE Computer Aug 1994

    Blum94

    1. Bruce I Blum
    2. A Taxonomy of Software Development Methods
    3. Commun ACM V37n11(Nov 1994)pp82-94 CR9602-0143
    4. history(pp84-90) methods
        Design methods include analysis...code. All based on ideas started in 1968-1977. No clear dividing lines between successive activities shift from life cycle to process Destinguishes: descriptive models("conceptual")(give guidance) from prescriptive models("formal")(establish criteria). and: problem oriented(focus on understanding the problem/solution) from product oriented(correct transformation from a prescription to a maintainable implementation). Four categories. problem oriented prescriptive models have potential automatic support for product oriented formal problem oriented tend to be descriptive and prescriptive tend to be product oriented.

        Mentions levels of abstraction, virtual machines, SWR, functional decomposition, structured design, coupling, cohesion, structure chart, information hiding, structured programming, proofs of correctness, algebraic specification, ADTs, structured analyisi, DFDs PSL/PSA, ERM(ERD), STD. petrie nets, warnier LCS (not LCP), JSP, JSD, VDM (not Z), OOP, OOA, Modern structured analysis, no silver bullets. ?? mathematical means top-down? isomorphism between problem and solution tension in development between need for subjective designs and formal programs.... top-down vs outside in, data flow vs data structure.


    Blum95

    1. Bruce I Blum
    2. Beyond Programming to a New Era of Design
    3. Oxford University Press 1995
    4. ISBN 0-19-509160 $40 CR9610-0771 reccommended in IEEE Software Mag July/Aug 1995
    5. =IDEA POSTMODERN

    Blythetal90

    1. David Blyth & Cornella Boldyreff & Clive Ruggles & Nik Tetteh-Lartey
    2. The Case for Formal Methods in Standards
    3. IEEE Software V7n5(sep 1990)

    Boasson93

    1. Maarten Boasson<boasson@hgl.signaal.nl>(Thomson)
    2. Exploding Complexity may be our own Fault(Insider Column)
    3. IEEE Software(Mar 1993)p12.
        ...TODO/0 Structure text Sent EMail, see Clippings....

    Bochenski89

    1. B Bochenski
    2. Importance of Optimization
    3. Software Magazine (Nov 1989) p79(Box)
    4. =IDEA data QUALITY

    Bochmann88

    1. Gregor von Bochmann
    2. Delay-Independent Design for Distributed Systems
    3. IEEE Trans Soft Eng VSE-14n8(Aug 1988)pp1229-1237
    4. =THEORY non-sequential STD/FSM timing theory
    5. regularity::=removing delays leads to equivalent states

    BochmannVerjus87

    1. Gregor von Bochmann & J P Verjus
    2. Some Comments on "Transition-Oriented" Versus "Structured" Specification of Distributed Algorithms and Protocols
    3. IEEE Trans Soft Eng VSE-13n4(Apr 1987)pp501-505
    4. =ESSAY reinvents JSP inversion in context of LOTOS SDL Estelle etc NONSEQUENTIAL

    Bock03

    1. Conrad Bock
    2. UML without Pictures
    3. IEEE Software Magazine V20n5(Sep/Oct 2003)pp33-
    4. =DEMO MODEL REPOSITORY UML2.0 SEMANTICS COMPILATION ACTIVITY
    5. Shows how a C++ function is represented by an activity diagram and by collection of objects (mini data base)that model the diagram -- a repository

    Bock05

    1. Conrad Bock
    2. UML 2 Activity and Action Models Part 6: Structured Activities
    3. JOT V4n3(May-Jun 2005) [ column4 ]
    4. =HOWTO UML2.0 STRUCTURE ACTIVITY interrupts exceptions REPOSITORY MODEL

    BockleClemensMcGregorMuthigSchmid04

    1. G|nter Bvckle & Paul Clemens & John D McGregor & Dirk Muthig & Klaus Schmid
    2. Calculating ROI for Software product lines
    3. IEEE Software Magazine V21n3(May/Jun 2004)pp23-31
    4. =DIALOG MATHEMATICS COSTS REUSE

    Boddie87

    1. John Boddie
    2. Crunch Mode
    3. Yourdon Press/Prentice Hall NJ 1987
    4. =HANDBOOK lifecycle SAD PURPOSE QUALITY

    BodinGordonLoeb05

    1. Lawrence D Bodin & Lawrence A Gordon & Martin P Loeb
    2. Evaluating information security using the analytic hierarchy process
    3. Commun ACM V48n2(Feb 2005)pp79-83
    4. =ADVERT AHP SECURITY QUALITIES TRADEOFFS COTS DECISIONS
    5. AHP [Saaty80]

    BodolfKingBen-Menachem05

    1. David Bodolf & Patrick C K King & Mordechai Ben-Menachem
    2. Web Metadata Standards: Observations and Prescriptions
    3. IEEE Software Magazine V22n1(Jan /Feb 2005)pp78-85
    4. =ESSAY WEB STANDARDS METADATA ONTOLOGIES AI Table 1 page 80: List of standards: ebXML, CPP, WSDL, UDDI, SOAP, WS-Security, P3P, DC, CIMI, OWL. Suggests
      1. Don't ignore testing, SQA and other long standing problems.
      2. Don't target a standard at too many purposes/uses.
      3. To find things may need meta-meta-data. Need tools to support search and navigation through classifications and thesau rus hierarchies.
      4. Don't add useless indexing. Don't work at too high a level and allow too much freedom at more concrete lev els. Conventional ontologies should be limited to narrow domains until more reliable methods to develop ontologies are developed.

    Boegh08

    1. Jorgen Boegh
    2. A New Standard for Quality Requirements
    3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp60-
    4. =STANDARD QUALITIES MANAGEMENT MODEL MEASUREMENT REQUIREMENTS EVALUATION ISO/IEC 25030 SQuaRE
    5. ISO 9126 Quality model{ {External, Internal}><{Functionality, Reliability, Usability, Maintainability, Portability}, Quality in Use {Effectiveness, Productivity, Safety, satisfaction }}
    6. Distinguish: computer system, mechanical part, Human process.
    7. Computer system: hardware, software, and data -- all with qualities.
    8. Stakeholder needs ->(definition)->Stakeholder requirements ->(Analysis)-> System Requirements.
    9. Many more details...

    Boehm80a

    1. Barry Boehm
    2. Software engineering - as it is
    3. See FreemanLewis80 pp 149-179
    4. =survey

    Boehm80b

    1. Barry Boehm
    2. Software Engineering Economics
    3. Prentice Hall International 1980
    4. =TEXT QUALITY ENGINEERING costs

    Boehm87

    1. Barry Boehm
    2. Industrial Software Metrics Top Ten List
    3. IEEE Software V4n5(Sep 1987)pp84-85
    4. =EXPEREINCE QUALITY

    Boehm96

    1. Barry Boehm(USC)
    2. Helping students Learn Requirements Engineering(abstract)
    3. Preliminary program conf on Softw Eng Education April 1996
    4. =EDUCATION REQUIREMENTS
    5. "Many software engineering courses (and methods) begin with an assumption that software requirements are presented to software engineers in a complete
    6. consistent
    7. feasible
    8. testable
    9. and traceable form
    10. and that the software engineer's main job is to correctly transform the requirements into code. This is generally an unhealthy approach
    11. as the requirements for virually alll significant software products are to some degree unknown
    12. unknowable
    13. or the results of compromises requiring the software engineer's participation and expertise."

    Boehm99

    1. Barry Boehm(USC)
    2. Making RAD Work for Your Project
    3. IEEE Computer V32n3(Mar 1999)pp113-114+117
    4. =ESSAY Types of RAD: DRAD(Bumb RAD=deathmarch).. SAIV(Schedule as Independent Variable) etc etc. See USC-CSE-99-512 on [ electronicopy.html ] for PDF formatted extended version

    Boehm00

    1. Barry Boehm
    2. Unifying Software Engineering and Systems Engineering
    3. IEEE Computer Magazine V33n3(Mar 2000)pp114-116
    4. =IDEA SYSTEMS QUALITY determine ARCHITECTURE + COST REQUIREMENTS should be part of SOFTWARE ENGINEERING

    Boehm00

    1. Barry Boehm
    2. Requirements that handle IKIWISI, COTS, and rapid change
    3. IEEE Computer Magazine V33n7(Jul 2000)pp99-102
    4. =ESSAY REQUIREMENTS EVOLUTION INFORMATION HIDING INCREMENTAL
    5. IKIWISI::=I'll know it when I see it.
    6. p99: "requirements tend to emerge with continued use".
    7. COTS, p99: "capailities determine the requirements".
    8. WWW change "an impossible to win game of catch-up".
    9. p100: "avoid one-size-fits-all approaches to requirements".
    10. new kindsof requirements: value-driven, sared-vision, change-driven, and risk driven.
    11. benefits vs schedule, business consequences and assumptions, require some room for likely changes like addin low priority needs, in orout? -- minimize the risk.

    Boehm00a

    1. Barry Boehm
    2. Project Termination doesn't Equal Project Failure
    3. IEEE Computer Magazine V33n9(Sep 2000)pp94-96
    4. =ESSAY SURVEY PROCESS RISK
    5. Competitive edge means risk. "You shouldn't expect all your risky projects to succed."
    6. manage your products.
    7. manage risk with incremental commitment.
    8. use architecture reviews, feasibillty rationales.
    9. monitor assumptions.
    10. Standish Group reported in 1995 [ chaos.htm ] that 31.1% of projects get cancelled before completion .
    11. Hayes97, computerworld nov 3 1997, managing user expectations.

    Boehm00b

    1. Barry Boehm
    2. Safe and Simple software cost analysis
    3. IEEE Software Magazine V17n5(Sep/Oct 2000)pp14-17
    4. =ADVERT COCOMO II ESTIMATING COST
    5. tables diagrams and examples. Pointers to tools.

    Boehm02

    1. Barry Boehm
    2. Get Ready for Agile Methods, with Care
    3. IEEE Computer Magazine V35n1(Jan 2002)pp64-69
    4. =IDEA XP AGILE adaptive risk-driven plandriven CMM
    5. Presents a spectrum of processes from Hacking to Inch-pebble ironbound contract. XP is the limit of th CMM range.
    6. Agile processes must have involved clientele. Plan-driven must have stable requirements.
    7. There exist requirements that break architectures.
    8. Shows graphs of risk exposure vs amount of planning for different losses that have to be traded-off at a sweet spot.
    9. For L:loss, risk_exposure(l)::=P[L] * size(L).

    Boehm08

    1. Barry Boehm
    2. Making a Difference in the Software Century
    3. IEEE Computer Magazine V41n3(Mar 2008)pp32-38
    4. =ESSAY IDEAS ACRONYMIC CATCHPHRASES ONESIZE OSUFA BITAR IKIWISI DAVAS SISOS TANIA
    5. Rapid change vs
    6. THWADI::="Thats How We've Always Done It".
    7. Uncertainty and Emergence. Cone of Uncertainty. [Armour08]
    8. BITAR::="Buy Information To Avoid Risk", Do extra things to reduce uncertainty. Tackle risks early.
    9. IKIWISI::="I'll know it when I see it". So Iterate.
    10. Dependability
    11. DAVAS::="Dependability As Value Assured to Stakeholders". Example of conflicting values in a well known failed project.
    12. Diversity.
    13. OSUFA::="One Size Fits All". Culture makes a difference in the adoption of process standards.
    14. SISOS::="Software Intensive Systems of Systems". OSUFA leads to failure
    15. Interdependence.
    16. TANIA::="There Are No Islands Anymore". No part of a system or of a process is isolated.
    17. Figure 5, p36: Activities >< Phases >-> Level_of_activity, CF RUP.
    18. SISOS need more time for Architecture and Risks.

    BoehmAdve12

    1. Hans-J. Boehm & Sarita V Adve
    2. You don't know Jack about shared variables or memory models
    3. Commun ACM V55n3(Feb 2012)48-54 [ 20764506.2076465 ]
    4. =DEMO RISKY BUGGY CODE SHARED VARIABLES DATA RACES MPI Pthreads Mutex synchronization
    5. Defines a data race as when two threads can access the same memory locations and one at least is a write and the instructions can execute at the same time.
    6. Demonstrates that data races are evil.

    BoehmBasili00

    1. Barry Boehm & Victor R Basili
    2. Gaining intellectual control of Software Development
    3. IEEE Computer Magazine V33n5(May 2000)pp27-33
    4. =ESSAY RESEARCH PLANNING PITAC NSF AESOP COTS PEOPLE SCIENCE ENGINEERING
    5. President's information technology advisory committee
    6. Report on two workshops.
    7. great software depends on more than good engineering or just good technology.
    8. need to study rea,l projects and compare successes and failures.
    9. confusing table mapping dependencies of key challenges on software eng technologies and these technologies on underlying science.
    10. need for domain science!

    BoehmBhuta08

    1. Barry Boehm & Jesal Bhuta
    2. Balancing Opportunities and Risks in Component-based software development
    3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp56-63
    4. =IDEA =EXAMPLE JPL PROCESS INCREMENTAL COMMITMENT ITERATION RISKs STAKEHOLDERS
    5. ICM::acronym="Incremental Commitment Model",
    6. ICM::lifecycle=exploration; valuation; foundations; develeopment & foundations; do(Operations & Development & Foundations ).
    7. Mentions example of an architectural mismatch leading to a 4 times over-run, taking 5 person-years rather than 1.

    Boehmetal97

    1. Barry Boehm & Alex Egyed & Julie Kwan & Ray Madachy
    2. Developing Multimedia Applications with the WinWin Spiral Model

      [JazayeriSchauer97] pp20-39

    3. =DEMO PROCESS TOOLs
    4. students develop multimedia systems for USC library in 11 weeks
    5. key milestones=life_cycle_objectives life_cycle_architecture initial_operational_capability.

    BoehmHuang03

    1. Barry Boehm & Li Guo Huang
    2. Value-Based Software Engineering: A case Study
    3. IEEE Computer Magazine V36n3(Mar 2003)pp33-41
    4. =CASESTUDY ECONOMIC REQUIREMENTS PROCESS ESTIMATING AGILE FEEDBACK
    5. Software can/does fail because of business non-technical value errors. See [ http://www.standishgroup.com/ ] CHAOS report.
    6. Need to track the business value of all tasks performed and needed and use this to adjust plans.
    7. initiative #(->cause_effect) ->assumptions
    8. EDSER::="Economics-Driven Software Engineering Research", [ http://www.edser.org ]

    BoehmHuangJainMadachy04

    1. Barry Boehm & LiGuo Huang & Apurva Jain & Ray Madachy
    2. The ROI of Software Dependability: The iDAVE Model
    3. IEEE Software Magazine V21n3(May/Jun 2004)pp54-61
    4. =CASESTUDY COCMO RELIABILITY ECONOMICS COQUALMO MTBF NASA OrderProcessing
    5. iDAVE::="information Dependability Attribute Value Estimation".
    6. Estimates the rate of introduction and removal of defects and the effect on the MTBF.
    7. MTBF::="Meantime before Failure",
    8. MTTR::="Meantime to Repair".
    9. MTBF and MTTR leads to Availability.
    10. Availability changes Benefit.
    11. Hence ROI.
    12. Does not quantify risks such as loss of life and reputation.

    BoehmIn96

    1. Barry Boehm & Hoh In(USC)
    2. Identifying Quality-Requirement Conflicts
    3. IEEE Software magazine V13n3(Mar 1996)pp25-35
    4. =ADVERT TOOL QUALITY conflicts
    5. QARCC Knowledge-based groupware tool WinWin Stakeholders--<quality attributes<>-<>Techniques

    BoehmPapaccio88

    1. Barry W Boehm & Philip N Papaccio
    2. Understanding and Controlling Software Costs
    3. IEEE Trans Soft Eng VSE-14n10(Oct 1988)pp1462-1477
    4. =IDEA spiral model+value chain+oportunity tree COST

    5. Conclude: important & contolling cost means controlling quality & less new code by best people with little rework and integrated support environment

    BoehmPortAl-Said00

    1. Barry Boehm & Dan Port & Mohammed Al-Said
    2. Avoiding the Software Model-Clash Spider-web
    3. IEEE Computer Magazine V33n11(Nov 2000)pp120-122
    4. =IDEA SUCCESS MODELS PQRST Mbase stake holders Master Net
    5. Stakeholder := user | acquirer | developer | maintainer | ... | public.
    6. Each stake holder has a different model of what is needed.
    7. Each model is a set of assumptions.
    8. Classified as process, product, property, and success.
    9. Could use purpose, qualities, techniques, team, etc .
    10. Clashes can occur between and within different stakeholder models.
    11. Has been used two diagnose problems quickly in large and small projects.
    12. interesting spider-web diagram on p121.
    13. Mbase::= See http://sunset.usc.edu/research/MBASE.

    BoehmTurner03a

    1. Barry Boehm & Richard Turner
    2. Using Risk to Balance Agile and Plan-Driven Methods
    3. IEEE Computer Magazine V36n6(Jun 2003)pp57-66
    4. =ADVERT one-size situation risk process agile vs planned anchor mbase rup xp spiral modules
    5. Based on book by same authors... [BoehmTurner03b].
    6. Sidebar pp58-59: defines home grounds for agile and plan-based processes plus five critical factors: size, criticality, dynamism, personnel, and culture. Kiviat style polar chart.
    7. sidebar p60:misquotes Cockburn03. 3 levels of skill.
    8. figure 1 p60. idea: if situation does not fit either agile or planned then architect the project into agile and planned parts.
    9. p63: can focus testing on the high-risk parts.
    10. fig 4 p65: 3 kinds of risk: environmental, agile, plan-driven. ranges: minimal..showstopper.

    BoehmTurner03

    1. Barry Boehm & Richard Turner
    2. Balancing agility and Discipline: A guide for the perplexed
    3. Addison-Wesley Longman Boston MA 2003 ISBN 0321186125
    4. =UNREAD =SYNTHESIS AGILE ONESIZE CR 0410-1130
    5. Avertized in [BoehmTurner03a].

    BoehmTurner05

    1. Barry Boehm & Richard Turner
    2. Management Challenges to Implementing Agile Processes in Traditional Development Organizations
    3. IEEE Software Magazine V22n5(Sep/Oct 2005)pp30-39 =REPORT WORKSHOP Management Agile vs Traditional People Organizations Culture
    4. p34. Sidebar lists 8 nonproblems + 10problems due to size/scope + 18 significant issues.
    5. Authors make suggestions.

    BoerFarenhorst08

    1. Remco C de Boer & Rik Farenhorst
    2. In search of 'Architectural Knowledge`
    3. ICSE 2008, 3rd I workshop on Sharing and reusing architectural knowledge (2008) pp71-78 [ 1370062.1370080 ]
    4. =SURVEY 115 ARCHITECTURE SEMANTICS
    5. Number of relevant papers increasing exponentially.
    6. Out of 115 papers, 14 give a clear definition. 7 in 2007 alone.
    7. Abstract
        The software architecture community puts more and more emphasis on 'architectural knowledge'. However, there appears to be no commonly accepted definition of what architectural knowledge entails, which makes it a fuzzy concept. In order to obtain a better understanding of how different authors view 'architectural knowledge', we have conducted a systematic review to examine how architectural knowledge is defined and how the different definitions in use are related. From this review it became clear that many authors do not provide a concrete definition of what they think architectural knowledge entails. What is more intriguing, though, is that those who do give a definition seem to agree that architectural knowledge spans from problem domain through decision making to solution; an agreement that is not obvious from the definitions themselves, but which is only brought to light after careful systematic comparison of the different studies.

    BoerVliet08

    1. Remco C de Boer & Hans van Vliet
    2. On the similarity between requirements and architecture
    3. Journal of Systems and Software V82n3(Mar 2009)pp544-550
    4. =ESSAY REQUIREMENTS = DECISIONS ARCHITECTURAL KNOWLEDGE
    5. Abstract
        Many would agree that there is a relationship between requirements engineering and software architecture. However, there have always been different opinions about the exact nature of this relationship. Nevertheless, all arguments have been based on one overarching notion: that of requirements as problem description and software architecture as the structure of a software system that solves that problem, with components and connectors as the main elements.

        Recent developments in the software architecture field show a change in how software architecture is perceived. There is a shift from viewing architecture as only structure to a broader view of `architectural knowledge` that emphasizes the treatment of architectural design decisions as first-class entities. From this emerging perspective we argue that there is no fundamental distinction between architectural decisions and architecturally significant requirements. This new view on the intrinsic relation between architecture and requirements allows us to identify areas in which closer cooperation between the architecture and requirements engineering communities would bring advantages for both.


    Bogart91

    1. Kenneth P Bogart
    2. An Obvious Proof of Burnside's Lemma
    3. American Math Monthly V98n12(Dec 1991)pp927-928
    4. "a function f from set S to a set T defines a multiset of size |S| chosen from T in which the multiplicity of t ∈ T is the number of s ∈ S with f(s)=t" =map[t:T]|/f(t)| = /f; Card= Card o /f. +(Card o /f)=Card o dom(f).

    Bohlen02

    1. Boris Bohlen & Dirk Jager & Ansgar schleicher
    2. UPGRADE: building interactive tools for visual languages

      [SCI2002] V1(Jul 2002)

    3. =EXPERIENCE VISUAL GRAPHIC TOOLS

    BohmJacopini66

    1. Corrado Bohm & Giuseppe Jacopini
    2. Flow Diagrams, Turing Machines, and Languages with only Two Formation Rules
    3. Commun ACM V9n5(May 1966)pp366-71 [ 355592.365646 ]
    4. =THEORY Structured programming technical sequential proof
    5. The key paper that allowed structured programming to take off.
    6. (BohmJacopini)|-All programs can be reprogrammed using sequence, selection, and iteration and no other structures.

    BojicEtal04

    1. Dragan Bojic & Thomas Eisenbarth & Rainer Koschke & Daniel Simon & Dusan Velasevic
    2. Addendum to "Locating Features in Source Code"
    3. IEEE Trans Software Engineering V30n2(Feb 2004)p140
    4. =SURVEY CONCEPT ANALYSIS
    5. Ball: tests vs parts of programs to help testing.
    6. BojicVelaseic: usecase vs parts of programs refactoring in UML.
    7. EisenbarthKosckeSimon: scenarios vs functional blocks to aid traceability

    BojicVelasevic00

    1. Dragan Bojic & Dusan Velasevic
    2. Reverse Engineering of Use Case Realizations in U ML
    3. ACM SIGSOFT Software Engineering notes V25n4(Jul 2000)pp56-61
    4. =IDEA VisualC++ TEST profiling LOGIC DA-C
    5. use concept analysis to convert profiles of test executions into lattices of use-cases

    Bokowski99

    1. Boris Bokowski
    2. CoffeeStrainer: Statically-checked Constraints on the Definition and use of Types in Java
    3. ESEC/FSE'99 SIGFOFT SE Notes V24n6(Nov 1999)pp355-374
    4. =TOOL JAVA V&V CORRECTNESS TYPES CONSTRAINTS

    BollellaGosling00

    1. Greg Bollella & James Gosling
    2. The Real-time specfication for java
    3. IEEE Computer Magazine V33n6(Jun 2000)pp47-54
    4. =HISTORY OBJECT-ORIENTED NET PERFORMANCE RTSJ RTJEG NIST STANDARD

    Bollinger95

    1. Terry Bolinger(DSC Communications)
    2. What can Happen when Metrics Make a Call
    3. IEEE Software Magazine V12n1(Jan 1995)pp15
    4. Distinguish feature metrics from derived metrics. derivation: equation supposed to show progress towards goal
    5. Dangers of Bogus metrics (eg lines of code). pressures practitioners into doing bad things almost inevitable
    6. need to listen to developers very carefully: can give a good metrics program & get some serious buy-in as well

    Bollinger00

    1. Terry Bollinger
    2. Visual Basic: Taming the woolly mamoth
    3. IEEE Software Magazine V17n3(May/Jun 2000)pp16-17
    4. =ESSAY COBOL BASIC THEORY vs PRACTICE
    5. why two very popular languages have so few papers written about them?

    BollingerBeckman99

    1. Terry Bollinger & Peter Beckman
    2. Linux on the Move
    3. IEEE Software Magazine V16n1(Jan/Feb 1999)pp30-35
    4. =HISTORY open-source development TECHNICAL
    5. only use honest unmanaged of code peer review

    Bolloju04

    1. Narasimha Bolloju
    2. Improving the quality of business object models using Collaboration patterns
    3. Commun ACM V47n7(Jul 2004)pp81-86
    4. =EXPERIMENT MODEL REALITIES PATTERN UML COMPOSITION
    5. Based on Coad and Fowler lists 12 simple patters that helped students improve their conceptual models in 13 different business application domains: spotting classes and connections, plus correcting errors.
    6. Collaboration_patterns::#Pattern=following,
      • E1: Role (1)-(0..*) Transaction
      • E6: Transaction (1)-(0..*) FollowupTransaction E5: Specification (1)-(0..*) Transaction
      • E3: CompositeTransaction (1)<*>-(0..*) LineItem
      • E2: Place (1)-(0..*) Transaction
      • R: Actor (1)-(0..*) Role
      • T1: Item (1)-(0..*) SpecificItem
      • T4: Group (1)<>-(0..*) Member
      • E4: SpecificItem (1)-(0..*) Transaction
      • T2: Assembly(1)<*>-(0..*) Part
      • P: OuterPlace (1)-(0..*) Place
      • T3: Container (1)<*>-(0..*) Content
    7. Next [BollojuLeung06]

    Bolloju09

    1. Narasimha Bolloju
    2. Conceptual Modeling of Systems Integration Requirements
    3. IEEE Software Magazine V25n5(Sep/Oct 2000)pp66-74
    4. =EXPERIMENT METHOD NOTATION SYSTEM REQUIREMENTS SERVICES
    5. Graph: Nodes represent subsystems and transformations. Arcs labelled with conditions and messages.
    6. Transformations: BATCH and SPLIT, AGGREGATE and DISTRIBUTE, X(translation).
    7. Uses <....> to indicate refined subsystem.
    8. Tested an 78 graduate students who found it usable.

    BollojuLeung06

    1. Narasimha Bolloju & Felix S K Leung
    2. Assisting Novice Analysts in Developing Quality Conceptual models with UML
    3. Commun ACM V49n6(Jun 2006)pp108-112
    4. =EMPIRICAL 15 PROJECTS UML UseCase Domain ERD sequence diagram model V&V SQA REQUIREMENTS CSCI372 CSCI375
    5. Table 3 lists the commonest errors by artifact
      Table
      ArtifactSyntaxSemanticsPragmatics
      Use Case Diagrambad notationbad extendscases too small?
      Use Case Descriptionmismatch name with diagram MIssing and ambiguous steps, invalid extension steps too small and implementation dependent
      Class Diagrams not listing operations in sequence diagram or listing implicit operations wrong multiplicity, mislocated attributes and operations, unrealizable operation Subclasses not distinguished, showing inherited attributes
      Sequence Diagram missing "found" signal, return to wrong object, class not on class diagram missing parameters, parameters used before set, missing classes Responsibility misallocated to wrong object [Larman05]

      (Close Table)
    6. Ref to [LindlandSundreSolvberg94] for qualities of conceptual models.
    7. Also see [Bolloju04]

    Bolognesi00

    1. Tommaso Bolognesi
    2. Toward Constraint-Object-Oriented Development
    3. IEEE Trans Software Engineering V26n7(Jul 2000)pp594-616
    4. =EXAMPLE OBJECT-ORIENTED SPECIFICATION DESIGN STYLE COO LOTOS CO-NOTATION Z GRAPHIC

    BolognesiBrinkma95

    1. T. Bolognesi & Ed Brinksma
    2. Introduction to the ISO specification language LOTOS
    3. Comput Network and ISDN Syst V14n1(1987)pp25-29

    Bolognesietal95

    1. T. Bolognesi & Jeroen van de Lagemaat (mailto:lagemaat@cs.utwente.nl) & C.A. Vissers (ed)
    2. LOTOSphere: Software Development using LOTOS
    3. Kluwer Academic Publishers 1995 ISBN 0-7923-9529-8
    4. =ADVERT LOTOS TOOLS

    Bolt84

    1. ?? BOLT
    2. Human interfaces for managers
    3. Computer World v16 (July 1984) pp In Depth/1..18
    4. =ARTICLE USER

    BoltaciJones95

    1. L. Boltaci & J.Jones
    2. Formal specification using Z: A modeling approach
    3. International Thomson Publishing London 1995.
    4. =DEMO MODEL Z SPECIFICATION FORMAL

    Bond95

    1. David Bond
    2. Project-Level Archetypes
    3. Software Development Magazine(Jul 1995)pp39-44+letter (Oct 1995)p11
    4. =IDEA DOMAINs ECONOMICS one-size does not fit all
    5. Suggests that different industries/situations have different "best practices". four models:
      1. constrained
      2. internal client
      3. vertical market
      4. mass market.

    6. cf [Constantine95b]
    7. Letter points out the additional complexity of producing software is the need to integrate the new into existing systems.

    BondAnderson01

    1. Mike Bond & Ross Anderson
    2. API-Level Attacks on Embedded Systems
    3. IEEE Computer Magazine V34n10(Oct 2001)pp67-75
    4. =HISTORY DESIGN SECURE INTERFACE CRYPTOGRAPHY ATMS COMMERCIAL IBM Visa VSM
    5. Using formal methods to calculate new attacks on ATMs!
    6. How to split a key so that it can be transmitted to a device securely in shares and combined internally so that the right key is installed and nobody knows what it is -- even if < n people collude, even if shareholders lie about their shares to the device!

    BondG05

    1. Gregory W Bond
    2. Software as Art
    3. Commun ACM V48n8(Aug 2005)pp118-124
    4. =ESSAY ART
    5. Knuth

    BonifattiEtal01

    1. Angela Bonifatti & Fabiano Cattaneo & stafano Ceri & Alfonso Fuggetta & Stefano Paraboschi
    2. Designing Data Marts for Data Warehouses
    3. ACM TOSEM Trans Software Engineering & Methodology V10n4(Oct 2001)pp452-483
    4. =CASESTUDY DATA OLAP REQUIREMENTS GQM Star ERD C-Graph snowFlake

    BontempsHeymansSchobbens05

    1. Yves Bontemps & Patrick Heymans & Pierre-Yves Schobbens
    2. From Live Sequence Charts to State Machines and Back: A Guided Tour
    3. IEEE Trans Software Engineering V31n12(Dec 2005)pp999-1014
    4. =THEORY REQUIREMENTS SCENARIOS SSDs MSC Message Sequence diagrams LSC Live sequence charts FSM/STD STATE CHARTS
    5. Proves that most problems linking message sequence charts to state based models are intractable -- efficient automation may be impossible. [Harel01]

    Booch83

    1. G Booch
    2. Software Engineering with Ada
    3. Benjamin Cummings 1983
    4. =HOWTO object-oriented graphic text Reality Technical

    Booch86

    1. Grady Booch
    2. Object Oriented Development
    3. IEEE Trans Soft Eng vSE-12n2(Feb 1986)pp211-221 (in BerglandZave86)
    4. =HOWTO Ada graphic Reality object

    Booch91

    1. Grady Booch
    2. Object Oriented Design with applications
    3. Benjamin Cummins Redwood City CA 1991 ISBN 0-8053-0091-0 CR9105-0322 & CR 9209-0690 & CR9404-0198
    4. =HOWTO [Booch94a instead]

    Booch94a

    1. Grady Booch(Rational)
    2. Object Oriented Analysis and Design with applications(2nd Edn)
    3. Benjamin Cummins Redwood City CA 1994
    4. ISBN 0-8053-5340-2 CR9502-0135"Marked improvement over the first edition while retaining the outstanding features of the original"(T H Tse)

    Booch94b

    1. Grady Booch
    2. Coming of Age in an Object-Oriented World
    3. IEEE Software Magazine V11n6(Nov 1994)pp33-41
        p35: distinguishes "off the shelf" from "custom"
      1. off the shelf
      2. Codifies a specific and well understood horizontal domain
      3. large market
      4. driven to higher technical sophistication by the market
      5. beomes a commodity item
      6. Custom
      7. Vertical business line
      8. includes off the shelf components
      9. must be as complex as the domain
      10. domain is not well understood and is complex.

      11. OO::=Net{Abstraction, Encapsulation, Inheritance, Polymorphism}.

        OO{programming, methods, infrastructure}

        Increasing focus on architectures rather than just classes

        Includes RDBMSs as OO.


    Booch99

    1. Grady Booch(guest editor)
    2. UML in action
    3. Commun ACM V42n10(Oct 1999)pp26-70
    4. See [Kobryn99] [Larsen99] [Selic99] [BellSchmidt99] [Conallen99]

    Booch01

    1. Grady Booch
    2. The Illusion of Simplicity
    3. Software Development Magazine V9n1(Jan 2001)pp57-59
    4. =ARTICLE PQRST MODEL MODULE
    5. Forces on software development: cost/schedule, functionality, compatibility, reliability/availability, security, failsafe/fault-tolerance, Resilience, technology churn, scalability, capacity, Performance
    6. help: abstractions: Object-Oriented , patterns, modeling
    7. balance and mitigating conflicting forces.

    Booch01b

    1. Grady Booch
    2. Developing the Future
    3. Commun ACM V44n3(Mar 2001)pp119-121
    4. =POLL OPINION PEOPLE SWEBOK XP Opensource
    5. Future: split betwen high and low ceremony processes leading to some reconciliation.
    6. More user-programmers vs a more mature profession.

    Booch06

    1. Grady Booch
    2. The Accidental Architecture
    3. IEEE Software Magazine V23n3(May/Jun 2006)pp9-11
    4. =ESSAY ARCHITECTURE =HISTORY WWW/NET PATTERNS
    5. Notes that we don't have a comprehensive list of architectures for software.
    6. ... unlike buildings: Babylonian, Greek, ...
    7. Refers to Henry Petroski.
    8. Describes a history of the WWW architectural styles: Plain HTML, Eye-Candy, simple scripting, middleware, simple frameworks, rich-client | service-oriented architecture.
    9. Argues that architectural patterns emerge from a experience.

    Booch06a

    1. Grady Booch
    2. Goodness of fit
    3. IEEE Computer Magazine V39n10(Oct 2006)pp14-15
    4. =ESSAY ARCHITECTURE STYLE PATTERNS FORTRAN COMPILER
    5. Bachus's original pipe-and-filter architecture for FORTRAN compilation remains good for recent languages....with some small tweaks.
    6. Does not mention [Jackson75]'s use of pipe+filter in Data Processing and McIlory's pipes in UNIX.
    7. For a given set of forces there is a better architecture. The forces in a given domain are pretty constant.

    Booch07

    1. Grady Booch
    2. Object-oriented analysis and Design with Applications
    3. Addison Wesley Longman Redwood City CA 2007 ISBN 020189551X CR 0808-0732
    4. =UNREAD =HOWTO ANALYSIS DESIGN OBJECTS
    5. Notes [click here [socket symbol] Booch07 if you can fill this hole]

    Booch10

    1. Grady Booch
    2. Enterprise Architecture and Technical Architecture
    3. IEEE Software Magazine V27n2(Mar/Apr 2010)pp96+95
    4. =ESSAY TECHNICAL vs SYSTEM
    5. Enterprise Architecture and Technical Architecture speak about different things mostly, so keep the notations etc. separate.
    6. One is about the organisation and the other about the software.
    7. Many more frameworks for doing enterprise architecture than technical architecture.

    Booch10a

    1. Grady Booch
    2. Architecture Reviews
    3. IEEE Software Magazine V27n3(May/Jun 2010)pp96+95
    4. =EXPERIENCE ARCHITECTURE REVIEWS CONFIDENCE QUALITIES ALTERNATIVES TRIAGE ASSUMPTIONS REALITIES
    5. Constructive Conflict. A review that just involves people nodding as artifacts are presented is a waste of time.
    6. Focus on the forces that shape the system.
    7. ATAM::="Architecture Tradeoff Analysis Method", [ http://www.sei.cmu.edu/architecture/start/glossary/ ]
    8. Name significant design decisions.
    9. Looking for a good enough plan to proceed. There is no single right answer.
    10. Deciding whether to fix or to replace?

    Booch10b

    1. Grady Booch
    2. An architectural oxymoron
    3. IEEE Software Magazine V27n5(Sep/Oct 2010)pp96+95
    4. =ADVERT AGILE ARCHITECTURE REQUIREMENTS DESIGN DECISIONS
    5. Pointers to pages: Ambler, Wikiwiki, Coplien, Kruchten, ...
    6. Need to socialize important design decisions and their rationale.

    Booch10c

    1. Grady Booch
    2. The elephant and the blind programmers
    3. IEEE Software Magazine V27n6(Nov/Dec 2010)pp88+87
    4. =FABLE ENTERPRISE ARCHITECTURE VIEWPOINTS POV RASHOMON
    5. so what do you think "the enterprise" is?

    Booch12

    1. Grady Booch
    2. The Professional Architecture
    3. IEEE Software Magazine V29n1(Jan/Feb 2012)pp12-13
    4. =ESSAY ARCHITECTURE TECHNICAL SOCIAL
    5. Complex balance between technology and needs,
    6. Tension between discovery, invention, and implementation, ...

    Boogie09

    1. Microsoft Research
    2. Boogie -- The World's Best Program Verification System
    3. Web site Aug 27th 2009 [ http://boogie.codeplex.com/ ]
    4. =ADVERT OPEN SOURCE VERIFIER SQA PROOF NONSEQUENTIAL TOOL #
    5. "Boogie is a program verification system that produces verification conditions for programs written in an intermediate languagec (also named Boogie). The intermediate language is easy to target from source languages such as Spec#, C#, or even C."

    BoralvStalmarck99

    1. Arne Boralv & Gunnar Stalmarck
    2. Formal Verification in Railways
    3. In [HincheyBowen99] pp329-350
    4. =EXPERIENCE RISKS SPECIFICATION STD/FSM LOGIC TPA vs DESIGN V&V TOOL Prover Delphi for ADtranz CVT Swedish Sternol
    5. Prover is a Company specializing in the industrialization of formal methods. Stalmarck has patented the proof algorithm!
    6. Can we make a formal tool that is as transparent to use as a word processor? Some parts need a formal methods expert, but some parts can be made more useful to railway interlocking engineers.
    7. Need to trade-off expressive power of logic with the performance of the tool.
    8. Claims that ONLY domain/application knowledge is needed to use the tools.

    Borger88

    1. Egon Bo"rger(Ed)
    2. Trends in Theoretical Computer Science
    3. Computer Science Press Rockville Maryland 1988
    4. =Series: Principles of Computer science series

      [Gurevich88]

    BorgerSchulte00

    1. Egon Bo"rger & Wolfram Schulte
    2. A Practical Method for Specification and Analysis of Exception Handling -- A Java/JVM Case Study
    3. IEEE Trans Software Engineering V26n9(Sep 2000)pp872-887
    4. =CASESTUDY LOGIC SPECIFICATION SEMANTICS JAVA COMPILER JVM PROOF

    Borgida85

    1. Alexander Borgida
    2. Features of Languages for the Development of Information Systems at the Conceptual Level
    3. IEEE Software V2n1(Jan 1985)pp63-72
    4. =SURVEY data concepual modeling

    Borgidaetal95

    1. Alex Borgida & John Mylopoulos & Raymond Reiter
    2. The frame problem in procedure specifications
    3. IEEE Trans on Software Eng VSE-SE-21n10(Oct 1995)pp785-798
    4. =CRITIQUE LOGIC Set Theory SPECIFICATION METHODS circumscription [BorgidaMylopoulosReiter93] JacksonD9 [McCarthy87] [Delgrande98]

    BorgidaGreenspanMylopoulos85

    1. Alexander Borgida & Sol Greenspan & John Mylopoulos
    2. Knowledge Representation as the Basis for Requirements Specifications
    3. IEEE Computer MAgazine V18N4(Apr 1985)pp82-91 [ MC.1985.1662870 ]
    4. =ESSAY MODEL REALITY PURPOSE Object-Oriented AI ONTOLOGY parts IS-A TIMES RML
    5. Also see what happened [BorgidaGreenspanMylopoulos94]

    BorgidaGreenspanMylopoulos94

    1. Alexander Borgida & Sol Greenspan & John Mylopoulos
    2. On formal requirements modeling languages: RML revisited
    3. SIGSOFT Proceedings of the 16th international conference on Software engineering pp135-147 .See
    4. =HISTORY RML MODEL REALITY PURPOSE Object-Oriented ONTOLOGY GIST KAOS
    5. Also see [BorgidaGreenspanMylopoulos85]
    6. Need QUALITIES -- non-functional requirements NFRs.

    BorgidaJarke92

    1. Alex Borgida & Mathias Jarke
    2. Knowledge and Representation in Software Engineering(Editorial on special issue)
    3. IEEE Trans SE-18n6(Jun 1992)pp449-450 CR9307-0467
    4. domain logic ... relation to formal methods ... power vs performance ... empirical results

    BorgidaMylopoulosReiter93

    1. A Borgida & J Mylopoulos & R Reiter
    2. "And Nothing Else Changes":The frame problem in procedure specifications
    3. In Proc of the 15th Int Conf on Software Engineering
    4. IEEE Computer Society(May 1993)pp303-314
    5. Ref from ZaveJackson93 [Borgidaetal95] [BicarreguiRitchie95]

    BorsoiBecerra08

    1. Beatriz Terezinha Borsoi & Jorge Luis Risco Becerra
    2. Definition and modeling of process using object orientation
    3. ACM SIGSOFT Software Engineering Notes archive V33n3 (May 2008) Article No. 2
    4. =IDEA PROCESS MODEL OBJECT-ORIENTED
    5. Compare to earlier proposal [JaccheriPiccoLago99] E^3 OO process language.
      But
        Why not just use the OMG_SPEM?
      1. OMG_SPEM::="Software Process Engineering MetaModel", [ modeling_spec_catalog.htm ]

      (Close But )

    BosakEtAl62

    1. Robert Bosak & Richard F Clippinger & Carey Dobbs & Roy Goldfinger & Renee B Jasper & William Keating & George Kendrick & Jean E Sammet
    2. An information algebra: phase 1 report - language structure group of the CODASYL development committee
    3. Commun ACM V5n4(Apr 1962)pp190-204 [ citation.cfm?doid=366920.366935 ]
    4. =THEORY DATA GEOMETRY ALGEBRA SETS GLUMPS
    5. An early attempt to at a unified theory of data -- using geometric metaphors.

    Bosak98

    1. Jon Bosak(Sun)
    2. Mediaindependent Publishing: Four Myths about XML
    3. IEEE Computer Magazine V31n10(Oct 1998)pp120-122
    4. =ADVERT XML
      1. XML is a not MS conspiracy -- many others are involved.
      2. XML is not an extension of HTML -- both come from SGML.
      3. XML can not drive a web browser without style rules: DSSL and XSL [ WD-xsl ]
      4. XML is not just for data -- it can convey any kind of structured data but it can also make any kind of information independent of platform/vendor/media/nationallity

    5. Compare XML with YAML and JSON.

    BossomaierGreen01

    1. Terry R J Bossomaier & David G Green (Editors)
    2. Complex Systems
    3. Cambridge University Press 2000 ISBN 0-521-46245-2 Q172.5.C45C64
    4. =SURVEY MATHEMATICS Alife GRAPH Theory Criticality fractals theory nets chaos

    Boswell95

    1. Anthony Boswell
    2. Specification and Validation of a Security Policy Model
    3. IEEE Trans on Software Eng VSE-21n2(Feb 1995)pp63-68
    4. =ADVERT TOOL FORMALIZER and Z
        typical Z schemas are 6..10 lines long, 65 schemas in total some here where 11..20 or more giant schemas: many definitions, state transitions, state includes state of many tables.

        systematic documentation of results and structure of arguments

        The usefulness of diagrams...systematic diagrams.


    Botting75

    1. Richard J Botting
    2. Letter on Comments and Methods
    3. Computing Europe, Oct 30th, p8.
    4. =LETTER ASSERTIONS CODE TECHNICAL
    5. Don't want comments that tell you that i++ adds one to i.
    6. You want comments that state what is necessarily true at that point in the program.

    Botting77

    1. RJ Botting
    2. Efficient Storage for Amorphous Data
    3. Software -Practice and Experience V7pp201-203
    4. =DEMO Technical data structure

    Botting78a

    1. Richard J Botting
    2. Loglan -- a more flexible language
    3. =ADVERT Loglan Mathematics Logic ITL UNIVERSAL LANGUAGES
    4. Computer Weekly (UK) n598 (Feb 16 1978)letters
    5. Response to [Kelly78]
    6. Argues that Loglan fits Kelly's criteria better.

    Botting78b

    1. Richard J Botting
    2. Languages at the Crossroads
    3. =ADVERT Loglan Mathematics Esperanto ITL UNIVERSAL LANGUAGES
    4. Computer Weekly (UK) n598 (April 27 1978)p4
    5. Response to [Love78]
    6. Calls for "an Intermediate Text Language that benefits language translation and not use computers to help Esperanto"
    7. Need to examine many alternative solutions to a problem.

    Botting84a

    1. RJ Botting
    2. Fred - a Friendly Editor
    3. Proc Western Educational Computing Conference Nov 1984 Western Periodicals Co N Hollywood CA.
    4. =DEMO USER DAD System Technical [ papers/rjb84a.FRED.html ]
    5. DAD::="Dynamic Analysis and Design", uses BNF style descriptions of entity life histories to determine the code of the software that keeps track of them.
    6. Evolution of FRED is further tracked in [Botting84b]

    Botting84b

    1. RJ Botting
    2. Generalization - An Alternative to Error Messages
    3. Proc Western Educational Computing Conference Nov 1984( pp98-99) Western Periodicals Co N Hollywood CA. [ papers/rjb84b.Generalization.html ]
    4. =DEMO USER non-sequential System PROTOTYPING EVOLUTIONARY AGILE
    5. History of a simple technology strapped but successful piece of software.
    6. Error messages show the lack of imagination of programmers.
    7. Software can be evolved.

    Botting85a

    1. RJ Botting
    2. On Prototypes vs Mockups vs Breadboards (letter)
    3. ACM SIGSOFT Software Engineering Notes v10n1(Jan 1985)p18
    4. =LETTER WORDS PROTOTYPING

    Botting85b

    1. RJ Botting
    2. An Eclectic Approach to Software Engineering
    3. pp25-29 Proc Third Int'l Workshop on Software Specification & Design(IWSSD3) Aug 1985
    4. =survey PQRST PURPOSES QUALITIES REALITIES SYSTEMS TECHNOLOGIES DFD PROTOTYPES NOTATIONS
    5. Names 28 processes available to a software developer and describes how they are connected. The processes are found in 31 different references.

    Botting85c

    1. RJ Botting
    2. Evolution of Software for a Faculty Workstation
    3. pp120-124 Western Educational Computing Conference1985
    4. =demo evolution prototypes tools System AGILE
    5. You can not reduce paperwork in an office by using a document driven software process in that office.
    6. Abstract
        The author describes the software for a small portable microcomputer workstation. The development of this software did not follow conventional methods, but used prototyping. He argues that useful programs tend to survive, whereas the less successful are either modified or thrown away. The set of successful programs, when compared with the set of unsuccessful programs, suggests some requirements for a faculty workstation. A second conclusion is the need for a new programming system which allows breadboard systems. He gives a preliminary specification for a software breadboarding system.

    Botting85d

    1. RJ Botting
    2. IO Statements in Higher Programming Languages(letter)
    3. IEEE Computer v18n8(Aug 1985)p95
    4. =harmful Technical

    Botting86a

    1. RJ Botting
    2. Into the Fourth Dimension: An Introduction to Dynamic Analysis & Design
    3. SE Notes v11 n2 pp36-48 Apr 1986 ACM SIG Software Engineering
    4. =THEORY DAD graphic logic Reality

    Botting86b

    1. RJ Botting
    2. Novel Security Techniques for Online Systems
    3. (Pracnique) Commun ACM Vol 29 No 5 (May 1986)
    4. =DEMO DAD SECURITY HCI

    Botting87a

    1. RJ Botting
    2. A Critique of Pure Functionalism
    3. pp148-153 Proc. Fourth Int'l Workshop on Software Specification & Design(IWSSD4) April 1987 IEEE Catalog No. TH0181-8 LA CA
    4. =DEMO formal DAD DFD ERD DDD data lift

    Botting87b

    1. RJ Botting
    2. Regular Expressions Relations & Software: Part I - Practice & Part II - Theory
    3. Western Educational Computing Conference Nov 1987 Western Periodicals Co. N Hollywood CA.
    4. =THEORY DDD JSP theory languages logic formal

    Botting88

    1. RJ Botting
    2. Data Structures Classes Can Mislead
    3. Western Educational Computing Conference Nov 1988 Western Periodicals Co N Hollywood CA.
    4. =THEORY DISK DATA OPTIMIZATION PERFORMANCE QUALITIES
    5. Assumes [PechuraShoefler83] 's formula for disk access: time delay is linearly dependent on distance between data.
    6. Proves that for large data structures common O(...) formulas are wrong.
    7. Example: a binary search of n items in a large disk file takes O(n) not O(log(n)).

    Botting89a

    1. RJ Botting
    2. Comments on Tripp's Graphical Notations
    3. ACM SIGSOFT Software Engineering Notes V14n1 (Jan 1989)p83
    4. =LETTER Dimensional charts graphic

    Botting89b

    1. RJ Botting
    2. Abstract of Research
    3. Proc ACM CSC Conf 1989
    4. =survey PQRST

    Botting93

    1. RJ Botting
    2. Would you like your program in a glass?
    3. IEEE Computer Magazine V26n10(Oct 1993)p104
    4. =JOKE PROCESS
    5. vaporware, liquidware, software, soggyware, firmware, hardware

    Botting94

    1. Richard J Botting
    2. When More is Expected of Programmers(Letter)
    3. IEEE Software Magazine V11n5(Sep 1994)p9
    4. =LETTER PEOPLE

    Botting95a

    1. Richard J Botting
    2. On the Relational Semantics of Programming Languages
    3. Faculty seminar CSci CSUSB Spring 1995 [ rjb95a.Relations.vs.Programs.html ]
    4. =THEORY SEMANTICS RELATIONS

    Botting95b

    1. Richard J Botting
    2. Can One Size Fit All?
    3. Faculty seminar CSci CSUSB Fall 1995 [ rjb95b.one.size.html ] [Botting97a]
    4. =IDEA ECONOMICS CULTURE ONE-SIZE

    Botting97a

    1. Richard J Botting
    2. On the Economics of Mass-Marketed Software
    3. pages 465-470 of Proceedings of [ICSE'97]
    4. =IDEA ECONOMICS SUNK externallities CULTURE ONE-SIZE
    5. why one product becomes dominant and then is eclipsed by a later one. network effects. Sunk Costs. cultural assumptions [Botting95b] [CusumanoYoffie98]

    Botting99

    1. Richard J Botting
    2. On the application of a popular notation to semantics
    3. ACM SIGPLAN Notices V34n6(Jun 1999)pp82-83
    4. =IDEA Why not use the UML and OCL to express Programming LANGUAGE SEMANTICS OBECT-ORIENTED
    5. Uses TABULAR presentation of polymorphic functions.
    6. Proposes a fixed point operator for the OCL

    Botting99a

    1. Richard J Botting
    2. The MATHS Manifesto
    3. URL [ 10_manifesto.html ]
    4. =ADVERT DEFINES MATHS
    5. MATHS::="Multi-purpose Abstractions, Terminology, Heuristics and Symbols".

    Botting00a

    1. Richard J Botting
    2. Designing the Real World
    3. IEEE Software Magazine (Letters) V17n2(Mar/Apr 2000)pp8-9
    4. =ESSAY REALITY OOA/D NONSEQUENTIAL
    5. See [Kaindl99]

    BottingJuristo00

    1. Richard J Botting
    2. Natural Language dispute (Letter)
    3. IEEE Software Magazine V17n5(Sep/Oct 2000)p11
    4. =DISCUSSION POLYMORPHISM MODEL ANALYSIS vs DESIGN OBJECT-ORIENTED GRASP
    5. Discussion of [JuristoMorenoLopez00]

    Botting02

    1. Richard J Botting
    2. Some Stochastic Models of Software Evolution

      [SCI2002] V1(Jul 2002)pp23-27

    3. =THEORY DEBUGGING EVOLUTION SOFTWARE
    4. Abstract:
        Stochastic processes model immature software processes. The model of an isolated debugger following the "Hacker Ethic" is presented. It is a Binomial Queue and easily solved. The distribution of defective parts follows. The expected quality of the code depends on diagnostic and fixing skills not the length of time spent hacking or the initial quality. Several different processes (extreme programming, open-source, clean-room, . . . ) are shown to tackle the problems with this approach to software development.

    5. Outline [ papers/rjb02.evolve.txt ] (TXT file).
    6. Conclusions
      1. One size does not fit all
      2. Keep your n small and your α high!
      3. A million monkeys will beat a blind watch maker.

    Botting05

    1. Richard J Botting
    2. Teaching and Learning Ethics in Computer Science: Walking the Walk
    3. ACM SIGCSE Tech Symp Proc (Feb 2005)pp342-346, SIGCSE Bulletin "Inroads" V37n1 (Mar 2005) pp342-346.
    4. =ANECDOTE EDUCATION ETHICS SECURITY Identity Theft

    Botting05a

    1. Richard J Botting
    2. On the co-evolution of SSADM and the UML
    3. Chapter V in [Yang05] pp134-151
    4. =IDEA UML2.0 SSADM

    Botting05b

    1. Richard Botting
    2. Small Errors in "Toward formalizing domain modeling semantics in language syntax"
    3. IEEE Trans Software Engineering V31n10(Oct 2005)pp911
    4. =Correction Statecharts fork vs decision

    Botting06

    1. Richard J Botting
    2. Use Case Diagrams
    3. IEEE Computer Magazine V39n8(Sep 2006)pp5 [ MC.2006.317 ]
    4. =LETTER DFD USE CASES UML2.0 information flows
    5. See [DedekeLieberman06] for an non-standard way to document use case data flows.
    6. Refers to [Botting05b] and [ http://cse.csusb.edu/dick/papers/rjb04bDFDs/ ]

    BottingRoss

    1. R J Botting & Paul Ross
    2. Software Engineering for Computer Scientists
    3. Unpublished Manuscript for a text book used in early 1980s.
    4. =text formal data DDD method co-routines nonsequential nondeterministic design technical assemblers loaders editors
    5. AKA Engineered Systems Software

    BourdeauCheng95

    1. Robert H Bourdeau & Betty H C Cheng
    2. A Formal Semantics for Object Model Diagrams
    3. IEEE Trans on Software Eng VSE-SE-21n10(Oct 1995)pp799-821
    4. OMT in Larch LSL GRAPHIC FORMAL OBJECT-ORIENTED [ serg.html ]
    5. Does not permit OMT subclasses to contain attributes found in superclass (fig 39..41 eqn 24)

    BourqueEtal99

    1. Pierre Bourque & Robert Dupuis & Alain Abran & James W Moore & Leonard Tripp
    2. A Guide to the Software Engineering Body of knowledge
    3. IEEE Software Magazine V16n6(Nov/Dec 1999)pp35-41
    4. =ADVERT SWEBOK PLAN ENGINEERING

    BoussinotSimone96

    1. Frederic Boussinot & Robert de Simone
    2. The SL Synchronous Language
    3. IEEE Trans Softw Eng VSE22n4(Apr 1996)pp256-266
    4. "as soon as signal hypotheses are allowed incorrect programs may be written". Incorrect meaning non-causal and unpredictable: "when S then t1 else t2" suspends if S is not present and then enters t2....

    Boute81

    1. R T Boute
    2. "Towards System Specification Languages"
    3. 4th International conference on Software Engineering for Telecommunications Switching Systems University of Warwick(Conventry UK)
    4. Inst of Electrical and Radio Engineers London UK July 1981 pp31-37
    5. =SURVEY SRS LANGUAGES
      1. Used p397 of DavisA90
      2. Condemns STDs/FSMs
      3. (1) not abstract, (2) not powerful enough (3) not structured Davis: "proposes using non-deterministic multistring dialogue grammars".

    Boute92

    1. Raymond T Boute
    2. The Euclidean definition of the functions div and mod
    3. ACM TOPLAS V14n2(April 1992)pp127-144
    4. CR9211-0871
    5. Semantics mathematics
        CR: "A paper that should have been written decades ago, in which case an existing widespread incompleteness in programming language design could have been prevented"

    Boute00

    1. Raymond T Boute
    2. Supertotal function definition in Mathematics and Software Engineering
    3. IEEE Trans Software Engineering V26n7(Jul 2000)pp662-672
    4. =IDEA FORMAL LOGIC FUNCTIONAL MATHEMATICS calculational
    5. Refers to FunMath [PVS]

      [Parnas93]

    6. Compare: [LPT]
    7. Question: How to calculated easily with partial functions?
    8. Idea: Functions defined by a domain and an expression can be treated as total by extension to an arbitrary value in calculating with suitably guarded formulae

    BouwersVisserDeursen12

    1. Eric Bouwers & Joost Visser & Arie Van Deursen
    2. Getting what you measure
    3. Commun ACM V55n7(Jul 2012)pp54-59 [ 2209249.2209266 ]
    4. =EXPERIENCE HOW METRICS FAIL
    5. Software Improvement Group
    6. Metrics steer people. You get what you measure.
    7. What does the metric mean? What is the goal?

      Metric in a bubble. No interpretation. No context. What does it mean?

      Treating the metric. Cosmetic changes. Find out the root cause and treat that!

      One-track metric. Focus on just one measurement and ignoring the rest. Dig deeper.

      Metrics galore. Too many metrics makes teams ignore all of them. Focus!

    BouyerFahrenbergLarsenMarkey11

    1. Patricia Bouyer & Uli Fahrenberg & Kim G Larsen & Nicolas Markey
    2. Quantitive Analysis of Real-Time Systems using Priced Timed Automata
    3. Commun ACM V54n9(Sep 2011)pp78-87 [ 1995376.1995398 ]
    4. =ADVERT MATHEMATICS AUTOMATA FSM TIMING PRICE PERFORMANCE ENERGY GAMES
    5. Presents an extension to timed automata to included pricing and uncertainty.
    6. Transitions change "clocks" and can supply constraints. States have prices.
    7. Example constraints have form x-y<=c where x & y are variables and c is a constant.
    8. Can calculate minimum price, minimum times, whether feasible, etc.
    9. Many tools exist to analyze these automata.

    BowdigeGriswold98

    1. Robert W Bowidge & William G Griswold
    2. Supporting the Restructuring of Data Abstractionns through Manipulation of a Program Visulaization
    3. ACM TOSEM V7n2(Apr 1998)pp109-157
    4. =TOOL TECHNICAL GRAPHIC ADT REENGINEER
    Bowen00
  1. Jonathon Bowen
  2. The Ethics of Safety-Critical systems
  3. Commun ACM V43n4 (Apr 2000)91-97
  4. =ESSAY RISKS METHODS Aristotle LOGIC
  5. 7 sins: epideictic, hyperole, pistic, oligarchy, ephemeral, epexegesis , maiandos
  6. principles
  7. modes of thought: scientific, technical, prudence, inntelligence/intuition, wisdom
  8. p93: "most theorems are correct, but most hand proofs are wrong"

Bowen01

  1. Jonathon P Bowen
  2. Experience Teaching Z with TOOL and Web Support
  3. ACM SIGSOFT Software Engineering Notes V26n2(Mar 2001)pp69-75
  4. =REPORT UK TEACHING MATHEMATICAL LOGICAL SPECIFICATION REFINEMENT TOOLS ZTC ZANS
  5. Diagnostic quizzes leading to makeup tutorials help handle wide ranges of math skills.

BowenHinchey94

  1. Jonathan P Bowen & Michael G Hinchey
  2. Formal Methods andSafety Critical Standards
  3. IEEE Computer Magazine V27n8(Aug 1994)pp68-71
      Quotes IEEE standard definitions Most standards are reccommending formal methods rather than mandating them or using them. Table 1, p70: shows that only 1 out of 5 US standards has FMs, but all 7 non-US standards have FMS

      FMs mentioned in standards: CCS(2), CSP(2), HOL(2), LOTOS(2), OBJ(2), Temporal Logic(2), VDM(3), Z(4)


BowenHinchey95a

  1. Jonathan P Bowen & Michael G Hinchey
  2. Ten Commandments of Formal Methods
  3. IEEE Computer Magazine V28 n 4(Apr 1995)pp56-63
      To: formal-methods@cs.uidaho.edu Subject: Re: FM technology transfer Date: Wed, 22 Feb 1995 20:44:35 +0000 From: Mike Hinchey <Michael.Hinchey@cl.cam.ac.uk>

      "Ten Commandments of Formal Methods" by J.P. Bowen and M.G. Hinchey is scheduled for the April (1995) issue of IEEE Computer. "Ten Commandments of Formal Methods" is available as a University of Cambridge Computer Laboratory Technical Report (no. 350). The IEEE Computer version will not differ significantly. http://www.cl.cam.ac.uk/users/mgh1001/TECHREPORTS/10cs.ps.Z (warning: even compressed it's 230K)

    1. I. Thou shalt Choose an Appropriate Notation
    2. II. Thou shalt Formalize but not Overformalize
    3. III. Thou shalt Estimate Costs
    4. IV. They shalt have a Formal Methods Guru On Call
    5. V. Thou shalt not Abandon Traditional ethods
    6. VI. Thou shalt Document Sufficiently
    7. VII. Thou shalt not Compromise thy QUALITY Standards
    8. VIII. Thou shalt not be Dogmatic
    9. IX Thou shalt Test, Test, and Test again
    10. X. Thou Shalt Reuse


BowenHinchey95b

  1. Jonathan P Bowen & Michael G Hinchey
  2. Seven More Myths of Formal Methods
  3. IEEE Software Magazine V12n4(Jul 1995)pp34-40
      Note Based on industrial experience Ref to [Hall90]
    1. 8. FM delay the development process
    2. 9. FM lack tools
    3. 10. FM replace traditional engineering design methods
    4. 11. FM only apply to software
    5. 12. FM are unnecessary
    6. 13. FM are not supportted
    7. 14. FM people always use FM
    8. p40: "system development should be as formal as necessary, but not more formal."

      Notes problems:

    9. sidebar, p37: defining FM, IEEE glossary has two.
    10. notation

      p38: Notes resources: internet forums for Z, VDM, Larch, OBJ. FTP archives, Periodicals. Courses.

      p40: Quotes BBC Interview: "If you want to build systems with ultra-high reliability whcih provide complaxe functionallity and you want to guarantee that they are going to work with very high reliability...you can't do it"


BowenHinchey96

  1. Jonathan P Bowen & Michael G Hinchey
  2. To Formalize or Not to Formalize
  3. IEEE Computer Magazine V29N4(Apr 1996}pp18-19
  4. =EXPERIENCE FORMAL MATHEMATICS
      too many misconceptions

      apply to get increased cofidence, to conuer complexity, to satisfy standards few tools

      not enough education and training(apply math to practical problems)


BowenHinchey99

  1. Jonathan P Bowen & Michael G Hinchey It's Greek to Me: Method in the Madness
  2. In [HincheyBowen99] pp1-4
  3. =ESSAY METHODS PHILOSOPHY ETHICS ARISTOTLE
  4. describes sins that can destroy a project that uses formal methods.
  5. Describes useful frames of mind

BowenHinchey06

  1. Jonathan P Bowen & Michael G Hinchey
  2. Ten Commandments of Formal Methods ... Ten years later
  3. IEEE Computer Magazine V39n1(Jan 2006)pp40-48
  4. =HISTORY FORMAL Z TLA
  5. See also "The Ten Commandments revisited: a ten-year perspective on Industrial application of formal methods" Proc 10th Int'l Workshop on formal methods for industrial Critical Systems, ACM Press 2005 pp8-16
  6. CF [BowenHinchey95a]
    Table
    ThenNow
    I. Thou shalt Choose an Appropriate Notation. More now. Hybrids.
    II. Thou shalt Formalize but not Overformalize. 3 levels: specs, Proofs, machine checked.
    III. Thou shalt Estimate Costs.
    IV. They shalt have a Formal Methods Guru On Call. Plus a domain expert early on.
    V. Thou shalt not Abandon Traditional methods.
    VI. Thou shalt Document Sufficiently. Iterative. Including why & when decided.
    VII. Thou shalt not Compromise thy QUALITY Standards. Notation & method.
    VIII. Thou shalt not be Dogmatic. Gap between analysis & specification.
    IX Thou shalt Test, Test, and Test again.
    X. Thou Shalt Reuse.

    (Close Table)

BowenHinchey11

  1. Jonathan P Bowen & Michael G Hinchey
  2. Ten Commandments of Formal Methods, a Decade Later
  3. FM 2011: 17th International Symposium of Formal Methods
  4. =HISTORY FORMAL METHODS COMMANDMENTS
  5. Slides [ ten-commandments-of-formal-methods-a-decade-later ]
  6. See older [BowenHinchey06] with same list but more commentary.

BowenReeves11

  1. Jonathan P. Bowen & Steve Reeves
  2. From a Community of Practice to a Body of Knowledge: A Case Study of the Formal Methods Community,
  3. In Michael Butler and Wolfram Schulte (eds.), FM 2011: 17th International Symposium of Formal Methods. Springer-Verlag, LNCS, V6664(2011) pp308-322 [ fm2011 ]
  4. =DEMO PROCESS COMMUNITY FORMAL METHODS Z BOK KNOWLEDGE Abstract.
      A Body of Knowledge (BoK) is an ontology for a particular professional domain. A Community of Practice (CoP) is the collection of people developing such knowledge. In the paper we explore these concepts in the context of the formal methods community in general and the Z notation community, as has been supported by the Z User Group, in particular. The existing SWEBOK Software Engineering Body of Knowledge is considered with respect to formal methods and a high-level model for the possible structure of of a BoK is provided using the Z notation.

  5. The slides for the presentation are under: [ fm-2011-symposium-slides ]
  6. Translation of formal portion of slides (in Z) into MATHS: [ samples/BoK.html ]

Bowles90

  1. Adrian J. Bowles
  2. A note on the Yourdon Structured Method(Announcement)
  3. ACM SIGSOFT SEN V15n2(Apr 1990)p27
  4. =HISTORY METHOD YSM evolution
  5. YSM::="Yourdon Method".

Bowles95

  1. Adrian J. Bowles
  2. Object methods Emerging and Converging
  3. Software Magazine (May 1995)pp96

BowmanBriandLabiche10

  1. Michael Bowman & Lionel C Briand & Yvan Labiche
  2. Solving the class responsibility assignment problem in object-oriented analysis with multiple-objective genetic algorithms
  3. IEEE Trans Software Engineering V36n6(Nov/Dec 2010)pp817-837
  4. =DEMO SEARCH MOGA OOAD CLASSES UML COUPLING COHESION EVOLUTION SPEA2
  5. Demonstrates that multiple-objective evolution can, at some expense, undo damage done to an expert's design class diagram.
  6. Compares work with other algorithms. SPEA2 is better.
  7. Assumes that design is a detailed form of analysis. Shows domain or analysis models that include methods.

BowmanHoltBrewster99

  1. Ivan T Bowman & Richard C Holt & Neil V Brewster
  2. Linux as a Case Study: Its Extracted Software Architecture
  3. ICSE'99, Proceeedings of the 21st International Conference on Software Engineering (May 1999)pp555-563
  4. =EMPIRICAL reverse-engineering extracts dependencies between modules.
  5. More connections than predicted between subsystems.

BoyerYu96

  1. Robert S Boyer & Yuan Yu
  2. Automated Proofs of Object Code for a Widely Used Microprocessor
  3. JACM V43n1(Jan 1996) pp166-192 CR9710-0117
  4. =EXPERIENCE PROOF

BoyleReslerWinter99

  1. James M Boyle & R Daniel Resler & Victor L Winter
  2. Do You Trust Your Compiler?
  3. IEEE Computer Magazine V32n5(May 1999)pp65-72 + letters V32n10(Oct 99)pp5-7
  4. =ADVERT TAMPR DDD PROOF sound code transformations
  5. Same ideas as McCarthy in the early 1960's
  6. Letters point out errors in paper and reccommend peer review/inspection

BrachiLockermann78

  1. ?? Brachi & ?? Lockermann
  2. Information systems Methodology
  3. Springer Verlag lecture notes in Comp Sci #65
  4. =survey SAD PQRST

BradacPerryVotta94

  1. Mark G Bradac & Dewayne E Perry & Lawrence G Votta
  2. Prototyping a Process Monitoring Experiment
  3. IEEE Trans on Software Eng VSE-20n10(Oct 1994)pp774-784
  4. CR1995-0106(by RJB)

Bradfield92

  1. Julian C Bradfield
  2. Verifying Temporal Properties of Systems
  3. Birkhauser Boston Inc Cambridge MA 1992
  4. ISBN 0-817603625 CR9209-0661(F.3.1)
  5. =THEORY CORRECTNESS Petri nets

BradyDeMarco94

  1. Sheila Brady & Tom DeMarco
  2. Management Aided Software Engineering
  3. IEEE Software Magazine V11n6(Nov 1994)pp25-32
  4. Interview re management best of practice in software development at Apple. [ BradyDeMarco94.html ]

BraekHaugen94

  1. R Braek & O Haugen
  2. Engineering Real Time Systems
  3. Prentice Hall Upper Saddle River NJ 1994 BCS Practitioner Series ISBN 0-13-034448-6
      presents an object-oriented methodology using SDL for complex distributed real-time systems and covers the complete life cycle.

BraffortHirschberg63

  1. Braffort & Hirschberg(Eds)
  2. Computer Programming & Formal Systems
  3. North Holland 1963
  4. =THEORY formal LISP languages

BraheSchmidt07

  1. Seen Brahe & Kjeld Schmidt
  2. The Story of a Working Workflow Management System
  3. ACM Proc GROUP'07 (Nov 2007) pp249-258 CR 0811-1106 ACM DOI [ 1316624.1316661 ]
  4. =EXPERIENCE SYSTEMS WORKFLOW BPEL XML SOA SERVICE LEGACY WFM PEOPLE DANISH BANK 2003-2007 ORCHESTRATION PORTAL TASK vs CASE
  5. CSCW::="Computer Supported Cooperative Work".
  6. WFM::="Workflow Management".
  7. SOA::="Service Oriented Architecture".
  8. Early attempts to program office procedures failed because exceptions to the procedures were common. How to make the result adaptable? How to fit in with the continuing creation and adaption of procedures/workflows. How to integrate existing (legacy) systems.
  9. Integrate systems by using SOA... encapsulate legacy code as a service. Workflow as glue.
  10. (dick)|-Workflow sytems/languages seems to be like scripting.
  11. Develop a workflow system iteratively.
  12. Get the developers and the users closely involved.
  13. Business's analyst's can get it wrong!
  14. Development followed Babbage's model: craft; division of labor; stepwise automation; more or less complete automation.
  15. Need to avoid fragmented tasks. People prefer complete cases to individual tasks. First task in process should assign remaining tasks in the case to same person. "We do not want to be a factory". Not task-centric, but case-centric. "It does not feel right " not to know the context of tasks.
  16. Another early task in each workflow is to determine if the task is simple enough to be automated or needs human discretion and guidance.
  17. Describing exceptions if difficult and time consuming. Better to bounce them to a human... and think about how to automate in a later iteration.
  18. Automating more kinds of processes is an optimization. Tweaking and Twisting the automated processes.
  19. Nearly a 20% gain in speed. 80-90% automated.
  20. No need to re-enter data into each application.
  21. People like to monitor automated processes.
  22. Tell the users when the system is becoming unstable. Tell them about bugs. Tell them about performance problems.
  23. Workflows integrated legacy systems into exiting processes -- so the old system could not be replaced until the workflow was redesigned, tested, and running with the new service provider. Increased coupling and dependency between systems.
  24. Application niche is a very regular system -- unlike, say -- medicine.

BrandtEtAl09

  1. Joel Brandt & Philip J Guo & Joel Lewenstein & Scott R Klemmer & Mira Dontcheva
  2. Opportunistic Programming: Writing code to prototype, ideat, and discover
  3. IEEE Software Magazine V25n5(Sep/Oct 2000)pp18-24
  4. =EXPERIMENT BRICOLLAGE POSTMODERN PROTOTYPING GLUE WWW/NET d.mix
  5. Principles for rapid prototyping
    1. Glue together existing high-level components.
    2. Add functionality via Copy-paste from the web.
    3. Iterate rapidly.
    4. Consider code to be impermanent.
    5. Expect and prepare for debugging.
    6. Use many languages.
    7. Don't expect good code.
    8. Need different version control.

BrandKlintVerhoef97

  1. M G J van den Brand & P Klint & C Verhoef
  2. Reverse Engineering and System Renovation -- an Annotated Bibliography
  3. ACM SIGSOFT Software Engineering Notes V22n1(Jan 1997)pp56-68 [ citation.cfm?doid=251759.251849 ]
  4. =BIBLIOGRAPHY REVERSE ENGINEERING RENOVATION REUSE REFACTOR 110 items

BrandtUden03

  1. D Scot Brandt & Lorna Uden
  2. Insight into Mental Models of Novice Internet Searchers Commun ACM V46n7(Jul 2003)pp133-136
  3. =ADVERT TKS KAT ACTA HCI USER PEOPLE WEB/NET
  4. Distinguishes mental models of tasks from conceptual models of systems.
  5. TKS::theory="Task Knowledge Structure", can express what people know about a task in a structured way.
  6. ACTA::technique="Applied Cognitive Task Analysis", interview ->outline; audit knowledge(cues+difficulties); simulate scenario giving cognitive processes, tabulate cognitive demands.
  7. KAT::technique="Knowledge Analysis of Tasks", break down ( objects, actions, goals, subgoals); identify central and generic properties; pseudocode procedures and taxonomy of terms use, add task knowledge needed to pseudocode.
  8. Novices may need more cues and structure to use search engines effectively.

BratthallWohlin02

  1. Lars Bratthall & Claes Wohlin
  2. Is it possible to decorate graphical Software design and architecture models with qualitative information? -- and Experiment
  3. IEEE Trans Software Engineering V28n12(Dec 2003)pp1181-1193
  4. =POLL 35 STUDENTS GRAPHIC COMPONENT METRICS RELATIONSHIPS
  5. How to show: A controls B, A is bigger than B, A is internally more complex than B, and A is harder to use then B.
  6. Rough consensus: control shown by position, size by area, complexity by darkening the inside or boundary.
  7. Demo for a car controller.

BrayHess95

  1. Olin Bray & Michael M Hess(both Sandia)
  2. Re-engineering a Configuration Management System
  3. IEEE Software Magazine V12n1(Jan 1995)pp55-63
  4. =DEMO NIAM
      Used resident experts, source code, system data to reengineer a 30 year old system.

    1. NIAM::=Natural Language Information-Analysis Methodology.
    2. NIAM::=Net{entity types. types of facts. interactions between types} verbal or graphic presentation deep-structure sentence tables of examples and counter examples of facts

      reinvention of LDST


BremleyHolmes00

  1. Jesse L Bremley & Donald Holmes
  2. Advanced Computer Topics for Precollege Students
  3. Proc SCI/ISAS2000 VI pp468-494 [SCI00]
  4. =EXPERIENCE EDUCATION AI
  5. How inner-city (Washington DC) children can do literature searches in AI and implement the results in programs.

Brender02

  1. Ronald F. Brender
  2. The BLISS programming language: a history
  3. Software - Practice & ExperienceV32n10(Aug 2002)pp955-981
  4. =HISTORY SYSTEMS LANGUAGE

BreretonBudgetHamilton98

  1. Pearl Brereton & David Budgen & Geof Hamilton
  2. Hypertext: The next Maintenance Mountain
  3. IEEE Computer Magazine V31n12(Dec 1998)pp49-55
  4. =IDEA EVOLUTION WWW

BrewkaEiterTruszczynski11

  1. Gerard Brewka & Thomas Eiter & Miroslav Truszczynski
  2. Answer set programming at a glance
  3. Commun ACM V54n12(Dec 2011)93-103 [ 2043174.2043195 ]
  4. =ADVERT DEFEASIBLE LOGIC DECLARATIVE PROGRAMMING ASP GROUNDERS SATISFY SAT SEMANTICS TOOLS APPLICATIONS ABBREVIATIONS
  5. a <- b1,...,bm, not c1, ..., not cm. where a,b,c... are "predicates'.
  6. Answer set is a set of predicates that can be derived if we assume certain predicates are true/false and is not contradicted by the derivable predicates.
  7. Able to express if-then-else and constraints easily and a number of other formulas that appear in practice.
  8. Can handle predicates that contain variables by reducing them.

BriandBunseDaly01

  1. Lionel C Briand & Christian Bunse & John W Daly
  2. A controlled Experiment for Evaluating Quality Guidelines on The Maintainability of Object-Oriented Designs
  3. IEEE Trans Software Engineering V27n6(Jun 2001)pp513-530
  4. =EXPERIMENT MODULE DESIGN MAINTAINABILITY QUALITIES Coad Yourdon
  5. 33 students attempt to understand two different designs -- one set up to be bad and the other good. The students did bette r on the good.
  6. Good had low coupling, high cohesion, higher clarity/lower fuzziness/simplicity, more realistic inheritance.

BriandDalyWust99

  1. Lionel C Briand & John W Daly & J"urgen K W"ust
  2. A Unified Framework for Coupling Measurement in Object-Oriented Systems
  3. IEEE Trans SoftEng V25n1(Jan/Feb 1999)pp91-121
  4. =THEORY METRICS

BriandDebanbuMelo97

  1. Lionel C Briand & P Devanbu & W Melo
  2. An Investigation into Coupling Measures for C++

    [ICSE'97]

  3. =EXPERIMENT OBJECT-ORIENTED METRIC

BriandEtal99a

  1. Lionel C Briand & J"urgen W"ust & John W Daly
  2. A Unified framework for coupling measurement in Object-Oriented Systems
  3. IEEE Trans Softw Eng VSE-25n1(Jan/Feb 1999)pp91-121 CR9910-0775
  4. =SURVEY EMPIRICAL TECHNICAL QUALITY OBJECT-ORIENETED METRIC COUPLING MODULE

BriandEtal99b

  1. Lionel C Briand & J"urgen W"ust & Stefan V Ikonomovski & Hakim Lounis
  2. Investigating Quality Factors in Object-Oriented Designs: an Industrial Case Study
  3. ICSE'99, Proceeedings of the 21st International Conference on Software Engineering (May 1999)pp345-354
  4. =EMPIRICAL QUALITY OBJECT-ORIENETD METRIC
  5. LALO and UMD Principal Components Logistic Regression
  6. Better than [BenlarbiMelo99]
  7. Only 7 principal components account for variation in all the 30+metrics.
  8. The metrics are related to fault proneness...
  9. High numbers of method calls indicates fault prone classes.
  10. Differences between LALO and UMD -- friends not found in UMD. UMD more experienced pALO and UMD -- friends not found in UMD. UMD more experienced people.

BriandMorascaBasili99

  1. Lionel C Briand & Sandro Morasca & Victor R Basili
  2. Ddefining and Validating Measures or Object-Based High-Level Design
  3. IEEE Trans Soft Eng V25n5(Sep/Oct 1999)pp722-743
  4. =EMPIRICAL DESIGN METRICS GQM OBJECT-BASED ADA FAULT-PRONE
  5. NASA Goddard 3 projects
  6. declared high-level links in package interfaces
  7. is_component_of, uses, data declaration interaction(dependency), data subroutine interaction, generics?
  8. ->cohesion, coupling
  9. change requests -> faults and modules
  10. logistic regression using maximum likelihood
  11. avg-depth +number imported parts+low cohesion has some effect increasing chance of a fault being reported

BriandMaloWust02

  1. Lionel C Briand & Walcelio L Malo & J"urgen W"urst
  2. Assessing the Applicability of Fault-Proneness Models Across Object-Oriented Software Projects
  3. IEEE Trans Software Engineering V28n7(Jul 2002)pp706-720
  4. =EXPERIMENT METRICS Object-Oriented ERRORS MARS logistic JAVA
  5. MARS::="Multivariate Adaptive Regression Splines".
  6. Can predictions that work well on one project be used on a different one? In this case: yes. Same team and language with different managers and projects.
  7. Inheritance trees where short in both projects.

BriandMorascaBasili02

  1. Lionel Briand & Sandro Morasca & Victor R Basili
  2. An Operational process for goal-driven definition of Measures
  3. IEEE Trans Software Engineering V28n12(Dec 2003)pp1106-1125
  4. =EXPERIENCE GQM/MEDEA METRIC DEFINITION QUALITIES DFDs UML TRIO+

BriandWust01

  1. Lionel C Briand & J"urgen W"urst
  2. Modeling Development Effort in Object-Oriented Systems using Design Properties
  3. IEEE Trans Software Engineering V27n11(Nov 2001)pp963-986
  4. =ANALYSIS EXPERIENCE EFFORT SIZE C++ METRICS LIOO
  5. Interface sizes (NMIMP, NMINH, NA, NM) are a good predictor of the effort needed to implement a class.
  6. Used regression trees and poisson regression work well.
  7. Measures of coupling and cohesion do not increase accuracy of estimates.
  8. ?? inherited methods and few implemented methods lower effort.

BriandEtal05

  1. Lionel C Briand & Yvan Labiche & Massimiliano Di Penta & Han (Daphne) Yan-Bondoc
  2. An experimental investigation of formality in UML-based Development
  3. IEEE Trans Software Engineering V31n10(Oct 2005)pp833-849
  4. =EXPERIMENT OCL UML COMPREHENSION INSPECTION EVOLUTION MAINTENANCE
  5. OCL improves comprehension, defect detection, maitenance of UML models of software by small ammounts depending on the OCL experience of the students.

BriandLabicheLeduc06

  1. Lionel C Briand & Yvan Labiche & Johanne Leduc
  2. Toward the Reverse Engineering of UML Sequence Diagrams for distributed Java Software
  3. IEEE Trans Software Engineering V32n9(Sep 2006)pp642-663
  4. =DEMO MAINTENANCE DYNAMIC TOOL NONSEQUENTIAL REVERSE JAVA UML
  5. Uses aspects to instrument distributed software and so log the calls between objects.
  6. Recognises conditions and so one sideof alt constructions (only).

Briggs93

  1. Albert W Briggs Jr
  2. Mathematics for Liberal Arts Students
  3. American Math Monthly V100n2(Feb 1993)pp162-166
  4. education analysis skills proof
      Description of evolution from a math course that teaches more or less useless pre-solved problems to the teaching of problem solving itself. page 164. specific goals: students learn:
    1. "1. to raise questions and make conjectures[...]
    2. 2. to test those conjectures
    3. 3. to settle definitely those questions and conjectures, or at least make progress toward such a settlement,
    4. 4. to raise more questions as a result of this process,
    5. 5. to read with enough precision to understand the questions and investigations of others,
    6. 6. to write with enough precision to communicate their investigations to others."
    7. "[...] students take to forming guesses and testing them with examples like ducks to water. But getting them to prove their guesses, or to deduce things from their guesses[...]is killingly hard. It is so hard that I have to wonder whether deduction[...] is as natural a human tendency as we[mathematicians] suppose."

Brin98

    .Seee
  1. David Brin
  2. The Transparent Society...
  3. Addison-Wesley1998 ISBN 0-201-32802-X
  4. =HISTORY =ESSAY SOCIETY ETHICS PRIVACY RISKS NET/WWW CRYPTOGRAPHY SSN VIDEO
  5. Argues that often more information is better than less.
  6. Adding a reverse flow is a way to solve a problem with an assymetric flow.
  7. Most solutions are partial.
  8. Secrecy that decreases accountability is bad for a society. Security, safety, & ideas can be improved by open information flows and criticism.
  9. Drops many names. Discusses opposing positions.
  10. Notes confusion between passwords and IDs. Example: SSN is an ID used by many systems as a password.

BrinchHansen81

  1. Per Brinch-Hansen
  2. The EDISON Papers
  3. Software - Practice and Experience V11n4 (Apr 1981) QV [BrinchHansen83]
  4. =DEMO DDD data languages optimization non-sequential EDISON BNF

BrinchHansen83

  1. Per Brinch-Hansen
  2. Programming a Personal Computer
  3. Prentice Hall International 1983 QV [BrinchHansen81]
  4. =DEMO DDD data languages optimization non-sequential EDISON BNF

BrinchHansen85

  1. Per Brinch-Hansen
  2. On Pascal Compilers
  3. Prentice Hall International
  4. =SURVEY DDD

BrinchHansen99

  1. Per Brinch Hansen
  2. Java's Insecure Parallelism
  3. ACM SIGPLAN Notes V34n4(Apr 1999)pp38-45
  4. =ESSAY JAVA TECHNICAL NON_SEQUENTIAL RISKS
  5. Need to have all variables are private and all public methods synchronized to get predicatable parallelism.
  6. Note. Also see [Hartley99]

Britcher96

  1. Bob Britcher
  2. A Few (proposed) fundamental laws of programming
  3. IEEE Computer Magazine V29N3(Mar 1996)p136(Open channel)
      The Law of Rapid Specialization
    1. In programming major changes in the product can occur in an instant
    2. vs time to change plant or physical products

      The Law of Fallibility

    3. The most careful reasoning about a simple sentence can lead to a wrong conclusion about the real world
    4. Programmers have to reduce big "word-problems" to logic.

      The Law of Intellectual Gravity

    5. Programs can be as massive(in there own way) as physical objcts.

      The Law of Permannence

    6. Programs do not become extinct. They are not discarded, they are piled up, combined, absorbed, breeding and spreading.

Brittan80

  1. Design for a Changing Environment
  2. Comp Jnl v23 n1 pp13-19
  3. =DEMO maintenance formal ENGINEERING lifecycle

BrockHunt99

  1. Bishop C Brock & Warren A Hunt Jr
  2. Formal Analysis of the Motorola CAP DSP
  3. In [HincheyBowen99] pp-
  4. =EXPERIENCE HARDWARE DESIGN V&V VERIFICATION FORMAL LOGIC TOOL ACL2

Brodaetal94

  1. Broda & Eisenbach & Khoshnevisan & Steve Vickers<sjv@doc.ic.ac.uk>
  2. Reasoned Programming
  3. Prentice Hall Englewood Cliffs NJ 1994 $40 ISBN 0-13-098831-6 CR9607-0469:
  4. =TEXT Formal miranda modular-2

Brodine06

  1. Dick Brodine
  2. Mathematical Server Sizing
  3. IEEE Computer Magazine V39n7(Jul 2006)pp91-93
  4. =ADVERT MATH QUEUING THEORY WEB/NET Trivedi
  5. Quotes a useful formulas modeling server performance.
  6. TRIVEDI::=following
    Net
    1. Kishor S Trivedi's model for M clients at rate λ to a server that handles them at rate μ -- both with exponential distributions.
    2. E[Response_time] = M/E[T] - 1/λ),
    3. E[T]=μ *(1-p0),
    4. p0:=P[0 requestss in system],
    5. p0=1/(+[n:0..M]((λ/μ)^n)*(fact(M)/fact(M-n)))

    (End of Net)

  7. Shows a screen short of a Java application that helps.

BrolundElnestam11

  1. Daniel Brolund & Ola Ellnestam
  2. Code Pick-up Sticks
  3. IEEE Software Magazine V28n4(Jul/Aug 2011)pp11-14
  4. =ANECDOTE EVOLUTION REFACTORING MAINTENANCE
  5. How to change a large badly structured code base?
    1. Document problems on a whiteboard.
    2. Pick an independent piece.
    3. Change and try to compile.
    4. If fails revert and record what you have learned. Try a different change.
    5. Repeat.

Brooks77

  1. Frederick P Brooks Jr
  2. The Computer "Scientist" as Toolsmith -- Studies in Interactive Computer Graphics
  3. Proc IFIP 77 (North Holland Pub Co 1977) pp625-634 (Invited Paper)
  4. =EXPERIENCE 10years USER ENGINEERING REQUIREMENTS
  5. p634:
      The architect Christopher Alexander, in his "Notes on the Synthesis of Form", makes the penetrating observation that the only way to achieve good fit between any design and its requirements is to find misfits and remove them; there is no direct way to derive form from requirements.

Brooks82

  1. Frederick P Brooks Jr
  2. The Mythical Man-Month - essays on software engineering
  3. Addison-Wesley Ma and CA USA 1982
  4. =survey costs PEOPLE

Brooks87

  1. Frederick P Brooks Jr
  2. No Silver Bullets
  3. IEEE Computer Magazine V20n4(April 1987) IEEE Press.
  4. =survey costs
  5. Predicts no great reduction in the costs of developing software.
    But
    1. See [Cox90a] [Harel92] [FraserManci08]

    (Close But )

Brooks95

  1. Frederick P Brooks Jr
  2. The Mythical Man-Month: Anniversary Edition
  3. Addison-Wesley Publishing Co Inc 1995
  4. Parts from Chapter 19 in pp57-60 IEEE Software Magazine (Sep 1995)
  5. Also speech at the ICSE 17
  6. =HISTORY PEOPLE COSTS MS-PROCESS

    [Keuffel95b]


      Chapter 19
    1. waterfall process is wrong. Early functinal prototype and incremental build are ways to GROW software -
    2. better to be wrong than vague. User distributions.
    3. design for evolution/family of products from the start(Parnas)
    4. peopleware empowerment. "the power of giving up power" in IBM and in MS

      [McCarthyJ95a] MS Process: Jim McCarthy of Microsoft power of teams owning a set of features and controlling define+biuld+ship. 4..5 specialities: testing, writing, building. Settle own squabbles. Effect not reported.

    5. encapsulation is OK - I was wrong and Parnas right
    6. Brooks law: Boehm, Abdel-Hamid Madnick [Abdel-Hamid96]
    7. Computers brought Fluidity to ...drawings, plans, ...texts, ...spreadsheets
    8. Metaprogramming: hypercard... pre-VBX!

Brooks96

  1. Frederick P Brooks Jr
  2. The Computer scientist as Toolsmith II
  3. Comm ACM V39n3(Mar 1996)pp61-68
  4. science & Engineering

BrooksD08

  1. David A brooks
  2. An Introduction to HTML and JavaScript for Scientists and Engineers
  3. Springer-Verlag Secaucus NJ ISBN 1846386565 CR 0810-0929
  4. =UNREAD =TEXT =REFERENCE INTRODUCTION HTML JAVASCRIPT CSS
  5. Notes [click here [socket symbol] if you can fill this hole]

Brooks10

  1. Frederick P Brooks Jr
  2. The Design of Design: Essays from a computer scientist
  3. Addison-Wesley Prof. Boston MA 2010 ISBN 02011362988 CR 1103-0278
  4. =UNREAD =ESSAYS DESIGN

BrooksM13

  1. Michael Brooks
  2. Code Red
  3. New Scientist (8 Jun 2014)36-39
  4. =HISTORY LANGUAGES HARMFUL
  5. Author couldn't find a good language to start programming in. Does not mention BASIC. Does not mention methods or processes.
  6. Claims that new languages are built out of previous ones.
  7. Identifies many well known and disastrous bugs. Misdiagnoses the Ariane explosion.
  8. Notes complexity of modern software.
  9. Suggests need to rebuild from the bottom up.
  10. Notes current attempts to cure problems:
    1. Jonathan Edwards exploring a spreadsheet as a role model. Subtext. Visual model of what program does. No discussion of previous visual languages like flowcharts, Dimensional Flowcharts, ... UML.
    2. Bret Victor: let programmers see what happens as they tinker with code.
    3. Chris Granger Light Table. Parts visible on work bench and ready for assembly.
    4. Crista Lopes: Ask questions and let computer search out answers. No discussion of Prolog.

Brown83

  1. ?? Brown
  2. Error Messages: The neglected area of the man-machine interface?
  3. Commun ACM 26 4 pp246-249
  4. =IDEA USER ERRORS

Brough01

  1. Mike Brough
  2. The History of YSM

    [ ysmhist.pdf ]

  3. =HISTORY METHODS YSM Yourdon

Brownbridge90

  1. David Brownbridge(drb@paxis.co.uk)
  2. Using Z to Develop a CASE Toolset
  3. pp142-149 in Nicholls90
  4. =EXPERIENCE SSADM Z CASE
  5. 340 pages of Z -> 37KLOC object-oriented in 11 months
  6. no need of refinement
  7. needed for typechecker
  8. formal specification reviews are needed
  9. needed roadmap of hierarchy

BrownChervanyReinicke07

  1. Susan A Brown & Norman L Chervany & Bryan A Reinicke
  2. What matters when introducing new information technology
  3. Commun ACM V50n9(Sep 2007)pp91-96
  4. =SURVEY IMPLEMENTATION ISSUES =EXPERIENCE
  5. Surveyed the literature and made list of 5 areas: Commitment, Knowledge, Communication, Planning, Infrastructure.
  6. Took 5 projects and looked for occurences of "disconnects": Commitment(59), Knowledge(18), Communication(53), Planning(25), Infrastructure(30).
  7. Figure 2 show relative frequency accross 4 phases: Initiation(Knowledge), Adoption(Communications), Adaption(Infrastructure), Acceptance(Infrastructure+Commitment).
  8. Table 3 lists 6 problems, identifies a area and suggests solutions. For example: If you can't identify the best new technology you have a Knowledge problem -- invest in employee education and create a central repository for sharing tech information.

BrownEarlMcDermid92

  1. Alan W Brown & Anthony N Earl & John A McDermid
  2. Software Engineering Environments: Automated Support for Software Engineering
  3. McGraw-Hill NY NY 1992 ISBN 0-07-707432-7 CR9409-0606
  4. =ADVERTS CASE TOOLS
      CR(R L Glass) advocacy of research with ignorance of the marketplace + highlevel abstraction and philosophy

BrownMalveauMcCormickMowbray98

  1. William J Brown & & R C Malveau & Hays W McCormick III & T J Mowbray
  2. AntiPattern: refactoring software, architectures, and projects in crisis
  3. John Wiley & Sons, New York NY(1999) ISBN 0-471-32929-0 CR9908-0593
  4. =PATTERNS ARCHITECTURE DESIGN REFACTOR EVOLUTION
  5. BallOfMud := "one class becomes responsible for everything that doesn't fit elsewhere."

BrownMcCormickThomas99

  1. William J Brown & Hays W McCormick III & Scott H Thomas
  2. AntiPattern and Patterns in Software configuration management
  3. John Wiley & Sons, New York NY(1999) ISBN 0-471-32929-0 CR9908-0593
  4. =PATTERNS SCM

BrowneMenon04

  1. Glen J Browne & Nirup M Menon
  2. Network Effects & social dilemmas in Technology Industries
  3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp44-50
  4. =Theory Markets Economics

BrowneMoore97

  1. Shirley V Browne & James W Moore
  2. Reuse Library Interoperability

    [Harandi97] pp182-189

  3. =ADVERT RIG WEB/NET REUSE URNs DATA MODEL RIG=http://www.rig.org.

BrownN96

  1. Norm Brown
  2. Industrial-Strength Management Strategies
  3. IEEE Software Magazine VSE13N4(Jul 1996)pp94-103
  4. =SURVEY people DoD managers list
  5. 9 best practices::=risk management & agreeed interfaces & formal inspections(not reviews) & metics & defect tracking & quality gates on tiny steps & configuration management & visible control panel & people aware accountability

BrownP91

  1. Patrick Brown
  2. Integrated hypertext and program understanding tools
  3. IBM Syst J V30n3(1991)pp363-392
  4. =TOOL TECHNICAL
  5. CR 9211-0872(N Zvegintov)
      CR92011-0875 is by N Zvegintov and refers to the lack of tools to record and maintain links between the domain and the implementation.

      Multiple{languages, platforms(IBM), uses, data/tools}

      ISEA Integrated SoftwareEngineering Applications tools platform OS/2 + VM + MVS, Distributed client &/| server

      CodeNavigator helps programmers {undertand software, analying change requests, Diagnosis} {what, where, how}-used, flows{logic, calling,...}, annotations, source code brousing

      p369 "Program analysis can create databases that may grow to many times the size of the original source library"

      500KLOC -> too big for wkstn DB

      Staged analysis, raw vs derived data

      flexible USER interfaces

    1. TRAILS::= prototype hypertext tool

      linking program data - HIPO | lexical afinity |Data model attributes

      p389: "Lost in Hyperspace" - "loosing track of what they are looking at or how they got there"


BrownShipmanVetter07

  1. Jeff Brown & Bill Shipman & Ron Vetter
  2. SMS: The Short Messaging Service
  3. IEEE Computer Magazine V40n12(Dec 2007)pp106-110
  4. =STANDARD SMS PROTOCOL CELL MOBILE PHONE Shortcodes WAP EMAIL
  5. SMS::protocol="Short Message Service", not just for teenagers, also connects to the web and EMail.

BrownswordOberndorfSledge00

  1. Lisa Brownsword & Tricia Oberndorf & Carol A Sledge (SEI)
  2. Developing new processes for COTS bases systems
  3. IEEE Software Magazine V17n3(Jul/Aug 2000)pp48-55
  4. =IDEA PROCESS COMPONENTS COTS
  5. CBS:="COTS based system", COTS:="commercial off the shelf".
  6. Requirements, marketplce, and architecture/design are defined and tradedog at once. cf [Boehm00?]
  7. engineering+business+project areas.
  8. architecture is only assett youown and so is strategic and must beflexible.

Broy93

  1. Manfred Broy
  2. Functional Specifications of time-sensitive Communicating systems
  3. ACM Trans Softw Eng Methodol V2n1(Jan 1993)pp1-46 CR9311-0858
  4. =THEORY PURPOSE NON_SEQUENTIAL
  5. (dick)|-Contacted Manfred by Email about a typo. Archive on Wiley. Copy in Office.

Broy01

  1. Manfred Broy
  2. Toward a Mathematical Foundation of software engineering Methods
  3. IEEE Trans Software Engineering V27n11(Jan 2001)pp42-57 CR0102-0065
  4. =THEORY METHODS ALGEBRA DIGRAPH FSM/STD DFDs ADT ERD SEQUENCE DATA
  5. Not object oriented.

Broy11

  1. Manfred Broy
  2. Can Practitioners neglect theory and theoreticians Neglect practice?
  3. IEEE Computer V44n10(Oct 2011)pp19-24
  4. =ESSAY GAP THEORY ENGINEERING
  5. Theory should help establish terminology, techniques, and measurements. Practicioners have provided good ideas but where is the scientific tests of these theories?
  6. Craft, Science, or Engineering?
  7. Theory should help organize knowledge -- both domain and technical knowledge
  8. A method/methodology may not have an explicit theory and probably: does not scle, is too difficult, not well designed, and not cost-effective.
  9. Theory should be part of a software enginmeers education: operating systems, data bases, protocols, formal languages, semantics,... informatics, sociology,...
  10. Theory in research: based on empirical data, isolated, vs ad hoc methods.
  11. We do not need beautiful theories -- we need to solve particular problems.
  12. Other forms of engineering a based on separate sciences... software engineering depends on logics and theories of information and computation.

BroyNelson89

  1. Manfred Broy & Greg Nelson
  2. Can fair choice be added to Dijkstra's calculus
  3. Report 38 (Feb 1989) from Digital Equipment Corpn Systems Research Center Palo Alto CA 94301
  4. =THEORY guarded-commands
  5. see BroyNelson94

BroyNelson94

  1. Manfred Broy & Greg Nelson
  2. Adding fair choice to Dijkstra's calculus
  3. ACM Trans Program Lang Syst V16n3(May 1994)pp924-938 CR9508-0601
  4. =THEORY guarded-commands
  5. see BroyNelson89

Brun-ColtonWall95

  1. Francoise Brun-Colton & Patricia Wall
  2. Using Video to Re-Present the User
  3. Commun ACM V38n5(May 1995)pp61-71
  4. =EXPERIENCE USER VIDEO DOCUMENTATION

BrunsChandra03

  1. Glenn Bruns & Satish Chandra
  2. Searching for Points-To Analysis
  3. IEEE Trans Software Engineering V29n10(Oct 2003)pp883-897
  4. =ALGORITHMS POINTERS CODE DATA LTS CFG SEMANTICS REACHABILITY

Brunner75

  1. John Brunner
  2. The Shockwave Rider
  3. Harper & Row 1975 ISBN 0-060-10559-3
  4. =NOVEL SF NETWORK WORMS PREDICTION MARKETS TARNOVER TOFFLER
  5. Wikipedia [ The_Shockwave_Rider ]
  6. Review 1976 [ 1095302.1095305 ]

BruntinkDeursenEngelenTourwe05

  1. Magiel Bruntink & Arie van Deursen & Remco van Engelen & Tom Tourwh One the use of clone detection for identifying crosscutting concern code
  2. IEEE Trans Software Engineering V31n10(Oct 2005)pp801-818
  3. =CASE STUDY CODE C ASPECTS TOOLS Clone ccdiml CCFinder Komondor's PDG-DUP
  4. Tools can find many examples of duplicated code for common tasks (eg. testing for NULL).
  5. But if set to find more they become imprecise and retrieve irrelevant code.
  6. Humans do better.
  7. Only Concerns relevant to weaknesses in C considered. Memory, null pointers, r ange checking, error handling, & tracing calls.

Bryant90

  1. Tony Bryant
  2. Structured methodologies and formal notations: Developing a framework for synthesis and investigation
  3. pp229-241 in Nicholls90
  4. =THEORY Z SSADM DEF STAN 0055
      Chapter 2 section 4.1 clash between rigid method and dynamic system page 231

BrylowPalsberg04

  1. Dennis Brylow & Jens Palsberg
  2. Deadline Analysis of Interrupt-Driven Software
  3. IEEE Trans Software Engineering V30n10(Sep 2004)pp634-655
  4. =DEMO Formal TIMING Z86 Interrupt Handling TEST

Buccietal94

  1. Paolo Bucci & Joseph E Holingsworth & Joan Krone & Bruce W Weide
  2. Implementing Components in RESOLVE
  3. ACM SIGSOFT Software Engineering Notes V19n4(Oct 1994)pp29-39 See Sitaraman94
  4. =IDEA ARCHITECTURE RESOLVE

BucciHeymLongWeide02

  1. Paolo Bucci & Wayne Heym & Timothy J Long & Bruce W Weide
  2. Algorithms and Object-Oriented Programming: Bridging the Gap
  3. SIGCSE'02 Proceeding & ACM SIGCSE Bulletin V34n1(Mar 2002)pp302-306
  4. =EXAMPLE ALGORITHM SORTING MACHINES Object-Oriented DESIGN
  5. describe principles: hide data representation, hide implementation, hide when things are done, expose mathematical state abstraction (lies), expose precise pre/post conditions for operations in interface.
  6. A sorting machine has a phase and a bag of items it can insert objects, change phase and then remove objects in a different order.
  7. Table with 6 implementations: insertion, selection, quick. merge, heap, tree.

Buchanan11

  1. Mark Buchanan
  2. The Cassandra Factor
  3. New Scientist V209n2797 (Jan 29 2011)pp36-39
  4. =ADVERT =EXAMPLES DYNAMIC SYSTEM MODEL ODEs SLOW RECOVERY CRITICAL POINT TIPPING POINT PHASE CHANGE
  5. Long before a system is about to change phase it starts to recover more slowly from disturbances.

Buchi02

  1. J R Buchi
  2. On a Decision Method in Restricted second-order arithmetics
  3. Proc Int'l Conf. Logic, Methods and philosophy of science (1962) pp1-12
  4. =THEORY AUTOMATA omega-automata Buchi-automata
  5. Given a standard finite state automata with accepting states its language is defines a set of infinite strings that are acceptable: they can return an infinite number of times to at least on of the accepting states.

BuchsGuelfi00

  1. Didier Buchs & Nicolas Guelfi
  2. A Formal Specification Framework for Object-Oriented Distributed Systems
  3. IEEE Trans Software Engineering V26n7(Jul 2000)pp630-652
  4. =DEMO FORMAL SPECIFICATION DISTRIBUTED OBJECT_ORIENTED PETRI-NETS CO-OPN/2 based on COOPN COIL
  5. transit node TNode example

Bucken93

  1. Mike Bucken
  2. Field Report: OO Methods Vie for Recognition
  3. Software Magazine(May 1993) pp25-26
  4. =REPORT Methods Object-oriented CASE
  5. 7 competing methods
  6. none complete(object class relationship attributes messages inheritance) but evolving to include
  7. CASE vendors doubtful

Buckley93

  1. Fletcher F Buckley<f.buckley@compmail.com>
  2. Defining Software Engineering as a Profession
  3. IEEE Computer Magazine(Aug 1993) pp76-78
      Establishing an ad hoc committee to initate action to establish SE as a Proffession Contact CS Pres James Aylor phone (203)371-0101 jha@virginia.edu See TODO/0 SE Proffession .Ref Parnas90

BuckleySilberschatz83

  1. An Effective Implementation for the Generalized Input-Output Construct of CSP
  2. ACM TOPLAS V5n2(April 1983)pp223-235
  3. =DEMO optimization non-sequential

Budd87

  1. Timothy Budd<budd@fog.cs.orst.edu>
  2. A Little Smalltalk
  3. Addison Wesley 1987
  4. =TOOL
  5. Source code: anonymous FTP to cs.orst.edu
  6. get pub/budd/small.v3

Budd94

  1. Timothy A. Budd<budd@cs.orst.edu>
  2. Classic Data Structures in C++
  3. ISBN 0-201-50889-3 QA76.73.C153B83(1994) BNB 93-21664 Dewey 005.7'3
  4. =TEXT source code <mail :almanac@cs.orst.edu>
      Chapter 1 pp3..29 Engineering Software, Introduction to Rumbaugh Responsibility-driven design.

      [CRC] cards Other documentation: arguments pro/con design decisions, project log and schedule, user manual. All evolve.

      Isolate sources of change.

      Reduce coupling.

      Isolate hardware dependencies.

      Software Component


      1. Behavior(protocol) & State
      2. Instance and Class
      3. Coupling and Cohesion
      4. Interface & Implementation (two views)

      Good side bar (page 17) on information hiding.

      Names:

    1. pronnounceable, words visible, few meanings, no digits, Booleans should identify the true condition, take care with infrequent and/or costly reuse via composition and inheritance

      Top down SWR:


      1. sequence, selection, parts
      2. find common


Budgen94

  1. David Budgen<db@cs.keele.ac.uk>
  2. Software Design
  3. Addison-Wesley Publishing Company 1995 ISBN 0-201-54403-2
  4. =TEXT =SURVEY METHODS

Budgen99

  1. David Budgen
  2. Software Design Methods: Life Belt or Leg Iron?
  3. IEEE Software Magazine V16n5(Sep/Oct 1999)pp136+134-135 [ software ]
  4. =ESSAY DESIGN METHODS
  5. Real designers are oportunistic and modify the methods they are taught.

Budgen13

  1. David Budgen
  2. Design Patterns: Magic or Myth?
  3. IEEE Software Magazine V30n2(Mar/Apr 2013)pp87-91 [ software ]
  4. =EMPIRICAL =SURVEY =POLL GoF OO DESIGN PATTERNS
  5. Evaluations of design patterns in [Gammaetal94] (GoF book).
  6. Not much experimentation and few polls on the "Gang of Four" patterns. Only a few (8) have been evaluated.
  7. Some evidence separating the best from the worst for 8 patterns.
  8. list= (Observer, Composite, Abstract Factory, Facade, Factory Method, Iterator, Visitor).
  9. More positive evidence for early items in list, and more negative for the end of the list.

BudgenRigby07

  1. David Budgen & Michael Rigby & Pearl Brereton & Mark Turner
  2. A Data Integration Broker for Healthcar Systems
  3. IEEE Computer Magazine V40n4(Apr 2007)pp34-41
  4. =ADVERT SERVICE DATA HEALTHCARE IBHIS ONTOLOGY SEMANTICS UK

Buhr95

  1. Peter A Buhr
  2. Are Safe Concurrancy Libraries Possible?
  3. Commun ACM V38n2(Feb 1995)pp117-120
  4. =EXPERIENCE NONSEQUENTIAL RISKS of adding libraries to sequential LANGUAGES

Buhr98

  1. R J A Buhr
  2. Use Case Maps as Architectural Enitites for Complex Systems
  3. IEEE Trans SE V24n12(Dec 1998)pp1131-1155 CR9908-0630
  4. =DEMO GRAPHIC [UCM]
  5. Collaborations as path thru responsibillities of components: forks and joins, and/or, rendezvous, time, stubs, plugins, component stacks, dynamic stub, movements
  6. UCM::graphic_noatation="Use Case Map". Syntax at [ agents ]

BuhrCasselman96

  1. R J Buhr & R S Casselman
  2. Use Case Maps for Object-oriented Systems
  3. Prentice Hall Int NJ 1996 ISBN 0-13-456542-8 [CR] 9705-0315 D.1.5
  4. =TEXT GRAPHIC [UCM]
  5. Structured prose descriptions of interactions: scenarios between a system to be designed and the users of the system

BuhrFortierCoffin95

  1. Peter A Buhr & Michel Fortier & Michael H Coffin
  2. Monitor Classification
  3. ACM Computing Surveys V27n1(Mar 1995)pp64-107
  4. =SURVEY nonsequential
      Monitors are best used to serialize access to passive objects and resources -- objects such as data structures and files -- that do not have their own thread of execution.

Bullard92

  1. L Bullard
  2. Applying frame based SGML to enterprise engineering
  3. <TAG> V5n7(Jul 1992)
  4. =DEMO SGML

Burge91

  1. T Burge
  2. Truth and Singular Terms
  3. in Philosophical Applications of Free Logic Oxford Univ Press 1991 pp 189-204
  4. =THEORY FORMAL LOGIC
  5. See [LPT]
  6. and [LPV]

BurgeBrown07

  1. Janet E Burge & David C Brown
  2. Software Engineering Using RATionale
  3. Journal of Systems and Software V81n3(2008)pp 395-413 CR 0906-0559
  4. =EXPERIMENT =DEMO TOOL REQUIREMENTS DESIGN RATIONALE IDE SEURAT Eclipse Java RATspeak inference
  5. Faster maintenance for nonexperts (only)
  6. Who were the subjects?
  7. What is cost of capturing the rationale?

Burgess91

  1. Angela Burgess (Ed)
  2. Phone Outages Blamed on Switching Software
  3. IEEE Software V8n5(Sept 1991)pp100-101
  4. =EXPERIENCE RISKS

Burns00

  1. David Burns
  2. The Mental Game of Debugging
  3. Software Development Magazine V8n3(Nov/Dec 2000)pp44-48
  4. =ESSAY ANECDOTE DEBUGGING GOOD
  5. boast, relax, know the territory, if obscure start at the beginning, know what you don't know, seek the right tool, patient, eyes open, know what it should have been(specs can be wrong), don't patch it: fix it!

Burnsten07

  1. Sidney L Burnsten
  2. To map a process, first find its swimlane
  3. Commun ACM V50n10(Oct 2007)p14
  4. =ANECDOTE IBM SLB GRAPHIC ANALYSIS DESIGN METHOD DesignFlow
  5. SLB::="Swim Lane Based".
  6. Draw both "as is" and "to be" diagrams.
  7. Involve users and stakeholders.
  8. Each actor has a swimlane. Show activities & decisions in lanes. include information.
  9. Claims many years of successful use.
  10. Claims better than DFDs or Usecases.
  11. Sounds like it is compatible with UML2.0 Activity diagrams.

BurrowsAbadiNeedham89

  1. M Burrows & M Abadi & R M Needham
  2. A Logic of Authentication
  3. Proc Royal Society of London A V426(1989)pp233-271
  4. =THEORY FORMAL LOGIC
  5. BAN_logic::Logic, logic of authentication -- who can believe what about whom? [ BAN.html ]
  6. See also [BurrowsAbadiNeedham90]

BurrowsAbadiNeedham90

  1. Michael Burrows & Martin Abadi & Roger M Needham
  2. A Logic of Authentication
  3. ACM Transactions on Computer Systems V8n1(Feb 1990)pp18-36 [ 77648.77649 ]
  4. =THEORY =DEMO LOGIC PROTOCOL PROOF V&V BAN KERBEROS CRYPTO
  5. See also [BurrowsAbadiNeedham89]
  6. Defines the [BAN_logic] of beliefs and messages.

Burridge99

  1. Trevor Burridge
  2. Certification in the united kingdom
  3. IEEE Software Magazine V16n6(Nov/Dec 1999)pp46
  4. =SIDEBAR ENGINEERING UK
  5. UK has certified software engineers via IEE+BCS for years, no adverts for software engineers [ http://www.iee.org ] [ http://www.bcs.org.uk ] [ http://www.jobserve.com/ ]

BuschmannHenney10

  1. Feank Buschmann & Kevlin Henney
  2. Five Considerations for software architecture, part 2
  3. IEEE Software Magazine V27n4(Jul/Aug 2010)pp12-14
  4. =DEMO PATTERN IMPROVEMENT FACTORY SYMMETRY creator EMERGENCE non-sequential
  5. Symmetry suggests that creators (for example factories) should also be responsible for destroying the objects they create.
  6. (dick)|-why not life history objects as in JSP/JSD? [Sanden09] [Sanden03]
  7. Emergence suggests the use of Pipes and Filters to handle work flows rather than a shared repository with hardwired transactions.
  8. (dick)|-Pipes and filters goes back to Doug McIlroy and compiler technology and Michael A Jackson's methods for Data Processing.

BuseWeimer10

  1. Raymond P L Buse & Westley R Weiner
  2. Learning a metric for code readability
  3. IEEE Trans Software Engineering V36n4(Jul/Aug 2010)pp546-558
  4. =EXPERIMENT READABILITY 120 ANNOTATORS FIT FEATURES METRICS CHANGES DEFECTS CODE QUALITIES sourceforge
  5. Annotators were students at U o Virginia.
  6. Can construct a metric that predict readability with 80% reliability.
  7. Same metric predicts the number of defect reports, changes, & defect log messages.
  8. Two dozen factors. High scoring metrics: avg number of identifiers, avg line length, avg number of parentheses, number of periods, avg indenting, etc.
  9. The number of comments, blank lines have a negative effect.

Bussler07

  1. Chistoph Bussler
  2. The Fractal Nature of Web Services
  3. IEEE Computer Magazine V40n3(Mar 2007)pp93-95
  4. =HARMFUL NAIVE SERVICE SOA PERFORMANCE QUEUES
  5. A new silver bullet: Service-oriented Architecture.
  6. If everything is a service and can be called by any other service then performance will be unstable.
  7. Example: Simple request and reply leads 14 messages, 24 remote invocations, and 4 distributed transactions.
  8. Need to think about what should be offered as a service....

BustardWinstanley94

  1. David W Bustard & Adam C Winstanley
  2. Making changes to Formal Specifications: Requirements and an Example
  3. IEEE trans on Soft Eng vSE-20n8(Aug 1994)pp562-568
  4. =DEMO SCAFFOLD FORMAL MAINTENANCE LOTOS Dynamics

ButlerEspositoHebron99

  1. Keith A Butler & Chris Esposito & Ron Hebron
  2. Connecting the Design of Software to the Design of Work
  3. Commun ACM V42n1(Jan 1999)pp38-46
  4. =ADVERT SYSTEM USER should drive design

ButlerHope02

  1. Samantha Butler & Sian Hope
  2. Software Process Evaluation using remote monitoring methods

    [SCI2002] V1(Jul 2002)pp

  3. =EXPERIENCE IMPROVEMENT MEASUREMENT metrics

Butov05

  1. Andrey Butov
  2. XML-Binary optimized packaging
  3. Dr. Dobbs #379(Dec 2005)pp53-55
  4. =ESSAY CODE Binary XML XOP
  5. How to embed binary data in XML?

CACM25

  1. Reprints
  2. Special 25th Anniversary Issue
  3. Commun ACM V26 n1 (Jan 1983)
  4. history

CR

  1. Various reviewers
  2. Computer Reviews
  3. ACM Press NY NY,
  4. see [ home.cfm ]
  5. =COLLECTION REVIEWS HISTORY
  6. =JOURNAL REVIEWS
  7. Each review is numbered YYMM-nnnn where YY indicates the year, MM the month, and nn is a serial number.

    [CR] also provides a classification of subjects for each item -- CCS. For example D.2.1 is for Requirements/Specifications

CWE10

  1. Steve Christie (Ed) [ cwe@mitre.com ]
  2. CWE - 2010 CWE/SANS Top 25 Most Dangerous Programming Errors
  3. MITRE/SANS [ http://cwe.mitre.org/top25/ ]
  4. =POLL ERRORS SECURITY WEB/NET
  5. Several categorized lists of error types: Cross-site scripting. SQL injection, Classic Buffer overflow, ...

CabotOliveTeniente03

  1. Jordi Cabot & Antoni Olive & Ernest Teniente
  2. Representing Temporal Information in the UML
  3. LNCS 2863 <<UML>> 2003 -- The Unified Modeling Language Oct 2003, pp44-59
  4. =IDEA UML/OCL TEMPORAL ER MODEL TOOL XML XMI XSL
  5. Ls:=life span of the system.
  6. E(e,t) :=e is an instance of type E at time t.
  7. R(e1,e2,...,t) :=(e1,e2,...) participate in relation R at time t
  8. Ci(e,E) :=all classification intervals of e in E
  9. Intervals have properties like BelongsTo, endsAt, ...
  10. Classification by frequency and durability. Therefore temporal stereotypes.
  11. Historical entities/relations hold the history of entities via <<timestamp>>

Cahoon06

  1. Jeff Cahoon
  2. Faster Development Through Modeling
  3. Dr. Dobb's Journal (Oct 05, 2006) Link: [ 193104822 ]
  4. =TYPE MODEL RAPID PROTOTYPE GENERATION MDA
  5. "Jeff describes a modeling technique that uses free tools and Model-Driven Architecture processes to speed up development."
  6. Method
    1. Create a model of the application.
    2. Write a miniapplication that implements the first instance of the repeated set of steps.
    3. Pull apart the miniapplication into template files replacing the named parts in the repeated set of steps with recognizable strings for substitution.
    4. Write code that can rebuild the miniapplication from the templates and the model.
    5. Generate all the code for the whole application.


  7. (dick)|-model=horrible diagram.

Caietal91

  1. Jiazhen Cai & P Facon & F Henglein & Robert Paige & E Schonberg
  2. Type Analysis and Data Structure Selection
  3. in Constructing Programs from Specifications B. Moeller ed. North_Holland 1991

CaiPaige93

  1. Jiazhen Cai & Robert Paige
  2. Towards Increased Productivity of Algorithm Implementation [Notkin93] pp 71-77
  3. =DEMO SETL2 Data Engineering
  4. Claims a 5 to 9 fold improvement in productivity by repetedly refining SETL2->SQ2->C. Giving 1.5 faster code than FORTRAN.

  5. States that SETL optimizations were never very effective because of the hardwired hash table implementations of data structures.

Calan89

  1. Frank Calan
  2. The Quality System: A Source Book for Management and Engineers (2nd Edn)
  3. Chilton Book Co. Radnor PA 1989
  4. =TEXT QUALITY

CalcagnoOHearnBornat03

  1. C Calcagno & P OHearn & R Bornat
  2. Program logic and equivalence in the presence of garbage collection
  3. Theoretical Computer Science V298n3(??? 2003)pp557-581
  4. =THEORY FORMAL LOGIC HOARE Garbage Collection (D.4.2) VERIFICATION
  5. What do we mean when we say that a particular object "exists" on the heap? To preserve Hoare's assignment axiom in the presence of garbage collection, the existence of garbage becomes "virtual".
  6. The wise program prover should use a language with proved automatic garbage collection, and avoid assertions that refer to garbage!
  7. Includes a formal model of garbage collection.

Calchera95

  1. Gini Calchera(DFAS)
  2. Assessing a System Before Re-engineering it: What a Novel Idea
  3. IEEE Reverse Engineering Newsletter n8(Winter 1995)pp6-9
      Mistake to start a reengineering projects without
      1. knowing what it will cost
      2. knowing the condition of what you are replacing
      3. Choosing it as the best bang for the buck

      Assess
      1. Support
      2. Strategic Value
      3. Functionallity
      4. Technical QUALITY
      5. Architecture and SE Envinronment

      Identify the problems then start planning what to do.

Caldieraetal91

  1. Gianluigi Caldiera & Victor R. Basili
  2. Identifying and Qualifying Reusable Software Components
  3. IEEE Computer V24n2(Feb 1991)
  4. Parallel SW process.

CalinescoGhezziKwiatowskaMirandola12

  1. Radu Calinescu & Carlo Ghezzi & Marta Kwiatowska & Raffaela Mirandola
  2. Self-adaptive Software needs Quantitative Verification at runtime
  3. Commun ACM V55n9(Sep 2012)pp69-77 [ 2330667.2330686 ]
  4. =THEORY ADAPTIVE PERFORMANCE MONITOR ADJUST DTMC PCTL SERVICE
  5. Need to verify: If Specification and Domain then Requirement.
  6. Non-standard activity diagrams look good...
  7. Markovian model of the specification, Probalistic Computer Treel Logic requirements.
  8. Domain data comes from monitoring service performance.
  9. System can switch components if performance is bad.

CallaghanHirschmuller98

  1. Michael Callaghan & Heiko Hirschm"uller
  2. 3-D Visualisation of Design Patterns and Java Programs in Computer Science Education
  3. ACM SICSE Conf Proc 6th Annual Conf on the Teching of Computing SIGCSE Bulletin V30n3(Sep 1998)pp37-40
  4. =DEMO GRAPHIC 3D VRML TOOL JAVA WWW SVL VISP
  5. See [ ~kira ] but compare with [FiejsJong98]

Callison95

  1. H Rebecca Callison(mailto:callison@research.cs.orst.edu)
  2. A Time-sensitive Object Model for Real-time Systems
  3. ACM Trans Softw Eng Methodol V4n3(Jul 1995)pp287-317
  4. TSO::=Time Sensitive Object.

CalloniBagert94

  1. Ben A Calloni<BGBAC@TTACSI.TTU.EDU> & Donald J Bagert<BEDJB@TTACSI.TTU.EDU>
  2. Iconic Programming in BACCI Vs Textual Programming: Which is a Better Learning Environment?
  3. ACM 25th Technical Symposium on Computer Science Education SIGCSE Bulletin V26n1(Mar 1994)pp
      Graphics helped people(EE and CS) to learn Pascal as shown by final scores and lab scores.

      BACCII uses MS windows helps students design algorithms by using Icons, intuitive gudance, and top-down methodology Ref to Scanlan88 & Scanlan89


CalvettiSomersalo2007

  1. Daniela Calvetti & Erkki Somersalo
  2. Introduction to Baresian Scientific Computing: Ten lectures on subjective computing
  3. Springer-Verlag NY Secaucus NY 2005 ISBN 0387733930 CR 0811-1048
  4. =UNREAD LECTURES BAYES PROBABILITY THEORY PHILOSOPHY

Cameron84

  1. John R Cameron
  2. JSP & JSD: The Jackson Approach to Software Development
  3. IEEE Tutorial Cat No EH0206-3 IEEE Computer Society LA Order No 516
  4. =HOWTO METHODS DDD DAD Reality System

Cameron86

  1. John R Cameron
  2. An overview of JSD
  3. See [BerglandZave86] pp222-240
  4. =ADVERT METHODS DAD Reality

Cameron89

  1. John R Cameron
  2. JSP and JSD: The Jackson Approach to Software development(2nd Edn)
  3. IEEE Comp Society Press CA 1989
  4. =HOWTO METHODS DDD DAD Reality System

Cameron02

  1. John Cameron
  2. Configurable Development Processes
  3. Commun ACM V45n2(Mar 2002)pp72-77
  4. =ADVERT WPD PROCESS PRODUCT DESCRIPTION META IBM EXPERIENCE
  5. WPD::="Work Product Description".
  6. About 100 WPDs plus dependency diagrams, work breakdown structures (rough plans/checkpoints), Roles/skill-sets linked to products and parts of plans, details of complex techniques.
  7. Easier to describe products rather than processes.
  8. Capturing intellectual capital.
  9. Rigid processes do not work when applied uniformly. They always fail. However work products can be transplanted with success.
  10. Configuration: selecting products using spreadsheet ad advice from WPDs. If a product is adopted then the WPD contains or refers to information for producing and using the product.
  11. Products evolve over time to a finished from.

CameronR93

  1. Robert D Cameron
  2. Extending contect free grammers with permutation phreases
  3. ACM Lett Program Lang Syst V2n1-4(March-Dec 1993)pp85-94
  4. CR9412-0877
      Defines permutation phrase <<e1||e2||....e[n]>> ::= | [p:perm(1..n)]( ![i:1..n]( e(p(i)) ) ) expressive utility context free power recursive descent style parsing when....

Camilleri90

  1. Albert John Camilleri
  2. Mechanizing CSP Trace Theory in Higher Order Logic
  3. IEEE Trans Software Engineering SE-V16n9(Sep 1990)

Camp01

  1. L Jean Camp
  2. An atomicity-Generating Protocol for anonymous Currencies
  3. IEEE Trans Software Engineering V27n3(Mar 2001)pp272-278
  4. =EXAMPLE THEORY ECommerce NONSEQUENTIAL

Campbell-Kelly03

  1. Martin Campbell-Kelly
  2. From Airline reservations to Sonic the Hedgehog: A History of the Software Industry
  3. MIT Press ISBN 0-262-03303-8 $29.95,
  4. Review IEEE Computer Magazine V36n6(Jun 2003)pp78- [CR] 0308-0762
  5. =HISTORY SOFTWARE ECONOMICS
  6. Three main sectors: contractors, makers of corporate software, producers for the mass market.
  7. Many diverse products and markets.

Campbell-Kelly08

  1. Martin Campbell-Kelly
  2. Historical Reflections -- Will the future of software be open source
  3. Commun ACM V51n10(Oct 2008)pp21-23 [ 1400181.1400189 ]
  4. =HISTORY 1950s-2000s OPEN SOURCE F/OSS
  5. Initially source code was distributed with the executables and libraries.
  6. Unsuspected technologies have and will disrupt predictions.

Campbell-Kelly10

  1. Martin Campbell-Kelly
  2. Be careful what you wish for
  3. Commun ACM V53n4(Apr 2010)pp25-26 [ 1721654.1721666 ]
  4. =HISTORY TABLES Napier Briggs Babbage Mauchly Eckert
  5. the history of mathematical tables.
  6. Babbage got into computing devices to print tables so the whole of Information and Computer Technology is an unintended side-effect of a limited initial project.
  7. Later the computer made the mass production of accurate and useful tables possible just when computers started to make mathematicsl tables obsolete.

Campbell-Kelly10b

  1. Martin Campbell-Kelly
  2. Historical Reflections: Victorian Data Processing
  3. Commun ACM V53n10(Oct 2010)pp19-21 [ 1831407.1831417 ]
  4. =HISTORY DATA PROCESSING LOGICAL vs PHYSICAL BABBAGE CLEARING CHECKS USA CHEQUES UK
  5. Shows an efficient solution to a problem in the form of a multi-agent procedure.
  6. Traces the evolution of Bank Clearing Houses in the UK (as documented by Babbage) and then in the USA.
  7. Argues that similar algorithms are still used in modern information technology.

CampbellHaberman74

  1. R H Campbell & A N Haberman
  2. The specification of Process Synchronisation by Path Expressions
  3. Lecture Notes in Computer Science n16 (Apr 1974)
  4. =THEORY REGULAR NONSEQUENTIAL
  5. Path expressions, ref in ACM SIGSOFT Software Engineering Notes V17n4 (Oct 1992)p49&52

CamposNunes07

  1. Pedro Campos & Nuno Jardin Nunes
  2. Practitioner Tools and Workstyles for User-Interface Design
  3. IEEE Software Magazine V24n1(Jan/Feb 2007)pp73-80
  4. =POLL 300 USER INTERFACE DESIGNERS =DEMO CanonSketch MXML macromedia
  5. Email surveys + interviews to establish how user interface designers work.
  6. Most use manual tools: paper, pencil, whiteboards, Post-It notes.
  7. Common transitions: problem->solution, refinement, ...
  8. Problem->solution was perceived as the most costly one.
  9. Examples of tools to support transitions -- drag and drop between synchronized views.
  10. TaskSketch::= See http://dme.uma.pt/tasksketch (Mac OSX)
  11. CannonSketch::= See http://dme.uma.pt/canonsketch

CanalEtal03

  1. Carlos Canal & Lidia Fuentes & Ernesto Pimentel & Jose M Troya & Antonio Vallecillo
  2. Adding Roles to CORBA Objects
  3. IEEE Trans Software Engineering V29n3(Mar 2003)pp242-260
  4. =CASESTUDY CORBA IDL PROTOCOL DYNAMIC SPECIFICATION π-calculus GRAMMAR ROLE TESTING MWB Java Orbix
  5. role name( formal_arguments)= ... role_name( actual_arguments ) ...

CanevetGilmoreHillstonKloulStevens04

  1. C Canevet & Stephen Gilmore & Jane Hillston & Leila Kloul & P Stevens
  2. Analyzing UML2.0 activity diagrams in the Software performance engineering process
  3. WOSP'04 & ACM SIGSOFT Software Engineering Notes V29n1(Jan 2004)pp74-78
  4. =DEMO TOOL performance PETRI ALGEBRA PEPA UML2 [GilmoreHillstonKloulRibaudo04]

Canforaetal92

  1. Gerardo Canfora & Anielo Cimitile & Ugo de Carlini
  2. A Logic-Based Approach to Reverse Engineering Tools Production
  3. IEEE Trans on Software Eng VSE-18n12(Dec 1992)pp1053-1064
      Prolog model of a Pascal-like program gives queriable data base/knowledge base.

      Implemented on silicon/UNSW Prolog.


CanforaPentaCerulo11

  1. Gerardo Canfora & Massimiliano Di Penta & Luigi Cerulo
  2. Achievements and challenges in software reverse engineering
  3. Comm ACM V54n4(Apr 2011)pp142-151 [ 1924421.1924451 $CR ]
  4. =SURVEY 2000-2010 REVERSE ENGINEERING TOOLS TECHNIQUES GUI PLUGINS
  5. Good lists and bad graphics!

CangussuDeCarloMathur02

  1. Joao W Cangussu & Raymond A DeCarlo & Aditya P Mathur
  2. A Formal model of the software test Process
  3. IEEE Trans Software Engineering V28n8(Aug 2002)pp782-796
  4. =MATH PREDICTING SOFTWARE TESTING
  5. Splits testing into phases. Models each phase in turn.
  6. Suggests an linear 2nd order ordinary differential equation to model the number of errors in a piece of software. Complexity is analogous to inertia, test effort is proportional to the number of errors (Volterra predator-prey model!), and that working quickly tends too slow the process(viscosity).
  7. Derives typical curves (some of two exponential decays) and a matrix version.
  8. Presets extreme cases and ways to estimate parameters.
  9. Case study of ΤΕΧ in a Purdue Tech report.
  10. Razorfish porting 4MLoc COBOL to SAP/R3program.

CangussuDeCarloMathur03

  1. Joao W Cangussu & Raymond A DeCarlo & Aditya P Mathur
  2. Monitoring the software test process using statistical process control: a Logarithmic approach
  3. FSE-11 & ESEC 9 & ACM SIGSOFT Software Engineering Notes V28n5(Sep 2003)pp158-167
  4. =THEORY STATISTICS TESTING QUALITY CONTROL
  5. Before applying quality control to the number of defects fixed it is best to first lake logarithms to fit an exponential curve to form the expected value vs time.

Cann93

  1. Ronnie Canne
  2. Formal Semantics: An Introduction
  3. Cambridge University Press New York NY 1993 ISBN 0-521-37610-6
  4. CR9411-0776
  5. (CR)|-Semantics of natural language, set theoretical, Lambda abstraction, generalized quantifiers, advanced text

CaoRamesh08

  1. Lan Cao & Balasubramaniam Ramesh
  2. Agile requirements engineering practices: an empirical study
  3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp60-
  4. =INTERVIEWS 16 FIRMS AGILE REQUIREMENTS BENEFITS CHALLENGES PURPOSES TESTS QUALITIES
  5. Identified 7 practices each with benefits & challenges.
    1. Face-to-face communication not documents.
    2. Iterating (requirements, priorities, planning, reviews, & acceptance tests).
    3. Prototypes.
    4. Test driven development(TDD).

  6. challenges: forgotten qualities, wrong architecture, lack experience of TDD...

CaplanHarandi95

  1. Joshua E Caplan & Mehdi T Harandi(*@cs.uiuc.edu)
  2. A Logical Framework for Software Proof Reuse [SamadzadehZand95] pp106-113
  3. =THEORY DEMO PROOF REUSE
  4. Hoare triples do not have referential transparency!
      Created a new quantifier to bind (and hide) program identifiers into a context and protect them from sustitution. deca;arations also bind identifiers (and so hide them).

      Assignment axiom:

    1. for_vars x( {P(t=>x[m])} x[m]:= t {P} ). Declaration axiom:
    2. for_vars x({ P and x[m]=e} C{Q})
    3. ---------------------------------------------------where x=y,x[m],z.
    4. for_vars y,z( {P} new x[m]:=e ; C {Q} )

CaplatSourrouille05

  1. Guy Caplat & Jean-Louis Sourrouille
  2. Model Mapping Using Formalism Extensions
  3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp44-51
  4. =EXAMPLE THEORY METAMODEL TRANSLATION + EXTENSIONS MOF UML PROFILES MDA ARTO C++ PIM PSM CODE Sherlock Constraint Checker
  5. The real problem in MDA is mapping between formalisms/languages.
  6. Translating between different modeling formalisms is complicated because they have extensions.
  7. Extensions are needed because translations can not be made between formalisms .
  8. Extensions become UML profiles.
  9. Constraint Checker is a tool that tests if a model conforms to a profile and u ses the language Sherlock.

Capperetal94

  1. N P Capper & R J Colgate & J C Hunter & M F James
  2. The Impact of object-oriented Technology on Software Quality: Three case histories
  3. IBM Systems Jnl V33n1(1994)pp131-157
  4. =CASESTUDY OBJECT-ORIENTED TECHNICAL QUALITY

Capra04

  1. Licia Capra
  2. Engineering Human Trust in Mobile System Collaborations
  3. Proc SIGSOFT'04/FSE-12& ACM SIGSOFT Software Engineering Notes V29n6(Nov 2004)pp107-116
  4. =THEORY MATHEMATICS TRUST AGENTS hTrust TMF
  5. TMF::="Trust Management Framework".
  6. Models the formation, dissemination and evolution of trust between agents.
  7. trust_data::=Net{who_trusts, opinion, trusted, level, subject, direct_experiences, credentials, recommendations }.
  8. Notes

CapraFrancalanciMerio08

  1. Eugenio Capra & Chiara Francalanci & Francesco Merio
  2. An Empirical study on the relationship among Software Design Quality, Development Effort, and Governance in Open Source Projects
  3. IEEE Trans Software Engineering (Nov/Dec 2008)pp765-782
  4. =EMPIRICAL ANALYSIS 75 OPEN SOURCE PROJECTS METRICS EFFORT PROCESS MANAGEMENT
  5. In open source there is a continuum of governance practices.
  6. Conclusion: Better quality code permits looser governance but that in turn takes effort to coordinate loosely governed people.
  7. (dick)|-results are unlikely to happen by chance but the causality may be reversed.

CapretzAhmed01

  1. Luiz Fernando Capretz and Faheem Ahmed Making Sense of Software Development and Personality Types IEEE IT Professional (Jan/Feb 2010)pp6-13 [ T_IT_MakingSense.pdf ]
  2. =THEORY PERSONALITY MYERS-BRIGGS MBTI TRAITS PEOPLE PROCESS SKILLS DISCIPLINES LIFE CYCLE
  3. Theory Different personallities are most useful at different times/jobs.
  4. MBTI::="Myers-Briggs Type Indicator", [ reference.html#MBTI ]
  5. Which types fits four disciplines/phases: Table 2 "The personality types with the strongest impact on the software life cycle."
    Table
    Personality typesSystem analysisSoftware designProgrammingTesting Maintenance
    Extroversion (E)x
    Introversion (I)x
    Sensing (S)xxx
    Intuition (N)x
    Thinking (T)xx
    Feeling (F)x
    Judging (J)x
    Perceiving (P)x

    (Close Table)

Carasiketal90

  1. RP Carasik & SM Johnson & DA Patterson & George A Von Glahn
  2. Towards a Domain Description Grammar: An Application of Linguistic Semantics
  3. ACM SIGSOFT SEN V15n5(Oct 1990)pp28-43
  4. conceptual model not ERA

Card93

  1. David Card (CSC)<dc@sei.cmu.edu>
  2. Defect-Causal-Analysis Drives Down Error Rates
  3. IEEE Software Magazine(July 1993)pp98-99
  4. SQA DCA
    1. DCA has a maturity-pull effect, 1% investment can give a 50% reduction in error rates. 60% action proposals are in method

CardComer94

  1. Dave Card & Ed Comer
  2. Why do So Many Reuse Programs Fail?
  3. IEEE Software Magazine V11n5(Sep 1994)pp114-115
      systematic reuse is not a technology problem so much as a problems of
    1. economics: setting up an internal marketplace between producers and consumers
    2. culture: traing, incentives, measuremtn, management
    3. Process: strong configuration management and quality assurance(level 2 CMM).

CardDN95

  1. David N Card<dnc@sps.con>
  2. Is Timing Really Everything?(Guest Editors Introduction)
  3. IEEE Software Magazine V12n5(Sep 1995)pp19-22
      Was David Card at CSC?

Cardenas-GarciaZelkowitz91

  1. Sergio Cardenas-Garcia & Marvin V Zelkowitz
  2. A Management Tool for Evaluation of Software Designs
  3. IEEE Trans SE-16 n9(Sep 1991)p961-971. QUALITY+PURPOSE risk analysis
  4. viabillity::=correct+weighted attributes

Cardetal87

  1. David Card & Frank E McGary & Gerald T Page
  2. Evaluating Software Engineering Technology
  3. IEEE Trans on Software Eng VSE-13n7(Jul 1987)pp845-851
  4. =STATISTICS PRODUCTIVITY QUALITIES
  5. concludes: using experienced+SQA+documentation improves reliability without effecting productivity. SP and top-down reduced productivity and made small +ve difference to reliability. Perhaps cleanroom testing? Weakness:
    Let
      computer_use:=computer_time/LOC and productivity:=LOC/programmer _time

    (Close Let )
    [SelbyBasiliBaker87]

CardMoranNewell83

  1. Stuart K Card & Thomas P Moran & Allen Newell
  2. The Psychology of Human-Computer Interaction
  3. CRC Press 1983
  4. =UNREAD USER INTERACTION HCI GOMS PEOPLE
  5. GOMS::=${Goals, Operators, Methods, Selection_rules}.
  6. Provides caculations to evaluate scenarios.
  7. TBD [click here [socket symbol] if you can fill this hole]

CardZubrow01

  1. David Card & David Zubrow
  2. benchmarking software organizations
  3. IEEE Software Magazine V18n4(July/Aug 2001)pp16-17
  4. =EDITORIAL BENCHMARKING PROCESSES CMM
  5. Difficult: define clear objectives, plan carefully, and interpret cautiously.
  6. For more see pages18-56

CareyCarlson02

  1. James Carey & Brent Carlson
  2. Lessons learned becoming a framework developer
  3. Software - Practice & ExperienceV32n8(10 July 2002)pp789-800
  4. =EXPERIENCE FRAMEWORKS PATTERNS Object-Oriented
  5. You are not producing a product.
  6. You must work on and with the framework's customer's teams.

CareyDeWittNaughton94

  1. ?? Carey & ?? DeWitt & ?? Naughton
  2. The OO7 Benchmark
  3. University of Wisconsin Technical Report April 1993 revised Jan 1994
  4. =EXPERIENCE OBJECT-ORIENTED DATA PERFORMANCE
  5. See [MartinSwaran97]

Carlson01

  1. Dave Carlson
  2. Modeling XML Applications with UML: Practical E-Business applications
  3. Addison-Wesley 2001
  4. =HOW-TO XML UML BUSINESS
  5. Advert in Software Development Magazine V10n2(Feb 2002)pp44-47
  6. Also see [Carlson02b] and [Carlson02c]

Carlson02b

  1. David Carlson
  2. Modeling XML Applications
  3. Software Development Magazine V10n4(Apr 2002)pp48-50
  4. =ADVERT UML XML xCBL
  5. transforming UML models for specific platforms.
  6. Use UML profile (stereotypes and tagged values) to model XML designs.
  7. Extract from [Carlson01]
  8. Also see [Carlson02c] and [Carlson02d]

Carlson02c

  1. David Carlson
  2. Modeling XML Applications Part 3
  3. Software Development Magazine V10n5(May 2002)pp45-48
  4. =IDEA UML XML XMI OMG MOF
  5. Demos standard mapping from class diagram to XML schema with and without stereotypes indicating the XML mapping.
  6. Shows how a schema can define the XML Scheme version of generalization: <xs: element name=... type=.... substitutionGroup="generalization"/>
  7. Also see [Carlson02b] and [Carlson01].

Carlson02d

  1. David Carlson
  2. Modeling XML Applications Part 4
  3. Software Development Magazine V10n6(Jun 2002)pp38-41
  4. =ADVERT UDDI in UML WEB services SOAP XML schema
  5. UDDI::="Universal Description, Discovery, and Integration", specifies XML documents for business data like contacts, services,etc. [ http://www.uddi.org ]
  6. Also see [Carlson02b]

    [Carlson02c] and [Carlson01]

CarmelWhitakerGeorge93

  1. Erran Carmel & Randall D Whitaker & Joey F George
  2. PD and Joint Application Design: A transatlantic Comparison
  3. Comm ACM V36n6(Jun 1993)pp40-48
  4. =HISTORY JAD PD USER DESIGN PROTOTYPING REQUIREMENTS
  5. PD:="Participatory Design".
  6. JAD:="Joint Application Design".
  7. Reports claimed benefits of JAD (Table 1).
  8. Typical drawing or typical JAD room of the time.
  9. JAD moved from documentation to using CASE tools.
  10. Many prescriptions and recipes for running meetings.

CarmelAbbot07

  1. Erran Carmel & Pamela Abbot
  2. Why 'nearshore' means that distance matters
  3. Commun ACM V50n10(Oct 2007)pp40-46
  4. =SURVEY 150 ARTICLES DISTRIBUTED PROCESS LOCATION OUTSOURCE OFFSHORE SHORING SOURCING
  5. nearshore::= low geographical temporal cultural linguistic political economic historical distance to lower wage software development.
  6. Some places are both exporters and importers of software work.

CarneyLong00

  1. David Carney & Fred Long
  2. What do you mean by COTS?
  3. IEEE Software Magazine V17n2(Mar/Apr 2000)pp83-86
  4. =ESSAY COMPONENTS
  5. Don't use acronyms! Specify the type of source plus the modifiability of the component

Caromel93

  1. Denis Caromel
  2. Toward a Method of Object-oriented Concurrent Programming
  3. Comm ACM V36n9(Sep 1993)pp90-116

Carpenter95

  1. Paul Carpenter(mailto:paul@pcserv.demon.co.uk)
  2. Never mide the Functionallity: Look at the graphics
  3. IEEE Computer MagaZine V28n9(Sep 1995)p112
      Graphic toools for design of hardware and test/measurement are buggy, unreliable, incompatable "Are there, by any chance, a lot of good software testers out there ehose services aren't being paid for by the correct company?"

CarrellSkeen92

  1. ?? Carrell & ?? Skeen
  2. Object Operations Benchmark
  3. ACM Trans DBS
  4. V17n1(Mar 1992)PP??-??
  5. =EXPERIENCE OBJECT-ORIENTED DATA PERFORMANCE
  6. See [MartinSwaran97]

Carrieroetal95

  1. Nicholas Carriero & Eric Freeman & David Gelernter(all Yale) &David Kaminsky(IBM)
  2. Adaptive Parallelism and Piranha
  3. IEEE Computer V28n1(Jan 1995)pp40-49
    1. Linda, coordination language, feeder, master-worker parallelism
    2. tuple::=#data
    3. tuplespace::=Bag(tuple)

CarrieroGelernter89

  1. N Carriero & David Gelernter
  2. Linda in Context
  3. Comm ACM V32n4(Apr 1989)pp444-458
  4. =ADVERT Technical Concurrency Tuples
      See Gelernter91 - pop mirror worlds, leads to Piranha

CarringtonDukeHayesWelsh93

  1. David Carrington<davec@cs.uq.oz.au> & David Duke<duke@minster.york.ac.uk> & Ian Hayes<ianh@cs.uq.oz.au> & Jim Welsh<jom@cs.uq.oz.au>
  2. Deriving Modular Designs from From Specifications [Notkin93] pp 89-98
  3. =CASE-STUDY FORMAL Design Z
      Case study: UQ2 generic editor of structured documents.

      finding dependencies, gnerating clusters, NuProlog, tools set for analysis of Z etc

      Formula for cohesion and closeness(roughly cohesion)

      promotion can hide the simplicity of connections at lower levels. Example p92-93... tables with rd, wr, ...


Carroll82

  1. John M Carrol
  2. The Adventure of Getting to Know a Computer
  3. Computer IEEE (Nov 1982) pp49-58
  4. =EXPERIMENT USER System
  5. Using a command line interface is very like trying to play a command line game like Adventure: disorienting, illusive, empy, mystery messages, slippery, side effects, clashes with experience, no help for acheiving goals.

Carroll91

  1. John M Carroll
  2. Making Errors; Making sense; Making Use
  3. pp154-167 in FloydCetal91
  4. =ESSAY USER
      chapter 0 science and software chapter 1 implicit models HCI Science vs design, software artifacts as theories, p165 "artifacts embody implicit theories of human interaction with software",p166"we do not and perhaps cannot have a conventional deductive science for software design"

Carroll94

  1. John M Carroll<carroll@cs.vt.edu>
  2. Making Use a Design Representation
  3. Commun ACM V37n12(Dec 1994)pp29-35
  4. =EXPERIENCE USER scenario use-case
      Scenarios have always been an informal but useful part of documentation. Make them the prime representation of the system instead -- reason with them....

      Also include analysis of psychological effects of technical decision: IN <situation> <a feature> CAUSES < + effect> BUT MAY ALSO CAUSE < - effect>


Carroll95

  1. John M Carroll(ed)
  2. Scenario-based Design: envisioning work and technology in system development
  3. John Wiley & Sons Inc NY NY 1995 $44.95 ISBN 0-471-07659-7 CR9607-0458
  4. =TEXTBOOK USER SCENARIO REQUIREMENTS REUSE Use-case CASESTUDY

Carrol01

  1. John M Carroll
  2. Making use: scenario-Based Design of Human-Computer Interactions,
  3. MIT Press Cambridge MA ISBN 0-262-03279-1 QA76.9 H85 C37 review IEEE Computer Mag Apr 2000 p96
  4. =HOWTO SCENARIOS USER ANALYSIS REQUIREMENTS

CarrollCarrithers84

  1. John M Carroll & ?? Carrithers
  2. Training Wheels in a User Interface
  3. Commun ACM V27n8(Aug 1984)pp800-806
  4. =EXPERIENCE prototypes System iterative process
  5. Compare [Kelley84]

CarrollE05

  1. Edward R Carroll
  2. Estimating Software based on use case points
  3. Companion to 20th ACM SIGPLAN OOPSLA (Oct 2005)pp257-265 CR 0611-1155
  4. =EXPERIENCES THEORY ESTIMATION UCP COCOMO RUP
  5. UCP tested at a CMM Level-5 organization! 95% of estimates are within 9% or actual.
  6. Actors classified as simple(API), average(alpha), or complex (GUI).
  7. Scenarios classified by number of transactions.
  8. 13 Technical factors (T1=must be distributed, ... T13=needs special user training).
  9. 8 Experience factors.
  10. . . .
  11. Feedback and tuning. Change process, management, technique, ...

CarrollL77

  1. Lewis Carroll (ed. William W Bartley III)
  2. Symbolic Logic Pts I & II
  3. Harvester Press 1977 Hassocks Sussex England
  4. =MONOGRAPH LOGIC syllogisms SORITES EXAMPLES
  5. Pt II uses something like resolution and semantic tableaux!

CarrollRossonChinKoenemann98

  1. John M Carroll & Mary Beth Rosson & George Chin & J"urgen Koenemann
  2. Requirements Development in Scenario-Based Design
  3. IEEE Trans SE V24n12(Dec 1998)pp1156-1170 CR9906-0433
  4. =CASESTUDY USER SCENARIO participatory design.
  5. SRS to SCENARIOS + observations ->- analysis->-activity, pragmatics

CartwrightShepperd00

  1. Michael Cartwright & Martin Shepperd
  2. An empirical investigation of an object-oriented software system
  3. IEEE Trans Software Engineering V26n8(Aug 2000)pp786-796
  4. =EXPERIENCES ANALYSIS Large testing system QUALITIES Shlaer-Mellor C++

  5. Project_Technology::= See http:/www.projtech.com/, Shlaer_Mellor.
  6. 32 classes 133k LOC 1year of use part of 10 year old multimillon LOC telecommunication system. 2k developers ISO9000 accredited. 1993-1994. not OOT experienced.
  7. one header had 2988 LOC! LOC = count semicolons.
  8. depth of inheritance ranged 0..2.
  9. defect/class stats (range=> 0..47, mean =>8, median =>2).
  10. number of events and states in a class predict the size and the number of defects. size and inheriting increase the number of defects.

CarvalloFranchQuer07

  1. Juan Pablo Carvallo & Xavier Franch & Carme Quer
  2. Determining Criteria for selecting Software Components: Lessons Learned
  3. IEEE Software Magazine V24n3(May/Jun 2007)pp84-94
  4. =EXPERIENCE STANDRADS COTS COMPONENTS SELECTION QUALITIES PURPOSES Criteria Catalog ISO/IEC9126-1 METRICS EVOLUTION REALITIES DOMAIN TAXONOMY
  5. "Adopt a balanced Criteria Catalog"
  6. Three level hierachy extending one in the standard.
  7. Built for a particular "scope": domain or category of similar domains.
  8. "Recognize the importance of nontechnical criteria"
  9. "Precisely Define your selection framework"

    UML model. KitchenhamHughesLinkman01. Criteria can be linked: synergy, conflict, ... Tool [ http://www.lsi.upc.edu/~gessi/DesCOTS/ ]

  10. "Consider the Criteria Catelogs final pupose". Catalogs can be reused between similar scopes.
  11. "Organize software scopes herarchically". Build a taxonomyof scopes (Figure 5).... Based a known hierarchy of business Applications.
  12. Describes 4 or 5 ways the experience can be used.
  13. The specific evolved catalogs and taxonomies are less important than the idea of evolving, iteratively, incrementally precise catalogs and taxonomies suited to your projects.

CarverNagappanPage08

  1. Jeffrey C Carver & Nachiappan Nagappan & Alan Page
  2. The impact of educational background on the effectiveness of Requirements Inspections: an empirical study
  3. IEEE Trans Software Engineering V34n6(Nov/Dec 2008)pp800-812
  4. =EXPERIMENT PEOPLE INSPECTIONS REQUIREMENTS
  5. Provides good evidence of a couple of useful facts:
    1. People who have written requirements are better at finding defects than people who have not written them.
    2. People with Computer or Software Engineering degrees are worse at find requirements defects than those who have other degrees.

CasatiEtal00

  1. Fabio Casati & Silvana Castano & Mariagrazia Fugini & Isabelle Mirbel & Barbara Pernici
  2. Using patterns to design rules in workflows
  3. IEEE Trans Software Engineering V26n8(Aug 2000)pp760-785
  4. =EXPERIENCE DESIGN RULEBASED EXCEPTIONS TOOL
  5. pp773-779: Interesting catalog of templates that handle exceptions in workflows.
  6. Templates related by refinement, enrichment, and instantition -based specialization

Caspi92

  1. ?? Caspi
  2. Clocks in Dataflow Languages
  3. Theor Comput Sci V95n1(Mar 23 1992)pp125-140
  4. CR9304-0231
  5. =THEORY CONCURRENT

Castagna95

  1. Giusepe Castagna
  2. Covariance and Contravariance: Conflict without Cause
  3. ACM Trans Prog Lang Syst V17n2(May 1995)pp431-447 CR9608-0612
  4. Objects theory genericity

Castagna97

  1. Giusepe Castagna
  2. Object-Oriented Programming: A Unified Foundation
  3. Birkhauser 1997
  4. IEEE Software Mag Review#907046

CastelloMiliTollis02

  1. Rodolfo Castello & Rym Mili & Ioannis G Tollis
  2. Automatic layout of statecharts
  3. Software - Practice & Experience V32n1(Jan 2002)pp25-55
  4. =DEMO TOOL GRAPHIC STATECHART FSM/STD LAYOUT

Casti92a

  1. John L Casti
  2. Reality Rules: I -- Picturing the world in Mathematics -- The Fundamentals
  3. Wiley NY NY 1992
  4. =MATHEMATICS MODELS CATESTROPHES CELULAR AUTOMATA CHAOS FRACTALS
  5. Also see Volume II [Casti92b]

Casti92b

  1. John L Casti
  2. Reality Rules: II -- Picturing the world in Mathematics -- The Frontier
  3. Wiley NY NY 1992
  4. =MATHEMATICS GAMES EVOLUTION SYSTEMS CYBERNETICS COMPLEXES COMPUTATION BELIEF
  5. Also see Volume 1 [Casti92a]

Cattell91

  1. R G G Cattell(Guest Editor)
  2. Next-Generation DataBase Systems
  3. Commun ACM V34n10(Oct 1991)pp31-33
  4. convergence of OO with DBMS remedies defects in RDBMS...

CavalcantiNaumann00

  1. Ana Cavalcanti & Daviv A Naumann
  2. A Weakest Precondition Semantics for refinement of object-oriented programs
  3. IEEE Trans Software Engineering V26n8(Aug 2000)pp713-728
  4. =THEORY SEMANTICS OBJECTS ROOL
  5. Study C C Morgan first!

CavanoLaMonica87

  1. Joseph P Cavano & Frank S LaMonica
  2. QUALITY Assurance in Future Development Environments
  3. IEEE Software V4n5(Sep 1987)pp26-34
  4. =THEORY SQA QUALITY

CavusogluMishraRaghunathan04

  1. Huseyin Cavusoglu & Birendra Mishra & Srinivasan Raghunathan
  2. A Model for Evaluating IT Security Investments
  3. Commun ACM V47n7(Jul 2004)pp87-92
  4. =THEORY MATHEMATICS COST SECURITY ROI BAYES

CegielskiHall06

  1. Casey G Cegielski & Dianne J Hall
  2. What makes a Good Programmer?
  3. Commun ACM V49n10(Oct 2006)pp-
  4. =EXPERIMENT 139 undergraduates PSYCHOLOGY Object-Oriented PROGRAMMER Allport-Lindzey-Vernon ETS etc
  5. theoretical_value_belief::@People= desire structure and proof, highly objective, highly focused, look for reason and validation, loners, no interest or consideration of the untested and unproven.
  6. Cognitive ability and personality type both associated with programming skill.
  7. theoretical_value_belief associated with cognitive ability and personality.

Cerietal88

  1. Stefano Ceri & Stefano Crespi-Reghizzi & Andrea Di Maio & Luigi A Lavazza
  2. Software Prototyping by Relational Techniques: Experiences with Program Construction Systems
  3. IEEE Trans Soft Eng VSE-14n11(Nov 1988)pp1597-1609
  4. =Experiences =Demo relational data Ada code

CerpaVerner09

  1. Narciso Cerpa & June M Verner
  2. Why did your project fail?
  3. Communications of the ACM V52n12 (Dec 2009) Virtual extension pp130-134 [ 1610252.1610286 ]
  4. =POLL 235 PROJECTS SUCCESS FAILURE PROJECT INSOURCE OUTSOURCE ESTIMATION DEVELOPMENT TIME QUALITY WORK PEOPLE MANAGEMENT
  5. Delivery date, estimates, and other management issues are the commonest reasons for failure.
  6. No time for reviews and reassessing risks, and so, no learning.
  7. Figure 1 page132. 18 top reasons -- Worth the price of the PDF download from ACM.
  8. inhouse not equal to outsourced.
  9. Need inhouse postmortems.

CerroGasquet02

  1. Luis Farnias Del Cerro & Olivier Gasquet
  2. A General Framework for Pattern-Driven Modal Tableaux
  3. L J of the IGPL V10n1(2002)pp51-83
  4. =THEORY PROVING MODAL LOGIC SEMANTIC TABLEAUX RELATIONS
  5. Proves completeness and soundness for a set of rules for proving formula in many different modal logics by combining Kripke semantics, semantic Tableaux, and relational calculus.
  6. p58 rule <>: If <>A,S @ p then add node q: <>A,S@p ---A@q.
  7. rule K: if []A,S@p----S1@q then []A,S@p----A,S1@q.
  8. Lotrec::tool= See http://www.itit.fr/ACTIVITIES/LILaC/Lotrec/, written in Java

Cervanto00

  1. Iliano Cervanto
  2. Logical Framework: Why not just classical logic?
  3. CSLI Lecture notes V91, Stanford U(2000)pp87-104 in "Formalizing the dynamics of information" ed. Martina Faller & Stefan C Kaufmann & Marc Pauly ISBN 1-57586-239-5 Q360
  4. =ESSAY LOGIC LAMBDA cf Z SCHEMA
  5. (dick)|-Parallels my thinking in creating MATHS.

CesareEtAl10

  1. Sergio de Cesare & Mark Lycett & Chaitali Patel &Ray Paul
  2. Examining perceptions of agility in software development practice
  3. Commun ACM V53n6(Jun 2010)pp126-130 (Virtual extension) [ 1743546.1743549 ]
  4. =POLL SENIOR PEOPLE HISTORY AGILITY
  5. Organizations have an explicit and tailored but flexible and iterative/incremental development process for example RUP DSDM XP.
  6. Strong belief in continuous delivery of working software, face-to-face communication, developers and business working together.
  7. No agreement on working software measures progress or allowing late changes in requirements.
  8. Postmortems/reflection used.
  9. Change is controlled but iteration rules (most 3 months ).
  10. Emergent design not well understood.

CeschiEtal05

  1. Martina Ceschi & Alberto Sillitti & Giancarlo Succi & Stefano De Panfilis
  2. Project Management in plan based and agile companies
  3. IEEE Software Magazine V22n3(May/Jun 2005)pp21-27
  4. =POLL 20 MANAGERS PROCESS SATISFACTION AGILE
  5. All use some form of incremental delivery and face similar problems with deadlines and changing requirements,
  6. Some nonsignificant evidence that Agile companies tend to be more satisfied with project planning and customer relationships.
  7. 50% of both want developers that can work in a group.

Chaaretal93

  1. Jarir K Chaar & Michael Halliday & Inderpal S Bhandari & Ram Chillarege
  2. In-Process Evaluation for Software Inspection and test
  3. IEEE Trans Softw Eng VSE19n11(Nov 1993) pp1055-1070
      Separate dfect trigger from defect classiication. Classification done by author Othogonal Defect Classification(ODC) discussed comp.software-eng April 1995.

ChaEtAl09

  1. Hoon S Cha & David E Pingry & Matt E Thatcher
  2. What Determines IT Spending Priorities
  3. Commun ACM V52n8(Aug 2009)pp105-110 [ 1536616.1536644 ] (Virtual Extension)
  4. =POLL 2006 IT SPENDING ECONOMICS PROJECT REASONS CS372
  5. Abstract
    1. "Based on survey results from 1,495 business leaders we have derived some important insights into how factors such as industry type, firm size, state location, and past IT performance affect a firm's allocation of IT expenditures across business functions. Specifically, the survey data shows that the highest IT spending priorities of the respondents are in the areas of administration and production and distribution while the lowest priorities are in the areas of R&D and security."

ChakrbortyLei04

  1. Dipanjan Chakrborty & Hui Lei
  2. Extending the Reach of Business Processes
  3. IEEE Computer Magazine V37n4(Apr 2004)pp78-80
  4. =IDEA BUSINESS PROCESS WORKFLOW WEBSERVICES SMS Email BPEL xBPEL WSDL
  5. BPEL::= "Business Process Execution Language".
  6. Use data+calendar+... to find route to people.

ChaeKwonBae00

  1. Heung Seock Chae & Yong Rae Kwon & Doo Hwan Bae
  2. A cohesion Measure for Object-Oriented classes
  3. Software - Practice & Experience V30n12(Oct 2000)pp-
  4. =CASESTUDY Object-Oriented METRIC cohesion C++ TOOL HYSS

Chaitin05

  1. Gregory Chaitin
  2. Meta Math
  3. Pantheon Books NY NY 2005
  4. =ESSAY MATH 42 GOEDEL TURING LIEBNITZ INFORMATION
  5. Argues that we need to stress creativity and imagination rather than formallity(Hilbert)

Chalin10

  1. Patrice Chalin
  2. Engineering a sound assertion semantics for the verifying compiler
  3. IEEE Trans Software Engineering V36n2(Mar/Apr 2010)pp275-287
  4. =TYPE USER V&V SQA FORMAL METHOD TOOL VC VERIFICATION COMPILER
  5. A verifying compiler should spot when assertions will go wrong.
  6. The logic of the verifying compiler should allow for expressions being undefined.
  7. Must handle arithmetic errors like 1/0 correctly. Even in assertions!
  8. Stresses the need to talk to the users of the compiler before deciding its semantics!
  9. Introduces a definedness predicate.
  10. Formal Methods shouldn't have imposed an elegant but unsound logic on software.

Champeaux02

  1. Dennis de Champeaux
  2. Software Engineering Considered Harmful
  3. Commun ACM V45n11(Nov 2002)pp102-104
  4. =ESSAY ENGINEERING SCIENCE LOGIC PRACTICE C++UML VALIDATION
  5. Quotes Denning on the state of current software systems and being hired to fix messes that should not have occurred.
  6. Need for extensions to Hoare Logic to pointers and parallel processes.
  7. Seems to ignore work by Hoare, Lamport and others.

Champauxetal93

  1. Dennis Champeaux & Doug Lea & Penelope Faure
  2. Object-oriented System Development
  3. Addison-Wesley Redwood City CA 1993
  4. 532pp $48.50 ISBN 0-201-56355-X CR9408-0496

ChampauxFaure92

  1. Dennis Champeaux & Penelope Faure
  2. A comparative study of object-oriented analysis methods
  3. Journal of Object-oriented Programming (Mar-Apr 1992)pp21-33.
  4. =COMPARISON OBJECT-ORIENTED METHODS

ChanEtal01

  1. William Chan & Richard J Anderson & Paul Beame & David H Jones & David Notkin & William E Warner
  2. Optimizing symbolic Model checking for Statecharts
  3. IEEE Trans Software Engineering V27n2(Feb 2001)pp170-190, also in ICSE'99
  4. =EXPERIMENTS FORMAL VERIFICATION REQUIREMENTS STATECHARTS GRAPHIC LOGIC OPTIMIZATION RSML TCAS II BDD
  5. Electrical power distribution system
  6. order of magnitude improvements.

ChandraGuptaHennessy94

  1. Rohit Chandra & Anoop Gupta & John L Hennessy
  2. COOL: An Object-based Language for Parallel Programming
  3. IEEE Computer Magazine V27n8(Aug 1994)pp13-25
  4. =IDEA LANGUAGE COOL OBJECT-ORIENTED
  5. extends C++
  6. declare functions to be parallel
  7. shared objects controlled by declaring functions 'mutex' or non-mutex
  8. synchronization by monitors + condition variables and signals...

  9. benefits of data abstraction

Chandrasekaran97

  1. Periannan Chandrasekaran
  2. How use case modeling policies have affected the success of various projects (or how to improve use case modeling)
  3. OOPSLA'97 & ACM SIGPLAN notices V??n?(??? 1997)pp6-9 [ 274567.274569 ]
  4. =ANECDOTE USE CASE REQUIREMENTS OOSE Jacobson
  5. Tells conclusion from several large projects that used OOSE.
  6. Problems
    1. need details of all changes in system as use case proceeds
    2. Need comprehensive list of use cases involving users, a comprehensive and clean model of the human actors, and robust domain model.
    3. Include algorithms(business rules?) as regular requirements
    4. Use cases must capture all interfaces with external systems even if not human.
    5. The GUI is not the use case. One screen can trigger different use cases that are independent of each other.
    6. Keep the use case and domain model synchronized. Common well defined terminology.
    7. Use abstract use cases for algorithms.

  7. An abstract use case is one that is not initiated by an actor and contains common steps abstracted from other use cases. Example: calculate discounts on sale. Notes that people expressed common algorithms and procedures as "business rules" (possibly in an attempt to fit them to SQL and AI style Rule Engines). Claims they should be expressed as (abstract) use cases. (dick)|-may be better to restrict business rules to invariants only??

ChandyMisra88

  1. K Mani Chandy & Jayadev Misra
  2. Parallel Program Design: A Foundation
  3. Addison-Wesley Redwood City CA 1988
  4. =DEMO UNITY NONSEQUENTIAL COMPOSITIONAL
  5. cited in [Staskauskas93] [LamShankar94a] [KayReed93] [Jonsson94] [CreveuilRoman94]

Chang89

  1. Shi-Kuo Chang(ed)
  2. Principles of Visual Programming Languages
  3. Prentice Hall Int. Englewood Cliffs NY 1989.
  4. =TUTORIAL graphic informal

ChangC93

  1. Carl K Chang
  2. Is Existing Software Engineering Obsolete?(editorial)
  3. IEEE Software Magazine V10n5(Sep 1993)pp4-5
  4. =EDITORIAL ENGINEERING
      Also wrote "How to solve the management crisis" Nov 1994 p15, reffred to in a letter Williams95

ChangCChristensen99

  1. Carl K Chang & Mark Christensen
  2. A net practice for softwar project management
  3. IEEE Software Magazine V16n6(Nov/Dec 1999)pp80-88
  4. =DEMO TOOL GRAPHIC SCHEDULE PLAN PROCESS PETRI PM-Net
  5. Better than hundreds of comercially available project management tools
  6. Petri nets with products decisions & constraints

ChangEtal01

  1. Carl K Chang & Jane Cleland-Huang & Shiyan Hua & Annie Kuntzmann-Combelles
  2. Function-class decomposition: a Hybrid Software Engineering Method
  3. IEEE Computer Magazine V34n12(Dec 2001)pp87-93 + letter from Dave Leigh IEEE Computer Magazine V35n3(Mar 2002)p6
  4. =ADVERT METHOD FCD PURPOSE MODULE Object-Oriented UML Use-Case-map scenario M-Net =EXPERIENCE
  5. Handles reported problem of having too many types of objects

ChangS-Ketal95

  1. Shi-Kuo Chang & Gennaro Costagliola & Giulano Pacini & Genoveffa Tortora & Bing Yu & Jing-Sheng Yu
  2. Visual-language System for User Interfaces
  3. IEEE Software Magazine V12n2(Mar 1995)pp22-44
  4. =IDEA LANGUAGE GRAMMAR for GRAPHICS GUI
    1. Positional grammars and positional rules
    2. S:= File Hor Arrow Hor OB
    3. relational grammar.

ChangWeissHinchey11

  1. Carl K Chang & David M Weiss & Mike Hinchey
  2. Where Software Engineering meets ...
  3. IEEE Computer V44n10(Oct 2011)pp17-18
  4. =EDITORIAL
  5. Introduces special feature: [Broy11] , [Fitzgerald11] , [Harman11] , ..., and [Parnas11]
  6. Argues that Software Engineering can be imporved when we juxtapose it close to other disciplines.

Chaochenetal91

  1. Zhou Chaochen & C. A. R. Hoare & A. P. Ravn
  2. A calculus of durations
  3. Information Processing Letters V40( 1991)pp269-276
  4. =MATHEMATICAL model of Time

Chapelle07

  1. Gregory Chapelle
  2. Comment on Risks to the Public May 1007, F-22
  3. ACM SIGSOFT Software Engineering notes V32n4(Jul 2007)pp6-7
  4. =LETTER RISKS FAILURE REQUIREMNTS TESTS DATELINE Jighter Jet
  5. Postmortem explanation of how an obvious test case (crossing the international date lien) was not noticed and so not tested for.
  6. Notes how scheduling pressure contributes to this kind of blindness. -- the need to be able to step back and see the whole picture.

Chapman90

  1. Gary Chapman
  2. Bugs in the Program
  3. "Viewpoint" Commun ACM (pp 251-252 ) Mar 1990
  4. =IDEA RISKS

[Chapman06]

  1. In Search of Stupidity: Over twenty years od high tech marketing disasters (2nd Edn)
  2. APress, Berkeley CA 2006 ISBN 1590597214 CR 0801-0047
  3. =UNREAD =EXPERIENCE MARKETTING SARCASM IBM Microsoft Apple MicroPro etc.

Charette95

  1. Robert N Charette
  2. How to Create a Successful Failure
  3. Commun ACM V38n5(May 1995)pp122(Inside RISKS)
  4. =HISTORY RISKS DISASTERS FAILURES COSTS PROCESS
    1. Never Plan,
    2. Exhibit extreme confidence,
    3. Take the most expedient solutions,
    4. Be simple Minded,
    5. Spawn situations with subtly interlinked decisions,
    6. Change decisions frequently,
    7. Practice Foolish inconsistency.

Charette05

  1. Robert N Charette
  2. Why Software Fails IEEE Spectrum Magazine (Sep 2005)pp-
  3. =ADVERT RISK MANAGEMENT DISASTERS COSTS
  4. p44. Hall of Shame 1992..2005
  5. Side boxes describe case studies
  6. Rounds up the usual [Charette95] suspects:
    1. Bad goals
    2. Bad estimates of needed resources
    3. Bad systems Requirement
    4. Poor project control and/or planning
    5. Bad communication ...
    6. Politics
    7. Commercial pressures

ChariSeshadri04

  1. Kaushal Chari & Saravanan Seshadri
  2. Demystifying Integration
  3. Commun ACM V47n7(Jul 2004)pp59-63
  4. =TAXONOMY STANDARDS BUSINESS
  5. (industry domain (independent | dependent ))><((data | business | presentation ) logic)><(( transport | data format | process ) level)

Charles96

  1. John Charles
  2. DoD Standards Go Global and Commercial
  3. IEEE Software Magazine V13N3(May 1996)pp98-99
  4. Mil-Std498->-ANSI Trial Use Standard J-Std-016
  5. =REPORT STANDARDS ONESIZE AGILE
  6. IEEE/EIA is adapting ISI/IEC 12207 Software Life Cycle Processes->- US Commercial S L C P standard US 12207
  7. trends: several lifecycles(waterfall|incremental|evolutionary)+ less paper documentation and formal review+clearer distinction between true requirements and design choices
  8. Perry DeWeese: "A lot of the things that happen in Software development have there genesis before the sofware-development process starts"

Charles08

  1. F Charles (ed)
  2. The gift of time: the work of Gerald M Weinberg
  3. Dorset House Pub 2008
  4. =SURVEY RESEARCH PEOPLE
  5. Help! [click here [socket symbol] Charles08 if you can fill this hole]

ChatterjeeRyderLandi01

  1. Ramkrishna Chatterjee & Barbara G Ryder & William A Landi
  2. Complexity of Points-to Analysis of Java in the Presence of Exceptions
  3. IEEE Trans Software Engineering V27n6(Jun 2001)pp481-512
  4. =THEORY JAVA COMPLEXITY

Chaterjee10

  1. Sutap Chatergee
  2. The Waterfall that won't go away
  3. ACM SIGSOFT Software Engineering Notes V33n1(Jan 2010)pp9-10 [ http://www.acm.org/sigsoft/SEN/ ]
  4. =EXAMPLE MAINTAINENCE LEGACY AGILE Waterfall
  5. Frontend experts must treat the backend developers as stakeholders.
  6. Need to transition from an agile process to a more ceremonial one as software moves from deployment to maintenance.

Chatzigeorgiou03

  1. Alexander Chatzigeorgiou
  2. Mathematical Assessment of Object-Oriented design quality
  3. IEEE Trans Software Engineering V29n11(Nov 2003)pp1050-1053
  4. =THEORY QUALITY COLLABORATION METRICS DIGRAPH eigenvalues authority hub HITS
  5. example of two designs for a microwave oven.

ChauChen03

  1. Michael Chau & Hsichun Chen
  2. Comparison of three vertical search spiders
  3. IEEE Computer Magazine V36n5(May 2003)pp56-62
  4. =SIMULATION NET/WEB NEURAL HITS BFS PageRank Hopfield
  5. Compared 3 algorithms on simulated 100K page subset of the web to see how well relevant medical pages could be found.
  6. PageRank formula had bad performance and relevance. Hubs and authorities may not be about medical things -- Adobe's page for example is an authority to define PDF!
  7. Breadth-first+priorities worked as well as a simulated Hopfield neural net at spotting relevant web sites.

ChaudhuriGalwaniLublierman12

  1. Swarat Chaudhuri & Sumit Gulwani & Roberto Lublierman
  2. Continuity and Robustness of Programs
  3. Commun ACM V55n8(Aug 2012)pp107-115 [ 2240236.2240262 ] , Letter David L Parnas V55n11(Nov 2012)p9 [ 2366316.2366318 ]
  4. =THEORY COMPOSITIONAL PROOFS CONTINUITY
  5. Programs define a map from initial values of a variable to a final value, if the variables have a metric, then the mapping is often a continuous function. This means that small changes in the initial state lead to small changes in the final output.
  6. Gives classic eta-delta definition, rules for proving in a simple imperative language, and demonstrated continuity for several famous algorithms.
  7. Key thought: conditions define boundaries where the two branches must match to get continuity.
  8. Continuity::= See http://en.m.wikipedia.org/wiki/Continuous_function.
  9. Parnas gives reasons for not trusting this approach.

Chauvet95

  1. Jean-Marie Chauvet
  2. Efficient use and reuse of object-oriented technology
  3. Software Development Magazine(Aug 1995)pp35-38
  4. =EXPERIENCE REUSE PQRST ARCHITECTURE DOCUMENTATION TOOLS NOTATIONS
    1. Reuse and standards are not automatic results of OOT
    2. Architecture:
      • Separate the data base (T) from the the GUI (T)
      • the objects and rules of the Business Process Model (R)
    3. Need for business savvy programmers.

    4. Need to have indexed and linked model, design specs and code.
    5. Common notation: description, indexed and exposed designs etc
    6. Agreed non-waterfall but disciplined process
    7. supportive tools.

Chavez00

  1. Tom Chavez
  2. A Decision-analytic Stopping Rule for Valdiation of Commercial Software Systems
  3. IEEE Trans Software Engineering V26n9(Sep 2000)pp907-918
  4. =MATHEMATICS BAYES STATITICS THEORY ECONOMICS RELIABILITY TESTS

ChechikDevereuxEasterbrookGurfinkel04

  1. Marsha Chechik & Benet Devereux & Steve Easterbrook & Arie Gurfinkel
  2. Multi-Valued Symbolic Model-Checking
  3. ACM TOSEM Trans Software Eng & Methodology V12n4(Oct 2003)pp371-408
  4. =IDEA TOOL MODEL CHECKING CTL FSM Kripke Multi-valued LOGIC Quasi-Boolean Lattice Χ\_CTL Χ\_Check Χ\_Kripke
  5. Extends classical {False, True} reasoning to {False, Maybe, True} values. Good for incomplete models found during analysis.
  6. Able to have multi-valued variables in: state of FSM, Transitions between states, satisfaction.
  7. meaning(EX(p)) := backward_image(RR)(meaning(p)).
  8. backward_image(RR)(TT) := map[s:S](multivalued_union[t:T](TT(t) multivalued_intersection RR(s,t) )).
  9. Implementation described in 2002 CSRG Tech Report 446, University of Toronto

ChechikGannon01

  1. Marsha Chechik & John Gannon
  2. Automatic analysis of consistency between Requirements and Designs
  3. IEEE Trans Software Engineering V27n7(Jul 2001)pp651-672 CR0203-0314
  4. =CASESTUDY SCR REQUIREMENTS V&V DESIGN TOOL CORD ALGORITHM LANGUAGE LIGHTWIEGHT FORMAL

Checkland81

  1. ??? Checkland
  2. Systems Theory; Systems Practice
  3. John Wiley & Sons 1981
  4. =monograph cybernetics USER System softsystems

Cheek95

  1. Martin Cheek
  2. Using Feedback to Improve Software Development
  3. IEEE Software Magazine V12n3(May 1995)pp89-90
  4. =REPORT FEAST EVOLUTION PEOPLE SYSTEMS
      Reports on research by Manny Lehman<mml@doc.ic.ac.uk> - complex social interactions explains why 20 years of technological innovations do not correspond with a significan improvement in the development process. The "Feast" Feedback Evolution And Software Technology.

ChelfEbert09

  1. Ben Chelf & Christof Ebert
  2. Ensuring the integrity of embedded software with static code analysis
  3. IEEE Software Magazine V26n3(May/Jun 2009)p96-99
  4. =ADVERT RISKS =HISTORY TOOLS lint
  5. p97 Links to resources in sidebar.
  6. Six_detectable_defect_classes:= division by zero + memory leak + null pointer dereference + uninitialized variable + buffer overflow or underflow +inappropriate cast.

Chen80

  1. Peter Pin-Shan Chen(Ed)
  2. Entity Relationship approach to Systems Analysis and Design
  3. North Holland 1980
  4. =TEXT ERD SAD data

Chen04

  1. Jing-Chao Chen
  2. Building a new sort function for a C library
  3. Software - Practice & Experience V34n8(10 Jul 2004)pp777-795
  4. =ALGORITHM quicksort psort qsort C
  5. Psort is O(n log n) in worst and average cases. It includes some the optimizations in qsort developed by Jim Bentley and Doug McIlroy.
  6. Source: [ Psort.htm ]

ChenChuangTsai01

  1. Ding-Yi Chen & Tyng-Ruey Chuang & Shi-Chun Tsai
  2. JGAP: A Java-based graph algorithms platform
  3. Software - Practice & Experience V31n7(Jun 2001)pp615-635
  4. =DEMO GRAPH TOOL Java
  5. Source and docs at [ JGAP.html ]

ChenDiosMiliWuWang05

  1. Yaofei Chen & Rose Dios & Ali Mili & Lan Wu & Kefei Wang
  2. An Empirical Study of Programming Language Trends
  3. IEEE Software Magazine V22n3(May/Jun 2005)pp72-79
  4. =POLL =HISTORY PROGRAMMING LANGUAGES
  5. Gathered data on what developers used, schools taught, and the primary language in companies. Dates: 1993, 1998, 2003
  6. Java is becoming the top language.
  7. Developers appear to value machine independence and extensibility mosts, and dislike simplicity and ease of implementation.

ChenGansnerKutsofios98

  1. Yih-Farn Chen & Emden R Gansner & Eleftherios Koutsofios
  2. A C++ Data Model Suppoerting Reachability Analysis and Dead Code Detection
  3. IEEE Trans on Software Eng VSE-24n9(Sep 1998)pp682-694
  4. =DEMO TOOL TECHNICAL CIAO EDG Acacia [ Acacia ]

ChenR08

  1. Raymond Chen
  2. The New Old Thing: practical development throughout the evolution of Windows
  3. Addison-Wesley Upper Saddle River NJ 2006 ISBN 0321440307 CR 0807-0639
  4. =UNREAD =ANECDOTES MICROSOFT PROCESS DESIGN WHY
  5. Reviewer: the essence of design is an compromise between competing forces in the presence of pressure and uncertainty. [click here [socket symbol] Chen08 if you can fill this hole]

Cheng93

  1. Jingwen Cheng<jim@bruce.cs.monash.edu.au>
  2. Parameterized Specifications for Software Reuse
  3. ACM SIGSOFT Software Engineering Notes V17n4 (Oct 1992)pp53-59
  4. =IDEA generic polymorphic ADT specifications
      Cheng93,Sample specifications included these attributes
      1. preconditons:
      2. behaviours:
      3. keywords:
      4. sideeffects:
      5. implementation:
      6. identifier:


ChengHeimdahl97

  1. Betty H C Cheng & Mats P E Heimdahl
  2. Bridging the Gap between Informal and Formal Approaches to Software Development
  3. ACM SIGSOFT SEN V22n5(Sep 1997)pp83-84
  4. =IDEA OMT+LARCH
  5. plan to provide OMT with Larch formalizations...

ChengWang02

  1. Betty H C Cheng & Enoch Y Wang
  2. Formalizing and Integrating the Dynamic Model for Object-Oriented Modeling
  3. IEEE Trans Software Engineering V28n8(Aug 2002)pp747-762
  4. =EXAMPLE Object-Oriented model OMT DYNAMICS semantics LOTOS
  5. For UML see McUmberCheng01

ChenFuchsChung01

  1. Shyh-Kwei Chen & Kent Fuchs & Jen-Yao Chung
  2. Reversible Debugging Using Program Instrumentation
  3. IEEE Trans Software Engineering V27n8(Aug 2001)pp715-727
  4. =EXPERIMENT DEBUGGING TOOL C TECHNICAL
  5. wraparound history buffer.

ChenJ97

  1. Jen-Yen Jason Chen
  2. CSPL: An Ada95-like UNIX-based Process Environment
  3. IEEE Trans software Engineering VSE23n3(Mar 1997)pp171-184
  4. =IDEA ADA ENVIRONMENT UNIX

ChenNishimotoetal90

  1. Y-F Chen & M Y Nishimoto & CV Ramamoorthy
  2. The C Information Abstraction System
  3. IEEE Trans SE-16n3 pp325-334
  4. =DEMO language ENGINEERING data

ChenPaul01

  1. Chaomei Chen & Ray J Paul <@brunel.ac.uk>
  2. Visualizing a Knowledge Domain's Intellectual Structure
  3. IEEE Computer Magazine V34n3(Mar 2001)pp65-71
  4. =SURVEY GRAPHIC 3D MODEL CITATIONS
  5. ACA := "Author Cocitation Analysis".
  6. SCI := "Science Citation Analysis".
  7. MDS := "Multidimensional Scaling".
  8. MSP := "Minimum Spaning Trees"..
  9. Landscape tools: Spire themescape, VxInsight, PathFinder
  10. PathFinder steps:= citation structure; essential connections; intellectual groups; citation history impact.
  11. (dick)|-why isn't time a dimension?.

ChenTseZhou02

  1. Tsing Yueh Chen & T H Tse & Zhi Quan Zhou
  2. Semi-Proving: an Integrated Method Based on Global Symbolic Evaluation and Metamorphic Testing
  3. Proc ISSTA02 & ACM SIGSOFT Software Engineering Notes V27n4(Jul 2002)pp190-195 & IEEE Trans Software Engineering V37n1(Jan/Fed 2011)pp109-125
  4. =EXAMPLE SYMBOLIC TESTING INVARIANT PROPERTIES TOOL METAMORPHIC RELATION PATHS
  5. Symbolically execute all paths to verify invariant results under changes of input.
  6. Example1: all permutations of 3 numbers have the same median.
  7. A mutated program will not satisfy the same test.
  8. Note: the IEEE Trans paper is extended and has title "Semi-proving: an integrated method for program proving, testing, and debugging".

CheonLeavens94

  1. Yoonsik Cheon & Gary T Leavens
  2. The Larch/Smalltalk Specification Language
  3. TOSEM V3n3(Jul 1994)pp221-249
  4. =DEFINITION LARCH SPECIFICATION MODULES Smalltalk OO
    1. First Larch Spec language with both subtyping and inheritance.
    2. Description of LSL etc..
    3. *Separate conceptual types from implemented classes.
    4. Type inference

    5. interface spec
       Header
         returns
         requires
         modifies
         ensures
       Trait specs
         includes
         introduces
       Asserts
         ... generated by ...
         ... partitioned by ....
           Axioms

Cherry92a

  1. George W Cherry
  2. Graphic Formalisims Should Integrate Communication, Control, and Data Flow
  3. ACM SIGSOFT Software EngineeringNotes V17n2(Apr 1992)pp64-69
  4. =ADVERT GRAPHIC writing is not ENGINEERING [Cherry92b]

Cherry92b

  1. George W Cherry
  2. Software Construction by Object-Oriented Pictures: Specifying Reactive & Interactive Systems
  3. Thought**Tools Inc. dist Dorset House Publishing New Your NY 10014-9982 ISBN 0-9625003-0-5
  4. =TEXT

ChesnevarMaguitmanLoui00

  1. Carlos Ivan Chesnevar & Ana Gabriela Maguitman & Ronald Prescott Loui
  2. Logical models of argument
  3. ACM Computing Surveys V32n4(Dec 2000)pp337-383
  4. =HISTORY 1950-99 FORMAL DIALECTIC DEFEASIBLE CONSISTENCY REASON ARGUMENT PLAUSIBLE AGENTS AI LAW NONMONOTONIC
  5. Formal logic is reasoning that can not be defeated. Normal reasoning is not like this.
  6. Detailed, difficult and hard to read.
  7. No ref to work on inconsistent requirements. Small comment on OO inheritance.

Chetali98

  1. Boutheina Chetali
  2. Formal Verification of Concurrent Programs Using the Larch Prover
  3. IEEE Trans Soft Eng V24n1(Jan 1998)pp46-62
  4. =EXPERIENCE UNITY LARCH SQA NONSEQUENTIAL SAFETY LIVENESS

CheyneRitter01

  1. Tanya L Cheyne & Frank E Ritter
  2. Targeting Audiences on the Internet
  3. Commun ACM V44n4(Apr 2001)pp94-98
  4. =EXPERIENCE WEB/NET Usenet polls
  5. 1 in 10K respond from Usenet. 8% complain (all from UK). More like a focus group.
  6. Banner adds with incentive is fruitful.
  7. Search engines are promising.
  8. Problem: anonymity, dishonesty, and multiple submissions.

CheungKramer94

  1. Shing Chi Cheung & Jeff Kramer
  2. Tractable Dataflow analysis for Distributed Systems
  3. IEEE trans on Soft Eng vSE-20n8(Aug 1994)pp579-593
  4. =PAPER STD/FSM CORRECTNESS NONSEQUENTIAL

ChidamberKemerer94

  1. S R Chidamber & C F Kemerer
  2. A Metrics Suite for Object-Oriented Design
  3. IEEE Trans SE V2?n?(??? 1994)pp467-493
  4. =IDEA METRICS OBJECT-ORIENTED

Chikofsky(ed)88

  1. Various authors
  2. Special Issue on the emergence of CASE
  3. IEEE Software v5n2(Mar 1988)
  4. =MAGAZINE tools graphic DFD ERD Technical

ChikofskyCross90

  1. Elliot J Chikofsky & Lames H Cross II
  2. Reverse Engineering and Design recovery: A Taxonomy
  3. IEEE Software V7n1(Jan 1991)pp13-17
  4. =DEFINITIONS REVERSE ENGINEERING

ChinEtAl06

  1. George Chin Jr & Eric C Stephen & Debbie K Gracio & Olga A Kuchar & Paul D Whitney & Karen L Schuchardt
  2. Developing concept-based user interfaces for scientific computing
  3. IEEE Computer Magazine V39n8(Sep 2006)pp26-34
  4. =DEMO HCI VISUALIZATION EXPLICIT GRAPHIC ONTOLOGIES MINDMAPS WORKFLOWS SCENARIOS VMWEB RCM-PSE SKFAM
  5. Intereting and useful: visual front end to a data base.
  6. In the 1980's FileVision on the Mac let you associate graphics with data input as forms into a data base....
  7. Now add useful tools: libraries of processes for a workflow as an example.

ChirouzeClearyMitchell05

  1. Olivier Chirouze & David Cleary & George G. Mitchell
  2. A software methodology for applied research: eXtreme Researching
  3. Software - Practice & Experience V35n15 (Dec 2005) pp1441-1454
  4. =EXPERIENCE DISTRIBUTED XP Erickson

Chisholm94a

  1. John Chisholm
  2. The Art of Software Design Part II
  3. UNIX Review V12n4(Apr 1994)pp17-20
  4. =ESSAY PROCESS
    1. Investigate: use all resources to gather all possible data users, problem, technology
    2. Taxonomy: user's goals, all aspects name, hierarchy
    3. Organisation: user goals parallel congruent to program functions
    4. Epiphany (Aha!): creative thinking ---> unified vision (metaphors)
    5. Dramatization: Scenarios based on goals
    6. Iteration: Repeat until USER goals match requirements

Chisholm94b

  1. John Chisholm
  2. Mail-enabled Applications: Part I
  3. UNIX Review V12n6(Jun 1994)
  4. =ARTICLE EMAIL UNIX
  5. See [Chisholm94c]

Chisholm94c

  1. John Chisholm
  2. Mail-enabled Applications: Part II
  3. UNIX Review V12n7(July 1994)
  4. =ARTICLE EMAIL UNIX
  5. See Part I [Chisholm94b]

Chittaro06

  1. Luca Chittaro
  2. Visualizing information on Mobile Devices
  3. IEEE Computer Magazine V39n3(Mar 2006)pp40-45
  4. =DEMO MOBILE USER INTERFACE DATA DISPLAY HCI HALOS Relevance
  5. Need to create new ways to display data on mobile device.

Chmuraetal90

  1. L J Chmura & A F Norcio & T J Wicinski
  2. Evaluating Software Design Processes by Analyzing Change Over Time
  3. IEEE Trans SE-16n7(Jul 1990)pp729-740
  4. =case-study lifecycle

ChoiZeller02

  1. Jong-Deock Choi & Andreas Zeller
  2. Isolating Failure-Inducing Thread Schedules
  3. Proc ISSTA02 & ACM SIGSOFT Software Engineering Notes V27n4(Jul 2002)pp210-220
  4. =DEMO TOOL TECHNIQUE TESTING Delta-Debugging NONSEQUENTIAL DEJAVU JAVA Jalapeno
  5. Tool found smallest difference in schedules that caused an error to occur.
  6. Based on .Seeee ZellerHildebrandt02

ChomskiSchutzenberger63

  1. Naom Chomski & ?? Schutzenberger
  2. The Algebraic Theory of Context-free Languages
  3. pp 118-161 in Braffort Hirschberg 63
  4. =theory languages topology SEMINAL

Choobinehetal92

  1. Joobin Choobineh & Michael V Mannino & Veronica P Tseng
  2. A Form Based Approach for Database Analysis and Design
  3. Commun ACM V35n2(Feb 1992)pp108-120 CR9305-0337
  4. =DEMO DDD DATA EXPERT cardinallities to determine structure EDDS ERA NORMALISATION System Reality

Chorost05

  1. Michael Chorost
  2. Rebuilt: How becoming part computer made me more human
  3. Houghton Mifflin NY NY 2005 ISBN 0-618-37829-4
  4. =ESSAY COCHLEAR IMPLANT HUMANITY GEEK CYBORG DEAFNESS
  5. How do you feel when what you hear depends on a program written in C and you can read the source code?
  6. Excellent discussion of science fictional treatments of cyborg's, androids, and the Butlerian Jihad in Dune.
  7. Much more...

Chow(Ed)84

  1. Software Quality Assurance
  2. IEEE Computer Society Tutorial
  3. =TUTORIAL SQA QUALITies V&V DESIGN

Christensen94

  1. Mark J Christensen(Northrop ESDiv)
  2. Would you do this to your customer?
  3. IEEE Software magazine v11n1(Jan 1994)pp12

ChristensenCM97

  1. Clayton M Christensen
  2. The Inovator's Dilemma: When new Technologies cause Great Firms to Fail
  3. Harvard Business School Press Boston MA 1997 ISBN 0-87584-585-1 CR9802-0061
  4. =HISTORY =THEORY ECONOMICS of INNOVATION
  5. Applied to software development in pp180-182 [Highsmith99]
  6. Doing the right things (research, listening to customers, finding improvements and profits) helps an organization fail to develop new makets/values that ultimately eclipses the normal.
  7. new_technology = sustaining_technology | disruptive_technology.
  8. Disruptive technology re-creates the market with new values and metrics and initially shows comparatively low profits, performance, and market.
  9. Historical examples: disk drives, mechanical shovels, motor bikes, Quicken, ...
  10. Sustaining tech fits given customers but disruptive tech discovers new customers that fit the given tech.
  11. New customers who need less performance at a lower price, higher convenience, and/or higher reliability. Disruptive is down-market.
  12. There are more reasons and profit to move up-market than down-market.
  13. Disruptive technology undermines the old market. It starts with a tiny unpredictable new one. Agnostic marketing!
  14. Survival: create small separated suborganisation with room to fail and learn. Don't ask the customer; watch them. K.I.S.S.!
  15. Uses trajectory maps showing performance (supply and demand) vs time.
  16. cf. Kuhn's paradigm shift in science. Thom's Catastrophe theory. Koestler's matrix shift. Toynbee's David and Goliath.

ChristensenChang96

  1. Mark J Christensen(Northrop ESDiv) & Carl Chang
  2. Blueprint for the Ideal Requirements Engineer
  3. IEEE Software magazine V13n3(Mar 1996)p12
  4. =ESSAY SYSTEM REQUIREMENTS
  5. RE continues thruout the life cycle embracing end-to-end responsibillity and allowing only smooth and controlled evolution based on understanding the concrete application domain
  6. RE language needs to be formal with both text and graphical notations.

ChristosPoniPalaiolgou10

  1. Ioannis T Christou & Stavros T Ponis & Eleni Palaiogou
  2. Using the agile unified process in banking
  3. IEEE Software Magazine V27n3(May/Jun 2010)pp72-79 CR 1106-0674(Jun 2011)p383
  4. =EXPERIENCE AGILE AUP RUP PROCESS UML SERVICES SOA GREEK BANKS INTEGRATED DESKTOP
  5. Describes phases and iterations in the AUP --agile unified process -- as tailored to a project.
  6. Collision between BDUF and emergent design of data base.
  7. Tools: simple -- whiteboards, sticky notes, index cards, flip charts, ...
  8. Produced too much documentation.
  9. Use cases also need
  10. business rules, HCI requirements, constraints, and nonfunctional requirements.
  11. Need more than the UML.
  12. Which artifacts do you really need?
  13. Managers like rigid but developers like flexible.
  14. Work on many artifacts at once.
  15. Simple just good enough artifacts.
  16. People must be able to both model and code.
  17. Honest open communication. Publish models.

Christy09

  1. Peter Christy
  2. Commentary: A Trip without a Roadmap
  3. ACM Queue V7n1(Mar 2009) [ detail.cfm?id=1515746 ]
  4. =CASE STUDY REVIEW TECHNOLOGY REQUIREMENTS RIA FITNESS PERFORMANCE USER
  5. Review of [Norwalk09]
  6. No user requirements -- straight to technological solution. Performance an afterthought.
  7. Quote
      A good start is to not imagine what users want or need, but instead to talk with them about it. Try to walk in their shoes and understand how your software might help make their lives better (or not, as in this case). If you don't have time to do that yourself, then you should at least work with good product marketing people and listen to what they have to say.

Chroust86

  1. G Chroust(IBM Vienna)
  2. Backtracking in Software Process Models
  3. p64-68 in [Dowson86].
  4. =case-study non-sequential lifecycle

Chu-Carroll11

  1. Mark Chu-Carroll
  2. Things Everyone Should Do: Code Review
  3. Good math, bad math blog(Jul 6 2011)
  4. .See http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/
  5. =BLOG CODE TECHNICAL QUALITY CONTROL

ChungNixonYuMylopoulos99

  1. Lawrence Chung & Brian A Nixon & Eric Yu & John Mylopoulos
  2. Non-functional Requirements in software engineering
  3. Kluwer Acad Norwell MA 2000 ISBN 0-7923-8666-3 QA76.758 .N65 1999
  4. =THEORY+CASESTUDYs FORMAL NFR SOFTGOALS SIGs GRAPHICS TABLES LOGIC QUALITIES REALITIES SYSTEMS TECHNIQUES
  5. Accuracy, security, performance,
  6. SIG:= "Softgoal Independency Graph", pp17+48+85
  7. presenting arguments connecting statements independently of their (boolean) value: "dialectical style of reasoning".
  8. refinements and correlations
  9. {BREAK, HURT, UNKNOWN, HELP, MAKE}, AND, OR, EQUAL.
  10. denied, undecided, satisficed.
  11. Consolidates and summarizes: [MylopoulosChungNixon92] [BorgidaMylopoulosReiter93] [ChungNixonYuMylopoulos99] [MylopoulosChungYu99] [MylopoulosChungLiaoWangYu01] also see [Nixon00]

Church56

  1. Alonzo Church
  2. Introduction to mathematical logic: Volume I
  3. Princeton Univ Press 1956 No17 in Princeton mathematical series
  4. =TEXT LOGIC
  5. Skolem normal form in section 42 &43

ChurchillBly99

  1. Elizabeth F Churchill & Sara Bly
  2. Virtual Environments at Work: ongoing use of MUDs in the WOrkplace
  3. ACM SIGSOFT SE Notes V24n2(Mar 1999)pp99-107 (Proceedingd of WACC'99)
  4. =EXPERIENCE using MUDs to aid software development
  5. Supports: maintaining relationships+coordination+reduces time for som interaction

Chusho93

  1. Takeshi Chusho
  2. What makes Software Tools successful?
  3. IEEE Software Magazine V10n5(Sep 1993)pp63-65

CiancariniFranzeMascolo00

  1. P Ciancarini & F Franze & C Mascolo
  2. Using a Coordination Language to Specify and Analyze Systems Containing Mobile Components
  3. ACM TOSEM Trans Software Engineering & Methodology V9n2(Apr 2000)pp167-198
  4. =IDEA LANGUAGE MOBILE PoliS MODEL-CHECKING TUPLE-SPACES vs CHAM UNITY

CiapessoniEtal99

  1. Emanuelle Ciapessoni & Alberto Coen-Porisini & Ernani Crivelli & Dino Mandrioli & Piergiorgio Mirandola & Engelo Morzenti
  2. From Formal Models to Formally Based Methods: An Industrial Experience
  3. ACM TOSEM V8n1(Jan 1999)pp79-113 CR9906-0432
  4. =EXPERIENCE TRIO FUNCTIONAL NONFUNCTIONAL PERFORMANCE Make haste slowly. EVOLUTION Adding formalism to existing

CicaleseRotenstreich99

  1. Cynthia Della Torre Cicalese & Shmuel Rotenstreich
  2. Behavioral specification of distributed component interfaces
  3. IEEE Computer Magazine V32n7(Jul 1999)pp46-53
  4. =THEORY COMPONENTS RELIABILITY IDL CORBA JAVA RMI
  5. BISCOTTI::=Java+contracts

CimattiRoveriSusiTonetta12

  1. Alessandro Cimatti & Marco Roveri & Angelo Susi & Stefano Tonetta
  2. Validation of Requirements for Hibrid Systems: A Formal Approach
  3. ACM TOSEM Trans Software Eng & Methodology V21n4(Nov 2012)#22:1-34 [ 2377656.2377657 ]
  4. =CASE STUDY UML OTHELLO ETCS LTL LINEAR TIME LOGIC TRAINS TOOLS ROSE SMT WORD Requisite Pro
  5. UML used to describe domain, a natural language form of LTL.
  6. Requirements classified: Glossary, Relationship, Action, Configuration, Behavior, Scenario, Property, Annotation.
  7. Formalized as UML class diagram plus LTL logic constraints.
  8. Tools check for consistency and completeness of requirements.
  9. Discover unexpected scenarios and cases where unwanted behaviors are allowed by the requirements.
  10. Example constraint
  11. for all t in trains (
    1. in the future t.front.end != t.MA.EOA.location and (
      1. in the future t.front.end = t.MA.EOA.location
      )
    )
  12. Experts learned to use the tools and method and liked them.

CiolkowskiLaitenbergerBiffl03

  1. Marcus Ciolkowski & Oliver Laitenberger & Stefan Biffl
  2. Software Reviews: The State of the Practice
  3. IEEE Software Magazine V20n6(Nov/Dec 2003)pp46-51
  4. =POLL 226 SQA WALKTHROUGHS INSPECTIONS ISERN IESE VISEK

ClabenHartmutWolz93

  1. Ingo Claben & Ehrig Hartmut & Dietmar Wolz
  2. Algebraic Specification techniques and tools for software development: The ACT approach
  3. World Sci Pub Co River Edge NJ $38 ISBN 981-02-1227-5

Clark73

  1. R. Lawrence Clark
  2. A Linguistic Contribution to GOTO-less Programming
  3. Datamation, December 1973. Reprinted in Comm ACM, April 1984
  4. =JOKE LANGUAGES COMEFROM
  5. proposed the comefrom statement.

ClarkB00

  1. Bradford K Clark
  2. Quantifying the effects of Process Improvement on Effort
  3. IEEE Software Magazine V17n6(Nov/Dec 2000)pp65-70
  4. =POLL ESTIMATION CMM
  5. 161 projects, ... 1 CMM level can reduce effort by 4%..11%

ClarkD00

  1. David Clark
  2. Are Too Many Programmers Too Narrowly Trained?
  3. IEEE Computer Magazine V33n6(Jun 2000)pp12-15
  4. =INTERVIEWS EDUCATION
  5. quotes norman matloff(UCD), les hatton, constantine, davis, & roger Pressman
  6. narrow ==> cheap&fast to hire==> inefficient&bad work
  7. Confuses training progammers with educating computer scientists.

ClarkeEmersonSifakis09

  1. Edmund M Clarke & E Allen Emerson & Joseph Sifakis
  2. Model Checking: algorithmic verification and debugging
  3. Commun ACM V52n11(Nov 2009)pp75-84 [ 1592761.1592781 ]
  4. =HISTORY MODEL CHECKING LTL CTL CTL* MODAL LOGICS PROOF TOOLS
  5. 2007 Turing Prize Article

ClarkeGrumbergPeled99

  1. Edmund M Clarke Jr & Orna Grumberg & Doron A Peled
  2. Model Checking
  3. MIT Press 1999 ISBN 0-262-03270-8 QA 76.76 V47 C553 1999
  4. =MONOGRAPH FORMAL LOGIC CTL MODEL CHECKING SMV SPIN OBDDS KRIPKE SYMMETRY GROUPS
  5. CSUSB cs565/656

ClarkeRosenblum06

  1. Lori A Clarke & David S Rosenblum
  2. A Historical perspective on runtime assertion checking in Software Development
  3. ACM SIGSOFT Software Engineering Notes V31n3(May 2006)pp25-37
  4. =HISTORY ASSERTIONS LOGIC PROVING DEBUGGING Ada Eiffel Anna C++ Euclid Turing
  5. Excellent bibliography on pages 34-37

ClarkeWing96

  1. Edmund M. Clarke & Jeannette M. Wing
  2. Formal Methods: State of the Art and Future Directions
  3. ACM Computing Surveys V28n4(Dec 1996)pp625-643
  4. =SURVEY

Cleaveland79/80

  1. James C Cleaveland
  2. Mathematical Specification
  3. SIGPLAN v??n??(1979 or1980) p31-41 [click here [socket symbol] if you can fill this hole]
  4. =DEMO formal

CleavelandParrowSteffen93

  1. Rance Cleaveland & Joachim Parrow & Bernhard Steffen
  2. The Concurrency Workbench: A Semantics-Based Tool for the Verification of Concurrent Systems
  3. ACM ToPLAS V15n1(Jan 1993)pp36-72 CR (C.2.2)
  4. Tool analysing non-sequential CCS Mu-calculus using Standard ML

CleavelandSmolkaEtal96

  1. Rance Cleaveland & Scott A Smolka et al
  2. Strategic Directions in Concurrency Research
  3. ACM Computing Surveys V28n4(Dec 1996)pp607-625
  4. =SURVEY NONSEQUENTIAL concurrency@cwi.nl

Cleland-HuangChangChristensen03

  1. Jane Cleland-Huang & Carl K Chang & Mark Christensen
  2. Event-Based Traceability for Managing Evolutionary Change
  3. IEEE Trans Software Engineering V29n9(Sep 2003)pp796-810
  4. =DEMO REQUIREMENTS PUBLISH CHANGES ARTIFACTS SUBSCRIBE DOORS Event-Notifier EBT
  5. See [ http://re.cti.depaul.edu/ebt/ ]

Cleland-HuangEtAl07

  1. Jane Cleland-Huang & Raffaella Settimi & Eli Romanova & Brian Berenbach & Stephen Clark
  2. Best Practices for automated traceability
  3. IEEE Computer Magazine V40n6(Jun 2007)pp27-35
  4. =ADVERT POIROT REQUIREMENTS TRACEABILITY TOOL =HOWTO IMPROVE DOCUMENTATION
  5. Detailed technical description of a tool that extracts links between documents in a software project.
  6. Describes a model of requirements and other artifacts: from Business Goals to Feature, Business use case, system use case, component, concrete ability, release, and product.
  7. Advice: create traceable artifacts
  8. Plan and introduce automatic tools/processes to maintain and/or expose traces.

Cleland-HuangMarreroBerenbach08

  1. Jane Cleland-Huang & Will Marrero & Brian Berenbach
  2. Goal-Centric Traceability: Using Virtual Plumblines to maintain critical Systemic qualities
  3. IEEE Trans Software Engineering V34n5(Sep/Oct 2008)pp685-699
  4. =CASESTUDIES REGRESSION TESTING QUALITIES KAOS QAM SIG SOFTGOALS i* ATAM GCT
  5. GCT::acronym="Goal Centric Traceability".
  6. Put tests for qualities into regression testing and derive tests from goals.
  7. Tests can be done statically or by running code. But are automatically traced to impacts on quality goals.
  8. QAM::acronym="Quality Assessment Methods", These may be manual or automatic.
  9. They can be: executable models(simulations), Manually evaluated models, Runtime monitors, or test cases.
  10. Develops from [Cleland-HuangEtAl07]

Cleland-HuangEtAL09

  1. Jane Cleland-Huang & Horatiu Dumitru & Chuan Duan & Carlos Castro-Hrrera
  2. Automated Support for managing feature requests in open forums
  3. Commun ACM V52n10(Oct 2009)pp19-20 [ 1562764.1562784 ]
  4. =EXPERIMENT TOOL CLUSTERING TOPICS USERS REQUESTS
  5. Evidence that an algorithm can analyse and classify issues better than the subjects provided by submitters.

Clemenconetal96

  1. Christian Clemencon & Bodhisattwa Mukherjee & Karsten Schan
  2. Distributed Shared Abstractions(DSA) on Multiprocessors
  3. IEEE Trans Soft Eng VSE22n2(Feb 1996)pp132-152
  4. =DEMO NET NONSEQUENTIAL DATA ABSTRACTION HARDWARE

ClementBesselaar93

  1. Andrew Clement & Peter Van den Besselaar
  2. A retrospective look at PD Projects
  3. Comm ACM V36n6(Jun 1993)pp29-37
  4. =POLL EXPERIENCE Participatory DESIGN JAD USER STAKEHOLDER PD REQUIREMENTS
  5. PD:="Participatory Design".
  6. Took 25 published (at IFIP) projects and got 15 response to questionaire. Selected 10 most substantive.
  7. Claims there had been hundreds of PD projects.
  8. Results include temporary empowerment, technologists thinking outside of the box, mostly accurate requirements -- but not necessarily in the market.
  9. PD is a complex process with far reaching implications to an organization and so involves juggling many competing forces.
  10. Need to address immediate needs and have an insider.
  11. All goals, plans, and rationales have to be continuously discussed and revized.
  12. Politics!

ClementsEtal02

  1. Paul Clements & David Garlan & Len Bass & Judith Stafford & Robert Nord & James Ivers & Reed Little
  2. Documenting Software Architectures: Views and beyond
  3. Pearson Education, Upper Saddle River NJ 2002 ISBN 0201703726 CR 0411-1291
  4. =UNREAD ARCHITECTURE VIEWS STYLES UML
  5. Notes [click here [socket symbol] if you can fill this hole]

ClementsJonesNorthropMcGrego05

  1. Paul G Clements & Lawrence G Jones & Linda M Northrop & John D McGregor
  2. Project Management in a Software Product Line Organization
  3. IEEE Software Magazine V22n5(Sep/Oct 2005)pp54-62
  4. =CASE STUDY PRODUCT LINE DOMAIN MANAGEMENT ASSETS VARIATIONS EVOLUTION REUSE
  5. Though similar maintaining and extending a product line requires some changes in traditional approaches.
  6. Lists similarities and differences.
  7. Adding a product to an existing line is based on the assembly of existing assets.
  8. Choosing the correct new product involves assessing both the existing assets and products as well as the traditional analysis.

Cline96

  1. Marshall P Cline
  2. The Pros and Cons of Adopting and Applying Design Patterns in the Real World
  3. Comm ACM V39n10(Oct 1996)pp47-49
  4. Objects allow hinges and patterns resolve dilemmas in nonfunctional requirements

Cloyd01

  1. Molly Hammar Cloyd
  2. Designing User-Centered Web applications in web time
  3. IEEE Software Magazine V18n1(Jan/Feb 2000)pp62-69
  4. =EXPERIENCE FAST WEB B2B APPLICATIONS USER
  5. How to introduce human factors methods into a reluctant development organization.
  6. Usability and first-time-to-market are now "must have" qualities.
  7. 1: user, 2: low tech prototypes prove concept, 3: storyboard, 4: module = use case+screen mockups, 5: others develop modules.

Coad88

  1. P Coad Jr
  2. Design Approaches & DoD-STD-2167
  3. ACM SIGSOFT Software Engineering Notes v12n1 (Jan 1987)p50
  4. =ESSAY lifecycle

Coad90

  1. Peter Coad
  2. Object Oriented Analysis
  3. Object Int & Ed Yourdon Press Prentice Hall NJ
  4. =HANDBOOK object-oriented SAD DFD ERD STD

Coad92

  1. Peter Coad
  2. Object-Oriented Patterns
  3. (Special Issue: Modeling) Comm ACM V35n9(Sep 1992)pp152-159

Coadetal95

  1. Peter Coad with David North & Mark Mayfield
  2. Object Models: Strategies & Patterns & Applications
  3. Prentice Hall 1995 $49 ISBN 0-13-108614-6
  4. CR9607-0462:"based on talks?" ref in Software Development Magazine(Jul 1995)p35 [Coadetal95a]
  5. with disk

Coadetal95a

  1. Peter Coad(mailto: coad@oi.com) with David North(dnorth@aig.com) & Mark Mayfield(mayfield@oi.com)
  2. title
  3. Software Development Magazine(Oct 1995)pp39-50 [Coadetal95]
  4. DEMO OBJECT-ORIENTED MODELS SCENARIOS strategies tactics

CoadLefebvre99

  1. Peter Coad & Eric Lefebvre
  2. Modeling in Color
  3. Software Development Magazine V7n3(Mar 1999)pp39-140
  4. =THEORY use Color for common analysis class stereotypes: role, time, thing, description

CoadMayfield97

  1. Peter Coad & Mark Mayfield
  2. Designing with Interfaces for Java
  3. Software Development V5n4(Apr 1997)pp47-48+50+52+54

CoadNorthMayfield97

  1. Peter Coad & David North & Mark Mayfield
  2. Object Models: Strategies, Patterns, and Applications
  3. Yourdon Press(Prentice Hall Int) 1997 ISBN 0-13-840117 $48
  4. =TEXT OO MODELS OMT UML PATTERNS
  5. reviewed ACM SIGSOFT Software Eng Notes V23n3(May 1998)pp123-126 "cute style"
  6. 148 strategies + 31 design patterns
  7. Playground::= See http://ww.oi.com/playground.htm

CoadNicola93

  1. Peter Coad & Jill Nicola
  2. Object-oriented Programming
  3. Yourdon Press Englewood Cliffs NJ 1993 ISBN 0-13-032616-X CR9502-0058
  4. =ADVERT

CoadYourdon91

  1. Peter Coad & Edward Yourdon
  2. Object Oriented Design
  3. Yourdon Press Prentice Hall NJ 1991
  4. =HANDBOOK object-oriented coupling and cohesion
  5. problem domain+HCI+task management+data management
  6. Review: Alejandro Teruel IEEE Computer Magazine V25n3(Mar 1992)p125
  7. CR9404-0198

CoadyKiczalesFeeleySmolyn01

  1. Yvonne Coady & Gregor Kiczales & Mike Feeley & Greg Smolyn (UBC)
  2. Using AspectC to improve Modularity of Path-Specific Customization in Operating System Code
  3. ACM SIGSOFT proc ESEC-8 FSE-9 Software Engineering Notes V26n5(Sep 2001)pp88-98
  4. =CASESTUDY ASPECTS MODULARITY FreeBSD C
  5. Layered architectures work well with OS's but some decisions can not be confined to a single layer but drill down through many layers. Aspects let this be handled in a modular way by encapsulating cross-cutting concerns.

CobbEtal98

  1. Maria A Cobb & Harold Foley III & Ruth Wilson & Miyi Chung & Kevin B Shaw
  2. An OO Database Migrates to the Web
  3. IEEE Software magazine V15n3(May/Jun 1998)pp22-30
  4. =EXPERIENCE OBJECT-ORIENTED Geographic DATA CORBA JAVA SMALLTALK IDL NET/WEB

CobleighAvruninClarke08

  1. Jamieson M Cobleigh & Gregory Avrunin & Lori A Clarke
  2. Breaking up is Hard to do: An Evaluation of Automated Assume-Guarantee Reasoning
  3. =EXPERIMENT TOOL AUTOMATED VERIFICATION NONSEQUENTIAL Ada Code FLAVERS LTSA
  4. ACM TOSEM Trans Software Eng & Methodology V17n2(Apr 2008)#7pp1-52
  5. Given a system with two or parallel subsystems can we compute the necessary and sufficient conditions for the whole to perform as specified.
  6. FSF::="Finite State Verification".
  7. Using the L* algorithm to find assume-guarantee conditions can slow the process but doesn't waste memory.
  8. Some assume-guarantee conditions discovered where large: 250 states. Not known if this is the best one.

Cockburn96

  1. Alistair Cockburn
  2. The 3 Rings of Object Technology
  3. Object Magazine (Nov 1996) pp20-22
  4. DATA MODEL vs OBJECT-ORIENTED: structure vs changes. Modeling data on disk vs data in organization
  5. conceptual+logical+physical. Date model quicker. SCENARIOS:channel effort
  6. test completeness and variations. [CRC] encourages creativity.

Cockburn00

  1. Alistair Cockburn [ arc@acm.org ]
  2. Characterizing People as Non-Linear, First-Order Components in Software Development
  3. Humans & Technology, HAY Technical Report 1999.03(Oct 21 1999) and Proc SCI/ISAS2000 VI pp728-736 [SCI00]
  4. =EXPERIENCE 20 projects PEOPLE AGILITY ONESIZE
  5. A commonly observed pattern by methodologists and tool smiths
    1. The people on the projects were not interested in learning our system.
    2. They were successfully able to ignore us, and were still delivering software, anyway.
    3. Almost any methodology can be made to work on some project.
    4. Any methodology can manage to fail on some project.
    5. Heavy processes can be successful.
    6. Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.
    7. people are
      1. are communicating beings, doing best face-to-face, in person, with real-time question and answer.
      2. have trouble acting consistently over time.
      3. are highly variable, varying from day to day and place to place.
      4. generally want to be good citizens, are good at looking around, taking initiative, and doing "whatever is needed"
      5. need both think time and communicating opportunities.
      6. work well from examples.
      7. prefer to fail conservatively than to risk succeeding differently
      8. prefer to invent than to research
      9. can only keep a small amount in their heads, and do make mistakes
      10. find it hard to change their habits.

    8. Individual personalities easily dominate a project.
    9. A person's personality profile strongly affects their ability to perform specific assignments.
    10. paper documentation is the least effective communication medium available.

Cockburn 00b

  1. Alistair Cockburn
  2. selecting a project's methodoloist
  3. IEEE Software Magazine V17n3(Jul/Aug 2000)pp64-71
  4. =IDEA PEOPLE before MEHODS
  5. size and criticallity(fear) drives need for bigger methods.
  6. nonlinear method->cost, d cost/d method is large.
  7. consider priorities and reconsider them later.
  8. face-to-face communicates better than paprr

Cockburn00c

  1. Alistair Cockburn
  2. Balancing Lightness with Sufficiency
  3. Cutter IT Journal V13n11(Nov 2000)pp26-33
  4. =ARTICLE METHODS PROCESSES PROJECT
  5. p26. "software development can be thought of as a cooperative game of invention and communication with limited resources." [ game ]
  6. Start with closest fitting methods. Need to tune and prune procedures to fit particular projects needs as they evolve. Hunting for sweet spots. No substitute for rapid feedback.

  7. technology >< team size >< damage potential >< culture. See [Cockburn00?]
  8. What is sufficient for now may be insufficient when the team is gone.
  9. A team has an insufficient methodology when it does not communicate often or well enough for its members to carry out their work.
  10. Crystal_Clear::= See http://members.aol.com/humansandt/crystal/clear

Cockburn02

  1. Alistair Cockburn
  2. Games Progremmers Play
  3. Software Development Magazine V10n2(Feb 2002)pp28-32
  4. =IDEA PROCESS GAME THEORY
  5. Software development considered as a game of invention and communication.
  6. Primary goal: deliver software that fits problem space.
  7. Secondary goal: leave tracks to make the next game easier to win.

Cockburn02b

  1. Alistair Cockburn
  2. Use Cases, ten years later
  3. STQE Magazine (Mar/Apr 2002) [ Use+cases,+ten+years+later ]
  4. =HISTORY =HOWTO USE CASES FORMALLITY Brief Casual Fully dressed STAKEHOLDERS GOALS Theory
  5. How people reacted to use cases...
  6. Some peole like formal structured use cases but others dislike them.
  7. Advice: Keep them simple. Keep them essential/logical. Use multiple formats: Brief, Casual, Fully Dressed.
  8. Mistakes: too many physical details, main use case too long and detailed.

Cockburn03

  1. Alistair Cockburn
  2. Agile Software Development
  3. Addison-Wesley Boston MA 2001 ISBN 0-201-69969-9 US$34.99
  4. Reviewed IEEE Software Magazine V20n1(Jan/Feb 2003)pp97-98 and [CR] 0305-0454 [CR] 0307-0652
  5. =HANDBOOK IDEAS PROCESS AGILE
  6. Communication+collaboration+insight+study+practice+experimentation

CockburnHighsmith01

  1. Alistair Cockburn & Jim Highsmith
  2. what
  3. IEEE Computer Magazine V34n11(Nov 2001)pp131-133
  4. =ADVERT AGILE PEOPLE trump Process

CODASYL71

  1. CODASYL Database Task Group
  2. CODASYL Database Task Group report
  3. ACM NY NY 1971
  4. =STANDARD data logic ENTITIES SETS(FUNCTIONS)

Codd70

  1. ?? Codd
  2. A Relational Model for Large Shared Data Banks
  3. Commun ACM 13 6 (Jun 1970) pp 377-387 (also CACM25)
  4. =DEMO data structures System

Codd82

  1. ?? Codd
  2. Relational Databases: a practical foundation for productivity
  3. Commun ACM v25 n2 Feb82 pp109-117
  4. =DEMO data structures

Codenieetal97

  1. Wim Codenie & Koen De Hodt & Patrick Steyaert & Arlette Vercammen
  2. From Custom Applications to Domain-Specific Frameworks
  3. Comm ACM V10n10(Oct 1997)pp71-77
  4. =EXPERIENCE REUSE GENERIC
  5. need more than fill-in-the-blanks (hotspots); must document how-to+effort of reuse as a contract

Codephirst07

  1. Colin Codephirst (alias) & Nail Maiden (ed)
  2. From the horse's mouth
  3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp21-23
  4. =JOKE REQUIREMENTS SPECIFICATION WORST PRACTICES

Codephirst09

  1. Colin Codephirst (alias) & Nail Maiden (ed)
  2. Where have all the stencils gone?
  3. IEEE Software Magazine V26n4(Jul/Aug 2009)pp
  4. =HISTORY STENCILS FLOWCHARTS =JOKE REQUIREMENTS
  5. Technique was easy and fun to use, impressed the stakeholders, and contributed little to understanding the problem.
  6. Compare [Codephirst07]

Coen-Porisinietal91

  1. Alberto Coen-Porisini & Flavio De Paoli & Carlo Ghezzi & Dino Mandrioli
  2. Software Specialization Via Symbolic Execution
  3. IEEE Trans SE-17 n9 (Sep 1991)pp884-899 CR9302-0092
  4. =DEMO logic symbolic execution re-engineering specialization

Coen-Porisinietal94

  1. Alberto Coen-Porisini &Richard A Kemerer & Carlo Ghezzi & Dino Mandrioli
  2. A Formal Framework for ASTRAL Intralevel Proof Obligations
  3. IEEE Trans on Soft Eng vSE-20n8(Aug 1994)pp548-561
  4. =MATHEMATICAL PROOF FORMAL TIMING FSMS

Coen-Porisinietal97

  1. Alberto Coen-Porisini & Carlo Ghezzi & Richard A Kemerer
  2. Specification of Realtime Systems using ASTRAL
  3. IEEE Trans on Soft Eng vSE-20n8(Aug 1994)pp548-561
  4. =ADVERT SPECIFICATION TIMING LANGUAGE [Coen-Porisinietal94]

Cohen79

  1. ?? Cohen
  2. Non-Deterministic Algorithms
  3. ACM Comp Surveys 11 2 (Jun 1979) pp79-94
  4. =SURVEY non-sequential optimization

Cohen90

  1. Jacqes Cohen
  2. Constraint Logic Programming Languages
  3. Commun ACM V33n7(Jul 1990)pp52-68
  4. =DEMO CLP non-sequential AI

Cohen04

  1. Jaques Cohen
  2. Bioinformatics: an Introduction for computer Scientists
  3. ACM Comput Surveys V36n2(Jun 2004)pp122-158 [ 1031120.1031122 ]
  4. =SURVEY BIOINFORMATICS BIOLOGY

CohenBirkinGarfieldWebb04

  1. Cynthia F Cohen & Stanley J Birkin & Monica J Garfield & Harold W Webb
  2. Managing Conflict in Software Testing
  3. Commun ACM V47n1(Jan 2004)pp76-81
  4. =INTERVIEWS 10 TESTERS PEOPLE MANAGEMENT PROCESS
  5. Uncovered (obvious) sources of conflict and proposes resolutions.
  6. Example: Time is scarce. So: Plan for overruns, manage schedule changes, learn from experience.
  7. p79: Managers matter: "The developers fired the manager".

CohenCampbell93

  1. Donald Cohen & Neil Campbell
  2. Automating Relational Operations on Data Structures
  3. IEEE Software Magazine(May 1993)pp53-59 Example: topological sort on page 54
    1. do( x' in graph & no y in graph(y before x);
    2. out:!x; graph:~x;
    3. )

Cohenetal97

  1. Don Cohen & Martin S Feather & K Narayanaswamy & Stephen S Fickas
  2. Automatic Monitoring of Software Requirements [ICSE'97]
  3. =IDEA FLEA AMOS

CohenFeldman04

  1. Yossi Cohen & Yishai A Feldman Automatic High-Quality Reengineering of Database Programs by abstraction, Transformation and Reimplementation
  2. ACM TOSEM Trans Software Eng & Methodology V12n3(Jul 2003)pp285-316
  3. =EXPERIENCE TOOL MIDAS REENGINEER network to RELATIONAL DATAbase COBOL SQL PERFO RMANCE
  4. simple translation of procedural code to relational/SQL leads to slow data base response. Need to abstract the plan for the legacy code. Used Plan Calculus with Query graphs.

CohenHarwoodJackson86

  1. B Cohen & W T Harwood & M I Jackson
  2. The specification of Complex cystems
  3. Addison Wesley Wokingham UK 1986
  4. UCR Rivera QA76.9.s88 1986
  5. =theory nonsequential specification VDM

Cohn04

  1. Mike Cohn
  2. User Stories Applied: for agile software development
  3. Addison-Wesley 2004 ISBN 0-321-20568-5
  4. =UNREAD USER REQUIREMENTS AGILE XP

CohnFord03

  1. Mike Cohn & Doris Ford
  2. Introducing an agile Process to an Organization
  3. IEEE Computer Magazine V36n6(Jun 2003)pp74-78
  4. =EXPERIENCE AGILE PROCESS PEOPLE RISKS Scrum programmer:
    1. initially need a balance of scepticism and enthusiasm. Need top talent.
    2. Can initially classify Scrum sprints as "prototyping","requirements capture, ... "stabilization".
    3. Do not use a distributed development team initially.... especially after a merger. culture clash.
    4. Some initially see agile as micromanagment.

    Testers: don't let them program! If they want to then hire them as programmers! Testing is up front and managers get involved.
  5. Manager problems: promise customers what? What progress now? How does it effect xyz? When is the end of the project?
  6. Involve Human Resources! Performance reviews without predicted deliverables?

CoistagliolaEtal06

  1. Gennaro Coistagliola & Vincenzo Deufemia & Filomena Ferrucci & Carmine Gravino
  2. Constructing Meta-CASE workbenches by exploiting visual language generators
  3. IEEE Trans Software Engineering V32n3(Mar 2006)pp156-175
  4. =DEMO GRAPHIC TOOLS for PROCESSES CASE UML GXL MEG WoG
  5. GXL::XML="Graph eXchange Language".
  6. MEG::Tool="Modeling Environment Generator".
  7. WoG::Tool="WOrkbench Generator".
  8. VLDesk::="Visual Language Desk"
  9. Figure 1 shows Cannallen's UML icon's for web components.
  10. Uses analysis/robustness diagrams with entity+interface+control classes.
  11. Examples of UML models of tools: meta-CASE.
  12. In usecase diagram replaces include by INCLUDED and extends by EXTENDED.
  13. Adds artifacts to activity diagrams and adds a dashed arrow indicating a constraints between artifacts.

ColbergThomborson02

  1. Christian S Colberg & Clark Thomborson
  2. Watermarking, Tamper-proofing, and Obfuscation -- tools for Software Protection
  3. IEEE Trans Software Engineering V28n8(Aug 2002)pp735-746
  4. =IDEA SECURITY RISKS ETHICS TECHNICAL Intellectual Property
  5. Security has has long been about protecting host systems from attacks by mobile code. This articles looks at protecting mobile code from abuse by its host!

Colbert02

  1. Ed Colbert
  2. Avionics architecture Description Language ( AADL )
  3. IEEE Los Angeles Chapter Bulletin (Jan 2002) p6
  4. =ABSTRACT DESIGN LANGUAGE UML MetaH TOOLS STANDARD SAE Automotive avionic
  5. Full paper presented at chapter meeting 8pm Jan 9th 2002, Los Angeles.

Coleman79

  1. Derek Coleman
  2. A Structured Programming Approach to Data
  3. Springer Verlag NY 1979
  4. =DEMO sequential DDD language data

Colemanetal94

  1. Derek Coleman & Patrick Arnold & Stephanie Bodoff & Helena Gilchrist & Fiona Hayes & Paul Jeremaes
  2. Object-oriented development: the FUSION Method
  3. Prentice Hall Englewood Cliffs NJ 1994 ISBN 0-13-338823-9 CR9502-0058
  4. =HOWTO OBJECT_ORIENTED MODEL FORMAL CRC BOOCH REGULAR ERD OMT COLLABORATION HP
  5. Combination of OMT Booch CRC and some formal methods.
  6. Prefigures UML and RUP, Subsumed in OPEN. Uses regular expressions to express dynamics.
  7. Unusually precise definitions!

ColemanHayesBear92

  1. Derek Coleman & Fiona Hayes & Stephen Bear
  2. Introducing ObjectCharts or How to Use Statecharts in Object-Oriented Design
  3. IEEE Trans SE-18n1(Jan 1992)pp9-18 CR9301-0026
  4. =IDEA ObjectCharts OBJECT GRAPHIC STD STATECHART Harel

CollierDeMarcoFearey96

  1. Bonnie Collier & Tom DeMarco & Peter Fearey
  2. A Defined Process for Project Postmortem Review
  3. IEEE Software Magazine VSE13N4(Jul 1996)pp65-72
  4. How to do a Postmortem::= anonymous survey; collect objective data; debriefing; project history day; publish; act [ postmortems.html ]

Collins02

  1. Rosann Webb Collins
  2. Software localization for Internet software: Issues and methods.
  3. IEEE Software Magazine V19n2(Mar/Apr 2002)pp74-80
  4. =EXPERIENCE PROBLEMS INTERNATIONAL WEB/NET
  5. examples: date formats, one graphic: meaningful, meaningless, holy, or even obscene!

CollinsBicknell98

  1. Tony Collins & David Bicknell
  2. Crash: learning from the world's worst computer disasters
  3. Simon and Schuster London Uk 1998 ISBN 0-684-81687-3
  4. =ANECDOTE RISK COST PQRST HISTORY 1830-1998 UK USA ...
  5. Simplify and standardize before you computerise.
  6. Cost is three times bigger than your most meticulous estimate.
  7. Big systems fail. Disastors happen when techies have control. Especially if they have power.
  8. Make sure you have a Plan B for when a new system fails -- even if all the tests and diligence seem to make failure impossible. Run old in parallel with old. Do one piece at a time.
  9. A computerized system that depends on its users acting perfectly or differently will fail. Plan for human errors and shortcuts.
  10. Cancel software development that will have no tangible benefits within 6.months .. 1.year. Instead buy COTS and change the organisation to fit it.
  11. Customers must be experts and sceptics. Know what is needed here and what has been done elsewhere.
  12. Better to do it yourself than use consultants or even local MIS.
  13. Avoid big-bangs. Go incremental.
  14. Normally a project fails and neither the customers nor the suppliers are to blame - they say. Lawyers profit.
  15. Don't set or accept artificially tight deadlines.
  16. Ten deadly sins: overambition, pride, presumption, credulity, consultancy, modification, concealment, buck-passing, lawyers.
  17. Suggestions:
    1. CEO must remain in control and be reay to terminate project.
    2. First tune existing system to 80% of capacity and simplify business procedures to 2 sides of A4 paper.
    3. Proceed warily. Put business ahead of technology. Look for a system that needs no changes and is minimally proprietary. Choose Lowest level technology: ( PCs < workstations/minis < mainframes )
    4. Get a complete list of all consultant's clients.
    5. Demand clear explanations - no meaningless jargon.
    6. Technical designers should work as or with end-users for a week/month/year before designing a new system.
    7. Freeze design before developing new software. Suppliers will still misundertand it. Further features or users will be added after system has succeeded and not before.
    8. Fixed price contract with consultant: We won't pay until it works to our satisfaction. Two stages: up to a complete frozen written spec., and after spec. if it beneficial in < 6 months.
    9. Have evidence system can handle expected loads/demands.
    10. Include data design and setup costs. Look for cheap but reliable ways to populate any databases
    11. Go live in small steps.
    12. No miracles! Instead the new system will be worse than the old, but slowly some benefits will appear.
    13. Big systems fail. Keep It Simple. No more than one year at a time. Best if less than 6 months. Computerize one bit at a time.
    14. Expect to throw the first attempt away.

Collinsetal94

  1. W Robert Collins Keith W Miller & Bethany J Spielman & Phillip Wheery
  2. How Good is Good Enough? An Ethical Analysis of Software Construction and Use
  3. Commun ACM V37n3(Jan 1994)pp81-91
      Presumes quality assurance is limitted to discussion and testing. Case study with inadequate analysis/design and bad cut-over plan. Tables of obligations between provider, buyer, USER, and penumbra

      Applies Rawls Theory of Justice.

      Concludes possibility of suits under theories of negligence, misrepresentation, strict liability, & malpractice. Notes that malpractice applies the standard of care of the appliction area, not that of software production!

      Does not ref Mumford refs McFarland91


CollofelloBuck87

  1. James S Collofello & Jeffrey J Buck
  2. Software Quality Assurance for Maintenance
  3. IEEE Software V4n5(Sep 1987)pp46-51
  4. =REPORT SQA QUALITY

Colmerauer90

  1. Alain Colmerauer
  2. An Introduction to Prolog III
  3. Commun ACM V33n7(Jul 1990)pp68-90
  4. =LRM logic-programming non-sequential AI

Colonna93

  1. Jean-Francois Colonna
  2. The Subjectivity of Computers(Letter)
  3. Commun ACM V36n8(Aug 1993)pp15-18
  4. = ESSAY RISKS
      Numerical errors and dependence on initial conditions.

      Hypercard shows no differences due to associativity over 60 iterations!

      Assumes that floating point is computing?


Colwell02

  1. Bob Colwell
  2. Near Misses: Murphy's Law Is Wrong
  3. IEEE Computer Magazine V35n4(Apr 2002)pp9-12
  4. =ESSAY EXPERIENCE RISKS ENGINEERING vs SCIENCE
  5. Learning from mistakes. eg. Challenger. Hubble. Mars Climate Orbiter etc.
  6. Engineers often can not afford a replicated scientific experiment -- especially testing something to destruction!
  7. "To engineer is human" -- Petroski85: never make the same mistake twice.
  8. "Failure is not an option" -- Gene Kranz 2000: NASA pushing the envelope means design mistakes so need test pilots.
  9. Erroneous sqrt vs 1.5 safety factor in aircraft wing design.
  10. Engineers must do two different things: design to achieve perfection and design as though errors are going to be made.
  11. A pattern: major failure occurs in unusual circumstances: three mile island & Chernobyl. Often as a result of humans in the loop.
  12. Perrow 1999: Normal accidents: Living with High-Risk Technologies: Coupling and interactions make systems harder to control and understand.
  13. James Chiles 2001: Inviting Disasters: Lessons from the Edge of Technology: Murphy is wrong -- things can fail to go wrong many times before a big disaster happens in the same way. "Near misses are nature's way of telling us something's wrong, and we'd better fix it fast."
  14. However: repeatedly getting away with something makes us feel that it is safe. The near disaster becomes the norm. Hence the requirements a bent a bit.
  15. Disasters are averted by deep understanding of the system and all its quirks plus the ability to keep ones head when all else are losing their's. Example lightening hitting Apollo 12.
  16. Emotional stress effects judgment.
  17. Beware management manipulation: "do you want your boss to know how stupid you are?", "We go with or without you"(sign off and they will blame you). "Take off your engineering hat and think like a manager..", "Ships are not supposed to be docked safely in the harbor all the time".
  18. User friendly designs can hide how close to disaster the user is/was.

Colwell03

  1. Bob Colwell
  2. Design Reviews
  3. IEEE Computer Magazine V36n10(Oct 2003)pp8-10 + letter V36n12(Dec 2003)p6-7
  4. =ANECDOTES PEOPLE DESIGN QUALITY INSPECTION SQA
  5. Article describes some disastrous design reviews.
  6. Jesse N Alexander's letter gives some rules:
    1. Reviews (informal high level discussion) are not inspections(formal and detailed error hunt).
    2. No Managers allowed.
    3. Meeting metrics must measure the process not the people.
    4. Define the Roles.
    5. Criticize the design not the designer.
    6. No design allowed.

    Colwell04

    1. Bob Colwell
    2. Brainstorming, influence, and icebergs
    3. IEEE Computer Magazine V37n4(Apr 2004)pp9-12
    4. =EXPERIENCE PEOPLE MEETINGS

Colwell04b

  1. Bob Colwell
  2. Interface Quotas and Internet-Derived Value
  3. IEEE Computer Magazine V37n12(Dec 2004)pp10-11
  4. =ESSAY USER SAFETY SIMPLICITY WEB/NET
  5. Keep user interfaces similar to old & thouqht-free.
  6. Use internet to simplify & unify user interfaces.

Comaford95

  1. Christine Comaford
  2. What's Wrong with Software Development?
  3. Software Development Magazine(Nov 1995)pp27..28
  4. 9 RISKS problems and solutions
    1. 1. understand your business better
    2. 2. understand your users better
    3. 3. manage developers better
    4. 4. better infrastructure for applications
    5. 5. understand the real mening of RAD
    6. 6. more reliable estimation for client/server development
    7. 7. control prototypes
    8. 8. better architectures
    9. 9. better testing

CommonerHoltEvenPnueli71

  1. F Commoner & ?? Holt & ?? Even & ?? Pnueli
  2. Marked Directed Graphs
  3. Jnl Computer and Systems Sciences V5pp511-523
  4. =THEORY formal graphic petri nets non-sequential
  5. My reduction of this work is in [ Marked%20Directed%20Graphs in math_76_Concurency ]

ComputerworldStaff05

  1. Computerworld Staff
  2. Computerworld Development Survey gives nod to C#
  3. Computerworld (Mar 28 2005) [ 0,4814,100542,00.html ]
  4. =POLL LANGUAGES C# JAVA VB JavaScript C++ API .Net IDE Linux Open Source
  5. Summary by ACM TechNews [ item8 in 0404m ]
  6. 50% use some open source code.
  7. 72% C#, 66% Java, 62% Visual Basic, 54% C++, 50% JavaScript...
  8. 58% Web Services being developed

Conallen98

  1. Jim Conallen
  2. Modeling Web Application Design with UML
  3. Rational [ dynamic.jtmpl?doc_key=100462 ]
  4. new stereotypes: server, client, xml, form, target, ...

Conallen99

  1. Jim Conallen(jconalle@Rational.com)
  2. Modeling web application architectures with UML
  3. Commun ACM V42n10(Oct 1999)pp63-70 in [Booch99]
  4. =ESSAY WWW/NET DESIGN UML stereotypes vs [RMM]
  5. Also see [Conallen98] on the WWW
  6. web application implement business logic and when accessed changes the state of the business. Separate business ADM from presentation UI.
  7. ADM:=Analysis/Design model
  8. classes: separate client side pages from server side pages. serverside builds clientside.
  9. components: Iconic stereotypes
  10. stereotypes for: server pages, client pages, links,builds, form, parts of forms, frame, target, applets, javascript, activex,...
  11. Details to be announced [ http://www.rational.com/ ]

Conallen01

  1. Jim Conallen
  2. Modeling Web-Tie Components
  3. Software Development Magazine V9n1(Jan 2001)pp49-55
  4. =ADVERT WAE MODEL WWW UML
  5. WAE := Web Application Extension.
  6. Proposes new sereotype: <<virtual root>>, <dynamic page>>, <<HTMLpage>>, <<active Server page>>, <<Java Server Page>, <Servlet>>, <<client page>>, <<server page>>, <<link>, <<build>>, <<submit>>, <<redirect>>
  7. Note: uses dependency arrows backwards and associations for behaviorial dependencies.
  8. Compare with [Conallen99]

Conallen02

  1. Jim Conallen
  2. Building Web Applications with UML (2nd edn.).
  3. Addison-Wesley Pearson Boston MA 2002 ISBN 0-201-73038-3 [CR] 0305-0332
  4. =TEXT WEB/NET HTML UML USER UX PQRST XML workflows process JavaScript Java ActiveX/COM RMI/IIOP DCOM UDDI SOAP WSDL
  5. A thorough coverage of web site development using UML based on authors own practice and experience.
  6. WAE::="Web Application Extension", not OMG standard but Rational Profile.
  7. Uses statecharts to map out transitions between web pages.
  8. UX::="User experience".
  9. Uses the Objectory icons for Interface, Control, and Entity objects.
  10. Describes development Processes using UML but does not use OMG SoftProc Modelling02-11-14.pdf but Rational's 27070_BusinessModeling.pdf
  11. See [Conallen01] [Conallen00] [Conallen99] [Conallen98]

ConboyCoyleWang11

  1. Kieran Conboy & Sharon Coyle & Xiaofeng Wang
  2. People over Process: key challenges in agile development
  3. IEEE Software Magazine V28n4(Jul/Aug 2011)pp48-57
  4. =POLL 27 PROJECTS AGILE PROBLEMS PRACTICES
  5. Good table defining agility.
  6. Transparency causes fear: provide alternative feedback, provide mentors, pairing.
  7. (dick)|-Also control big mouths!
  8. Every body must master all trades: pairing and rotation, allow self-assignment for learning, perhaps reintroduce specialist roles when it would help team.
  9. More social skills: training using own examples, add documentation to communication.
  10. Lack of business/domain knowledge: enterprise training+interactive niche training modules, hire tech+business skills.
  11. Need to adopt agile values and principles as well as practices: many get trained or go to conference, coaching and championing, cross-team observation, assess values not practice.
  12. Motivation: include motivated in each team, collect and share success stories.
  13. Devolved decision-making: sharing and learning, democratic voting, manager as facilitator.
  14. Need agile compliant performance evaluation: bredth not depth, 360 degree evaluation.
  15. Recruitment: special processes, team recruiting, put new graduates on agile projects to learn hands-on.

ConboyFitzgerald11

  1. Kieran Conboy & Brian Fitzgerald
  2. Method and Developer characteristics for agile method tailoring: a study of XP expert opinion
  3. ACM TOSEM Trans Software Eng & Methodology V20n1(Jan 2011)#2.1-30 [ 1767751.1767753 ]
  4. =INTERVIEWS 16 XP EXPERTS 16 PRACTITIONERS AGILE TAILORING
  5. XP is a rigid process that is never completely adopted.
  6. Tailoring proceeds ad hoc and backwards -- adding practices as desired.
  7. Table II. Research needed to clarify when XP is good, what parts are dependent, develop a rationale for each practice, ...
  8. Table III. Advice to those about to adopt a process/method
    1. Formally analyze your situation, before the project starts, to see if the method fits.
    2. Involve all the stakeholders.
    3. What are the organizational limits on adopting the process?
    4. Train before you try it out. Accept/reject a practice after trying it.
    5. Include practical training before tailoring.

  9. RUP is not mentioned. But comes with tailoring instructions.

ConcasEtAl11

  1. Giulio Concas & Michele Marchesi & Alessandro Murgia & Roberto Tonelli & Ivana Turnu
  2. On the distribution of bugs in the Eclipse system
  3. IEEE Trans Software Engineering V37n6(Nov/Dec 2011)pp872-877
  4. =EMPIRICAL BUG FIX STATISTICS DEFECTS MODELS ECLIPSE Yule-Simon
  5. Reports on attempts to match bug fix stats to 4 statitical models. One fits very well.
  6. Apparently bugs like company -- fixes tend to be in modules that have fixed more often before. The Yule-Simon model.
  7. This means that the Yule Simon distribution fits the number of bugs per module very well indeed.
  8. p(x)=p0 * Β(x+c, α) / Β(h0+c, α),
  9. Β(a,b)::= Γ(a)*Γ(b) / Γ(a+b).
  10. Compare [ConcasEtAl07] on other OO Metrics.

ConcasEtAl07

  1. Giulio Concas & Michele Marchesi & Sandro Pinna & Nicola Serra
  2. Power-laws in a large Object-Oriented Software System
  3. IEEE Trans Software Engineering V33n10(Oct 2007)pp687-708
  4. =EMPIRICAL STATISTICS OBJECT-ORIENTED METRICS Pareto Log-normal Yule Power-law POWER LAWs
  5. Measured metrics on three large OO development tools to determine distributions of properties. Found patterns: most metrics have a log-normal or Pareto distribution.
  6. Quoted theories for these distributions.
  7. Noted that for these distributions extreme values are more likely than the normal/chi-square/t family of distributions. The mean value is not a good estimated of position.
  8. Basic process: number of entities have a numeric property. Entities are picked at random and the chosen entities property is increased. How many entities will have a given range of properties?
  9. If the each entity has the same chance and the same change is made the resulting distribution is binomial.
  10. If the size of the increase depends on the value of the property the distribution is log-normal.
  11. (Yule process): If the increase is fixed but the chance if the entity being chosen depends on the property value then the distribution is Pareto.
  12. (log-normal): p(x) = if(x<0, 0, (1/sqrt(2*π))*exp(-(ln(x)-μ)**2/(2*σ**2))).
  13. Example metrics: #methods/class, #all instance variables/class, #LOC/class, class out-degree (see note below).
  14. (Pareto): p(x) = if(x<xmin, 0, (α*(x/xmin)**(-α)/xmin)).
  15. Example Metrics: #Inst vars/class, #subclasses, inst variable names, method names and calls, LOC/method, class in-degree.
  16. Refers to H Simon Biometrica V42 pp425-440 1955 and Newman Cont Physics V46 pp323-351 2005.
  17. Notes that the class outdegree is correlated with the class LOC and so outdegree/LOC has a Gamma distribution.
  18. More see [LouridasSpinellisVlachos08] [ConcasEtAl11]

ConcepcionBottingScroggins00

  1. Arturo I Concepcion & Richard J Botting & Darryl D Scroggins
  2. ROOT Project: An Integration of an OOA/D Methodology in the Computer Science Curriculum
  3. Proc SCI/ISAS2000 V2 pp401-405 [SCI00]
  4. =EXPERIENCE OBJECT-ORIENTED EDUCATION

ConcepcionLinSimon99

  1. Arturo I Concepcion & Sunny Lin Scott J Simon
  2. The RMT(Recursive Multi-Threded) Tool: A Computer Aided Software Engineering Tool for Monitoring and Predicting Software Development Progress
  3. ICSE'99, Proceeedings of the 21st International Conference on Software Engineering (May 1999)pp660-663
  4. =DEMO TOOL PROCESS MANAGEMENT

ConcepcionZeigler87

  1. Arturo I Concepcion & Bernard P Zeigler
  2. DEVS Formalism: A Framework for Hierarchical Model Development
  3. IEEE Trans Soft Eng VSE-14n2(Feb 1988)pp228-241
  4. =DEMO hardware performance top-down simulation formal graphics

Cone06

  1. Edward Cone
  2. Scott Rosenberg: What Makes Software So Hard
  3. CIO Insight (Jan 8th 2007) Zipf-Davis URL [ 0,1540,2079462,00.asp ]
  4. =REVIEW EXPERIENCE Salon ITERATIVE
  5. Book: Dreaming In Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software (Crown, 2007)
  6. "people have succeeded in creating amazing software systems that do work, and do serve people's needs....So it's doable. But when you pick up the rock and look underneath the surface of every one of those systems, you find stories of delay and difficulty and problems. "

Conklin96

  1. Peter F Conklin
  2. Enrollment Management: Managing the Alpha AXP Program
  3. IEEE Software Magazine VSE13N4(Jul 1996)pp53-64
  4. =EXPERIENCE PEOPLE MANAGEMENT MOTIVATION
  5. motivate by

ConklinJ06

  1. Jeff Conklin
  2. Dialogue mapping: Building shared understanding of wiked problems
  3. John Wiley NY NY 2006 ISBN 047017686 CR 0811-1059
  4. =UNREAD =ADVERT =MANUAL IBIS Compendium STAKEHOLDERS
  5. Compare [DenningYaholkovsky08]

ConnellShafer95

  1. John Connel & Linda J Shafer
  2. Object-oriented rapid prototyping
  3. Yourdon Press NJ $39.40 ISBN 0-13-629643-2 CR9603-0154
  4. =HANDBOOK Object-oriented RAD

ConnollyBegg04

  1. Thomas Connolly & Carolyn Begg
  2. Database Systems(4th edn)
  3. Pearson Education Harlow Essex UK 2005
  4. =TEXT DATA PQRST
  5. Comprehensive & detailed

Conrad06a

  1. Paul Jefferson Conrad
  2. Analysis of PSP-Like Processes for Software Engineering
  3. CSUSB CSci Masters Thesis Spring 2006
  4. =SURVEY =POLL PSP STUDENT PROCESS TOOLS
  5. How can Watts Humphrey's Personal Software Processes be used at in the computer science department at CSUSB?
    1. Abstract
    2. The PSP, Personal Software Process, is introduced to Computer Science graduate students in Software Engineering (CS655). The purpose of introducing PSP to Computer Science students is to allow students to enhance their coding skills and documentation. PSP is the leading approach for software developers to improve their own software development skills. However, the PSP data collection process is a time consuming task and error prone. The purpose of this thesis is to provide the California State University, San Bernardino Department of Computer Science with an analysis and recommended solution to improving the software development process of graduating Computer Science students.

Conrad06b

  1. Paul Jefferson Conrad
  2. What
  3. CSUSB CSci Technical Report #1 Spring 2006 [ cs690/20060519PaulConrad.html ]
  4. =IDEA PSP STUDENT PROCESS TOOLS Eclipse
  5. Using an integrated development environments with a PSP plugin can improve the education of Computer Science students.

ConradiDyba01

  1. Reidar Conradi & Tore Dyba
  2. An Empirical study on the utility of formal routines to transfer knowledge and experience
  3. ACM SIGSOFT proc ESEC-8 FSE-9 Software Engineering Notes V26n5(Sep 2001)pp268-276
  4. =POLL PEOPLE PROCESS IMPROVEMENT MANAGEMENT vs DEVELOPERS
  5. Written process is doubted by developers BUT trusted by technical managers.
  6. Social processes are more effective than written manuals at transferring knowledge.
  7. Written processes are without schedule revision and update procedures.
  8. Involvement leads to belief in the efficiency of a training/learning medium.

ConradiDybaEtAl06

  1. Reidar Conradi & Tore Dyba & Dag L Sjoberg & Tor Ulsund
  2. Software Process Improvement: Reulsts and Experience from the field
  3. Springer-Verlag NY Secaucus NY 2006 ISBN 3540321780 CR 0712-1162
  4. =UNREAD CONFERENCE SPI IMPROVEMENT EMPIRICAL SCANDINAVIAN

ConradiWesfechtel98

  1. Reidar Conradi & Bernhard Westfechtel
  2. Version Models for Software Configuration Management
  3. ACM Comp Surveys V30n2(Jun 1998)pp232-282
  4. +THEORY =SURVEY TOOLS [SCM]

Constantine90

  1. Larry L Constantine
  2. Comments "On Criteria for Module Interfaces"
  3. IEEE Trans SE-16 n12(Dec 1990)p1440

Constantine94

  1. Larry Constantine
  2. Essentially Speaking
  3. Software Development V2n1(Nov 1994)pp96+95
    1. p96 "Data Flow diagrams were intended as a nonprocedural model o computation, separating the essence of what the computer was to do from how it was to be accomplished through any particular algorithm or procedure[...] In practice, designers often turned DFDs into flowcharts with funny figures, a corruption encouraged by enhancements taht implicitly invited procedural thinking." ref to McMenaminPalmer86, Stephen P McMenamin & John Palmer, Essential Systems Analysis, Yourdon Press 1986
    2. p95 Essential use-case modeling: S-T
    3. p95"If we don't design to the ideal, we can't see where technology or technical assumptions are limiting us, and we may miss completely the opportunity for alternative approaches."

Constantine95

  1. Larry Constantine
  2. Essential modeling: use cases for user interfaces
  3. interactions V2n2(Apr 1995)pp34-46
  4. CR9607-0521 USER SCENARIO

Constantine95a

  1. Larry Constantine
  2. Software Objectives
  3. Software Magazine (Jun 1995)pp88-87
      Object orientation is to good to be ignored, but it is not Early religious attacks on earlier methods often hid the speakers lack of knowledge of these methods.

      Putting data and process in one box makes it look neater and lets it hold more - so we can make bigger things with it!

      Reccommends Eiffel for learning OO


Constantine95b

  1. Larry Constantine
  2. Embedded with the Best
  3. Software Development Magazine(Jul 1995)pp88&87+letter(Oct 1995)p11
      hidden applications demand precision and accuracy.... and have nearly flawless code. Cf Bond95 questioned in letter

Constantine95c

  1. Larry Constantine
  2. Under Pressure
  3. Software Development Magazine(Oct 1995)pp112+111
  4. =EXPERIENCES
  5. reports on competition to produce a complex system in under one day in Australia
  6. Concludes that design time pays off but configuration management is vital when under pressure.

Constantine99

  1. Larry Constantine
  2. Modeling for the long term
  3. Software Development Magazine V7n11(Nov 1999)pp40-43
  4. =EXPERIENCE USER MODEL ECONOMICS REUSE
  5. Models clarify needs and designs early.
  6. Persistent models have an extra pay off later.
  7. =ADVERT [ConstantineLockwood99]

Constantine00

  1. Larry Constantine
  2. Cutting Corners
  3. Software Development V8n2(Feb 2000)pp72+70-71
  4. =EXPERIENCE Crunch mode TANSTAAFL PROTOTYPING MODELING
  5. Face-time can be traded for user modeling.
  6. A real user is a better model of the user than any model!

Constantine00b

  1. Larry Constantine(ed) with Sylvain Hamel & Jim Highsmith
  2. Optimize -- or Adapt
  3. Software Development Magazine V8n4(Apr 2000)pp80+78-79
  4. =DEBATE PROCESS PEOPLE

Constantine01

  1. Larry Constantine
  2. Managing Creative Input
  3. Software Development Magazine V9n1(Jan 2001)pp70-72
  4. =IDEA VISION REQUIREMENTS
  5. managers and marketers speak a different language to designers and developers - and this not a bad thing.
  6. Input is fantasy not SRS. Compile, sort, compare, combine, weigh.
  7. user roles.
  8. To bridge the gap use a role_support_matrix:
  9. role_support_matrix := ( ( capability | page) >< user_role ) -> importance.
  10. importance := -2 .. +2, prohibited .. necessary.
  11. Use cases are not features, but specific desired ways to use features and functions

Constantine01b

  1. Larry L Constantine
  2. Back to the Future
  3. Commun ACM V44n3(Mar 2001)pp126+128-129
  4. =ESSAY HISTORY QUALITY SOFTWARE
  5. Increased hardware power has permitted software to be developed without being engineered
  6. The result is that it doesn't work well and gives little extra value.

ConstantineLockwood99

  1. Larry L Constantine & Lucy A Lockwood
  2. Software for use: a practical guide to the models and methods of usage-centered design
  3. ACM Press/Addison-Wesley 1999 ISBN 0-201-92478-1 QA76.76.A65 C665 1999 CR9906-0400
  4. =HANDBOOK USER PURPOSES DESIGN METHOD MODEL CARDS SCENARIOS DOCUMENTATION HCI ERGONOMICS GRAPHICS PROTOTYPES
  5. models: {user role maps, essential use cases, use case map, focal use cases, low tech model, navigation map}
  6. 5 rules of usability:= {access, efficacy, progression, support. context }
  7. 6 principles of usability:= {structure, simplicity, visibility, feedback, tolerance, reuse }.

ConstantineLockwood02

  1. Larry L Constantine & Lucy A D Lockwood
  2. Usage-Centered Engineering for Web Applications
  3. IEEE Software Magazine V19n2(Mar/Apr 2002)pp42-50
  4. =EXPERIENCE =DEMO AGILE WWW/NET USECASE METHOD PROCESS CARDS
  5. Usage-centered design differs from user-centered design in using models(role, task, content), engineering to provide tools supporting user tasks.
  6. Process involves exploration and iteration.
  7. task cases: technology free essential abstract description of user's intentions and system's responsibilities.
  8. Content model aka abstract prototype based on several canonical forms: [ cannonical.pdf ]
  9. Navigation map connects interaction contexts.

ContedeLeonAlves-Foss06

  1. Daniel Conte de Leon & Jim Alves-Foss
  2. Hidden implementation dependencies in high assurance and critical computing systems
  3. IEEE Trans Software Engineering V32n10(Oct 2006)pp790-811
  4. =CASE STUDY FORMAL HA&CCS ARTIFACTS RELATIONS LOGIC PROLOG GRAPHIC IMPLEMENTATION ABSTRACTION GUAM DO-178B
  5. Pedantic theory leads to tool that found problems in software from traceability relations on "work product sections" (artifacts).
  6. Translation into MATHS
    Net
    1. artifact:Sets.
    2. implements: @(artifact,artifact) =given, indicates traceability between artifacts.
    3. |-STRICT_ORDER(strict_relation=>implements, artifact).
    4. l: artifact>->level =given, assigns a level to each artifact.
    5. <: @(level, level) =given.
    6. |-STRICT_ORDER(strict_relation=>(<), level).
    7. dependency: @(artifact, artifact) =goal.
    8. d := dependency.
    9. |- (conceptual_completeness): for x, y, z: artifact((if (x implements y and z) and l(x)<l(y)<l(z) then y d z) and (if (x and y implements z) and l(x)<l(y)<l(z) then x d y))

    10. STRICT_ORDER::= See http://csci.csusb.edu/dick/maths/math_21_Order.html#STRICT_ORDER


    (End of Net)

Conway63

  1. Malcolm E Conway
  2. Design of a Separable Transition Diagram Compiler
  3. Commun ACM V6n7(Jul 1963)pp396-408)
  4. =DEMO graphic non-sequential CO-ROUTINES
  5. Source for the 2 stars-> uparrow and cards to lines problem of Hoare.
  6. ChandyMisra88 pp185-190 (design without processes and channels by added them later)
  7. Knuth (V1.4.5 p226) writes that M E Conway invented co-routines in 1958.

Cook10

  1. Mary Rose Cook
  2. Creative Requirements Conversations
  3. IEEE Software Magazine V27n2(Mar/Apr 2010)pp90-91
  4. =ADVERT USER REQUIREMENTS ELICITATION ALTERNATIVE CODESIGN Uscreates
  5. Gathering requirements should be a creative conversation and so needs special environments and techniques.
  6. The Touring Cafe Caravan -- mobile space to collect requirements. Free refreshments...
  7. Speed modeling: 3d brainstorming, plasticine, ...
  8. Compare [Gottesdiener99] requirements workshops.

CookDaniels94

  1. S Cook & J Daniels
  2. Designing Object Systems
  3. Prentice Hall Upper Saddle River NJ 1994
  4. Syntropy

CookWolf98

  1. Jonathon E Cook & Alexander L Wolf
  2. Discovering Models of Software Processes from Event-Based Data
  3. ACM TOSEM V7n3(Jul 1998)pp215-249
  4. =ANALYSIS EXPERIENCE data mining neural nets DaGamma GRAMMAR FSM Markov

CookWolf99

  1. Jonathon E Cook & Alexander L Wolf
  2. Software Process Validation: Quantitive Measuring the Correspondence of a process to a model
  3. ACM TOSEM V8n2(Apr 1999)pp147-176
  4. =EXPERIENCE PROCESS vs SYSTEM Balboa Petri Net FSM/STD TOOL

Cooke06

  1. John Cooke
  2. Constructing Correct software(2nd edn)
  3. Springer 2005 QA76.76 ISBN 1-85233-820-2
  4. =INTRODUCTION MATHEMATICS LOGIC PROOF CORRECTNESS PROGRAMMING TECHNICAL
  5. compare with Bo Sandin's stuff in the 1980's and Huth & Ryan (textbook).

CookPodelskiRybalchenko11

  1. Byron Cook & Andreas Podelski & Andrey Rybalchenko
  2. Proving program termination
  3. Commun ACM V54n5(May 2011)pp88-98 [ 1941487.1941509 ]
  4. =DEMO MATHEMATICS TERMINATION LOGIC DISJUNCTIVE
  5. Instead of proving that the transition relation R is a sub-relation of a well-founded relation T:
  6. R==>T, One can try to prove that
  7. R^(1..*) ==> | [i:1..n] T[i], where each T[i] is well-founded.
  8. Claims that "Ramsey's Theorem" implies that only a finite collection of T's need be considered.
  9. Adding extra statements and assertions to the code can express termination as invariants. For example, to verify that a variable is decreasing but positive:
        assert( oldx > x && x > 0 );
        oldx:=x;
  10. Tools can then verify the invariants.
  11. Compare Andreas Blass and Yuri Gurevich. ACM Trans Comp Logic (Dec 2006) pp1-25 [ download?doi=10.1.1.146.4485&rep=rep1&type=pdf ]

CookeRushton09

  1. Daniel E Cooke & J Nelson Rushton
  2. Taking Parnas's Principles to the Next Level: Declarative Design
  3. IEEE Computer Magazine V42n9(Sep 2009)pp56-63
  4. =ADVERT SequenceL FUNCTIONAL LANGUAGE SERIAL PARALLEL
  5. Rediscovers APL and Lucid.
  6. (dick)|-almost like executable MATHS. For example, Σ( 1/((0..n)!) ) in MATHS looks like this
      sum(1/fact( [0,...,N]))
    in SequenceL.
  7. Compare [Holmes09]

CoomberChilds90

  1. CJ Coomber & RE Childs
  2. A Graphical Tool for the Prototyping of Real-Time Systems
  3. ACM SIGSOFT SEN V15n2(Apr 1990)pp70-82 DFDs prototyping STDs

CoombsRenearDeRose87

  1. James H Coombs & llen H Renear & Steven J DeRose
  2. Markup Systems and the Future of Scholarly Text Processing
  3. Commun ACM V30n11(Nov 1987)pp933-947
  4. =SURVEY MARKUP LANGUAGES
  5. SGML markup_forms::=none | presentational | procedural | descripitive | metamarkup |punctuational.

Cooper95

  1. Alan Cooper
  2. about face: the essentials of user interface design
  3. idg book foster city ca 1995 isbn1-56884-322-4 qa76.9 u83 c6 1995
  4. =MANUAL USER GUI

Cooper99

  1. Allen Cooper
  2. The Inmates are Running the Asylum
  3. Sams 1999, ISBN 0-672-31649-8
  4. =EXPERIENCE PEOPLE PROCESS ECONOMICS REQUIREMENTS =ADVERT interaction design USER PURPOSE QUALITY Scenarios
  5. goals persona cognitive friction thinking [ Cooper99.html ] [ persona in Cooper99 ]

CooperP07

  1. Peter Cooper
  2. Beginning Ruby: From Novice to Professional
  3. Apress Berkeley CA 2007 ISBN 1-59059-4 QA76.64 C667
  4. =TEXT Ruby LANGUAGE =REFERENCE

Coplien97

  1. James O Coplien
  2. Idioms and Patterns as Architectural Literature
  3. IEEE Software Magazine V14n1(Jan/Feb 1997)pp36-42
  4. =HISTORY

Coplien99

  1. James O Coplien
  2. Multi-paradigm Design for C++
  3. Addison Wesley Longman Reading MA 1999 ISBN 0-201-82467-1 CR9905-0317 CR9906-0404
  4. =DEMO DESIGN C++ METHODS OBJECT-ORIENTED DATA INHERITANCE

Coplien99d

  1. James O Coplien
  2. Reevaluating the Architectural Metaphor: Toward Piecemeal Growth
  3. IEEE Software Magazine V16n5(Sep/Oct 1999)pp 40-44
  4. =HISTORY ARCHITECTURE OBJECTS PATTERNS PEOPLE
  5. Growing systems piecewise in teams, uncovering architecture by growing system

CoplienDevos00

  1. James O. Coplien & Martine Devos
  2. Architecture as Metaphor
  3. Proc SCI/ISAS2000 VI pp737-??? [SCI00]
  4. =SURVEY ARCHITECTURE meeting grounded theory
  5. concepts: Change, Role Interaction, Structure, Economics, Constraints, Process, Professionalism
  6. Sample insites
    1. In buildings the clienbt is a slave to fashion but in software it is the architect.
    2. In buildings the architect shows the user interface to prospective clients and delegates the internals, in software the architect focusses on the internals and delegates the user interface!

CoplienSchmidt96

  1. J O Coplien & D C Schmidt
  2. Pattern Languages of Program Design
  3. Addison-Wesley Redwood City CA 1995(paperback) $39.76 ISBN 0-201-60734-4
  4. based on PLoP94 [ index.html ]

Corbato91

  1. Fernando J Corbato
  2. On Building Systems that Will Fail(Turing Award lecture)
  3. Commun ACM V34n9(Sep 1991)pp72-81
  4. CR9209-0696
  5. The questions to ask about ambitious systems are "what will go wrong" and what happens "when it does go wrong"
  6. p80 "Worse yet
  7. There is no way to simply 'look' at a system and determine what the privacy and security implications".

CorbettAvrunin94

  1. James C Corbett & George S Avrunin
  2. Towards Scalable Compositional Analysis
  3. SIGSOFT'94 Proc 2nd ACM SIGSOFT Symp on Foundations of Software Engineering & ACM SIGSOFT Software Engineering Notes V19n5(Dec 1994)pp53-61
  4. =THEORY =DEMO NONSEQUENTIAL MODEL CHECKING
      Predicting behavior of composition from behavior of parts, CCS-like model, Set of visible events, Events in pairs to comminicate, Uses integer programming to find feasible flows describing an event sequence that is a trace of both plus a single event such that the event sequence with the added event is a trace of one only.

      Tested on Message Router Problem and Two Slot Buffer Router problem studied in the 6th Intarnational Workshop on Software Specification and Design


Cordesetal91

  1. David Cordes & Marcus Brown
  2. The Literate-Programming Paradigm
  3. IEEE Computer V24n6(Jun 1991)pp52-61
  4. =ADVERT LITERATE

Cordova99

  1. Jose L Cordova
  2. Matheatical Proofs as Graph Search Problems in Theory Courses
  3. ACM SIGCSE Bulletin -- Inroads V31n1(Mar 1999)pp110-113
  4. =EXPERIENCE Teaching ANALYSIS

CormodeMuthukrishnan12

  1. Graham Cormode &S Muthukrishnan
  2. Approximating data with the count-min sketch
  3. IEEE Software Magazine V29n1(Jan/Feb 2012)pp64-69
  4. =ADVERT APPROXIMATE DATA STRUCTURE SKETCH count-min
  5. Can use a fixed number of fixed hash tables to store enough data to retrieve good approximate answers. to problem of the minimum counts. see also Bloom filter and AMS sketch...

CornelHorstmann98

  1. Gary Cornell & Cay Horstman
  2. Taking the Right Approach
  3. Software Development Magazine V6n6(Jun 1998)pp34-36+38+40-41
  4. =ARTICLE TECHNICAL Java RMI vs CORBA IDL
  5. Java smaller simpler and less general.

CorriganGurry94

  1. Peter Corrigan & Mark Gurry
  2. ORACLE Performance Tuning
  3. O'Reilly & Assoc 1993 ISBN 1-56592-048-1 Review p492 AMM May 1994
  4. =MANUAL data ENGINEERING database technique->quality

Cortellessa01

  1. V. Cortellessa & A. D'Ambrogio & G. Iazeolla
  2. Automatic derivation of software performance models from CASE documents
  3. Performance Evaluation V45n2-3 (Jul 2001) pp81-105 [ http://www.elsevier.com/ ] [CR] 0201-0025
  4. =DEMO QUALITY PERFORMANCE MODEL SCENARIO CASE UML Flowgraphs QUEUES LQN
  5. LQN::="Layered Queuing Network".
  6. (dick)|-sounds like modern version of SSADM physical design control.

Costagliolaetal95

  1. Genaro Costagliola & Genoveffa Tortora & Sergio Orefice & Andreas De Lucia
  2. Automatic Generation of Viusal Programming Environments
  3. IEEE Computer Magazine V28n3(Mar 1995)pp56-66
  4. =TOOL GRAPHIC PROGRAMMING
    1. positional grammars
    2. HOR and VER
    3. bibliography...
    4. Positional LR model
    5. Positional context free grammars

CortellessaPompei04

  1. Vittorio Cortellessa & Antonio Pompei
  2. Towards a UML profile for QoS:a contribution in the reliability
  3. WOSP'04 & ACM SIGSOFT Software Engineering Notes V29n1(Jan 2004)pp197-206
  4. =IDEA QUALITY reliability SPECIFICATION UML profile =EXAMPLE elevator.
  5. Gives rules mapping model into formulae for calculating reliability.

CortellessaEtal05

  1. Vittorio Cortellessa & Katerina Goseva-Postojanova & Kalaivani Appukkutty & Ajith R Guedin & Ahmed Hassan & Rania Alnaggar & Walid Abdelmoez & Hany H Ammar
  2. Model-Based Performance Analysis
  3. IEEE Trans Software Engineering V31n1(Jan 2005)pp3-20
  4. =DEMO REQUIREMENTS DESIGN QUALITY PERFORMANCE TIMING RISK PROBABILITY LOAD UML1.5 MODEL
  5. How to estimate the probability that a performance requirement will fail.

    For each scenario:

    1. assign demand vectors(CPU,Disk,network,...) to steps in sequence diagram; map to software execution model (=~= Activity diagram)
    2. Add hardware info to deployment diagram
    3. Devise workload parameters, map to execution model, contention analysis, est. Probability of violating timing
    4. Severity analysis
    5. Risk=severity * probability; identify high risk components.

  6. Estimate probability of failure at workload w, P(w) by linear interpolation from upper and lower bounds on throughput (l(w).. u(w)) and objective t. Assume l & u are monotonic increasing.
  7. If u(w0)=t then P(<=w0)= 0 and if l(w1) = t then P(>=w1) =1.
  8. For w: [w0..w1], P(w)= (u(w)-t)/(u(w)- l(w)).
  9. Research continued in [CortellessaPieriniRossi07]

CortellessaPieriniRossi07

  1. Vittorio Cortellessa & Pierluigi Pierini & Daniele Rossi
  2. Integrating software models and platform models for performance Analysis
  3. IEEE Trans Software Engineering V33n6(Jun 2007)pp385-401
  4. =DEMOs MODEL PERFORMANCE QUALITY TIMING UML-RT ANNOTATIONS RRT REAL TIME
  5. Shows how to model design + platform so that the system can be simulated.
  6. RRT::= "IBM-Rational Rose RealTime tool set", includes simulation.
  7. Simulations appear to fit actual system loads well.
  8. Note. Diagrams may be UML-RT but they are not UML1.* or UML 2.0. They use a non-standard conditional node.
  9. Continues [CortellessaEtal05]

CostagliolaEtal97

  1. Gennaro Costagliola & Andrea De Lucia & Sergio Orefice & Genoveffa Tortora
  2. A Parsing Methodology for the implementation of Visual Systems
  3. IEEE Trans SE V23n12(Dec 1997)pp777-799)
  4. =THEORY pLR GRAMMAR =DEMO TOOL VLCC compiler-compiler for graphic languages

CostagliolaDeufemiaPolese04

  1. Gennaro Costagliola & Vincenzo Deufemia & Giuseppe Polese
  2. A Framework for Modeling and Implementing Visual Notations with Applications to Software Engineering
  3. ACM TOSEM Trans Software Eng & Methodology V13n4(Oct 2004)pp431-487
  4. =DEMO THEORY GRAPHICS LANGUAGE GRAMMAR PARSING METACASE VLDesk XPG XpLR UML Statecharts
  5. XPG::="eXtended Positional Grammar", syntactic description of visual notations in terms of visual symbols (vsymbols), plus spatial relations generating visual sentences.
  6. Ontology of spatial relations:
    Net
    1. Relation = Connection | Geometric
    2. Plex ==>Graph==>Connection,
    3. String ==>Iconic==>Box==>Geometric.

    (End of Net)

  7. XpLR::=parsing method associated with XPG.
  8. VLDesk::tool, provides a "desk" where methodologists can develop CASE tools.

CostagliolaEtal05

  1. Gennaro Costagliola & Filomena Ferruci & Genoveffa Tortara & Giuliana Vitiello
  2. Class Point: an approach for the size estimation of Object-Oriented systems
  3. IEEE Trans Software Engineering V31n1(Jan 2005)pp53-74
  4. =EXPERIMENT ESTIMATION CODE SIZE LoC EFFORT FP IFPUG TUCP METRICS NEM NSR
  5. CP1::level= "Class Point 1", based on NEM and NSR (Methods and services requested).
  6. level::= (low, average, high).
  7. CP2::level= "Class Point 2", based on NEM, NSR, and NOA(attributes).
  8. TUCP::= "Totally Unadjusted Class Point",based on CP1 and CP2.
  9. |-TUCP=Sum [class_type c, level l]( weight[c, l] * number classes[c, l]).
  10. class_type::= problem_domain | human_interaction | data_management | task_management.
  11. CP::= "Class Point", based on TUCP and 18 technical factors.
  12. p71. fig 6. Form
  13. Significant correlation between CP1 and CP2

CostelloLiu95

  1. Rita J. Costello & Dar-Biau Liu
  2. Metrics for Requirement Engineering
  3. Journal of Systems and Software V29n1 (Apr 1995) pp39-63. Elsevier Science Inc. 655 Avenue of the Americas New York NY 10010.
  4. =ADVERT REQUIREMENTS METRICS
      See also first authors MS thesis

      requirements volatillity, tracebillity, specification completeness


CougerZawacki01

  1. D J Couger & R A Zawacki
  2. Motivating and Managing Computer Personel
  3. John Wiley 1980
  4. =POLL THEORY PEOPLE

CoulourisThimbleby93

  1. George Coulouris & Harold Thimbleby
  2. HyperProgramming: building interactive programs with HyperCard
  3. Addison-Wesley Reading MA 1993 ISBN 0-201-56886-1 CR9402-0062
  4. =TEXT APPLE HYPERTALK HYPERCARD VISUAL GRAPHIC PROGRAMMING

CounsellSwiftCrampton06

  1. Steve Counsell & Stephen Swift & Jason Crampton
  2. The Interpretation and utitlity of three cohesion metrics for Object-Oriented Design
  3. ACM TOSEM Trans Software Eng & Methodology V15n2(Apr 2006)pp123-149
  4. =THEORY Object-Oriented METRICS COHESION QUALITIES LCOM CAMC NHD SNHD
  5. Notes the lack of definition of OO cohesion comparedto Constantine and Myers definition for "structured" code in 1979.
  6. CAMC, NHD, and SNHD measure the extent that all methods in a class have similar signatures.
  7. (dick)|-does not refer to Larman's description and use of High Cohesion as a design pattern/principle using sequence diagrams [Larman04b].

CourageBaxter05

  1. Catherine Courage & Kathy Baxter
  2. Understanding your user: a practical guide to user requirements
  3. Morgan Kaufman SF CA 2005 ISBN 1-55860-935-0 QA76.9H85C69
  4. =HANDBOOK USER REQUIREMENTS
  5. comprehensive

Cousot90

  1. Patrick Cousot
  2. Methods and Logics for Proving Programs
  3. Chapter 15 (pp841..993) of Leeuwen90
  4. =THEORY Operational and relational semantics
      Studies relation between operational and relational semantics. Theorem 19(pages 856..858) proves that relational semantics imply operational with termination ignored. Angelic - Floyd non-determinsism and demonic - Dijkstra non-determinism being extreme cases in which operational can handle relational non-determinism. Refers to HoareLauer84, GreifMeyer81

Courte07

  1. Jill E Courte
  2. Comparing Student Acceptance and Performance of Online Activities to Classroom Activities
  3. Proceedings of the 8th ACM SIGITE conference on Information technology education (2007)pp185-190 [ 1324302.1324341 ]
  4. =EXPERIMENT ONLINE vs FACE-TO-FACE TEACHING EDUCATION JavaScript
  5. The average grades may be the same.... but the online students lose interest in the topic.

CowanDEtal02

  1. Robert D Cowan & Ali Mili & Hany Ammar & Alan McKendall Jr & Lin Yang & dapeng Chen & Terry Spencer
  2. Software Engineering Technology Watch
  3. IEEE Software Magazine V19n4(Jul/Aug 2002)pp123-129
  4. =THEORY TECHNOLOGY
  5. Distinguishes 3 kinds of research: Analytical, Empirical and Experimental.
  6. Many questions and theories but no results yet.

Cowanetal80

  1. Cowan & Graham & Welsh & Lucena
  2. A Data Directed Approach to Program Construction
  3. Software Practice & Experience V10 pp355-372
  4. =DEMO DDD graphic sequential

Cowanetal95

  1. Donald D Cowan & Carlos J P Lucena
  2. Abstract Data Views: An Interface specification Concept to enhance Design for Reuse
  3. IEEE Trans on Software Eng VSE-21n3(Mar 1995)pp229-243 CR9602-0126
  4. =DEMO ADO ADV OBJECT-ORIENTED REUSE ARCHITECTURE
      ADO - Abstract Data Object Rediscovering the value of separating the physical from the logical and one type of object from another, also from network...
           I/O      ADO
              \     / ||
              ADV1    ADV2
      MVC suggests use of dynamic objects!

      ADV2 are relations!

      Claims OMT is an modernized version of JSD!(RUBBISH)

      Quotes Kazman et al: Metaphors as first class objects.

      Reccommends developing graphic notations


Cox90a

  1. Brad C Cox
  2. There is a Silver Bullet
  3. BYTE V15n10(Oct 1990) pp209-218
  4. =HYPE Objected-Oriented

Cox90b

  1. Brad C Cox
  2. Planning the Software Industrial Revolution: The Impact of Object-Oriented Technologies
  3. IEEE Trans SE-15n11(Nov 1990)
  4. =HYPE Objected-Oriented

Cox01

  1. Brad J Cox
  2. Object-Oriented programming: an evolutionary approach
  3. Addison-Wesley 1987 QA76.9.S88C69 ISBN 0-201-10393-1
  4. =DEMOS MODULES UNIX C++ OBJECTIVEC

CoxA98

  1. Alan Cox
  2. Cathedrals, Bazaars and the Town Council
  3. Slashdot Features (0ct 1998)98/10/13 [ 1423253.shtml ]
  4. =EXPERIENCE OPEN SOURCE PROCESS 8086 Linux
  5. Why talk without code can be a problem with open source development
  6. Quote: Beware "We should", extend a hand to "How do I"...

CoxD01

  1. David Cox
  2. Parsing XML
  3. Dr. Dobbs #320(Jan 2001)pp96+98+100
  4. =DEMO XML PARSE TREE C++
  5. parsing a subset of UML in C++.

Craigenetal93

  1. Dan Craigen(dan@ora.on.ca) & Susan Gerhart(pl0183@mail.psi.net) & Ted Ralston(ralston@cli.com)
  2. An International Survey of Industrial Applications of Formal Methods
  3. 2 Vols National Technical Information Service Springfield Virginia 22161 1993 ( NIST GCR 93/626-V1 -V2 order PB93-178556/AS+PB93-178564/AS Microfiche: A02 $12.50+ A03/$12.50)
  4. =SURVEY FORMAL METHODS EXPERIENCE
  5. Long survey of twelve case studies of the use of formal methods in industrial projects. Volume 1 describes the purpose, approach, analysis, and conclusions of the survey; Volume 2 describes the case studies.
  6. CSR Gypsy B Statecharts Z*5 Cleanroom RAISE FDM HP-SL(VDM+??)

Craigenetal95

  1. Dan Craigen<dan@ora.on.ca> & Susan Gerhart<pl0183@psilink.com> & Ted Ralston
  2. Formal Methods Reality Check: Industrial Applications
  3. IEEE Trans SE-20n2(Feb 1995)pp90-98 CR9601-0215
  4. =EXPERIENCES FORMAL METHODS [GerhartCraigenRalston94]
      In Proceedings of Formal Methods Europe '93 (FME'93)}, Springer-Verlag, 1993. Also in {\it Transactions on Software Engineering, February 1995. .Abstract Based on a systematic survey and analysis of the use of formal methods in the development of twelve industrial applications, we summarize the methods being used, characterize the styles of industrial usage, and provide recommendations for evolutionary enhancements to the technology base of formal methods.

      The 12 industrial applications ranged from reverse engineering to system certification; code scale ranges from 1 KLOC to 10 KLOCS. Applications included a software infrastructure for oscilloscopes; a shutdown system for a nuclear generating station; a train protection system; an airline collision avoidance system; an engine monitoring system for shipboard engines; attitude control of satellites; security properties of both a smartcard device and a network; arithmetic units; transaction processing; a real-time database for a medical instrument; and a restructuring program for COBOL.}


CraigenMeiselsSaaltink99

  1. Dan Craigen & Irwin Meisels & Mark Saaltink
  2. Analyzing Z specifications with Z/EVES
  3. In [HincheyBowen99] pp255-283
  4. =DEMO SQA Z SPECIFICATION PROOF TOOL Z/EVES SWP
  5. demo on Sliding Window Protocol and a simple password/user system.
  6. Short and simple introduction to Z.

Crameretal94

  1. Joachim Cramer & Ernst-Erich Doberkat & Michael Goedicke
  2. Formal methods
  3. Schaferetal94 pp 79-111
  4. =THEORY REUSE FORMAL ALGEBRA SPECIFICATIONS
  5. Describes hierarchy of semantic models for algebraic specification, cf Lin93.

Cramm10

  1. Susan Cramm
  2. IT and Business Leaders: Getting Along Is Not Enough
  3. Harvard Business Review (Mar 3 2010) blog [ it-and-business-leaders-getting-along.html ]
  4. =POLL UNDERSTANDING INFORMATION TECHNOLOGY vs BUSINESS
  5. Thought that business does not understand IT well enough and IT doesn't understand business as well

Crawford90

  1. Diane Crawford
  2. National Software Needs: A Matter of Priorities
  3. "from Washington" Commun ACM V33n3 (Mar 1990)pp272-273
  4. =NEWS USA SOFTWARE

Creel99

  1. Chris Creel
  2. Requirements by Pattern
  3. Software Development Magazine V7n12(Dec1999)pp44-46
  4. =EXPERIENCE PATTERN REQUIREMENTS
  5. avoid overspecification by using: present|display, specify|locate, prioritize|sort, ...

CreveuilRoman94

  1. Christian Creveuil & Gruia-Catalin Roman
  2. Formal Specification and Design of a Message Router
  3. ACM Trans Softw Eng Methodol V3n4(Oct 1994)pp271-307 CR9512-0963
  4. =CASE-STUDY UNITY FORMAL NONSEQUENTIAL CASESTUDY
  5. Router problem studied in the 6th International Workshop on Software Specification and Design p304-305, Conclusions
    1. "It is better to specify and reason about a closed system - i.e. a system and its environment -- rather than an open one" ...

      "[A] critical element is the formulation of the top-level specification[...] focussing on I/O properties[...]selecting the "right" notation. [..] One does not stumble upon appropriate notation. Experience, exploration, and some looking ahead can provide the required insight. [...] True design, however, never makes such pretense[of being mechanistic]. Looking ahead and back-tracking are a part of the method. [...] selection of auxilary variables was one of the key decisions."

      "[...]small refinements proved helpful."

      "It was relatively easy to separate the formal treatment of the proofs from the refinement process itself. [... many trial refinements,...final design proved]. [...] design and verification can actually be carried out by different people."


Crispin06

  1. Lisa Crispin
  2. Driving software quality: how test-driven development impacts software quality
  3. IEEE Computer Magazine V39n10(Oct 2006)pp70-71
  4. =ADVERT TDD
  5. Quotes experience & pubs showing that writing tests first have many good effects on a project.

CRL

  1. See web site [ serg.publications.html ]
  2. Reports from theCommunications Research Laboratory of the Telecommunications Research Institute of Ontario(TRIO) McMaster University Hamilton Ontario Canada
  3. includes [Parnas92] + [Wang95] + [Janicki97]

CrnkovicSentillesVulgarakisChaudron11

  1. Ivica Crnkovic & Severine Sentilles & Aneta Vulgarakis & Michel R V Chaudron
  2. A classification framework for software component models
  3. IEEE Trans Software Engineering V37n5(Sep/Oct 2011)pp593-615
  4. =SURVEY TAXONOMY COMPONENT MODELS MODULES LIFE-CYCLE AUTOSAR BIP BlueArX CCM COMFES CompoNETS EJB Fractal Koala KobeA IEC 61131 IEC 61499 JavaBeans MS-COM OpenCOM OSGI Palladio PECOS Pin ProCom ROBOCOP RUBUS SaveCCM SOFA 2.0
  5. extra-functional-properties::=quality requirements.

CrowstonHowison06

  1. Kevin Crowston & James Howison
  2. Assessing the Health of Open Source Communities
  3. IEEE Computer Magazine V39n5(May 2006)pp89-91
  4. =EXPERIENCE =SURVEY OPEN SOURCE FLOSS SOCIOGRAM
  5. Assess the stage in the life cycle, the size, and the shape of the community.
  6. 10 is about the mode for size.
  7. Mature groups are structured in shells like an onion.
  8. Growing community means more time spent synchronizing -- many projects don't make it past the "one developer=user" stage.
  9. Has the community survived the transition in the leadership -- e.g. founders becoming inactive?
  10. Who provides the infrastructure (a necessary but boring function)?

CrowVito98

  1. Judith Crow & Ben Di Vito
  2. Formalizing Space Shuttle Software Requirements: Four CASE Studies
  3. ACM TOSEM V7n3(Jul 1998)pp215-249
  4. =ANALYSIS EXPERIENCE [PVS] GPS RAPID FORMAL LOGIC TABLE MATH MurΦ
    1. Where do states come from, shared variables used as input/output.
    2. Large number of errors discovered (early) just by formalizing requirements without checking!
    3. Need for readymade math theories: eg properties of mappings!
    4. Failed proofs are more help than successful ones.
    5. Specification is iterative.
    6. Need to specify constraints found in the problem domain.
    7. Can simplify model: remove continuous values and time and remove costraints. Therefore check some impossible states
    8. Tailor formal methods to the situation.

CSSyllabus92

  1. Computer Science Syllabus
  2. Summer 1992
  3. Syllabus Press Sunnyvale California<syllabus@applelink.aplle.com>
  4. =HISTORY Kay Object-Oriented education

CSTB'89

  1. National Research Council's Computer Science and Technology Board
  2. Scaling Up: A Research Agenda for Software Engineering
  3. Excerpts -Commun ACM V33n3(Mar 1990)pp281-293 & Full Report - National Acad Press Wa. D.C.
  4. =handbook harmful RISKS

CubranicMurphySingerBooth05

  1. Davor Cubranic & Gail C Murphy & Janice Singer & Kellog S Booth
  2. Hipikat: A Project memory for Software Development
  3. IEEE Trans Software Engineering V31n6(Jun 2005)pp429-526
  4. =ADVERT TOOL EVOLUTION DOCUMENTATION WWW EMAIL CVS BUGZILLA Hipikat tool analyzes artifacts gathered in Eclipse development and provides readings to newcomers with maintenance tasks.

CugolaNitoEtal96

  1. Giampaolo Cugola & Elizabetta di Nitto & Alfonso Fuggetta & Carlo Ghezzi
  2. A Framework for Formalizing Inconsistencies and Deviations in Human-centred Systems
  3. ACM TOSEM V5n3(Jul 1996)pp191-230
  4. =THEORY USER REQUIREMNTS FORMAL Z: REALITY vs SYSTEM PETRIE GRAPHICS

CugolaDiNottiFuggetta01

  1. Gianpaolo Cugola & Elisabetta Di Notti & Alfonso Fuggetta
  2. The JEDI Event-Based Infrastructure and its application to the development of the OPSS WFMS
  3. IEEE Trans Software Engineering V27n9(Sep 2001)pp827-850
  4. =DEMO ARCHITECTURE NET JAVA JEDI OPSS WORKFLOW lifecycle regular expressions ORCHESTRA TWIST IETF TIMING latency =SURVEY
  5. JEDI_architecture::=decouple objects by passing events to a centralized or distributed dispatcher that notifies subscribed objects using a hierarchical strategy.
  6. stateServer -- handles FSMs that define admissible sequences of events.

Cukic05

  1. Bojan Cukic
  2. The virtues of assessing reliability early
  3. IEEE Software Magazine V22n3(May/Jun 2005)pp51-53
  4. =ADVERT COMPONENTS QUALITIES RELIABILITY PREDICTION UML MODEL USE CASES SEQUENCE DEPLOYMENT TOOL beta-distribution Monte Carlo ECRA
  5. ECRA::= "extended component-based reliability assessment".
  6. See cukic@csee.wvu.edu.

CunhaGreathead07

  1. Alessandra Devito Da Cunha & David Greathead
  2. Does Personality Matter? An Analysis of code-review ability
  3. Commun ACM V50n5(May 2007)pp109-112
  4. =EXPERIMENT 64 PEOPLE INSPECTION CODE TECHNICAL MBTI DEBUGGING
  5. Used the Myers-Briggs Type Indicator (MBTI) to classify students vs their skill at finding bugs in code.
  6. iNtuitive+Thinking people do significantly better at finding bugs in code than iNtuitive+Feeling, Sensing+Thinking, and Sensing+Thinking types.

Curtis01

  1. Tex(Bill) Curtis
  2. So you Wanna Be a cowboy
  3. IEEE Software Magazine V18n2(Mar/Apr 2000)pp122+110-111
  4. =ARTICLE PEOPLE
  5. cowboys: work long hours alone, never admit uncertainty, ignores bureaucracy, no time for family, takes on any challenge.
  6. death marches and cattle drives,
  7. Unique skills
  8. branding irons and copyrighting code.
  9. projects and cattle drives.
  10. But cowboys need discipline and teamwork - think stampede. Call the rowdy programmer a maverick!

CurtisKellnerOver92

  1. Bill Curtis & Marc I Kellner & Jim Over
  2. Process Modeling
  3. (Special Issue: Modeling) Comm ACM V35n9(Sep 1992)pp75-90
  4. =SURVEY MODEL PROCESS

CurtisKrasnerIscoe88

  1. B Curtis & H Krasner & N Iscoe
  2. A Field Study of the software design process for large systems
  3. Commun ACM V31n11(Nov 1988)pp1268-1287
  4. =POLL EXPERIENCE 17 LARGE PROJECTS DESIGN
  5. Problems: not enough domain knowledge, fluctuating and conflicting requirements, and Communication.
  6. "Writing code isn't the problem, understanding the problem is the problem."
  7. "Planned is probably a generous term . . . . an englightenment occurs as they move forward."
      refed to in [KrautStreeter95] [Maiden90a]

Cusumano04

  1. Michael A Cusumano
  2. Who is Liable for Bugs and Security Flaws in Software
  3. Commun ACM V47n3(Mar 2004)pp25-27
  4. =NEWS =ARTICLE SECURITY RISKS LEGAL Microsoft
  5. Oct 2003: NYTimes reports lawsuit in California vs Microsoft.
  6. Software companies are liable for flaws. Some are better than others at detecting and fixing defects. None are 100% successful.
  7. Most if not all networked software have had security flaws. What is acceptable?
  8. So why was Microsoft sued?

Cusumano07

  1. Michael A Cusmano
  2. What Road Ahead for Microsoft the Company
  3. Commun ACM V50n2(Feb 2007)pp15-18
  4. =ARTICLE ECONOMICS Microsoft vs OPEN SOURCE WEB/NET
  5. Rivals use new business model: use fee but pay for support and enhancements. Rather than pay for licence and upgrades.
  6. Challenge of breaking up monolythic code.
  7. Challenges of changing top management.

Cusumano07b

  1. Michael A Cusumano
  2. The Changing Labyrinth of software pricing
  3. Commun ACM V50n7(Jul 2007)pp19-22
  4. =NEWS ECONOMICS PRICES
  5. Notes a shakeout in software producers in last 10 years.
  6. Reports his students MS work (S Nayak, Pricing and licensing of software products and services: A study of industry trends", MIT MS Thesis Sys Des & Man Program MIT, May 2006)
    1. software_pricing::=
      Net{
        licence:Licence_options, time:Licence_term, type:Installation_types, payment:Payment_methods, term:Terms_and_compliance, flex:Flexibility}.
      1. Licence_options::=individual | group | concurrent | enterprse | site.
      2. Licence_term::= 0..1.year | annual | 3 years | perpetual.
      3. Installation_types::= designated computer | standalon named user | network named user | concurrent user.
      4. Payment_methods::= up_front | pay_as_you_go | financed.
      5. Terms_and_compliance::=shrink_wrap | contract | dongled | activation.
      6. Flexibility::= product specific | product agnostic | remix.

    2. Also variations on free software: free razor + paid_for_blades, free software + paid_for_services, free software + advertizing.

    Cusmano07c

    1. Michael A Cusumano
    2. Extreme Programming compared with Microsoft-Style Iterative Development
    3. Commun ACM V50n10(Oct 2007)pp15-18
    4. =ESSAY XP Microsoft ITERATION HP WATERFALL
    5. Useful comparison

    Cusumano08

    1. Michael Cusumano
    2. Technology Strategy & Managment: The Puzzle of Apple
    3. Commun ACM V51n9(Sep 2008)pp- [ 1378727.1378736 ]
    4. =ESSAY ECONOMICS PRODUCTS vs PLATFORMS
    5. MS tends to create platforms that encourage other businesses to get involved.
    6. Apple prefers a closed but higher quality (and higher priced) product.
    7. Comparison with Betamax vs VHS.

    CusumanoMaccormackKemererCrandall03

    1. Michael Cusumano & Alan Maccormack & Chris F Kemerer & Bill Crandall
    2. Software Development worldwide: The State of the practice.
    3. IEEE Software Magazine V20n6(Nov/Dec 2003)pp28-34
    4. =POLL 104 PROJECTS INTERNATIONAL PRACTICES ONESIZE
    5. LOC productivity about the same as 10 years ago. lowest = India <US < Europe etc < Japan = most.
    6. Defect rates have improved. worst US > India > Europe etc > Japan.
    7. Certain clusters of practices work better than others: for example, iterative development with beta testing works as well as waterfall with complete specification.
    8. See [CusumanoMaccormackKemererCrandall03]

    CusumanoMaccormackKemererCrandall09

    1. Michael A Cusumano & Alan MacCormack & Chris F Kemerer & William Crandall
    2. Critical Decisions in Software Development: Updating the State of the Practice
    3. IEEE Software Magazine V25n5(Sep/Oct 2000)pp84-87
    4. =SURVEY PROCESS MANAGEMENT waterfall vs agile ONESIZE QUALITIES
    5. Revisits [CusumanoMaccormackKemererCrandall03] showing a wide range of processes and qualities.
    6. One size does not fit all.
    7. Must choose a process to fit the situation.
    8. Distributed development gives rise to a more modular structure and needs special learning to pay off.
    9. A rigid process can give higher quality but at risk of loosing innovative products.

    CusumanoSelby95

    1. Michael Cusumano & Rick Selby
    2. Microsoft's Secrets: How the world's most powerful software company creates technology& shapes markets & and manages people
    3. Simon & Schuster September 1995
    4. =REPORT MICROSOFT PROCESS PEOPLE MS-PROCESS AGILE
    5. See also [Keuffel95b] , [Bond95] , [MyersW95] , and an extract in [CusumanoSelby97]
    6. For a view of the later Microsoft proceesses, see [ Cusumano06 ]
    7. Key observations:
        MS objective was to quickly and cheaply establish and dominate a market and become de facto standards

        Scale up hacker culture to many small concurrent teams with frequent synchronisation and periodic stabilization. Aim to "Grow" rather than Design Software.

      1. Process::= Planning;Development;Stabilization,
      2. Planning::=Vision;Spec;Organize,
      3. Development::=(vision&spec&design&tests evolve and grow in parallel)&(first1/n; second1/n; third1/n; ...),
      4. n in {3,4}. each_1/n::=code&test&stabilise_features; integrate&test&debug;BUFFER time.
      5. Frequent synch/daily build.
      6. Stabilization::=Internal test; external test; Prepare for release.
      7. Fixed dates and multiple releases
      8. Continuous customer feedback
      9. Aim: large teams work like small ones.

        Focus on the production of code (not design vs documentation). Minimal optional high level architectures. Some implementation decisions (data structures) may be documented. "One document. One. It's the Source code."

        Costs:1 tester for each developer PLUS >1 customer-support engineer per developer


    8. Also Warren Keuffel's notes [ notes/Keuffel95b.html ] on Cusmano's talk at ICSE 1995.

    CusumanoSelby97

    1. Michael A Cusumano & Richard W Shelby
    2. How Microsoft Builds Software
    3. Commun ACM V40n6(Jun 1997)pp53-61 CR9711-0916
    4. =ADVERT [CusumanoSelby95]

    CusumanoYoffie98

    1. Michael A Cusumano & David B Yoffie
    2. Competing on Internet Time
    3. Free Press (Simon & Shuster) NY NY 1998 ISBN0-684-85319-1 HD9696.65.U64N473
    4. =EXPERIENCE ECONOMICS PEOPLE PROCESS Netscape
      1. Part in Commun ACM V42n10(Oct 1999)pp??-??
      2. Note: Confirming instance of theories in [Botting97a]
      3. Internet implied a changing situation but Internet time does not last for ever!
      4. Andreesen claims his processes are based on rejecting processes he had seen bog down while an intern in IBM: trying to finish a perfect product before delivering anything.
      5. Initially stressed innovation and time to market, later needed to add reliability and architecture to enter corporate market.
      6. Netscape and MS avoid researching new technologies "Rocket science" in favor of exploiting other people's inventions.
      7. Many at Netscape Equated SQA with testing! To increase quality, hire more testers!
      8. As with MS, avoid checkout;lock;checkin delays by frequent builds to detect incompatibilities. Synchronize and Stabilize also IEEE Computer Magazine V32n10(Oct 1999)pp60-69.
      9. Parallel development of several releases at one time.
      10. Dynamic specifications, time-boxed milestones, and multiple Betas.

    Cutkoskyetal96

    1. Mark R Cutkosky & Jay M Tenenbaum & Jay Glicksman
    2. Madefast: Collaborative Engineering over the Internet
    3. Commun ACM V39n9(Sep 1996)pp78-87
    4. =TOOL DISTANCE ENGINEERING
    5. Engineering Web: problems to solve security+standards+interactivity+organising site+people [ ACM_paper.html ]
    6. ENGINEERING documents are a mixture of formal and informal information

    Cutts88

    1. Geof Cutts
    2. Structured Systems Analysis and Design Methodology
    3. Van Nostrand Reinhold NY NY 1988
    4. =TEXT SAD ERD(cow format) DFD DAD(using std not ELH) SSADM PQRST

    CybulskiReed92

    1. Jacob L Cybulski & Karl Reed
    2. A Hypertext Based Software Engineering Environment
    3. IEEE Software V9n2(Mar 1992)pp62-68
    4. =ADVERT HyperCASE

    CysneirosLeite04

    1. Luiz Marcio Cysneiros & Julio Cesar Sampaio do Prado Leite
    2. Nonfunctional Requirements: from elicitation to Conceptual models
    3. IEEE Trans Software Engineering V30n5(May 2004)pp328-350
    4. =CASESTUDY operational QUALITIES REQUIREMENTS NFR UML LEL CR 0504-0459
    5. NFR::="Nonfunctional Requirement".
    6. LEL::= "Language Extended Lexicon", project glossary.
    7. NFR_graph::lattice, mapped to class diagrams etc..
    8. Figures have spelling mistakes & they ignore UML stereotypes & tags.
    9. Can not handle Qs like maintainability that "do not demand actions to be performed by the system".

    D'Souza93

    1. Desmond F D'Souza
    2. A Comparison of Object-Oriented Analysis and Design Methods and Application Domains
    3. OOPSLA 1993 Tutorial Notes # 2 ACM PRESS
    4. =SURVEY METHODS OBJECT-ORIENTED
        covers OMT (Rumbaugh), Shlaer and Mellor, Booch, Objectory(Jacobson), Fusion, de Champeaux/Lea/Faure Wirfs-Brock, Martin-Odell, Embley-Kurtz-Woodfield

    D'Souza98

    1. Desmond D'Souza
    2. Interface-Centric Design
    3. Software Development Magazine V6n6(Jun 1998)pp43-44+46-47
    4. =ADVERT for UML book [D'SouzaWills98]
    5. type models describe vocabulary
    6. collaborations via interfaces
    7. patterns

    D'SouzaWills98

    1. Desmond D'Souza & Alan Willis
    2. Objects, Components, and Frameworks with UML: the CATALYSIS approach
    3. AddisonWesleyLongman Reading MA 1999 ISBN 0-201-31012-0 CR9903-0146
    4. =EXAMPLES OOA/D UML CATALYSIS

    DAmbrosLanzaLungu09

    1. Marc D'Ambrose & Michele Lanza & Mircea Lungu
    2. Visualizing co-change information with the evolution radar
    3. IEEE Trans Software Engineering V35n5(Sep/Oct 2009)pp720-735
    4. =TOOL GRAPHIC EVOLUTION MODULE CHANGE CVS Java PACKAGES FILES
    5. The image shows a central module and all the other modules surrounding it.
    6. A Module is a slice of the pie and contains files.
    7. The files are shown as circles with size proportional to the degree of change.
    8. Their angle of a file is determined by their name with in each module.
    9. Their distance depends on the degree that they are changed at the same time as the central module.
    10. Relies on a revision /configuration control system that records all changes in time.
    11. Tested on one maintenance project.

    DaCapo08

    1. Stephen M Blackburn & Kathryn S McKinley & Robin Garner & Chris Hoffman & Asjad M Khan & Rotem Bentzur & Amer Diwan & Daniel Feinberg & Daniel Frampton & Samuel Z Guyer & Martin Hirzel & Antony Hosking & Han Lee & J Eliot & B Moss & Aashish Phansalkar & Darko Stefanovic & Thoms VanDrunen & Daniel von Dineklage & Ben Wiedemann
    2. Wake Up and Smell the Coffee: Evaluation methodology for the 21st century
    3. =ADVERT JAVA BENCHMARKs PERFORMANCE METRICS
    4. Commun ACM V51n8(Aug 2008)pp83-89 [ 1378704.1378723 ]
    5. Developing a useful benchmark is time consuming.
    6. Using them needs understanding of relevant workloads, good experimental design, and rigorous analysis.
    7. Benchmark research is underfunded.

    DagRegnellGervasiBrinkkemper05

    1. Johan Natt och Dag & Bjorn Regnell & Vincenzo Gervasi & Sjaak Brinkkemper
    2. A Linguistic-Engineering Approach to Large-scale requirements Management
    3. IEEE Software Magazine V22n1(Jan /Feb 2005)pp32-39
    4. =IDEA LANGUAGE SIMILARITY DOCUMENTATION RETRIEVAL REQUIREMENTS Map documents into vector space and use cos(angle) to measure matches when ret rieving. Use log functions to scale the frequency of occurrence of words (formula is su spect)
    5. Applied to matching market requirements to business requirements.

    DahlbomMathiassen97

    1. Bo Dahlbom & Lars Mathiassen
    2. The Future of Our Profession
    3. Commun ACM V40n6(Jun 1997)pp80-89
    4. =SURVEY of literature re ENGINEER: artifact(build) vs Culture(help/evolve) vs Power(change). Machanistic vs Romantic. Leads to a new curriculum stressing what RJB calls ANALYSIS POSTMODERN

    Dahletal72

    1. O Dahl & E W Dijkstra & C A R Hoare
    2. Structured Programming
    3. Ac Press NY NY 1972
    4. =TEXT sequential non-sequential PURPOSE Technical
    5. Once called "The Old Testament".

    DaiXieLongNg07

    1. Yuan-Shun Dai & Min Xie & Quan Long & Szu-Hui Ng
    2. Uncertainty Analysis in Software Reliability modelling by Bayesian Approach with Maximum-Entropy Principle
    3. IEEE Trans Software Engineering V33n11(Nov 2007)pp781-795
    4. =THEORY PROBABILITY RELIABILITY PREDICTION
    5. Problems: few tests fail, inorporating prior information, allowing uncertainty in modelling to reduce reliability.
    6. MEP::= "Maximum-Entropy Principle", choose an a prior distribution to maximize the entropy given the known data.
    7. For distribution p, entropy(p):= E(-ln(p(_))).
    8. Use Bayesian a postiori formula to encorporate data from tests.
    9. Use simulation and analysis to predict relibilities of whole system.
    10. Gives examples.
    11. Refers to texts for calculations of MEP.

    DalaKamathKolarikSivaraman04

    1. Nikuni P Dala & Manjunath Kamath & WilliamJ Kolarik & Eswar Sivaraman
    2. Toward an Integrated Framework for Modeling Enterprise Process
    3. Commun ACM V47n3(Mar 2004)pp83-86
    4. =ADVERT BUSINESS PROCESS MODELLING IMPROVEMENT ERP EPML XML Petri Analysis TED
    5. Need to model/implement distributed.
    6. Need for process semantics.
    7. Need to link business and enginering.
    8. Graphic front-end(EPML) <->XML<-> formal Back-end. Analise back end.
    9. NSF Scalable Enterprise Systems Initiative.
    10. EPML::="Enterprise Process Modelling Language".
    11. Graphic showing: activities (Human, Computer, Machine), logic and decision logic, data icons, control flows , (input, output)><( material, data), timing triggers.
    12. TED::="Task Execution Diagram". Analysis petri nets: design (termination, deadlock, safety) + performance (resource assignment, simulation, timing, success vs time statistics)

    DalalMcIntosh94

    1. Siddhartha R Dalal & Allen A McIntosh
    2. When to stop Testing for Large Software Systems with Changing Code
    3. IEEE Trans SE-30n4(Apr 1994)pp318-323
    4. =THEORY ECONOMIC TEST MAINTENANCE
        Applied stochastic and economic theory to a particular project to calculate the optimum time to stop testing the new product. The figures for a large piece of telecommunications software are worth quoting - the final product had roughly 7 million lines of code (not counting comments) and during testing 342,358 lines where changed. The testing took roughly 1,300 staff hours and 870 faults were uncovered and fixed. Their model estimates that that the expected number of faults remaining is 145 and is in a Poison distribution. The testing process stopped because it had become too expensive to continue testing to find the 100 bugs remaining. They point out that system testig had removed 21 out of every 25. However they feel that having 25 faults in every 10000 lines of code "may be too high" and that "It may be that something can be done about it"(p323)

    DamasLambeauDupontLamsweerde05

    1. Christophe Damas & Bernard Lambeau & Pierre Dupont & Axel van Lamsweerde
    2. Generating Annotate Behavior Models from End-User Scenarios
    3. IEEE Trans Software Engineering V31n12(Dec 2005)pp1056-1073
    4. =DEMO INTERACTIVE TOOL SCENARIOS MODEL MSC LTS FLUENTS use-cases
    5. Given positive and negtive scenarios (sequence charts) the system asks questions in the form of scenarios.
    6. It then generates a state-based model to fit all the scenarios. It uses fluents and grammar induction to create a Labeled Transition System (LTS) that fits the scenarios and annotates each state with fluents. The fluents provide a meaningful interpretation of the state.
    7. Fluents have a name, start and end events, and an initial value. Booleans. Example: doorOpen. [GiannakopoulouMagee03]

    DamianChesan06

    1. Daniela Damian & James Chesan
    2. An empirical study of the complex relationships between requirements engineering processes and other processes that lead to payoffs in productivity, quality, and risk management
    3. IEEE Trans Software Engineering V32n7(Jul 2006)pp433-453
    4. =EXPERIENCE REQUIREMENTS PROCESS IMPROVEMENT ACUS
    5. Evidence that collaborative and iterative analysis and negotiation of requirements into testable scenarios improves estimates and quality.
    6. Evidence that change management reduces requirements creep.
    7. Important contributions from forming cross-functional teams, group-analysis, traceability, and decomposition.

    DamianEberleinShawGaines00

    1. Daniela E Herlea Damian & Armin Eberlein & Mildred L G Shaw & Brian R Gaines
    2. Using different communications media in requirements negotiation
    3. IEEE Software Magazine V17n3(May/Jun 2000)pp28-36
    4. =EXPERIMENT REQUIREMENTS PEOPLE ORGANISATION
    5. 2 conflicting customers + 1 systems analyst + 1facilitator
    6. face to face is not the best!
    7. don't put all your customers in one room.

    DamianiEtal06

    1. Ernesto Damiani & Brian Fitzgerald & Walt Scacchi & Marco Scotto & GianCarlo Succi
    2. Open source systems: IFIP Working Group 2.13 Foundation Conference on Open Source Software, June 8-10, 2006, Como, Italy (IFIP International Federation for Information Processing)
    3. Springer-Verlag New York, Inc., Secaucus, NJ, 2006.
    4. =PROCEEDINGS HISTORY OPEN SOURCE F/OSS PROCESS PSYCHOLOGY ECONOMICS SOCIOLOGY USAGE CR 0802-0110
    5. Academic.
    6. F/OSS projects are not chaotic but self organizing. A mature project is a collection of groups of people who work together. Face-to-face friendships influence the makeup of groups. The 'onion' model: a permanent, small, elite core of developers with recognizable subgroups.
    7. Outer layers of a project are transient debugging groups that stay together as they move from project to project.
    8. Prestige comes from sharing information like in scientific research.

    DamianiFuginiBelletini99

    1. E Damiani & M G Fugini & C Belletini
    2. A Hierarchy-Aware Approach to Faceted Classification of Object-Oriented Components
    3. ACM TOSEM V8n3(Jul 1999)pp215-262 + Corrigenda V8n4(Oct 1999)pp425-472
    4. =TOOL REUSE COMPONENT FRAMEWORK OBJECT-ORIENTED Isa MFC C++ Borland Delphi Facetted descriptors

    DamonJacksonJha96

    1. Craig A Damon & Daniel Jackson & Somesh Jha
    2. Checking Relational Specifications With Binary Descision Diagrams
    3. Proc 4th ACM SIGSOFT 96 Symp on the Foundns of Software Eng: ACM SIGSEN V21n6(Nov 1996)pp70-80
    4. =DEMO MODEL CHECKING BDDs
    5. Z-like specs checked via testrolog-type diagrams
    6. BDDs::=Binary Decision Diagrams

    Daneva04

    1. Maya Daneva
    2. ERP Requirements Engineering Practice: Lessons Learned
    3. IEEE Software Magazine V21n2(Mar/Apr 2004)pp26-33 +CR 0705-0527
    4. =EXPERIENCE REQUIREMENTS reuse ASAP ERP
    5. 13 lessons learned mainly reinforcing known results!
    6. cooperation win-win team communication learning are good
    7. reuse needs management: query assumptions, analyze risks, plan, do, measure...
    8. need data modeling
    9. lookout for unofficial requirements leaking into project.

    DanforthTomlinson88

    1. S Danforth & C Tomlinson
    2. Type Theories and Object Oriented Programming
    3. Comp Surveys V20n1 (pp29-72)Mar 1988
    4. =THEORY object-oriented logic Reality

    DangleLarsenShawZelkowitz05

    1. Kathleen Coleman Dangle & Patricia Larsen & Michele Shaw & Marvin V Zelkowitz
    2. Software Process Improvement in Small Organizations: A Case Study
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp68-75
    4. =CASE STUDY DSCS CMM
    5. (dick)|-when does software process improvement merge into business process reengineering?
    6. (dick)|-Rediscovers some trad systems analysis and design ideas.
    7. Discoveries:
      • Processes and process improvement should address business goals not just CMM dogma,
      • Choose the sequence of improvements to support needs not CMM KPAs.
      • TANSTAAFL: Improvement needs resources.
      • Test proposed improvements on selected projects and change them before expanding enterprise-wide.
      • Ongoing activities should drive the plans for introducing new processes.
      • Start formal reviews immediately to provide feedback to stakeholders.
      • Divide improvements up and delegate.
      • Assess experience with software processes and SP improvement.

    Daniels02

    1. John Daniels
    2. Modeling with a sense of Purpose
    3. IEEE Software Magazine V19n1(Jan/Feb 2002)pp8-10
    4. =ESSAY MODELs REALITY SPECIFICATION TECHNICAL UML
    5. Three types of model: World/conceptual, Specification, Implementation
    6. Maps UML notations to types of model (eg UseCase-> spec)
    7. Proposes using three UML stereotypes: <<concept>>, <<type>>, <<class>>

    DanoBriandBarbier97

    1. Benedicte Dano & Henri Briand & Frank Barbier
    2. An Approach Based on the Concept of Use Case to Produce Dynamic Object-Oriented Specifications [RE'97] p54-64
    3. petri-nets

    DarcyKemerer05

    1. David P Darcy & Chris F Kemerer
    2. OO metrics in Practice
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp17-19
    4. =ADVERT =SURVEY CK METRICS Object-Oriented

    Dasgupta89

    1. Subrata Dasgupta
    2. The Structure of Design Processes
    3. pp1-62 of Yovitz(ed)89
    4. =THEORY ENGINEERING lifecycle=scientific discovery

    Darwiche10

    1. Adnan Darwiche
    2. Bayesian Networks
    3. Commun ACM V53n12(Dec 2010)pp80-90 [ 1859204.1859227 ]
    4. =ADVERT BAYES PROBABILITY NETWORK CAUSALITY BBN HMM HIDDEN MARKOV
    5. Good description of the theory, practice, and possibilities of Bayesian models.
    6. Source [Pearl88]

    Dasgupta91

    1. Subrata Dasgupta
    2. Design Theory and Computer Science: Processes and Methodology of Computer Systems Design
    3. Cambridge U Press NY NY 1991(Tracts in theoretical Comp Sci)
    4. =THEORY ENGINEERING methodology
    5. Reviews: CR9207-0475
    6. Am Math Monthly V100n4(Apr 1993) page 423
        Note -- best study of design and science so far

        systems always change[pp128-129].

        engineering uses a similar process but has different aims to scientific discovery[pxvii, p8, pp353ff...]

        Need formal requirements, feedback implementation & design to requirements[p170].

        compilers [pp324-331], PR vs T = functional vs implementation requirements(p165)

        multiple constraints[pp234-237,249-253,272-276]

        scientific method: conceptual problems->change, many design methods,

        1.3 Intractabillity,

        1.5 designs are Hypotheses [ch12]

        layout problems intractable pp73-74

        Plausibility documents reasons, evidence, and evolution of documentation [chapter 9]

        software=hardware, Simon, complexity of design paradigms: ASE synthetic rule-based algorithmic... plausibillity,

        Pearce, Kuhn, Popper,...

      1. plausibility::={undetermined, assumed, validates, refuted}.

    Dashboard08

    1. Project Dashboard Initiative
    2. Project Dashboard
    3. Sourceforge [ http://processdash.sourceforge.net/ ]
    4. =UNTESTED =TOOL PSP TSP GRAPHIC MANAGEMENT DEFECTS QUALITITES ESTIMATION
    5. Notes [click here [socket symbol] if you can fill this hole]

    Date00

    1. Christopher J Date
    2. What not how: the business rules approach to application development
    3. Addison-Wesley Longman Boston MA 2000 pp131 $24.95 ISBN 0-201-70850-7 CR0011-0557 H.2.0 qa76.76 a65 d375 2000
    4. =ADVERT RULES SQL LOGIC LPC TABLES

    DateDarwen06

    1. Christopher J Date & Hugh Darwen
    2. Databases, Types, and the Relational model
    3. Addison Wesley Longman Publishing Co, Inc., Redwood City, CA, 2007
    4. =THEORY DATA Rejects SQL. Back to Codd.

    DateFagin92

    1. C J Date & Ronald Fagin
    2. Simple conditions for guaranteeing higher normal forms in relational databases
    3. ACM Trans Database Systems V17n3(Sept 1992)pp465-476
    4. =THEORY DATA NORMALIZATION 5NF 4NF PJ/NF(Projection-join)

    DatteroGallup04

    1. Ronald Dattero & Stuart D Gallup
    2. Programing Language and Gender
    3. Commun ACM V47n1(Jan 2004)pp99-102
    4. =POLL 37398 PEOPLE LANGUAGES GENDER COBOL Java C++ SQL HTML
    5. Roughly 80/20 male/female split.
    6. Experience:= distribution (..1.yr +> 11%, 1..2.yr+>16%, 3..5+>33%, 6..10+>20%, 11..14+>8%, 15.yr.. +>12%)
    7. Languages:=(HTML+>36%, SQL+>29%, VB+>23, JavaScript+>23%, Java+>18%, C +>17%, "C++"+>16%, Oracle+>13%, ASP+.13%, Perl+>11%, ActiveX+>10%, Basic+>9%, "VisualC++"+>9%, OOP+>8%, COBOL+>7%, ...).
    8. Most have 2 languages.

    DavanbuStubblebine02

    1. Premkumar T Davanbu & Stuart G Stubblebine
    2. Stack and Queue Integrity on a Hostile Platforms
    3. IEEE Trans Software Engineering V28n1(Jan 2002)pp100-108
    4. =THEORY ADTs without trust

    Davidson88

    1. Colin M Davidson
    2. Quicksort Revisited
    3. IEEE Trans Soft Eng VSE-14n10(Oct 1988)pp1480-1481
    4. =DEMO METHOD new Quicksort with no recursion [MillsLinger86]
    5. inspired new way to derive quicksort: put unsorted segments into a set and so no stack and no recursion.

    DaviesDavies97

    1. Byron Davies & Victoria Bryan Davies
    2. Patching onto the Web: Common LISP Hypermedia for the Intranet
    3. Comm ACM V40n5(May 1995)pp66-69
    4. ADVERT LISP WEB/NET CL-HTTP
    5. CL-HTTP to put large factory database onto the WWW

    DaviesJ94

    1. Jim Davies
    2. Specification and proof in real-time CSP
    3. Cambridge Univ Press NY NY ISBN 0-521-45055-1(distinguished dissertation) CR9407-0395 AMM Review: timed denotational semantics
    4. =THEORY SEMANTICS TIMING SPECIFICATION PROOF

    DavisA90

    1. Alan M. Davis
    2. Software Requirements: Analysis and Specification
    3. Prentice Hall Englewood Cliffs NJ 1990 ISBN 0-13-824673-4 BNB89-16392 QA76.76 D47 D38 1990
    4. =TEXT SADT DFD DATA Coad bibliography
    5. Reviews: IEEE Software magazine v11n2(Mar 1994) CR9112-0915.
    6. Revised as DavisA93a

    DavisA92

    1. Alan M. Davis
    2. Operational Prototyping: A New Development Approach
    3. IEEE Software Magazine V9n5(Sep 1992)pp70-78
    4. lifecycles
      1. Throwaway vs evolutionary prototyping
      2. Operational= Throwaway+evolutionary
      3. Implement a high quality solution for understodd functions. In the field prototypers tryout ideas and then deletes them. When well understood and worthwhile the prototyper submits a change request. Periodically a new baseline is released.

    DavisA93a

    1. Alan M Davis
    2. Software requirements: objects & functions and states
    3. Prentice Hall Englewood Cliffs NJ 1993
    4. =TEXT SADT DFD DATA Coad bibliography
        Revision of DavisA90 CR9112-0915 Best broad coverage

    DavisA93b

    1. Alan M. Davis
    2. Software Lemmingineering
    3. IEEE Software Magazine V10n5(Sep 1993)pp79-81&84;correspondence V11n1 (Jan 1994) pp10+V11n4(Jul 1994)pp110-111+QV DavisA94a&b.
    4. =ARTICLE METHODS TOOLS FAIL
        Fads and trends and following the crowd:
      1. Structured
      2. Object
      3. Maturity
      4. C
      5. Prototyping
      6. CASE
      7. Reuse
      8. Comquats (COMercial off-the-shelf QUAlity sofTware)

        Tom Adams letter describes methodology life cycle

      9. good project with new idea
      10. idea reduced to a buzz phrase
      11. complex methodology based on just the buzz phrase
      12. many seminars
      13. many books
      14. Many many failed projects

        Richard Wells

      15. I reuse and am careful in C.
      16. CASE does not address my problems.

    DavisA94a

    1. Alan M. Davis
    2. Counterpoint: There are no bad guys and no one has the "Truth"(Side bar in Glass94a)
    3. IEEE Software magazine v11n3(May 1994)pp92
    4. =DEBATE

    DavisA94b

    1. Alan M. Davis
    2. Rewards of Taking the Path Less Traveled
    3. IEEE Software magazine v11n4(Jul 1994)pp100-101+102
    4. =ESSAY IMPROVEMENT CUSTOMER PROTOTYPES FORMAL SQA REUSE
        Refers back to "lemmingineering" [DavisA93] and [Glass94]

        Instead-

      1. Get the Big Picture or - little risk, little cost, proven to give some benefit, fuddy-duddy
      2. Talk to your customers
      3. Build Prototypes
      4. Do Trade-Off Analysis
      5. Play with Formal methods
      6. Review, Walkthrough, inspect
      7. Salvage

    DavisA94c

    1. Alan M. Davis(ed)
    2. Fifteen Principles of Software Engineering
    3. IEEE Software Magazine V11n6(Nov 1994)pp94-96&101
    4. =ADVERT and Excerpt from [DavisA95]
        "Today's principles will look equally silly in 30 years..."
      1. 1. Make Quality Number 1
      2. 2. High-Quality Software is Possible
      3. 3. Give Products to Customers Early
      4. 4. Determine the Problem before Writing the Requirements
      5. 5. Evaluate Design Alternatives
      6. 6. Use an Appropriate Process Model
      7. 7. Use Different Languages for Different Phases
      8. 8. Minimize Interlectual Distance
      9. 9. Put Technique before Tools
      10. 10. Get it Right Brefore You Make it Faster
      11. 11. Inspect Code
      12. 12. Good Management is more importatn than Good Technology
      13. 13. People are the Key to Success
      14. 14. Follow with Care
      15. 15. Take Responsibillity
      16. -------- -- --(Table page 95)
      17. 16. Understand the Customers Priorities
      18. 17. The more they see the more they want
      19. 18. Plan to through one away
      20. 19. Design for Change
      21. 20. Design without documentation is not design
      22. 21. Use tools, but be realistic
      23. 22. Avoid tricks
      24. 23. Encapsulate
      25. 24. Use Coupling and cohesion
      26. 25. Use McCabe Complexity Measure
      27. 26. Don't Test your own Software
      28. 27. Analyze Causes for Errors
      29. 28. Realize that Software's Entropy Increases
      30. 29. People and Time are not Interchangeable
      31. 30. Expect Excellence

    DavisA95

    1. Alan M Davis
    2. 201 Principles of Software Engineering
    3. McGrawHill NY NY 1995 $24.95 ISBN 0-07-015840-1 CR9512-0926(Praise by Tom DeMarco)
    4. =HANDBOOK [DavisA94c]

    DavisA95a

    1. Alan M Davis
    2. Software Prototyping
    3. Advances in Computers V40(1995)pp39-63
    4. =EXPERIENCES PROTOTYPING COST QUALITY
    5. Is not instantly cheaper! Choose throwaway or evolutionary.
    6. Evolution demands good QUALITY from the beginning and maintained for ever.

    DavisA00

    1. Alan M Davis
    2. The Software Company Machine
    3. IEEE Software Magazine V17n2(Mar/Apr 2000)pp14-15
    4. =THEORY ORGANISATION
    5. (R&D + Financial + Marketting& Sales) engines

    DavisA03

    1. Alan M Davis
    2. The Art of Requirements Triage
    3. IEEE Computer Magazine V36n3(Mar 2003)pp42-49
    4. =CASESTUDY REQUIREMENTS vs SCHEDULING ESTIMATION PROBABILITY vs FIRST-TO-MARKET
      1. Keep a simple hierarchical list of requirements.
      2. Record dependencies.
      3. Add effort needed, importances to different stake holders.
      4. Importance of super-requirement > max sub-requirements.
      5. Involve customers, developers and financial representatives in triage.
      6. Foster teamwork between all stake holders.
      7. Nothing is absolute, think in terms of probabilities in a given time.
      8. Base probabilities on previous projects.
      9. You can do triage by paring down the optimistic plan or expanding the pessimistic plan.
      10. Plan multiple releases but re-plan before every new release.
      11. Don't be intimidated into accepting schedules that are either technically impossible or too late to market. Look for a creative compromise that gives a high probability of both.
      12. Better 90% now than 95% in sic months.

    5. Partition requirements into (must have + must not have + may or may not have) in this release. Use priorities to schedule the third group.
    6. Use schedule probability graphs: map dates>->probability of completion by that date.
    7. When there 100s of requirements group them into features/"super-requirements" capable of unified implementation and sale.
    8. Refers to A Davis03? "Just enough Requirements Management", Prentice Hall Int 2003.

    Davis03a

    1. Alan M Davis
    2. System Phenotypes
    3. IEEE Software Magazine V20n4(Jul/Aug 2003)pp54-56
    4. =IDEA REQUIREMENTS PHENOTYPE vs DESIGN CODE GENOTYPE
    5. The difference between requirements and design is not a matter of detail or refinement.
    6. Examining a fly in detail under a microscope shows you the phenotype not the genetic. Genetics is not always expressed. Phenotype is observable.
    7. Requirements are observable even if highly detailed. They constrain the internal structure (genotype).
    8. Requirements expressed(spoken, drawn,..) in the customers language not technical jargon.

    Davis05

    1. Alan M Davis
    2. Just enough Requirments management: where software development meets marketting
    3. Dorset House NY NY 2005, 240 pages, ISBN 0932633641 CR 0712-1159
    4. =UNREAD EXPERIENCES REQUIREMENTS ELICITATION TRIAGE SPECIFICATION
    5. May also have been published in 2003. See [DavisA03] above

    Davisetal88

    1. Alan M. Davis & Edward H Bersoff & Edward R Comer
    2. A Strategy for Comparing Alternative software Development Life Cycle Models
    3. IEEE Trans Soft Eng VSE-14n10(Oct 1988)pp1453-1461
    4. =THEORY METHODS PROCESS USER vs TIME
    5. plot USER needs and functionallity supplied against time

    Davisetal91

    1. Alan M. Davis & Peter A Freeman
    2. Requirements Engineering (Guest Editors Introduction)
    3. IEEE Trans SE-17 n3(Mar 1991)pp210-211
    4. =EDITORIAL REQUIREMENTS RESEARCH
        "Of the 35 papers, only 3 were deemed of sufficient quality to merit publication in this section.[...] we are left with the strong impression that requirements engineering research is not in a healthy state."


    Davisetal94

    1. Alan M. Davis & Pradip Sitaram
    2. A Concurrent Process Model of Software Development
    3. ACM SIGSOFT Software Eng Notes V19n2(Apr 1994)pp38-51
    4. =THEORY non-sequential process statechart ...

    DavisM11

    1. Michael Davis
    2. Computer ethics: will software engineering ever be engineering?
    3. Commun ACM V54n11(Nov 2011)pp32-34 [ 2018396.2018407 ] Rebuttal GM Samaras V55n1(Jan 2012)p6 [ 2063176.2063168 ]
    4. =ESSAY ENGINEERING KNOWLEDGE
    5. SWEBOK omits knowledge (eg chemistry) found in engineering. Also misdefines engineering.
    6. Software engineering has its own methods.
    7. But engineering is starting to look like software engineering!

    DavisMorgan93

    1. John Davis<74155.416@compuserve.com> & Tom Morgan
    2. Object-Oriented Development at Brooklyn Union Gas
    3. Special Theme "Making OO Work" IEEE Software V10n1(Jan 1993)pp67-74
    4. =EXPERIENCE OBJECT-ORIENTED OOA/OOD PL/I CICS
        400 concurrent users, CICS, 100,000 transactions each evening.... reduced CPU load, more memory than trad., OO AD but PL/I+MVS/CICS technology
      1. p74 "Developers shouldn't try to specify the system more than a few steps into its life cycle"
      2. pp72-73:Reuse during maintenance - 2K lines added but 40K lines used to support them
      3. pp70: "The largest single source of technical program erors [...no] real garbage collector."
      4. pp68: 3 layers{Interface, Process, Busness-Object}

    DavisMS00

    1. Mathew S Davis
    2. an object-oriented approach to constructing recursive descent parsers
    3. ACM SIGPLAN notices V35n2(Feb 2000)pp46-51
    4. =DEMO TECHNICAL SMALLTALK DDD

    DavisR07

    1. Randall Davis
    2. Magic Paper: Sketch-understanding Research
    3. IEEE Computer Magazine V40n9(Sep 2007)pp34-41
    4. =DEMO TABLET SKETCH GRAPHICS CASE Rose USER
    5. Tantalysing glimpse of a tool that front-ends Rational Rose to turn a rough sketch of a class diagram into Java Code.
    6. Discusses issues in recognizing and parsing roughly hand drawn graphics.

    DavisRetal96

    1. Randall Davis & Pamela Samuelson & Mitchell Kapor & Jerome Reichman
    2. A new View of Intellectual Property and Software
    3. Commun ACM V39n3(Mar 1996)pp21-30
    4. =IDEA ETHICS PROPERTY

    DavisTE00

    1. Thomas E Davis
    2. Object-Oriented Design in Procedural Environments
    3. Dr. Dobbs Journal #313(Jun 2000)pp68+70-72
    4. =DEMO
    5. Reinvents techniques used in FORTRAN and C!

    Dean96

    1. Neville Dean
    2. The Essence of Discrete Mathematics
    3. Prentice Hall Hemel Hempstead UK 1996
    4. =TEXT DISCRETE MATHEMATICS
    5. part of the "Essence of Computing" series 1996. See DeanHinchey95

    DeanCordy95

    1. Thomas R Dean & James R Cordy
    2. A Syntactic Theory of Software Architecture
    3. IEEE Trans on Software Eng VSE-21n4(Apr 1995)pp301-314 CR9602-0119 D.2.0
    4. =THEORY ARCHITECTURE DFDs GRAMMAR

    DeanGhemawat08

    1. Jeffrey Dean & Sanjay Ghemawat
    2. MapReduce: Simplified Data Processing on Large Clusters
    3. Commun ACM V51n1(Jan 2008)pp107-113
    4. =EXPERIENCE FUNCTIONAL PROGRAMMING Google DATA C++ LIBRARY FP NONSEQUENTIAL PIPE
    5. Very large numbers of problems have been programmed to run on large clusters. Each is written as two (2) functions:
    6. map: Key><Value><Data -> List(Key>< Value),
    7. reduce: (Key->List(Value)) ->List( Value).
    8. Also, implicitly the system has a sort function:
    9. sort: List(Key><Value) -> (Key->List(Value).
    10. System applies map to some data, sorts data by key and passes it to reduce.
    11. map; sort; reduce
    12. All the concurrency, distribution, fault tolerance etc. is provided by the system not the programmer.
    13. Note: the idea using functions was in LISP and FP(Jim Bachus). Similar techniques used in UNIX/Linux Shell scripts, but dates back to the COBOL SORT verb! Part of MATHS.
    14. For an attempt to express this in Haskell see [Lammel08]

    DeanGhemawat10

    1. Jeffrey Dean & Sanjay Ghemawat
    2. MapReduce: A Flexible Data Processing Tool
    3. Commun ACM V53n1(Jan 2010)pp72-77 [ 1629175.1629197 ]
    4. =ADVERT =EXPERIENCE GOOGLE TOOLS MapReduce Hadoop FORMATS Protocol Buffer
    5. Reply to [StonebrakerEtAl10]
    6. Has some conclusions (p77) for speeding up MapReduce processes.

    DeanHinchey95

    1. Neville Dean & Michael G Hinchey
    2. Introducing Formal Methods Through Role-playing
    3. Papers of the 26th SIGCSE Technical Symposium on Computer science Education: ACM SIGCSE Bulletin V27n1(Mar 1995)pp302-36
    4. =EDUCATION FORMAL Z
        Note [ http://www.anglia.ac.uk/~cdean/ ] deescribes Z "there is no suitable text which prepares in the way that they need."..."it has been necessary to write a new book"[Dean96] Tendency of studentss to use clever formal techniques to give formal statements of ambiguous and incomplete requirements.

        [students think] "the purpose of the exercise is to write a 'program' to include as many of the esoteric aspects of the notation that they can squeeze in"

        student are angry working with simulation of real requirements(!)

        force students to re-express clever (but wrong) Z specs in english until ambiguities show up.

        Instructor must act the part of customer: dismissing formal specs, and forcing students to include English explanations.


    DeAntonellisZonta90

    1. Valeria De De Antonellis & Bruta Zonta
    2. A Disciplined Approach to Office Analysis
    3. IEEE Trans SE-16n8(Aug 1990)pp822-828
    4. =DEMO System Reality

    DeBakker75

    1. J W de Bakker
    2. Flow of Control in the Proof of Sequential Programs
    3. Proc 16th Ann Symposium on the Fundamentals of Computer Science Berkeley California(pp29-33) IEEE Computer Society 1975
    4. =THEORY regular logic

    DeBakker96

    1. Jaco de Bakker
    2. Control Flow Semantics
    3. MIT Press Cambridge MA 1996 ISBN0-262-04154 $50 CR9709-0654(F.3.2)
    4. =MATHEMATICAL 27 LANGUAGES MATHEMATICS TOPOLOGY Complete Metric spaces

    Deck01

    1. Michael Deck
    2. Managing Process Diversity while Improving your Practice
    3. IEEE Software Magazine V18n3(May/June 2001)pp21-27
    4. =EXPERIENCE IMPROVEMENT EVOLUTION CLEANROOM PEOPLE RISKS INCREMENTS ONE-SIZE CMM
    5. Even in one project "one size does not fit all" parts of the project. For example inspection do not help you test a prototype algorithm for adequate performance. Remotely executed software must be derived in the most rigorous zero-defect approach but locally executed software does not need this.
    6. People -- especially new ones -- are a prime risk factor.
    7. Diversity plan distinguishes three levels for each part of a process: Foundation, standard and advanced.
    8. A practice can be required, recommended, or optional.

    DedekeLiberman06

    1. Adenekan (Nick) Dedeke & Benjamin Liberman
    2. Qualifying Use Case Diagram Associations
    3. IEEE Computer Magazine V39n6(Jun 2006)pp23-29
    4. =DEMO UML USE CASE DOMAIN MODEL DATA FLOWS DFDs
    5. Analyzing data needed for a use case and linking it to a conceptual domain model leads to better use cases.
    6. Extension to UML2.0 use case diagrams.
    7. (dick)|-why not use a DFD? [ papers/rjb04bDFDs/ ]

    DedeneSnoeck94

    1. G Dedene & M Snoeck<fdbaa30@cc1.kuleuven.ac.be>
    2. MERODE: A Model-Driven Entity-Relationship Object-oriented DEvelopment method
    3. ACM SIGSOFT Software Engineering Notes V19n3(Jul 1994)pp51-61
    4. =ADVERT METHOD DAD REGULAR-EXPRESSION NONSEQUENTIAL ERD
      1. object_type::="<" @Events "," RegularExpression(Elements=>Events) ">", Restriction
          RE\S
        more deterministic Parallel composition of object types. They use "||" for interleaving type semantics

    5. For an improved method see [SnoeckDedene98]

    DeekMcHugh07

    1. Fadi P Deek & James A M McHugh
    2. Open source: technology and policy
    3. Cambridge UP NY NY 2008 ISBN 0-521-88L03-X
    4. =TEXT Open source

    DeGraceStahl90

    1. Peter DeGrace & Leslie H Stahl
    2. Wicked Problems and Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms
    3. Yourdon Press NY NY 1990 QA76.758.D44 1990 CR9208-0538
    4. =POLEMIC METHODS vs PROBLEMS
    5. many DFDs of methods.
    6. wicked_problem::=The solution is part of the problem & no stopping rules & not true/false. [rittel & webber 73: dilemmas in a genl theory o planning policy sciences v4pp155-169].
    7. handcuffs and hacking.
    8. (dick)|-possible confusions: COBOL=DP. top-down=waterfall. [Cardetal87]

    DeGraceStahl93

    1. Peter DeGrace & Leslie H Stahl
    2. The Olduvai imperative: CASE and the state of software engineering practice
    3. Yourdon Press NY NY 1993 ISBN 0-13-161100-3 CR9401-0006
    4. =ESSAY METHODS
      1. CR by RL Glass: Folksy sophisticated, pragmatic yet intellectual, call-a-spade-a-spade, Two different cultures - Roman and Greek. will be cheered by practitioneers and disliked by academics and managers.
      2. Greek::=individual brilliance, informal methods, problem-focussed people, empirical/inductive.
      3. Roman::= group, formal, management, analytic/deductive.
      4. QV: Gods of Management...

    DeganoEtAl08

    1. Pierpaolo Degano & Rocco De Nicola & Jose Meseguer (eds)
    2. Concurrency, Graphs and Models: Essays dedicated to Ugo Montanari on his 65th Birthday
    3. LNCS 5065 Springer Verlag Berlin Heidelberg (2008) CR 0909-0812
    4. =FESTSHRIFT MATHEMATICS GRAPH THEORY CONCURRENCY NON-SEQUENTIAL CATEGORIES SEMIRINGS TOOLS HISTORY
    5. Includes [AstesianoReggioRicca08] UML BUSINESS ... [Baetan08] ALGEBRA EQUATIONS AUTOMATA ... [BeauxisPalamidessiValencia08] NONSEQUENTIAL BAGS... [HermenegildoEtAl08] LANGUAGE Ciao ... [Quaglia08] BIOLOGICAL CELLULAR SYSTEMS...

    deJong07

    1. Jennifer deJong
    2. It's Lean, But Is It Agile? Iterative methods are closely aligned
    3. SD Times (15 Jun 2007) [ story-20070615-04.html ]
    4. =ARTICLE AGILE = LEAN XP Crystal Beck Cockburn

    deGuzman0jedaValverdes95

    1. I P de Guzman & M Ojeda & A Valverdes
    2. A formal identifiaction between tuples and lists with application to list-arithmetic categories
    3. Acta Inf V32n1(1995)pp61-78 CR9602-0125 D.3.1
    4. =THEORY DATA STRUCTURES

    DelamaroMaldonadoMathur01

    1. Macio E Delamaro & Jose c Maldonado & Aditya P Mathur
    2. Interface Mutation: An Approach for Integration Testing
    3. IEEE Trans Software Engineering V27n3(Mar 2001)pp228-247
    4. =DEMO TESTING MODULES

    Delany76

    1. Samuel R Delany
    2. Triton: Some Informal Remarks Toward the Modular Calculus Part One
    3. Corgi Edn. 1977 Transworld London UK
    4. =FICTION =SEMINAR language SEMANTICS theory structure

    DelatteHeitzMuller93

    1. B Delatte & M Heitz & J F Muller
    2. HOOD: Reference Manual 3.1
    3. Prentice Hall International(UK) Mason Paris France 1993 ISBN 0-13-396243-1 CR9411-0756
    4. =HANDBOOK Object-oriented method

    DelenDalaBenjamin05

    1. Dursun Delen & Nikunj P Dala & Perakath C Benjamin
    2. Integrated Modeling: The key to Holistic understanding of the enterprise
    3. Commun ACM V48n4(Apr 2005)pp107-112
    4. =ADVERT ERP MODELING TOOL PROCESS FUNCTION DATA COST ONTOLOGY PQRST GERAM IDEF CPM MODELMOSAIC REPOSITORY
    5. GERAM::= See http://www.cit.gu.edu.au/~bernus/taskforce/

    Delgrande98

    1. James P Delgrande(Simon Fraser U, Burnaby, BC, Canada)<jim@cs.sfu.ca>
    2. On first-order conditional logics
    3. Artif Intell V105n1-2(Oct 1998)pp105-137 CR9903-0211
    4. =THEORY defeasible LOGIC possible worlds Kripke
      1. Proposes replacing for all x( P implies_if_normal Q) by P implies_for_all_normal[x] Q
      2. Examples: all birds fly, penguins are birds, penguins don't fly.
      3. All elephants like their keepers, unless the keeper is mean like Fred in which case they don't like him, unless the elephant is Clide who likes all the keepers.

    DeLine01

    1. Robert DeLine
    2. Avoiding Packaging Mismatch with Flexible Packaging
    3. IEEE Trans Software Engineering V27n2(Feb 2001)pp124-143 in ICSE'99 + Correction IEEE Trans Software Engineering V27n6(Jun 2001)p576
    4. =DEMO MODULE ARCHITECTURE ware+packager NONSEQUENTIAL
    5. Allows one piece of logic to be mapped into spreadsheet, CGI, yacc, ....
    6. Stresses use of coroutines as more flexible than procedural code.

    DeLineVenoliaRowan10

    1. Robert DeLine & Gina Venolia & Kael Rowan (Microsoft Research)
    2. Software Development with Code Maps
    3. ACM Queue(Jul 4 2010) [ detail.cfm?id=1831329 ] & Commun ACM V53n8(Aug 2010)pp48-62 (Better pictures) [ 1787234.1787250 ]
    4. =ADVERT TOOL GRAPHIC TECHNICAL CODE VISUALIZATION HCI CODE MAP VISUAL STUDIO CODE CANVAS
    5. Another tool that generate graphic zoomable and editable images of code. But a tool based on what programmers already did!
    6. A rare example of applying systems analysis to software engineering.

    DeLineZelesnikShaw97

    1. Robert DeLine & Gregory Zelesnik & Mary Shaw
    2. Lessons on Converting Batch Systems to Support Interactions [ICSE'97]
    3. =Experience architecture evolution
    4. 8 rules on page 203
    5. no ref to Jackson's work in 1975.

    DelisleGarlan90

    1. Norman Delisle & David Garlan
    2. A Formal Specification of an Oscilloscope
    3. IEEE Software V7n5(sep 1990)
    4. =DEMO FORMAL SPECIFICATION HARDWARE

    DeLoachHartrum00

    1. Scott A DeLoach & Thomas C Hartrum
    2. A Theory-based representation for object-oriented domaon models
    3. IEEE Trans Software Engineering V26n6(Jun 2000)pp500-517
    4. =DEMO CATEGORY THEORY fits OMT O-SLANG
    5. classes events sorts atttributes axioms

    DeMarco79

    1. Tom De Marco
    2. Structured Analysis & Systems Specification
    3. Prentice Hall 1979
    4. =TEXT SAD DFD PURPOSE System

    DeMarco80

    1. Tom De Marco
    2. Structured Analysis & System Specification
    3. Yourdon Press NY NY
    4. =HANDBOOK SAD DFD ERD PURPOSE System Reality

    DeMarco88

    1. Tom de Marco
    2. Interview
    3. IEEE Software v6n2(Mar 1988)pp92-93
    4. =INTERVIEW object-oriented non-sequential

    DeMarco95

    1. Tom DeMarco
    2. Why Does Software Cost So Much? And Other Puzzles of the Information Age
    3. Dorset house 1995 CR9702-0104 rev IEEE Software Magazine VSE13N4(Jul 1996)pp134-135(Alan M Davis)
    4. =ESSAYs PEOPLE COST

    DeMarco03

    1. Tom DeMarco
    2. The McCarthy Protocols
    3. Commun ACM V46n6(Jun 2003)pp24-25
    4. =ADVERT TEAM PEOPLE MEETING CEREMONY PATTERN
    5. Describes Jim and Michele's patterns for meetings, see
    6. TeamorX::= See http://www.mccarthytech.com, and [McCarthyMcCarthy02]

    DeMarco09

    1. Tom DeMarco
    2. software engineering: an idea whose time has come and gone
    3. IEEE Software Magazine V26n4(Jul/Aug 2009)pp96+95 =ESSAY PROCESS CONTROL METRIC ESTMATING PLANNING
    4. 1982 book tried to control too much.
    5. Only marginal projects need tight control.
    6. Better to ask for incremental growth to better and better systems until time runs out.

    DeMarco11

    1. Tom DeMarco
    2. All late projects are the same
    3. IEEE Software Magazine V28n6(Nov/Dec 2011)pp104+103 [ lateprojects ] with discussion V29n1(Jan/Feb 2012)pp8-11
    4. =ESSAY ESTIMATION COST LATE PROJECTS
    5. Late projects start too late.
    6. Either trying to catch a competitor, or to save money, or discovered need too late!
    7. Discussions look at other possible reasons for failure.

    DeMarcoBoehm02

    1. Tom DeMarco & Barry Boehm
    2. The Agile Methods Fray
    3. IEEE Computer Magazine V35n6(Jun 2002)pp90-92
    4. =DEBATE AGILE METHODS
    5. Previous [Boehm02]
    6. Individual skills or organizational rules?
    7. Also see "Duking it out" in Software Development Magazine V10n7(Jul 2002)pp53-55

    DeMarcoHruschkaEtAl08

    1. Tom Demarco & Peter Hruschka & Tim Lister & Suzanne Robertson & James Robertson & McManamin
    2. Adrenaline Junkies and Template Zombies: Understanding patterns of project behavior
    3. Dorset House, NY NY 2008 pp248 ISBN 0932633676
    4. =UNREAD PEOPLE PATTERNS PROJECTS PROCESSES
    5. Contributions needed -- [click here [socket symbol] DeMarcoHruschkaEtAl08 if you can fill this hole]

    DeMarcoLister87

    1. Tom DeMarco & T Lister
    2. Peopleware: Productive Projects and Teams
    3. Dorset House NYNY 1987
    4. =TEXT PROCESS PEOPLE TEAM
    5. from [Brooks95]

    DeMarcoLister03

    1. Tom DeMarco & Tim Lister
    2. Risk Management during Requirements
    3. IEEE Software Magazine V20n5(Sep/Oct 2003)pp99-101
    4. =EXPERIENCE RISKS REQUIREMENTS PEOPLE POLITICS
    5. Continuous public identification of risks to a project.
    6. examples: arbitrary schedule, stakeholder conflict, scope creep, personnel loss, productivity variation.
    7. Assign ranks to all requirements and express all outcomes in probabilities. Show growth of probability of delivering requirement as a graph. Risks of using vague requirements to hide non-agreement (non-concurrence)
    8. Diagnose non-agreement/politics by precisely documenting data flows in and out of system.

    DeMelo06

    1. Darrion DeMelo
    2. ReMoTe: A Complete tool to support software process management
    3. CSUSB MS Presentation (Feb 24 2006)
    4. =DEMO TOOL MANAGEMENT PROCESS RMT CHAT MESSAGES GANT BAR CVS BUGZILLA

    DeMilloLiptonPerlis79

    1. Richard DeMillo & Richard Lipton & Alan Perlis
    2. Social processes and Proofs of Theorems and Programs
    3. Commun ACM V22n5(May 1979) pp271-280, letters V22n11pp621-630
    4. =ESSAY EXAMPLES MATHEMATICS PROOF LOGIC
    5. p272: "There is simply no way to describe the history of mathematical ideas without describing the successive social processes at work on proofs."
    6. See [Lakatos76] [Bauer92]
    7. (DeMilloLiptonPerlis79)|-rigorous software development will also depend on social processes

    DeMouraBjorner11

    1. Leonardo de Moura & Nikolaj BjC8rner
    2. Satisfiability modulo theories: introduction and applications
    3. Commun ACM V54n9(Sep 2011)pp69-77 [ 1995376.1995394 ]
    4. =ADVERT LOGIC FORMAL MATHEMATICS PROBLEM SOLVING TOOLS SMT SAT
    5. SMT solve problems within specialized mathematical theories.
    6. Example theory: difference arithmetic where every formula has form x-y<=c where x & y are variables and c is a constant.
    7. SMT work with SAT solvers.
    8. Several solvers for different theories can be combined.
    9. Many problems about programs can be expressed in the theories with tractable solvers.

    Demers81

    1. Richard A. Demers
    2. System Design for Usability
    3. Commun ACM V24n8 (Aug 1981) pp494-501
    4. =DEMO USER IBM System/38

    DemirersGencel09

    1. Onur Demirors & Cigdem Gencel
    2. Conceptual Association of Functional Size Measurement Methods
    3. IEEE Software Magazine V26n3(May/Jun 2009)pp71-78
    4. =CASESTUDIES ESTIMATION FPA FSM UM

    DempseyWeissJoneGreenberg02

    1. Bert J Dempsey & Debra Weiss & Paul Jone & Jane Greenberg
    2. Who is an Open Source Software developer
    3. Commun ACM V45n2(Feb 2002)pp67-72
    4. =HISTORY OPEN SOURCE LINUX ARCHIVE 4k contributions MetaLab LSM ibiblio.org
    5. more European than US, more com than edu, more single submissions than many, some maintenance, mix of apps+utilities+games+system+etc
    6. LSM::="Linux Software Map", defines data about a contribution, Net{ Title, Version, Entered=date, description, Primary-site: fields, ...}.
    7. Archive at [ http://www.ibiblio.org ]

    DemskyRinard06

    1. Brian Demsky & Martin C Rinard
    2. Goal-Directed Reasoning for specification-based Data Structure Repair
    3. ICSE'05 & IEEE Computer Magazine V39n12(Dec 2006)pp931-951
    4. =DEMO DATA SPECIFICATION SETS RELATIONS ABSTRACTION INVARIANTS CONSTRAINTS REPAIR FAULT AbiWorld CTAS Freeciv File System
    5. In some cases it is better to repair a broken data structure incorrectly and continue running rather than crash and stop running.
    6. Data structures can be repaired by using formal abstract specification in terms of Sets and Relationships.
    7. Comparison with bespoke/domain specific fsck and chkdsk.
    8. Fix each broken constraint in turn and use a Repair Dependence Graph to avoid infinite loops of repairs.
    9. Lists actions to repair data structure.
    10. Focuses on internal consistency rather than "REALITY" and as a consequence the whole application may work incorrectly.
    11. Compare [KuncakLamZeeRinard06] that uses a similar abstraction/specification but includes domain constraints to model bot internal data structure consistency and external domain constraints.

    DeneckerBruynooghe02

    1. Marc Denecker & Maurice Bruynooghe
    2. Logic Programming Revisited: Logic Programs as Inductive Definitions
    3. ACM Trans Computational Logic V2n4(Oct 2001)pp623-654
    4. =THEORY LOGIC Prolog INDUCTION

    DenneCleland-Huang04

    1. Mark Denne & Jane Cleland-Huang
    2. The incremental funding method: Data-driven Software Development
    3. IEEE Software Magazine V21n3(May/Jun 2004)pp39-47
    4. =EXAMPLES ECONOMICS ROI COST-BENEFIT INCREMENTAL
    5. Include value of each delivered increment as benefit with costs.

    Denning90

    1. Peter Denning
    2. Human Error and the Search for Blame(editorial)
    3. Commun ACM V33n1(Jan 1990)pp6-7
    4. =EDITORIAL RISKS

    Denning93

    1. Peter J Denning
    2. Educating a New Engineer
    3. Comm ACM V35n12(Dec 1992)pp83-97
    4. =EDUCATION ENGINEER

    Denning94

    1. Peter J Denning
    2. Designing a Discipline of Software Design
    3. Keynote address at the 7th SEI Conference on Software Engineering Education "Putting the 'Engineering' into Software Engineering" January 5-7 1994 San Antonio Texas USA
    4. =IDEA REALITY ONTOLOGY [WandWeber90] cf [WiederholdWegnerCeri93] cf
    5. ?? S-->RPQ->T (ontological mapping)
        From Abstract

        The central claim explored here is that the standard engineering design process produces a fundamental blindness to the domains of action in which the customers of software systems live and work. The connection between measurable properties of the software and the satisfaction of those customers is, at best, tenuous. We propose a broader interpretation of design that is centered on observing the work processes of a community of customers in a domain and connecting those processes to supportive software technologies. The skill that a designer needs to have to observe work processes and begin making the connections is here called ontological mapping. This skill can be learned and is the basis of a discipline of software design.


    Denning02

    1. Peter J Denning
    2. Flatlined
    3. Commun ACM V45n6(Jun 2002)pp15-19
    4. =ESSAY THINKING GRIDs 2dimensional GRAPH TABLE Science
    5. Rather than set up a false P vs Q dichotomy, map out in two dimensions (low P..high P)><(low Q.. high Q). Thus 4 quadrants.
    6. Example: science: understanding >< utility.
    7. Example: software industry: technical excellence >< customer satisfaction.
    8. Example: professions: technical skills >< value skills

    Dennning03

    1. Peter J Denning
    2. Accomplishment
    3. Commun ACM V46n7(Jul 2003)pp19-23
    4. =ADVERT Language-action PHILOSOPHY PEOPLE SYSTEMS COORDINATION USER AI
    5. People use language to make more or less explicit contracts for action. Trust comes from a promised action satisfying expectations.
    6. action_loop::=#( a.request; b.promise; b.deliver; a.accept).
    7. Watch out for miscommunication. Exposed by action.
    8. Loss of market can come from lack of satisfaction in above loop between producer and consumer.
    9. Used as a basis for Email client.
    10. Management depends on handling action_loops.
    11. There are protocols for inventing possibilities.
    12. disclosure: Implicit awareness of signals about other's thoughts & feelings (but distorted). Need to consciously listen; react; adjust interpretation. [DenningDunham03]

    Denning04

    1. Peter J Denning
    2. The Social Life of Innovation
    3. Commun ACM V47n4(Apr 2004)pp15-19
    4. =SURVEY INNOVATION ENGINEERING WEB
    5. |-invention != innovation.
    6. Innovation has a strong social component because it leads to change. Refers to [Drucker85] and adds a new kind of opportunity "marginal practices" from Spinoza % Dreyfus &Flores: "Disclosing New Worlds", MIT Press 1997 Adds a table of practice for innovation: Awareness, Focus+persistence, Listening+Blending, declarations, destiny, Offers, Networks+Institutions, Learning. Cognitive blindness: not seeing something and not knowing you didn't see it. applies theory to Tim Berners-Lee and the WWW.

    Denning04b

    1. Peter J Denning
    2. The Field of Programmers Myth
    3. Commun ACM V47n7(Jul 2004)pp1-20
    4. =HISTORY EDUCATION programming vs computer science
    5. (public)|- (myth_cs_is_p): computer science = programming != science.
    6. Separate and link programming practice with algorithmic thinking/abstraction. "ladder of competence".
    7. Teach error detection and correction

    Denning04c

    1. Peter J Denning
    2. Network Laws
    3. Commun ACM V47n11(Nov 2004)pp15-20
    4. =SURVEY MATHEMATICS NETWORKS RANDOM GRAPHS POWER LAWS SMALL WORLDS
    5. Clique: highly connected subset with few connections outside the clique.
    6. Hubs: nodes with many links.
    7. Broker: the only connection between a pair of cliques.
    8. Bridge: connected to several cliques In many real networks the Pr[k links at a node] = (1/k)**p, "power law".
    9. Accounted for by new nodes being created at random and connecting to nodes wit h larger numbers of links.
    10. Hubs are key for securing and using a network.
    11. Command a network by communicating intent and delegating decision making.

    Denning05

    1. Peter J Denning
    2. Is Computer Science Science?
    3. Commun ACM V48n4(Apr 2005)pp27-31
    4. =HISTORY =SURVEY SCIENCE ENGINEERING TECHNOLOGY ART
    5. Simulated dialog with a skeptic.
    6. Notes internal doubts and discussion. Notes the credibility problem of research claims that were not tested before publication, and practical predictions that did not pan out.

    Denning05b

    1. Peter J Denning
    2. The Locality Principle
    3. Commun ACM V48n7(Jul 2005)pp19-24
    4. =SURVEY =HISTORY LOCALITY

    Denning07

    1. Peter J Denning
    2. Mastering the Mess
    3. Commun ACM V50n4(Apr 2007)pp31-25
    4. =ESSAY PROBLEMS INNOVATION THINKING
    5. mess: disorder, no problem statement, controversy, doubtful causality, fixes don't work, ... "Normal"...
    6. 4 levels of mess and actions.
    7. 6 stratagems: declare, learn, question, many views, lead, disguise

    Denning07a

    1. Peter J Denning
    2. Computing is a natural science
    3. Commun ACM V50n7(Jul 2007)pp13-18
    4. =ESSAY COMPUTING SCIENCE ARTIFICIAL
    5. Refutes Herbert Simon's claim the that we study the "Science of the Artificial". [Simon69]
    6. Claims that computation is found inside all other natural sciences -- not just as a tool but as a model of processes in their topic area.

    Denning07b

    1. Peter J Denning
    2. The Choice Uncertainty Principle
    3. Commun ACM V50n11(Nov 2007)pp9-14
    4. =ESSAY RACE HAZARDS ARBITRATION SYNCHONISATION NON-SEQUENTIAL METASTABLE STATE flipflop Buridan
    5. CUP::= "No choice between near-simultaneous events can be made unambiguously within a preset deadline".
    6. 9 refs. Many examples: hardware, software, and mundane.

    Denning11

    1. Peter J Denning
    2. The profession of IT: The Grounding Practice
    3. Commun ACM V54n12(Dec 2011)pp36-40 [ 2043174.2043188 ]
    4. =IDEA CLAIMS EVIDENCE ARGUMENTS DATA cf TOULMIN
    5. Grounded_claim::=a claim accompanied by sufficient relevant supporting evidence.
    6. Objective vs subjective evidence.
    7. Also: plausibility, balance, commitment.
    8. Need to provide more than objective evidence when an innovation may change the culture.
    9. Some claims depend on community opinions. But beware truthiness.
    10. p40: Table describes the anatomy of a grounded claim.
    11. Get into the habit of noticing what kind of grounds are presented when people present claims.

    DenningDunham03

    1. Peter J Denning & Robert Dunham
    2. The Missing Customer
    3. Commun ACM V46n3(Mar 2003)pp19-23
    4. =FLAME CUSTOMER USER VALUE SATISFACTION TRUST ACADEMIC EDUCATION
    5. argues that IT professionals, academics, and companies can focus on technical excellence rather than the impressions that a customer gets of the profession/company.
    6. Four basic truths:=following
      Net
      1. Customers buy because of perceived future value but buy again because of remembered past satisfaction.
      2. customer: Actor.
      3. performer: Actor.
      4. something: Thing.
      5. performer provides something.
      6. something satisfies customer.
      7. customer trusts performer to provide something.
      8. performer trusts the customer will be satisfied by something.
      9. Note. money is not a required as part of this relationship.

      (End of Net)

    DenningDunham06

    1. Peter J Denning & Robert Dunham
    2. Innovation as Language Action
    3. Commun ACM V49n5(May 2006)pp47-52
    4. =ADVERT INVENTION INNOVATION PEOPLE
    5. Based on the Language-Action Perspective [Dennning03]
    6. Innovation is more than invention: innovation changes what people do.
    7. Most innovation is a normal process.
    8. Some innovations are bad and are|should be abandoned.
    9. Innovation size is measured by the number of people involved: 4..4M
    10. Innovation takes time.
    11. Most Innovations are incremental not radical.
    12. (dick)|-Viral innovation is effortless.
    13. Stresses the need to observe what is going on and listen to criticism during development.
    14. Claims there are seven skill areas or practices that can be learned that are needed: Sensing, Envisioning, Offering, Executing, Adopting, Sustaining + Leadership.
    15. Non-verbal communication ( body language, tone of voice, ...) are the most important part of these skills.
    16. Gives examples, tables, and references.
    17. (dick)|-the 7 practices fit perfectly into the classic SDLC(Software Development Life Cycle).
    18. Does not mention subversive innovations as in "The Inventors Dilemma".
    19. Used in my CSCI372 course 2006

    Denningetal89a

    1. P J Denning & D E Comer & D Gries & M C Mulder & A Tucker & A J Turner & P R Young
    2. Computing as a Discipline
    3. Commun ACM V32n1(Jan 1989)pp9-23
    4. =CURRICULUM education science ENGINEERING

    Denningetal89b

    1. Peter Denning (ed)
    2. A Debate on Teaching Computing Science
    3. Commun ACM V32n12 pp1397-1414(Dec 1989)
    4. =DEBATE education
    5. Dijkstra89 plus replies by 7 others also letters V33n3p264-271(Mar 1990) and V33n6pp628-630&633(Jun 1990)

    DenningEtAl08

    1. Peter J. Denning & Chris Gunderson & Rick Hayes-Roth
    2. The Profesion of IT: Evolutionary System Development
    3. Commun ACM V51n12(Dec 2008)pp- [ 1490360.1409371 ]
    4. =REPORT EVOLUTION PROCESS AGILE USA GOVERNMENT LTEs RISKS FITNESS
    5. Important to understand how fast a situation is changing and make sure that software is developed and delivered before the requirements change.
    6. USA procurement rules allow LTE -- Limited Procurement Experiments -- that don't follow the BDUF waterfall.
    7. Reports that the W2COG was able to deliver in 18 months an 80% complete version of software using LTE ($100K) and evolution while a parallel BDUF project delived only a concept document ($1.5M).

    DenningFloresLuzmore10

    1. Peter J Denning & Fernando Flores & Peter Luzmore
    2. The Profession of IT -- Orchestrating Coordination in Pluralistic Networks
    3. Commun ACM V53n3(Mar 2010)pp30-32 + Correspondence V53n6(Jun 2010)p6 + letter Ronnie Ward V53n2(Jun 2010)p6
    4. =ANECDOTE WoW SIMULATE TRAINING TEAMS CULTURES PEOPLE
    5. Claims that there is a need for effective multicultural distributed teams.
    6. Claims that certain values/activities help and can be learned in multiplayer style game environment like World of Warcraft.
    7. Values/activities
      1. Proficient in a practice essential to the team.
      2. Able to articulate vision of teams worth that others embrace.
      3. Make commitments and fulfill them.
      4. Spot and eliminate waste.
      5. Share assessments+moods+emotions to build & maIntain trust.
      6. Observe own history and link it to other's history.
      7. Able to Blend: dynamically align to own intentions+actions of others.

    8. Ronnie ward states the obvious that Email does not do enough to inspire teamwork.

    DenningFreeman09

    1. Peter J Denning & Peter A Freeman
    2. The Profesion of IT: computing's paradigm
    3. Commun ACM V52n12(Dec 2009)pp28-30 [ 1610252.1610256 ] +Letters V53n4(Apr 2010)pp6-7 [ Fulltext in citation ]
    4. =ESSAY SCIENCE MATHEMATICS ENGINEERING COMPUTING
    5. shared_paradigm::=initiation; conceptualization; realization; evaluation; action.
    6. (dick)|-Ignores analysis, maintenance, iterations, updating, and social processes.

    DenningHorning0202

    1. Peter J Denning & James J Horning
    2. Inside RISKS: Risks of Linear Thinking
    3. Commun ACM V45n2(Mar 2002)p120
    4. =ESSAY USER vs TECHNIQUE
    5. Quotes Donald Stokes (Pasteur's quadrant: basic science and technological innovation, Brooking's institute, 1997). 2><2: inspired by use >< quest for fundamental understanding. Pasteur(Y,Y), Bohr (N,Y), Edison(Y,N), and unnamed(N,N).
    6. Argues that software development is similar: focus on the user and focus on the technical aspects.

    DenningRiehle09

    1. Peter J Denning & Richard D Riehle
    2. The Profession of IT: Is Software Engineering Engineering
    3. Commun ACM V52n3(Mar 2009)pp24-26 [ 1467247.1467257 ]
    4. =POLEMIC ENGINEERS
    5. Things we do worse than engineers do:
      1. The Principle of least surprise.
      2. Design metrics -- including design to tolerances.
      3. Separating design from implementation.
      4. Reconciling conflicting forces and constraints.
      5. Adapting to changing environments

    6. Roles (one person plays many roles in a team) --
    7. software { architect, engineer, programmer, manager } | O(systems engineer).
    8. Need for Systems Thinking: From the hardware.... to the user environment.
    9. Need for better tools, education, adoption of effective practices.

    DenningYaholkovsky08

    1. Peter J Denning & Peter Yaholkovsky
    2. Getting to "We"
    3. Commun ACM V51n4(Apr 2008)pp19-24
    4. =ESSAY TOOLS PEOPLE TEAM WICKED PROBLEMS SYNERGY DESIGN Charettes
    5. Collaboration is when people create synergistic solutions|strategies
    6. Notes that tools support communication, coordination and cooperation rather than collaboration.

    Dent96

    1. Alan Dent(dent@highway1.com.au)
    2. Solo Software Engineering
    3. Software Development Magazine(Apr 1996)pp41+42+44-45
    4. =EXPERIENCE SOLO
    5. interuptions mean need for documentation
    6. recommends diarys: project diary+random thoughts diady+design decisions diary+code change diary
    7. User testing via self-hypnosis
    8. Version control system [ adsoftware ]

    Dern11

    1. Daniel P. Dern
    2. Lost programming skills: What today's coders don't know and why it matters
    3. ITWorld(Aug 5 2011) [ lost-programming-skills ]
    4. =POLL MANAGERS TECHNICAL LOST CODING

    DershowitzJouannaud90

    1. Nachum Dershowitz & Jean-Pierre Jouannaud
    2. Rewrite Systems
    3. Chapter 6 (pp243-320) of Leeuwen90.
    4. =THEORY STRINGS GRAMMARS

    DesaiEtal05

    1. Nirmit Desai & Ashok U Mallya & Amit K Chopra & Munindar P Singh
    2. Interaction protocols as design abstractions for business processes
    3. IEEE Trans Software Engineering V31n12(Dec 2005)pp1015-1027
    4. =THEORY MODEL BUSINESS PROCESS COMMITMENTS SCENARIOS OWL-P AGENTS ROLES π-CALCULUS
    5. Proposes a logic of commitments between agents.
    6. Uses sequence charts containing commitments to describe protocols.
    7. Implies that activity diagrams are a bad way to describe business processes. Entangles the internal logic of different agents with each other. So unstable.
    8. (dick)|-take home message: don't use control flows to model work flow.

    DesaiChopraSingh09

    1. Nirmilt Desai & Amit K Chopra & Munindar P Singh
    2. Amoeba: A methodology for modeling and evolving cross-organizational business processes
    3. ACM Transactions on Software Engineering and Methodology V19n2(Oct 2009)pp6.1-45
    4. =ADVERT 2 CASE STUDIES Amoeba REQUIREMENTS METHOD LOGIC COMMITMENTS SCENARIOS SEQUENCE CHARTS AXIOMS EVOLUTION AGENTS SERVICES ORCHESTRATION CHOREOGRAPHY
    5. Amoeba::Method= iterate( roles and interactions; contractual relationships -> Commitments; message meanings->create and manipulate commitments; Constraints; compose protocols -> process model).
    6. Uses the idea of business protocols as modules. These have messages and resulting changes in the commitments between components. For example CC(VENDOR, BUYER, pay(price), ship(goods)) would result from a VENDOR sending a quotation(price, goods) message to a BUYER.
    7. Theory [DesaiEtal05]

    DeselEtAl04

    1. Jorg Desel & Wolfgang Reisig & Grzegorz Rozenberg (Eds)
    2. Lectures on Concurrency and Petri nets: Advances in Petri Nets (LectureNotes in CSci 3098)
    3. SpringerVerlag NY NY 2004 ISBN 3540222618 CR 0511-1194
    4. =UNREAD =PAPERS NONSEQUENTIAL MODELS Petri TIMED AUTOMATA algebra TCP

    Desfray94

    1. Phillippe Desfray(SOFTEAM)
    2. Object Engineering: the Fourth Dimension
    3. Addison-Wesley Redwood City CA 1994 $36.95 ISBN 0-201-42288-3 CR9511-0834
    4. =TEXT OBJECT-ORIENTED [Desfray96]
        class-relation model, structuring, modeling, OMT, Chen+Petri+FSM?, hypergenericity::=model>->implementation

    Desfray94

    1. Phillippe Desfray(SOFTEAM)
    2. title
    3. IEEE Computer Magazine V29N2(Feb 1996)pp62-66
    4. =CASE-STUDY Hypergenericity client-server
    5. see [Desfray94] for details
        developed language H for mapping an anlytical class-relation model+annotations onto particular implementations via hypergeneric rules.

        Annotations of form @name(classes_to_which_it_applies).

        Typical rule:

      1. Adds a method with processing etc to an existing class.
      2. "for each attribute..."


    DesharnaisEtal98

    1. Jules Desharnais & Marc frappier & Ridha Khedri & Ali Mili
    2. Integration of Sequential Scenarios
    3. IEEE Trans SE V24n9(Sep 1998)pp695-678 CR9906-0431
    4. =THEORY RELATIONS Z SCENARIOS If pre(R)&pre(Q)=pre(R&Q) then demonic_meet(R,Q) ::= R&Q | Q~(pre(R)><post(Q)) | R~(pre(Q)><post(R)).
    5. Scenario as a digraph labelled by two kinds of relations: those describing environment actions and those defining system actions.
    6. Integration defined by union of environment actions and demonic meet of system actions.
    7. "the simple fact of formalizing a specification or a scenario is a step towards a better understanding of the system under consideration"

    Desilets08

    1. Alain Desilets
    2. Tell Me a Story
    3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp14-15
    4. =EXPERIENCE USER REQUIREMENTS STORIES
    5. Express user goals as simple, specific, and concrete stories about particular people getting valuable things.

    Desouza03

    1. Kevin C Desouza
    2. Barriers to effective use of Knowledge Management systems in software engineering
    3. Commun ACM V46n1(Jan 2003)pp99-100
    4. =SURVEY REPOSITORY KNOWLEDGE EXPERTISE PEOPLE
    5. Software engineers do not like being categorized as experts since it may type-cast them.
    6. Knowledge about software is hard to capture and categorize on a computer data base.
    7. Alternative (Human) systems may work better.
    8. Measure communication not just use of repository use.

    Desouza03b

    1. Kevin C Desouza
    2. Facilitating Tacit Knowledge exchange
    3. Commun ACM V46n6(Jun 2003)pp85-88
    4. =EXPERIENCE TEAM KNOWLEDGE
    5. People needed encouraging to use a game room on company time.
    6. Managers expected job-related knowledge to be shared in the room.
    7. Lotus notes was used fro sharing knowledge later and both game room and project oriented knowledge started to be posted.

    DesouzaAwazuTiwana06

    1. Kevin C Desouza & Yukika Awazu & Amrit Tiwana
    2. Four Dynamics for bringing use back into software reuse
    3. Commun ACM V49n1(Jan 2006)pp97-100
    4. =POLL 100 REUSE PEOPLE
    5. Traditional reuse of published artifacts works better among novice and transient developers.
    6. Uncovered evidence of three "knowledge spaces": private, public, and quasi-private.
    7. A knowledge space is a collection of artifacts that may be more or less reusable. Examples repositories, code libraries, ..., and CASE tools.
    8. Developers prefer to reuse stuff in their private space rather than the public space,
    9. Expert: if it isn't in my private space, it probably doesn't exist.
    10. Experts understand the interconnections better than novices and so tend to work with them rather than refactor into modules.
    11. Novices and rookies are risk averse and don't have a wide knowledge space so they tend to reuse public artifacts.
    12. Modularity encourages reuse.
    13. Reuse tends to occur within groups rather than across team boundaries. The teams have tacit shared knowledge that makes reuse more valuable.
    14. Transient teams tend to reuse public artifacts more than permanent ones. Repeated interaction between members of teams over a long time develops shared searching strategies.
    15. Notes application of theories to open source projects.

    DetlefsNelsonSax05

    1. David Detlefs & Greg Nelson & James B Sax
    2. Simplify: A theorem prover for program checking
    3. J ACM V52n3(May 2005)pp365-473 CR 0605-0494
    4. =UNREAD =DEMO TOOL PROGRAM PROVING V&V Simplify [click here [socket symbol] if you can fill this hole]

    Deursen01

    1. Arie van Deursen
    2. Customer Involvement in Extreme Programming -- XP2001 Workshop Report
    3. ACM SIGSOFT Software Engineering Notes V26n6(Nov 2001)pp70-73 & [ http://www.cwi.nk/~arie/wci2001/ ]
    4. =CONFERENCE XP USER CUSTOMER SQA
    5. Customer representatives are a vital role (not a person) in XP, they re responsible for the right system being built and may need training and support.
    6. Ask customers to add a "...so that..." clause to their User Stories that refers to the higher level goal.

    DeursenKlintVisser00

    1. Arie van Deursen & Paul Klint & Joost Visser
    2. Domain-Specific Languages: An Annotated Bibliography
    3. ACM SIGPLAN notices V35n6(Jun 2000)pp26-36
    4. =BIBLIOGRAPHY DOMAIN LANGUAGES DSL
    5. Project [ dsl ]

    DeursenKuipers99

    1. Arie van Deursen & Tobias Kuipers
    2. Identifying Objects using Cluster and Concept Analysis
    3. ICSE'99, Proceeedings of the 21st International Conference on Software Engineering (May 1999)pp246-255
    4. =EXPERIMENT Concept analysis beats cluster analysis [Snelting??]

    Deville90

    1. Yves Deville
    2. Logic Programming: Systematic Program Development
    3. Addison Wesley 1990 QA76.63.D48 CR9204-0201 & CR9102-0042
    4. =TEXT LOGIC PROGRAMMING
        Note pp14-17 outlines steps: Problem->Spec(predicates, multiplicity and directionallity)->first order logic->logic program.

        (MATHS suitable for expressing the Problem and perhaps the Spec as well.)


    Devlin01

    1. Keith Devlin
    2. The Real Reason why Software Engineers need Math
    3. Commun ACM V44n10(Oct 2001)pp21-22
    4. =ADVERT MATH
    5. Learning of specific mathematical skills is not important -- they may never be used in practice.
    6. Software practice demands abstract thinking.
    7. Repetitive practice in mathematics makes thinking about abstractions a familiar and so easier process.
    8. Evidence of rigorous algebra improving all scores!

    DevlinEtal03

    1. Keith Devlin (ed)
    2. Why Universities require computer science students to take math (special section)
    3. Commun ACM V46n9(Sep 2003)pp37-55
    4. =ESSAYS MATH
    5. Devlin: "Being smart is about doing, not knowing"... need to open up (train) abstr act ways of thinking. Bruce et al give examples of how math helps develop good software.
    6. Henderson argues for math in software engineering because need precise abstract th inking.
    7. Almstrum reports a survey of 500 computer professionals on why they were attracted to computing: 1:benefit, 2:Science and math, 3:experimenting, 4:being in the Vangu ard

    DevlinRosenberg96

    1. Keith Devlin & Duska Rosenberg(Brunel)
    2. Language at Work: analyzing communication breakdown in the workplace to inform systems design
    3. CSLI/Stanford Standford CA 1996 ISBN 1-57586-05101
    4. =EXPERIENCE SYSTEM MATHEMATICS: Situation theory
    5. LFZ::="Layered formalism and zooming".

    Dewan05

    1. Presan Dewan
    2. Teaching inter-object design patterns to freshman
    3. ACM SIGCSE Tech Symp Proc (Feb 2005)pp482-486
    4. =DEMO small Object-Oriented PATTERNS iterator MVC observer facade composite factory Java

    DewanRiedl93

    1. Prasun Dewan & John Riedl
    2. Toward Computer-Supported Concurrent Software Engineering
    3. IEEE Computer Magazine V26n1(Jan 1993)pp17-28
    4. =DEMO Flecse TECHNICAL TOOLS Concepts LIFECYCLE integration sharing NONSEQUENTIAL
        p21:"The module specifications do not clearly state the storage allocation rules, so, at an impasse, the programmers decide to suspend their synchronous interaction and think more about the problem."

    DharJarke88

    1. Dependency Directed Reasoning and learning in Systems Maintenance Support
    2. IEEE Trans Soft Eng VSE-14n2(Feb 1988)pp211-227
    3. =EXPERIENCE OBJECT-ORIENTED MAINTAINCE AI ONTOLOGY WHY
    4. maintenance aided by storing justification for existence of parts of the design in terms of other parts(including external parts). object hierarchy AI analogy generalization

    DiamondJ03

    1. Jared Diamond
    2. Guns, Germs, and Steel: The Fates of Human Societies
    3. Norton NY NY(2003) ISBN 0-393-31755-2
    4. =HISTORY PEOPLE CONNECTIONS COMPLEXITY INNOVATION GEOGRAPHY MIME TICS
    5. The differences between societies -- and who conquers who -- appear to depend on geography not genetics.
    6. Innovation happens most when there are large numbers of communicating and competing parts.
    7. The technologies of farming flow east-west more than North-South.
    8. Catalogs crops and domesticated animals by geography.
    9. The 2003 edition relates the theories to software development at Microsoft vs IBM etc.

    Diaz-Herrera93

    1. Jorge L Diaz-Herrera(SEI-CMU)
    2. The Importance of Static Structures in Software Construction
    3. IEEE Software Magazine(May 1993)pp75-87
    4. =IDEA GRAPHIC MODULAR HMD
    5. Hierarchical Modular Diagrams(HMD) GRAPHIC
        Argues that call-return structure does not determine a stable, safe, testable architecture.

        Proposes a new notation.


    DiazSligo97

    1. Michael Diaz & Joseph Sligo
    2. How Software Process Improvement Helped Motorola
    3. IEEE Software Magazine V14n5(Sep 1997)pp75-81
    4. =EXPERIENCE IMPROVEMENT CMM
    5. increased quality and lowered cycle time
    6. process defined by task leaders and preactitioners
    7. CMM lower levels pay off in higher levels

    DisneyJohnson98

    1. Anne M Disney & Phillip M Johnson
    2. Investigating Data QUALITY Problems in the PSP
    3. ACM SIGSOFT Software Engineering Notes V23n6(Nov 1998)pp143-152 & Proc 6th Int Symp on the Foundations of Software Engineering(Nov 1998)
    4. =ANALYSIS CASE-STUDY 10 students...

      [JohnsonDisney98]

    DistefanoScarpaPuliafito11

    1. Salvatore Distefano & Marco Scarpa & Antonio Puliafito
    2. From UML to Petrie Nets: the PCM-based Methodology
    3. IEEE Trans Software Engineering V37n1(Jan/Feb 2011)pp65-79
    4. =DEMO METHOD ESTIMATE PERFORMANCE UML NON-MARKOVIAN PETRIE NETS PCM

    Dichter93

    1. Carl Dichter
    2. Software Audits
    3. UNIX Review V11n10(Oct 1993)pp43-49
    4. =NEWS STANDARDS SQA QUALITY ISO SEI MATURITY
        Introduction to where and what of process assessment and audit
      1. ISO9000
      2. SEI CMM

    Dick05

    1. Jeremy Dick
    2. Design traceability
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp14-16
    4. =ESSAY traceability REQUIREMENTS DESIGN
    5. Value in knowing why something is needed or how a need is met.
    6. Defines implicit traceability and rich traceability.
    7. Review. Sufficient design? Necessary design?

    DickKrauseCozens90

    1. A J J Dick & P J Krause & J Cozens
    2. Computer Aided Transformations of Z into Prolog
    3. pp71-85 in Nicholls90
    4. =DEMO TOOL Z SPECIFICATION PROLOG PROTOTYPE
    5. prototype
    6. animation tool
    7. finds unintended non-determinism in Z specification

    Diehl07

    1. Stephan Diehl
    2. Software Visualization: Visualizing the structure, behavior, and evolution of sofware
    3. Springer Verlag NY NY 2007 ISBN 3540465049 CR 0809-0828 & 0810-0932
    4. =UNREAD =TEXT GRAPHIC CODE TECHNICAL [click here [socket symbol] if you can fill this hole]

    DiesteJuristo11

    1. Oscar Dieste & Natalia Juristo
    2. Systematic review and aggregation of empirical studies on elucidating techniques
    3. IEEE Trans Software Engineering V37n2(Mar/Apr 2011)pp283-304
    4. =SURVEY 30 EMPIRICAL REQUIREMENTS ELICITATION
    5. Covers until 2005.
    6. Guidelines
      1. Unstructured interviews(and perhaps structured interviews) are more effective than introspection and sorting
      2. And give more complete information
      3. But are less efficient.
      4. Introspection is worst!
      5. Laddering is preferable to sorting and introspection.

    DiesteJuristoShull08

    1. Oscar Dieste & Natalie Juristo & Forrest Shull
    2. Understanding the customer: What do we know about Requirements Elicitation
    3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp11-13
    4. =SURVEY USER REQUIREMENTS ELICITATION
    5. Many techniques and results, see [ s2voe.html ]
    6. Summary:
    7. Plan interviews in advance! Plan a Structure.
    8. Include general question when new to a domain.
    9. Introspective techniques are less useful.
    10. Sorting techniques not as useful as interviews but sometimes quicker.

    Dietz06

    1. Jan L G Dietz
    2. The deep Structure of Business Processes
    3. Commun ACM V49n5(May 2006)pp59-64
    4. =EXPERIENCE INTERACTION DESIGN LANGUAGE-ACTION PEOPLE REALITIES SYSTEMS
    5. Used the language action perspective to analyze and design interactions.
    6. Sample diagrams and jargon not well defined.
    7. Distinguishes language acts from performing acts.
    8. Mentions communication facts and performance facts... but not defined.
    9. Goal to extract the essential map of a process as a basis for discovering opportunities and designs.

    Digre98

    1. Tom Digre<tomd@dataaccess.com>
    2. Business Object Component Architecture
    3. IEEE Software Magazine V18n5(Sep/Oct 1998)pp60-69
    4. =THEORY DOMAIN ARCHITECTURE
    5. Boca::="Business Object Component Architecture", pseudoC.

    Dijkstra68a

    1. Edsger W Dijkstra
    2. Co-operating Sequential Processes
    3. "Programming Languages" Academic Press 1968
    4. =DEMO TECHNICAL non-sequential

    Dijkstra68b

    1. Edsger W Dijkstra
    2. GOTO statement considered harmful
    3. Letter Commun ACM 11 3 pp147-148 (Mar 1968)
    4. =EXPERIENCE =HARMFUL sequential

    Dijkstra68c

    1. Edsger W Dijkstra
    2. The structure of the "THE"-Multiprogramming System
    3. Commun ACM 11 5 pp341-346 (May 1968)
    4. =DEMO non-sequential formal analysis virtual machine

    Dijkstra72

    1. Edsger W Dijkstra
    2. The Humble Programmer - ACM Turing Award Lecture 1972
    3. see ACM86
    4. =HISTORY science

    Dijkstra74

    1. Edsger W Dijkstra
    2. Self-Stabilising systems in spite of distributed control
    3. Comm ACM V17n11(Nov 1974)pp643-644
    4. =THEORY TECHNICAL NONSEQUENTIAL
    5. Ref by letter from Xavier A Bebest(Hochhheim Germany) Comm ACM V38n2(Feb 1995)pp115-117

    Dijkstra76

    1. Edsger W Dijkstra
    2. A Discipline of Programming
    3. Prentice Hall Inc Englewood Cliffs NJ
    4. =TEXT guarded-commands sequential non-sequential formal logic structures

    Dijkstra89

    1. Edsger W Dijkstra
    2. On the Cruelty of Really Teaching Computer Science
    3. Talk at ACM Computer Science Conference Louisville Feb 1989(See [Denning89b] )
    4. =TALK formal logic education

    Dijkstra90

    1. Edsger W Dijkstra(Editor)
    2. Formal Development: programs and proofs
    3. Addison-Wesley 1990(U Texas Year of Programming Series)
    4. =MONOGRAPH FORMAL PROOFS

    Dijkstra01

    1. Edsgar W Dijkstra
    2. The End of Computing science?
    3. Commun ACM V44n3(Mar 2001)p92
    4. =IDEA COMPLEXITY SCIENCE
    5. |-Research is about what we don't know how to do.
    6. (above)|-we need to study intricacy and simplicity.
    7. "The average customer [...] expects his system to crash all the time."

    DilligDilligAiken10

    1. Isil Dillig & Thomas Dillig & Alex Aiken
    2. Reasoning about the unknown in static analysis
    3. Commun ACM V53n8(Aug 2010)pp116-123 [ 1787234.1787259 ]
    4. =DEMO LOGIC MATHEMATICS MODEL CHECKING C Linux may/must SOUNDNESS

    Dillon90

    1. Laura K Dillon
    2. Verifying General Safety Properties of Ada Tasking Programs
    3. IEEE Trans SE-16n1pp51-63(Jan 1990)
    4. =EXPERIENCE formal QUALITY non-sequential

    Dillonetal86

    1. Laura K Dillon & G S Avrunin & J C Wileden
    2. Constrained Expressions: Toward Broad Applicability of Analysis Methods for Distributed Software Systems
    3. COINS Tech Report 86-15 Univ of Amherst MA
    4. =THEORY PREDICTING regular DAD formal

    Dillonetal94

    1. Laura K Dillon & G Kutty & L E Moser & P M Melliar-Smith && Y S Ramakrishna
    2. A Graphical Interval Logic for Specifying Concurrent Systems
    3. ACM Trans Softw Eng Methodol V3n2(Apr 1994)pp131-165 [ 33145.html ] [ citation.cfm?id=192218.192226&coll=portal&dl=ACM&idx=J790&part=transaction&WantType=transaction&title=ACM%20Transactions%20on%20Software%20Engineering%20and%20Methodology%20%28TOSEM%29&CFID=1643654&CFTOKEN=8691090 ]

    4. =ADVERT NOTATION MODAL TEMPORAL LOGIC FORMAL GIL TOOL GILED
    5. GIL::="Graphic Interval Logic".
    6. Later see [RTGIL] -- real time GIL

    DillRushby96

    1. David L Dill(Stanford) & John Rushby(SRI International)
    2. Acceptance of Formal methods: Lessona from Hardware Design
    3. IEEE Computer Magazine V29N4(Apr 1996)pp23-24
    4. =HISTORY HARDWARE vs SOFTWARE TOOLS
      1. Cost needs to be justified
      2. Hardware has a small number of design elements.
      3. Formal treatment can pay off accross many applications
      4. Mechanize formal calculations to reduce cost
      5. A tool to find bugs (not all, but some) at a small cost per bug would make a clear payoff.

      6. Prime need: effective, pragmatic tools.

    DimaghaniDibble12

    1. Ania Dimaghani & Jim Dibble (Oracle Corp)
    2. Strategies for Early-Stage Collaborative Design
    3. IEEE Software Magazine V29n1(Jan/Feb 2012)pp39-45
    4. =ADVERT EXPERIENCE COLLABORATION DESIGN SUCCESS VISEO RECORD
    5. Good things to do
      1. Agree on and agenda and goals.
      2. Determine the target Users.
      3. Reframe requirements around users.
      4. Sketch the problem Domain.
      5. Drive to a solution.
      6. Foster communication -- may be, perhaps, it might, what do you think
      7. Evaluate as you go vs users and their needs.
      8. Mine disagreements -- learn the opposing viewpoint as well as your own.
      9. Don't sweat the details -- yet.
      10. Capture Decisions.

    6. Part of workshop [BakerHoekOssherPetre12]

    DimitrovSchietendorfDumke02

    1. Evgeni Dimitrov & Andreas Schietendorf & Reiner Dumke
    2. UML-based Performance Engineering Possibilities and Techniques
    3. IEEE Software Magazine V19n1(Jan/Feb 2002)pp74-83
    4. =ESSAY UML QUALITY PERFORMANCE OCL CONSTRAINTS STEREOTYPES TAGGEDVALUES STATECHARTS

    DingMateti90

    1. Chen Ding & Prabhaker Mateti
    2. A Framework for the Automated Drawing of Data Structure Diagrams
    3. IEEE Trans SE-V16 n5 pp543-557(May 1990) CR9207-0512
    4. =THEORY graphic ERD

    DingelGarlanJhaNotkin98

    1. J Dingel & D Garlan & S Jha & DNotkin
    2. Reasoning about Implicit Invocation
    3. ACM SIGSOFT Software Engineering Notes V23n6(Nov 1998)pp209-221 & Proc 6th Int Symp on the Foundations of Software Engineering(Nov 1998)
    4. =DEMO =THEORY PROOF ARCHITECTURE MODULARITY

    DingelLiang04

    1. Juergen Dingel & Hongzhi Liang
    2. Automating comprehensive safety analysis of concurrent programs using VeriSoft and TXL
    3. Proc SIGSOFT'04/FSE-12& ACM SIGSOFT Software Engineering Notes V29n6(Nov 2004)pp13-22
    4. =DEMO SQA AUTOMATED MODEL CHECKING TOOL ViP TXL plLTL Verisoft

    Dinh-TrongBieman05

    1. Trung T Dinh-Trong & James M Bieman
    2. The FreeBSD Project: A Replication Case Study of Open Source Development
    3. IEEE Trans Software Engineering V31n6(Jun 2005)pp481-494
    4. =POLL OPEN SOURCE PROCESS FreeBSD GNATS
    5. Replicates [MockusFieldingHerbsled02]
    6. FreeBSD has been developing for 10 years.
    7. A small group of up to 15 developers controlled the code base.
    8. No more than 50 top developers contributed most of the functionality.
    9. Some ceremony was needed to coordinate work but it is neither imposed nor veri fied.
    10. A larger group repairs defects fed by an even larger group of developers who r eport problems,
    11. A mechanism for separating stable from unstable code means that stable code will have a lower defect density than commercial feature tested code.
    12. The developers were users.

    dick

    1. Richard J Botting
    2. Comments on Item in this bibliography
    3. Various item in this bibliography [ newbib.html ] source code [ newbib.mth ]
    4. =METAINFORMATION
    5. I use the MATHS assertion syntax to add my annotations to items:
       		(dick)|-comment
    6. Direct quotations from original items are in double-quoted strings like this
       		page-number:"..."

    diSessaAbelson86

    1. Andrea diSessa & Harold Abelson
    2. Boxer: A Reconstructable Computational Medium
    3. Commun ACM V29n9(Sep 1986)pp859-868
    4. =ADVERT graphic nested boxes/text + sprites as objects+LOGO-like

    DittoMunakata95

    1. William Ditto & Toshinori Munakata
    2. Principles and Applications of Chaotic Systems
    3. Commun ACM V38n11(Nov 1995)pp96-107
    4. =THEORY CHAOS COMPLEXITY

    DittrichVaucouleurGiff09

    1. Yvonne Dittrich & Sebastien Vaucouleur & Stephen Giff
    2. ERP customization as software engineering: knowledge sharing and cooperation
    3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp41-47
    4. =EMPIRICAL VIDEOS DEVELOPERS INTERVIEWS DOCUMENTATION ADDON ENHANCE COMPLEX CODE
    5. Understanding the ERP is the main challenge. Communication. Apprenticeship. Studying code.
    6. Need more than user documentation to customize ERP.
    7. Separate new code from old code.
    8. A feature can effect tables , forms, code, etc. Crosscutting:.aspects?! Multilevel.
    9. (dick)|-more like maintenance than green field development.

    Dixmier84

    1. Jacques Dixmier
    2. General Topology
    3. Springer Verlag Undergraduate Texts in Maths 1984
    4. =MATHEMATICS

    DjuricDevedzic10

    1. Dragan Djuric & Vladan Devedzic
    2. Magic Potion: incorporating new development paradigms through metaprogramming
    3. IEEE Software Magazine V27n5(Sep/Oct 2010)pp38-44
    4. =ADVERT JAVA LISP JVM Modeling Spaces XML RDF/OWL DSL DOMAIN MODEL LOGIC ONTOLOGY UML MDA
    5. Clojure::= See http://clojure.org, Dialect of LISP that runs in the Java Virtual Machine.

    DladodHarmanOteroHu03

    1. J J Dladod & M Harman & M C Otero & L Hu
    2. An Empirical investigation of the influence of a s type of side effects on program comprehension
    3. IEEE Trans Software Engineering V29n7(Jul 2003)pp665-670
    4. =EXPERIMENT CODE TECHNICAL SIDEEFEECTS UNDERSTANDING C
    5. Compared answers of students to questions about C code with and without side effects (x++).
    6. Side effects make code harder to read.

    DobingParsons06

    1. Brian Dobing & Jeffrey Parsons
    2. How UML is Used
    3. Commun ACM V49n5(May 2006)pp109-113 + letterV49n8(Aug 2006)pp11-13 + CR 0705-0477
    4. =POLL GRAPHIC UML PRACTICE
    5. Frequency of diagrams/narratives use varies a lot between teams/projects.
    6. At least Half the projects are not use case driven --- more class diagram usage.
    7. Clients are involved in most diagram types.
    8. Use case narratives are used >70% by analysts and programmers.
    9. Use case naratives do not capture all requirements.
    10. UML is complex and could be understood better.

    DobricaNiemela02

    1. Liliana Dobrica & Eila Niemela
    2. A Survey on Software Architecture Analysis Methods
    3. IEEE Trans Software Engineering V28n7(Jul 2002)pp638-653
    4. =SURVEY 8 METHODS Architecture Qualities SAAM SAAMCS ESAAMI SAAMER ATAM SBAR ALPSM SAEM scenarios metrics

    Doernhoefer00

    1. Mark Doernhoefer(ed)
    2. Large vs Small. More on Programming in Small Teams
    3. ACM SIGSOFT Software Engineering notes V25n4(Jul 2000)pp13-18
    4. =DISCUSSION ONE-SIZE PROCESS
    5. What to do when you are successful small project engineer faced by a manager who expects lsrge scale processes.
    6. Methods and processes for small teams.

    Doernhoefer01

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: Free Software
    3. ACM SIGSOFT Software Engineering Notes V26n6(Nov 2001)pp19-28
    4. =ADVERT OPEN SOURCE WWW/NET GNU Linux FreeBSD Apache PHP MySQL OSDN Slashdot SourceForge OpenSource.org W3C

    Doernhoefer03a

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: GUI Building
    3. ACM SIGSOFT Software Engineering Notes V28n3(May 2003)pp13-21 [ http://www.acm.org/sigsoft/SEN/ ] ACM DL subscribers: [ 773126.773134 ]
    4. =SURVEY GRAPHIC USER GUI
    5. Dozen good WWW sites

    Doernhoefer03b

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: Database Design
    3. ACM SIGSOFT Software Engineering Notes V28n4(Jul 2003)pp11-20 [ http://www.acm.org/sigsoft/SEN/ ] ACM DL subscribers: [ ??? ]
    4. =SURVEY DATA DESIGN KNOWLEDGE
    5. 17 good WWW sites

    Doernhoefer04

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: XML
    3. ACM SIGSOFT Software Engineering Notes V29n3(May 2004)pp15-24 [ http://www.acm.org/sigsoft/SEN/ ] ACM DL subscribers: [ 986710.986718 ]
    4. =SURVEY XML MARKUP LANGUAGES
    5. Dozen or more good WWW sites related to the eXtensible Markup Language.

    Doernhoefer05

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: service oriented architecture
    3. ACM SIGSOFT Software Engineering Notes V30n6(Nov 2005)pp5-13 [ http://www.acm.org/sigsoft/SEN/ ] ACM DL subscribers: [ 1102107.1102116 ]
    4. =SURVEY WEB SERVICES SOA XML Sun BEA IBM ESB .NET CBD OASIS TOGAF ADM OWASP WS-I W3C Notes.Close
    5. Another excellent collection of web sites on a new topic/hype-fest.

    Doernhoefer06

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: Software Process Improvement
    3. ACM SIGSOFT Software Engineering Notes V31n1(Jan 2006)pp5-13 [ http://www.acm.org/sigsoft/SEN/ ] [ 1108768.1108783 ]
    4. =SURVEY PROCESS IMPROVEMENT CMM-I SEI SPICE PSP SWPI SEPO USNAVY SWEBOK

    Doernhoefer06a

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: Requirements Management
    3. ACM SIGSOFT Software Engineering Notes V31n2(Mar 2006)pp17-25 [ 1118537.1118553 ]
    4. =SURVEY NET REQUIREMENTS
    5. Excellent survey of resources on the web [ http://www.jiludwig.com/ ] [ requirements_management.htm ] [ index.php ] [ reqtracing.html ] [ AgileArticlesCatSearch?category=Requirements ] [ read.php ] (tools) [ p2_req.htm ] [ life_cycle_management.jsp ] [ Methodology ] [ reqanalysis.html ] [ http://www.telelogic.com/ ] [ reqfrm.htm ] plus lots more...

    Doernhoefer06b

    1. Mark Doernhoefer
    2. Surfing the net for software engineering notes: The semantic Web
    3. ACM SIGSOFT Software Engineering Notes V31n3(May 2006)pp8-16
    4. =SURVEY SEMANTIC WEB ONTOLOGY URI OWL RDF DAML SPARQL Jena pOWL Protege SWOOP
    5. Links [ sw ] [ swintro ] [ uri-schemes.html ] [ RDF ] [ owl-features ] [ http://www.daml.org ] [ rdf-sparql-query ] [ j-sparql ] [ index.html ] [ j-jena ] [ http://powl.sourceforge.net ] [ http://protege.stanford.edu ] [ SWOOP ] (editors) [ http://dublincore.org ] (DCMI) [ home ] [ URI ] (URIs must be static.... Tips)

    Doernhoefer07

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: Database Technology
    3. ACM SIGSOFT Software Engineering notes V32n4(Jul 2007)pp10-19 [ surfing.html ]
    4. =REVIEW WEB/NET DATA

    Doernhoefer07a

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: User Interface Design
    3. ACM SIGSOFT Software Engineering notes V32n5(Sep 2007)pp7-16 [ surfing.html ]
    4. =REVIEW WEB/NET USER SIGCHI HCI MVC FOX Webby Suck

    Doernhoefer08

    1. Mark Doernhoefer
    2. Surfing the Net for Software Engineering Notes: Requirements
    3. =REVIEW WEB/NET REQUIREMENTS
    4. ACM SIGSOFT Software Engineering Notes V33n3(May 2008)pp7-16 [ 1360602.1360606 ]
    5. Includes

    Doernhoefer08b

    1. Mark Doernhoefer
    2. Surfing the net for software engineering notes: Computer People
    3. ACM SIGSOFT SEN V33n4(Jul 2008)p7-16 [ 1384139.1384149 ]
    4. =SURVEY WEB BIOGRAPHIES PEOPLE
    5. Allan Turing, John von Neumann, John W Mauchly, J Presper Eckert, C A R Hoare, Edsger Dijkstra, David Parnas, Grace Murray Hopper, Barry Boehm, Frederick Brooks, Brian Kernighan, Dennis Ritchie, Ken Thompson, Alan Perlis, Niclaus Wirth, Donald Knuth, Richard Hamming, Edgar Frank Codd, Gordon Bell, Gary Kildall, ...

    Doernhoefer09

    1. Mark Doernhoefer
    2. Surfing the net for software engineering notes: Tool Time
    3. ACM SIGSOFT SEN V34n1(Jan 2009)pp7-16 [ 1457516.1457519 ]
    4. =SURVEY TOOLS Eclipse NetBeans MySQL PostGresSQL Apache Tomcat JBoss Caucho Resin ArgoUML C# .Net Subversion CVS FindBugs PMD Pentaho W3C VALIDATION LINK CHECKER

    Doernhoefer09a

    1. Mark Doernhoefer
    2. Surfing the net for software Engineering notes -- Software and System Reliability
    3. ACM SIGSOFT Software Engineering Notes V34n3(May 209)pp6-15 [ 1527202.1527204 ] (PDF)
    4. =SURVEY =LINKS RELIABILITY
    5. Handbook [ http://www.cse.cuhk.edu.hk/~lyu/book/reliability/ ]
    6. The Reliability Information Analysis Center [ http://www.theriac.org/ ]
    7. The Data and Analysis Center for Software [ https://www.thedacs.com/databases/url/key/2/ ]
    8. Relex Reliability Dictionary [ ReliabilityDictionary.asp ]
    9. Weibull.com [ http://www.weibull.com/ ]
    10. NASA Software Assurance Technology Center [ http://satc.gsfc.nasa.gov ]
    11. IEEE Reliability Society [ index.jsp?&pName=relsoc_home ]
    12. City University Centre for Software Reliability [ http://www.csr.city.ac.uk ]
    13. Reliability Engineering Tools [ tools.htm ]
    14. ...
    15. IEEE Transactions on Software Engineering(1993) [ toc.cfm?id=173802&type=issue&coll=GUIDE&dl=GUIDE&CFID=29760540&CFTOKEN=27889279 ]
    16. Dependable Embedded Systems [ http://www.ece.cmu.edu/~koopman/des_s99/sw_reliability/ ]
    17. ...
    18. Reliability Calculators [ AvailabilityTranslator.htm ] [ reliability_calculator ]

    Doernhoefer09b

    1. Mark Doernhoefer
    2. Surfing the net for software Engineering notes -- Empirical Software Engineering
    3. ACM SIGSOFT Software Engineering Notes V34n3(Jul 2009)pp4-16 [ 1543405.1543409 ] (PDF)
    4. =SURVEY =LINKS EMPIRICAL EXPERIMENTAL EXPERIENCE POLLS SURVEYS
    5. LInks to Journals, Groups, Courses, Conferences all concerned with gathering data and fitting theories to software development.

    Doernhoefer09c

    1. Mark Doernhoefer
    2. Surfing the net for software engineering notes: computer science
    3. ACM SIGSOFT SEN V34n5(Sep 2009)pp8-17 [ 1598732.1598752 ]
    4. =SURVEY SWEBOK SigACT ALGORITHMS CALGO NUMERICAL NIST GAMS DATA STRUCTURES THEORY HARDWARE TM OS IMBOK FUZZY LOGIC PROGRAMMING LANGUAGES

    Dolado00

    1. Jose Javier Dolado
    2. A Validation of the Component-Based Method for Software Size Estimation
    3. IEEE Trans Software Engineering V26n9(Sep 2000)pp1006-1021
    4. =EXPERIMENT 46 SIMULATED BUSINESS Informix-4GL ESTIMATE LOC CBM FPs
    5. component := menu | input | report_and_enquiry.
    6. stats: regression, neural nets, genetic programming.
    7. NOC::= number of components.
    8. example: LOC = 116 + 75 *inputs + 73 *menus + 68 * reports.
    9. NOC increases with LOC. NOC/LOC decreases with LOC from 0.03 to 0.005. Type of components matter.

      [VernerTate92]

    Dolev00

    1. Shlomi Dolev
    2. Self-Stabilization
    3. MIT press 2000 $40 ISBN 0-262-04178-2 CR0006-0360
    4. =MONOGRAPH THEORY NONSEQUENTIAL RELIABILITY

    DongYangZhang07

    1. Jing Dong & Sheng Yang & Kang Zhang
    2. Visualizing Design Patterns in Their Applications and Compositions
    3. IEEE Trans Software Engineering V33n7(Jul 2007)pp433-453
    4. =DEMO TOOL VisDP UML PROFILE PATTERNS GRAPHICS WEB SERVICE XMI J2EE java.awt
    5. Need to show how one object/class plays many roles depending on the patterns.
    6. Defines an UML profile to show how classes/attributes/operations take part in design patterns.
    7. Demonstartes the clutter that appears with different ways of displaying this information.
    8. Demonstrates a tool that will make design paterns visible as requested by the user.

    DonnellanEtal05

    1. Brian Donnellan & Brian Fitzgerald & Brian Lake & John Sturdy
    2. Implementing an Open Source Knowledge Base
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp92-95
    4. =COMPARISON TOOLS KB OPEN SOURCE COSPA MetaData DSpace LAMP Data Centric KMS Lotus Notes
    5. KB::="Knowledge Base", part of an expert system, the body of knowledge available for the inference engine to use.
    6. Dublin_Core::standard= See http://dublincore.org.
      (Open archives initiative Protocol for Metadata Harvesting): framework [ http://www.openarchives.org ]

    7. Only works well when it evolves with the needs of the users.

    Donnelly00

    1. Daniel Donnelly
    2. In your Face Too!
    3. Rockport Pubs Inc., Gloucester MA, 2000 ISBN 156496-677-1
    4. =EXAMPLES interactive interfaces CD-ROM DVD web/net kiosks user HCI

    Donzelli 06

    1. Paulo Donzelli
    2. A Decision Support System for Software Project Management
    3. IEEE Software Magazine V23n4(Jul/Aug 2006)pp67-75
    4. =DEMO SIMULATION QUEUING NONSEQUENTIAL PROCESS ESTIMATION STAFFING + COCOMO REQUIREMENTS QNAP2 NASA SEL
    5. Two level model: artifacts circulate around workstations, work station parameters determined by COCOMO.
    6. Predicts staffing requirements -- completely ignoring Brooke's Law.
    7. Changing requirements add more work later in the project and extend time to complete by about 30%
    8. Comparable with staffing profile from SEL project with high instability.
    9. For a survey of other process models see [AcunaJuristo05].

    Doolan92

    1. E P Doolan
    2. Experience with Fagan's Inspection Method
    3. Software - Practice & Experience V22n2(Feb 1992)pp173-182
    4. =EXPERIENCE QUALITY V&V INSPECTIONS REQUIREMENTS
    5. Each personel-hour of inspection saved cost of 30 personel-hours of fixing

    DoppkeEtal98

    1. John C Doppke & Dennis Heimbigner & Alexander L Wolf
    2. Software Process Modeling and execution within Virtual Environments
    3. ACM ToSEM V7n1(Jan 1998)pp1-40
    4. =DEMO PROCESS can be described game(MUD/MOO) using lambdaMOO

    Dorfman99

    1. Merlin Dorfman
    2. Commercial vs Aerospace Worlds: comparing software engineering cultures
    3. IEEE Software Magazine V16n6(Nov/Dec 1999)pp97-100
    4. =ESSAY EXPERIENCE
    5. one size does not fit all
    6. comercial: - smaller projects +Time to market -new methods - new tools - funding + hope - time accounting - costing - estimating

    Dori08

    1. Dov Dori
    2. Words from Pictures for Dual-Channel Processing
    3. =DEMO TOOL GRAPHIC NATURAL LANGUAGE SYSTEM DESIGN MODELLING OPM OPD OPL OPCAT FSM
    4. Commun ACM V51n5(May 2008)#7pp47-52
    5. Claims that automatically linking diagrams to text makes process more intuitive. [MillerJ02]

    Doublait97

    1. Stephane Doublait
    2. Standard Reuse Practices: Many Myths vs a Reality
    3. ACM StandView V5n5(Sep 1997)pp84-91
    4. =EXPERIENCES at Sodalia(ISO9001& CMM=2)

    Douglass99

    1. Bruce Powel Douglass
    2. Components: Logical, Physical Models
    3. Software Development Magazine V7n12(Dec 1999)pp52-54
    4. =ADVERT OBJECT-ORIENTED METHOD UML ROPES COMPONENTS
    5. Components are runtime plugin Binaries not objects .Note UML components include data files, web pages, source code, etc etc.

    Douglass99b

    1. Bruce Powel Douglass
    2. Doing Hard Time: developing real-time systems with UML, Objects frameworks, and patterns
    3. Addison Wesley, Longman 1999 ISBN 0-201-49837-5 QA46.6 D655 1999 includes CDROM
    4. =TEXTBOOK ADVERT UML Rhapsody TMING NONSEQUENTIAL ROPES Object-Oriented
    5. special stereotypes pp48-52
    6. 5 safety patterns pp116-124
    7. Mechanistic design
    8. 12 state-behavioral-patterns, table pp 590-591.
    9. Many patterns recur in different parts.
    10. RMA:: theory = Rate Monotonic Algorithm, requires sum [i : 1..n](worst [i ] / period [i ] ) < n*( 2**(1/ n )-1).
    11. has some UML errors:
      1. multiplicity "1" when should be "0,1" or "2",
      2. Collaboration diagrams show classes rather than objects,
      3. composition put in collaboration diagrams and mis-defined,
      4. some activity diagrams are flowvharts, etc..

    Douglass04

    1. Bruce Powell Douglass
    2. Real Time UML (3rd edn): Advances in the UML for Real-Time Systems
    3. Pearson Education Boston MA 2004 ISBN 0-321-16076-2 (Addison-Wesley Object Technology Series)
    4. =TEXT QUALITIES PURPOSE PERFORMANCE TIMING RELIABILITY UML ROPES PATTERNS
    5. No mention of OCL and some diagrams have non-standard UML notations.
    6. Introduction to and examples of PTS profile and RT-UML [OMG020302].
    7. ROPES::="Rapid Object-Oriented Process for Embedded Systems".
    8. Quotes (misquotes?) the Rate Monotone Analysis bound.
    9. Older and subtly different [Douglass99b].

    DowdyFoster82

    1. Comparative Models of the File Assignment Problem
    2. ACM Comp Surveys V14 n2 (Jun 1982) pp287-313 see also V15 n1 pp87-89
    3. data optimization Technical

    DownsA00

    1. Andrew Downs
    2. From Engineer to Technical Lead
    3. Software Development Magazine V8n4(Apr 2000)pp72-74
    4. =EXPERIENCE PEOPLE code reviews

    DownsClareCoe8792

    1. Ed Downs & Peter Clare & Ian Coe
    2. Structured Systems Analysis and Design Method
    3. Prentice Hall International (UK) Herts UK 1988(1st edn) & 1992(2nd Edn) CR9305-0292
    4. =TEXT SSADM management COMPACT
    5. COMPACT for Office systems
    6. 2nd Edn has Combined viewpoint diagrams(CCTA 1990) : two parts control+Process

    Dowson86

    1. M Dowson(ed)
    2. Iteration in the Software Process
    3. Proc of the 3rd Int Software Process Workshop (Nov 1986)
    4. =PROCEEDINGS non-sequential lifecycle PROCESS ITERATION AGILE

    Drake96

    1. Thomas Drake
    2. Measuring Software Quality: A Case Study
    3. IEEE Computer Magazine V29n11(Nov 1996)pp78-87
    4. NSA SEATC(Software Engineering Applied Technology Center)
    5. =EXPERIENCE TECHNICAL QUALITY
    6. 25MLoC benefits Kiviat Diagrams profile many Qualities of code

    Dribin96

    1. Lawrence S Driben
    2. Defining Design Terminology(letter)
    3. IEEE Software Magazine V13N3(May 1996)p8
    4. external design vs internal design: which is the true architecture?

    DrobkaNoftzRaghu04

    1. Jerry Drobka & David Noftz & Rekha Raghu
    2. Piloting XP on four mission-critical projects
    3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp70-75
    4. =EXPERIENCE XP AGILE 4 Motorola Projects
    5. Gained a minimum of 260% productivity vs waterfall (incremental was 162%) with 70-90% test coverage, and with a 51..75% improvement in quality (defects at system test/KAELOC)
    6. High morale and confidence, training easier.
    7. Challenges: fitting with non-XP projects and managers. Need thorough training and coaching.
    8. Did an initial "blitz" software architecture rather like Unified Process.

    Dromey88

    1. RG Dromey
    2. Systematic Program Development
    3. IEEE Trans Soft Eng SE-V14n1(Jan 1988)pp12-29
    4. formal

    Dromey90

    1. Geof Dromey
    2. Program derivation: the development of programs from specifications
    3. Addison-Wesley Reading MA 1990 TEXT FORMAL METHOD

    DromeyChorvat90

    1. RG Dromey & TA Chorvat
    2. Structure clashes -- an alternative to program inversion
    3. Comput J V33n2(Apr 1990)pp126-132
    4. JSP

    Drucker85

    1. Peter Drucker
    2. Innovation and Entrepreneurship
    3. Harper Business 1993, Harper Perennial 1985
    4. =EXPERIENCES INNOVATIONS ENGINEERING BUSINESS ANALYSIS
    5. Innovation includes: searching for opportunity & analysis & listening & Focus & leadership. Opportunities include: unexpected events, incongruities, process need, change of industry structure, demographics, change of mood or perception, and new knowledge.

    DuJingLiu12

    1. J Du J & S Jing & J Liu
    2. Creating shared design thinking process for collaborative design
    3. Journal of Network and Computer Applications V35n1(2012)pp111-120
    4. =DEMO ENGINEERING RATIONALE TOOL TEAMTHINK S-DTPM cf COMPENDIUM IBIS TOULMIN
    5. Ideas about designs are issues, options, solutions, rules, criteria, and annotations.
    6. There are operations for sharing perspectives: Argument, evolution, association, fusion.
    7. Very weak evidence: one demo/case-study with 2 people.

    DubocRosenblumLetier10

    1. Leticia Duboc & David S Rosenblum & Emmanuel Letier
    2. Death, Taxes, & Scalability
    3. IEEE Software Magazine V27n4(Jul/Aug 2010)pp20-21
    4. =ADVERT REQUIREMENTS KAOS QUALITY REALITY SCALABILITY LAS HMRC
    5. Scalability is not just about performance but impacts other qualities and even functionality.
    6. Scalability is not defined well in most projects. Examples: LAS (London Ambulance System) & HMRC (UK Revenue and Customs).
    7. Scalability requirements can be stated in such away that they can not be met by a finite system. This has to be spotted and fixed. All scalability requirements need to be critiqued.
    8. Scalability is always relative to the reality and the system surrounding the software. These must be defined as assumptions. They must then be challenged.
    9. Analyzing how a system will fail to scale leads to better systems -- for example adding emergency procedures and back up processing power.

    DucasseLanza05

    1. Stephane Ducasse & Michele Lanza
    2. The Class Blueprint: visually supporting the understanding of classes
    3. IEEE Trans Software Engineering V31n1(Jan 2005)pp79-90
    4. =EXPERIMENTAL GRAPHIC Object-Oriented code metrics structure smalltalk
    5. Classifies attributes and methods into layers: initialization, interface, internal implementation, accessors, attributes.
    6. Attributes and methods shown as boxes. Metrics mapped to height and width. Type to color.
    7. Caller-callee link goes from bottom of caller box to top of called.
    8. Tested on real code. and by a dozen students (all found it helpful).

    DueckCormack90

    1. G D P Dueck & G V Cormack
    2. Modular Attribute Grammars
    3. Computer Jnl V33n2(Feb 1992)pp164-173

    DuenasEtAl07

    1. Juan C Duenas & Hugo A Prada G & Felix Cuado & Manuel Santillan & Jose L Ruiz
    2. Apache and Eclipse: Comparing open source project incubators
    3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp90-98
    4. =EMPIRICAL COMPARISON 2 F/OSS PROCESSES PROJECT INITIATION LIFE CYCLE ANALYSIS
    5. Incubation is the process of developing and defining new project/subprojects to be further developed and integrated into a the current (evolving) system.
    6. Apache and Eclipse have well defined processes and share many features (Table 1 page 97)

    DugganByrneLyons04

    1. Jim Duggan & Jason Byrne & Gerard J Lyons
    2. A task allocation optimizer for Software Construction
    3. IEEE Software Magazine V21n3(May/Jun 2004)pp76-82
    4. =DEMO PEOPLE PROCESS PLAN ALGORITHM MOEA
    5. Allocating people to tasks has many objectives: time & defects.
    6. Multiobjective optimizer computes Pareto-optimal set using elitist genetic algorithm.
    7. Human picks one.
    8. dominates::@(solution, solution), x dominates y iff for all f:objectives(f(x)better_than f(y).
    9. Pareto_optimal_set::@(solution)= {x. for no y(y dominates x)}.

    DumasParsons95

    1. Joseph Dumas & Paige Parsons
    2. Discovering the Way Programmers Think about New Programming Environments
    3. Commun ACM V38n6(Jun 1995)pp45-56
    4. Dylan USER PROTOTYPE
    5. OODL::=OBJECT-ORIENTED with automated memory management & dynamic linking & incremental development & self-identifying objects
        Previous experiences make it hard to spot new oportunities and idea in HCI Programmers think in terms of files and documents.

      Dumay04

      1. Mark Dumay
      2. Business Processes: the theoretical impact of process thinking on information development
      3. arXive.org e-print archive Sun, 19 Sep 2004 09:56:24 GMT [ 0409037 ]
      4. =ESSAY POSTMODERN SYSTEMS PEOPLE SOCIOLOGY BPR RISKS PROCESS vs FUNCTIONS TECHNOCRACY =SURVEY SOCIOLOGY
      5. Argues that Business Process Reengineering tends to fail because they expect & require people to fit the process not vice versa.
      6. Business Process ReEngineering deliberately uses information technology to impose a process view on an organization... ignoring the existing culture, structure, management, etc.

      Duncan79

      1. Fraser Duncan
      2. Microprocessor Programming & Software Development
      3. Prentice Hall International
      4. =harmful Technical =MANUAL highlevel assembler

      DunlopBasili82

      1. DD Dunlop & VP Basili
      2. Comparative Analysis of Functional Correctness
      3. Comp Surveys v14n2(Jun 1982)pp229-244
      4. theory SQA

      Dunne95

      1. Alex Dunne
      2. The Office Environment's Trickle-Down Effect(Editorial)
      3. Software Development Magazine(Oct 1995)pp7-8
      4. POLL more readers(26%) need better communication at all levels than anything else. Then more time and a clear view of requirements and a more defined process.

      Dunn03

      1. William R Dunn
      2. What
      3. IEEE Computer Magazine V36n11(Nov 2003)pp40-46
      4. =ESSAY RISKS COST MITIGATION HAZARD MISHAP
      5. What is an acceptable risk? How to achieve it?

      DunsmoreRoperWood03a

      1. Alastair Dunsmore & Marc Roper & Murray Wood
      2. The Development and Evaluation of Three diverse techniques for object-oriented code inspection
      3. IEEE Trans Software Engineering V29n8(Aug 2003)pp673-686
      4. =EXPERIMENT V&V SQA CODE TECHNICAL INSPECTIONs Object-Oriented Java delocalization use-case checklists abstraction
      5. 69 SoftEng. students U Strathclyde. 200 LoC 2 classes extending known software 90 minutes 14 defects.
      6. 3 reading techniques: (abstraction, checklist, use case)-based.
      7. abstraction: write specification for methods...
      8. Possibly significant differences between detection rates: means: checklist>abstraction>use case. all ranges from 2-11 out of 14.
      9. None good at spotting omissions.
      10. None found a subtle misuse of a class library.
      11. (dick)|-some evidence that the chance of detecting a defect is independent of the reading method.
      12. More readable with more examples [DunsmoreRoperWood03b]

      DunsmoreRoperWood03b

      1. Alastair Dunsmore & Marc Roper & Murray Wood
      2. Practical code inspection techniques for Object-Oriented systems: and experimental comparison
      3. IEEE Software Magazine V20n4(Jul/Aug 2003)pp21-29
      4. =ADVERT V&V SQA CODE TECHNICAL INSPECTIONs Object-Oriented Java delocalization use-case checklists abstraction
      5. Static and dynamic views.
      6. Results and stats in [DunsmoreRoperWood03a]

      Durfee01

      1. Edmund H Durfee
      2. Scaling Up Agent Coordination Strategies
      3. IEEE Computer Magazine V34n7(Jul 2001)pp39-46
      4. =SURVEY AGENTS PROBLEMS STRATEGIES

      DutertreStavidou97

      1. Bruno Dutertre & Victoria Stavidou
      2. Formal Requirements Analysis of an Avionics Control System
      3. IEEE Trans Softw Eng VSE23n5(May 1997)pp267-278
      4. =DEMO V&V REQUIREMENTS LOGIC TOOLS TIMING RISKS REALITY PVS [PVS]
      5. model of time and clocks
      6. exposed some unstated assumptions about REALITY and one defect

      Dutton93

      1. James E. Dutton<dutton@parcplace.com>
      2. Commonsense Approach to Process Modeling
      3. IEEE Software Magazine(July 1993)pp56-64
      4. =IDEA PROCESS MODELING DFDs
      5. ProSLCES VPML::= DFDs+StructuredText
          p61. ref to Osterweil87

          p61. " dataflow[...]seems to be a natural way for people to think about [processes]. After surveying several process-definition efforts, we found that almost all of them used some sort of dataflow notation as a first approximation -- and sometimes as final documentation".


      DuvalHodgins06

      1. Erik Duval & Wayne Hodgins
      2. Standardized Uniqueness: Oxymoron or Vision of the Future
      3. IEEE Computer Magazine V39n3(Mar 2006)pp96-98
      4. =STANDARD EDUCATIONAL OBJECTS METADATA LOM IEEE1484 LTSC XML
      5. The IEEE1484 standard specifies the information to be recorded about "Learning Objects": artifacts that help you learn.
      6. The standard is MODULAR separating logical structure from physical bindings.
      7. The standard defines many data elements in a hierarchical data model but every part is optional.
      8. How to make the metadata invisible?

      Dvorak94

      1. Joseph Dvorak<dvorak@ast.dsd.northrop.com>
      2. Conceptual Entropy and its effect on Class Hierarchies
      3. IEEE Computer Magazine V27n6(Jun 1994)pp59-63

      Dwelly00

      1. Andrew Dwelly
      2. XML, Reflective pattern matching, and Java
      3. Dr. Dobbs Journal #313(Jun 2000)pp46+50-51+54
      4. =DEMO TECHNICAL Marius DDD HARMFUL

      Dwyer81

      1. Barry Dwyer
      2. A User-friendly Algorithm
      3. Commun ACM V24n9(Sep 1981)pp556-561 [ 358746.358751 ]
      4. =EXPERIENCE USER BEHAVIORISM PEOPLE HCI BEHAVIOR MODIFICATION
          SUMMARY: The interface between a person and a computer can be looked at from either side. Programmers tend to view it from the inside; they consider it their job to defend the machine against errors made by its users. From the outside, the user sees his/her problems as paramount. He/she is often at odds with this complex, inflexible, albeit powerful tool. The needs of both people and machines can be reconciled; users will respond more efficiently and intelligently if they receive meaningful feedback. A "user-friendly" algorithm that covers a wide range of interactive environments and is typical of most operating systems and many application programs is presented.

      5. Correspondence [McMahon82] Critiquing this approach -- skinnerian -- with Dwyer's rebuttal.

      DwyerM92

      1. Michael Dwyer(IBM Corp)
      2. The Cleanroom approach to quality software development
      3. John Wiley& Son NYNY 1992
      4. ISBN 0-471-54823-5
      5. CR9211-0861 Review [Humphrey93]

      Dyadkin94

      1. Lev J Dyadkin<ldyad@lahey.com>
      2. Multibox Parsers
      3. ACM SIGSOFT Software Engineering Notes V19n3(Jul 1994)pp23-26
      4. DDD FORTRAN
          see Dyadkin95 (almost identical)

      Dyadkin95

      1. Lev J Dyadkin<ldyad@lahey.com>
      2. Multibox Parsers: No More Handwritten Lexical Analyzers
      3. IEEE Software Magazine V12n5(Sep 1995)pp61-67 & see Dyadkin94
          Note. Compare Conway63!
        1. FORTRAN 90 needs 8 boxes to lex parse it.
        2. Most code generated automatically from generic boxes.
        3. 96% of the lexer automatically generated!
        4. Easily ported to other platforms.
        5. Use fast LL(1) processes.
        6. Does not run slower than another FORTRAN 90 compiler(Salford).

      Dyba00

      1. Tore Dyb'a
      2. Improvisation in small Software Organizations
      3. IEEE Software Magazine V17n5(Sep/Oct 2000)pp82-87
      4. =SURVEY 120 managers in 55 Norwegian companies. PROCESS One-SIZE CMM
      5. Larger organizations reduce exploration in turbulent environments but small ones increase it.
      6. In a turbulent environment success requires mix exploiting known and predictable skills with exploring unpredictable new ideas.
      7. Theory: Variance helps survival. Failure is inherent in seeking to succeed in dynamic situations.
      8. Compare with [Highsmith99b] and [Highsmith99]

      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. See [Dyba00].

      Dyba05

      1. Tore Dyba
      2. An Empirical investigation of the Key Factors for success in Software Process Improvement
      3. IEEE Trans Software Engineering V31n5(May 2005)pp341-424
      4. =POLL 120 ORGANIZATIONS IMPROVEMENT SPI STATISTICS
      5. p421: "organizational issues are at least as important in SPI as technology, if not more so."
      6. Results suggest the following,
        1. Align improvement goals with business. Share knowledge between business and software experts.
        2. Management provides resources not leadership in SPI.
        3. Involve the developers/workers in creating the proposed changes and metrics.
        4. Focus on the measurement of success.
        5. Look for existing knowledge to exploit and/or explore for new knowledge
        6. Encourage workers/developers to explore new ideas because this involves them in the process.

      DybaDingyrMoe04

      1. Tore Dyba & Torgeir Dingyr & Nils Brede Moe
      2. Process improvement in practice: a handbook for IT companies
      3. Kluwer Academic, Norwell MA 2004 ISBN 1402078692 CR 0511-1197
      4. =HANDBOOK SOFTWARE PROCESS IMPROVEMENT SPI

      DybaDingsoyr09

      1. Tore Dyba & Torgeir Dingspoyr
      2. What do we know about agile software development
      3. IEEE Software Magazine V26n5(Sep/Oct 2009)pp6-9 + Correspondence V26n6(Nov/Dec 2009)p8
      4. =SURVEY EMPIRICAL RESEARCH AGILE XP
      5. Agile processes can improve customer satisfaction, productivity and job satisfaction.
      6. They can be difficult to introduce into a large organization.
      7. Being the onsite customer is stressful and hard to sustain.
      8. A Team needs a strong focus on both the interpersonal and the team goals.
      9. Skill and experience helps.
      10. May not be the best approach for large projects.
      11. Need more research.
      12. (William Adams)|-fads, bullets, need to match situation to method/process.

      DybaEtAl07

      1. Tore Dyba & Erik Arisholm & Dag I K Sjoberg & Jo E Hannay & Forrest Shull
      2. Are two heads better than one? On the effectiveness of pair programming
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp12-15 CR 0902-0169
      4. =META-ANALYSIS EXPERIMENTS PAIR-Programming QUALITY COST
      5. Quality tends to be a little better and the time to complete the project is better. The effort (people * time) is slightly worse.

      DybaKitchenhamJorgensen05

      1. Tom Dyba & Barbara A Kitchenham & Magne Jorgensen
      2. EVIDENCE-BASED Software Engineering for Practitioners
      3. IEEE Software Magazine V22n1(Jan /Feb 2005)pp58-65
      4. =IDEA PRACTICES LITERATURE SURVEY EBSE META-ANALYSIS
      5. How to select technologies, methods, processes to put into a project?
      6. EBSE::acronym="EVIDENCE-BASED Software Engineering", and following
        1. Convert problem/information into answerable question.
        2. Search the literature for best evidence.
        3. Critically appraise evidence: valid? Impact?, Applicable?
        4. Apply the evidence that fits current project: experience, values, circumstances.
        5. Evaluate performance and seek to improve.

      7. Resources page 61
      8. Checklist page 62.
      9. Example page 64: Chaos report does not fit with other surveys and does not include data to evaluate the accuracy of its evidence.

      DybaSharp12

      1. Tore Dyba & Helen Sharp
      2. What's the evidence for Lean
      3. IEEE Software Magazine V29n5(Sep/Oct 2012)pp19-21 [ software ]
      4. =SURVEY EVIDENCE LEAN MANUFACTURING TOYOTA IMVP OVERTIME
      5. Evidence for Lean Manufacturing has been challenged -- it ignored overtime...

      DzidekEtAl08

      1. Wojciech James Dzidek & Erik Arisholm & Lionel C Briand
      2. Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance
      3. =EXPERIMENT UML MAINTENTANCE EFFECTIVENESS VALUE Oslo Java Eclipse BESTWeb
      4. IEEE Trans Software Engineering V34n2(May/Jun 2008)pp407-432
      5. Use 20 real developers to maintain real software!
      6. BESTweb:=Internal bibliographic data base on software cost and effort estimation. Realistic (1..2 weeks) tasks. Half had UML diagrams.
      7. Replicates on [Arisholm06BriandHoveLabiche06]
      8. UML improves quality significantly with only a 14% worse time.

      Eaddy01

      1. Marc Eaddy
      2. C# Versus Java
      3. Dr. Dobbs #321(Feb 2001)pp74+76+78+80+82
      4. =HISTORY JAVA C++

      EaddyEtAl08

      1. Marc Eaddy & Thomas Zimmermann & Kaitlin D Sherwood & Vibhav Garg & Gail C Murphy & Nachiappan Nagappan & Alfred V Aho
      2. Do Crosscutting Concerns Cause Defects
      3. IEEE Trans Software Engineering V34n4(Jul/Aug 2008)pp497-515
      4. =EMPIRICAL ASPECTS REQUIREMENTS CONCERNS CROSS-cutting CODE QUALITY BUGS
      5. Requirements mapped into concerns.
      6. Reverse engineered concern->code map and the bug->code mapping and deduce concern->bug relationship in corpus of Java code.
      7. Defects tend to be associated more with wide-spread concerns than with total amount of code implementing a concerns.

      EastawayWyndham98

      1. Rob Eastaway & Jeremy Wyndham
      2. Why do busses come in threes: the hidden mathematics of everyday life
      3. Wiley 1998 + Barnes & Noble 2002
      4. =FUN MATHEMATICS BOOK

      EasterbrookCallahan97

      1. Steve Easterbrook & John Callahan
      2. Formal Methods for V&V of Partial Specifications: An Experience Report [RE'97] pp160-168
      3. Value of formalizing english specs is in finding ambiguities incompleteness and contradictions
      4. AND/OR and SCR TABULAR

      EasterbrookEtal98

      1. Steve Easterbrook & Robyn Lutz & Richard Covington & Yoko Ampo & David Hamilton
      2. Experiences Using Lightweight Formal Methods for Requirements Modeling
      3. IEEE Trans Soft Eng V24n1(Jan 1998)pp4-14
      4. =EXPERIENCES FORMAL SQA complement trad METHODS: SCR And/Or TABULAR [PVS] OMT
      5. results of using a formal model is useful after the model is out-of-date
      6. great deal of domain knowledge needed to distinguish strange but possible cases from impossible cases

      Easton78

      1. Frank M Easton
      2. Esperanto Success
      3. =ADVERT Esperanto ITL UNIVERSAL LANGUAGES
      4. Computer Weekly (UK) (Mar 23 1978)p19
      5. Rebuts Botting78a "Loglan unheard of".

      Ebert06

      1. Chistof Ebert
      2. Understanding the Product Life Cycle: Four Key Requirements engineering Techniques
      3. IEEE Software Magazine V23n3(May/Jun 2006)pp19-25
      4. =STATISTICS ? PROJECTS OVERRUN vs REQUIREMENTS ALCATEL
      5. 4 technique associated with finishing embedded or application software products with less overrun.
      6. portfolio::= "depicts all products in the organization together with their market and investment etc.".
      7. Techniques
        1. Install an empowered core team for each release at its start.
        2. Focus life cycle on the early gate-reviews using portfolio as guide.
        3. Evaluate requirements from various perspectives.
        4. Assure dependable portfolio visibility and release implementation.

      8. project size/length not associated with higher %overrun.

      EbnerKaindl02

      1. Gerald Ebner & Hermann Kaindl
      2. Tracing All Around in Reengineering
      3. IEEE Software Magazine V19n3(May/Jun 2002)pp70-77
      4. =CASESTUDY REENGINEERING RETH HYPERTEXT DOCUMENTATION
      5. RETH::="Requirements Engineering Through Hypertext".
      6. Erroneous UML metamodel (roles at wrong end of association )! Requirements justify Design Decision, new Requirements replace old Requirements.

      Ebrahimi97

      1. Nader B Ebrahimi
      2. On the statistical analysis of the number of errors remaining in a software design document after inspection
      3. IEEE rans Se V23n8(Aug 1997)pp529-532
      4. SQA =THEORY not capture/recapture allows non-independent reviews but requires independent issues

      Ebrahimi99

      1. Nadar B Ebrahimi
      2. How to Improve the Calibrartion of Cost Models
      3. IEEE Trans SE V25n1(Jan/Feb 1999)pp136-140 CR9906-0435
      4. =THEORY STATISTICS ESTIMATION COSTS proxy variable for size beats COCOMO

      EbringerThorneZheng00

      1. Tim Ebringer & Peter Thorne & Yuliang Zheng
      2. Parasitic Authentication to Protecting Your E-Wallet
      3. IEEE Computer Magazine V33n10(Oct 2000)pp54-60
      4. =IDEA USER SECURITY

      Eckstein99

      1. Robert Eckstsein
      2. XML pocket reference
      3. O'Reilly 1999 ISBN 1-56592-709-5 $8.95
      4. =MANUAL XML

      Eco85

      1. Umberto Eco
      2. Travels in hyperreality
      3. Harcourt brace etc 1985 0-15-1911079-0 PQ4865.c6t7
      4. =ESSAY modern etc culture
      5. p178: In scientific publishing photocopying meant price up, number down, and less to authors

      Eco94

      1. Umberto Eco
      2. The Search for the Perfect Language
      3. Blackwell Oxford UK & Cambridge USA 1995 ISBN 0-631-17465-6 P106.E2813
      4. =HISTORY semiotic artificial languages in europe
      5. "[...] it is only necessary to make one simple assumption: the perfect language exists, and it is identical to one's own tongue. Once this assumption is made, the choice of the metalanguage follows[...]"

      Edel88

      1. Mark Edell
      2. The Tinkertoy Graphical Programing Environment
      3. IEEE Trans Soft Eng VSE-14n8(Aug 1988)pp1110-1115
      4. Graphical Functional LISP: problems with PROG sequential iterative structures

      EditorU08

      1. Unknown Editor
      2. Special Issue on Formal Proof
      3. Notices of the American Mathematical Society V55n11 (Dec 2008) [ http://www.ams.org/notices/200811/ ]
      4. =EXAMPLES FORMAL PROOFS MATHEMATICS
      5. Includes [Hales08] [Gonthier08] [Wiedijk08]

      Editors00

      1. Contributing Editors
      2. Tales of Terror
      3. Software Development Magazine V8n9(Oct 2000)pp41-80 + Letters V8n12(Dec 2000)p11
      4. =ANECDOTES FAILURE METRICS ETHICS MARKETING PLANNING TESTING DIRECTORIES ALGORITHM META-BUREAUCRATIC DENIALS CLUELESS DATA SIZING LEGACY TESTING

      Editors01

      1. Many contributors
      2. Pick a Language any Language
      3. Software Development Magazine V9n3(Mar 2001)pp44-47
      4. =OPINION LANGUAGES VB SmallTalk MVC C++ STL Prolog Java Perl
      5. "What ever I get paid for is best".
      6. "the one I designed and built myself".

      Edmond92

      1. David Edmond
      2. Information Modeling: Specification and Implementation
      3. Prentice Hall Englewood Cliffs NJ 1992
      4. $51 ISBN 0-13-457748-5 CR9501-0017
          See [Stevens95] Comp Rev V36n1(Jan 1995)p62

      Edwards94

      1. Stephen H Edwards
      2. Annotated Bibliography of RESOLVE Research
      3. ACM SIGSOFT Software Engineering Notes V19n4(Oct 1994)pp65-67 [Sitaraman94]

      Edwards97

      1. Stephen H Edwards
      2. Representation Inheritance: A Safe Form of "White Box" Code Inheritance
      3. IEEE Trans Softw Eng V23n2(Feb 1997)pp83-92
      4. =IDEAS object-oriented

      Edwards09

      1. Kathryn Edwards
      2. The A-Z of Programming Languages: MATLAB
      3. Computerworld Australia (Dec 09 2009) [ -z_programming_languages_matlab ]
      4. =INTERVIEW =HISTORY 25 years MATLAB LANGUAGE MATHEMATICS ENGINEERING Cleve Moler
      5. Surprise success of a tool develop for students... favourite feature
        1. It's the mathematics. The thing that I enjoy as a mathematician is finding out how mathematics underlies so many different disciplines. We didn't intend to do automobiles, anti-lock brakes or human genome or pricing of derivatives in the finance market. We never set out to do any of that originaly, but mathematics is common to all of these. I really enjoy talking about how these different fields are unified by the underlying mathematics.

      Edwardsetal94

      1. Stephen H Edwards & Wayne D Heym & Timothy J Long & Murali Sitaraman & Bruce W Weide
      2. Specifying Components in RESOLVE
      3. ACM SIGSOFT Software Engineering Notes V19n4(Oct 1994)pp23-28
      4. See Sitaraman94

      EdwardsEtal04

      1. Stephen H Edwards & Murali Sitaraman & Bruce W Weide & Joseph Hollingsworth
      2. Contract-check Wrappers for C++ Classes
      3. IEEE Trans Software Engineering V30n11(Nov 2004)pp794-810
      4. =DEMO WRAPPERS CONTRACT ASSERTIONS TECHNICAL C++ V&V SQA FACTORY
      5. Instead of inline code checking assertions, can provide optional compiled wrappers that contain assertions.

      EdwardsJacksonTorlak04

      1. Jonathan Edwards & Daniel Jackson & Emina Torlak
      2. A Type System for Object Models
      3. Proc SIGSOFT'04/FSE-12& ACM SIGSOFT Software Engineering Notes V29n6(Nov 2004)pp189-199
      4. =IDEA LOGIC RELATIONAL TYPES Alloy 2.0
      5. Defines an improved type system for Alloy with subtypes, relations, etc.
      6. Compares with UML OCL.
      7. Precisely defines two types for formulas: bounding type and relevance type.
      8. An empty relevance type indicates an error.

      EfromHarelCohen05

      1. Sol Efrom & David Harel & Irun R Cohen
      2. Reactive Animation: Realistic modeling of complex dynamic systems
      3. IEEE Computer Magazine V38n1(Jan 2005)pp38-47
      4. =ADVERT Flash TCP/IP Rhapsody state chart MODEL CELL Thymus bioinformatics MVC

      Egyed02

      1. Alexander Egyed
      2. Automated abstraction of Class Diagrams
      3. ACM TOSEM Trans Software Eng & Methodology V11n4(Oct 2002)pp449-491
      4. =ADVERT THEORY TOOL ABSTRACTION UML/analyzer

      EgyedGrunbacher04

      1. Alexander Egyed & Paul Grunbacher
      2. Identifying Requirements Conflicts and Cooperation: How Quality Attributes and Automated Traceability can help
      3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp50-58
      4. =THEORY AUTOMATED REQUIREMENTS TRADE-OFFS PURPOSES QUALITIES DEMO VOD Video-on-demand
      5. Express all requirements as tests and run them tracing which ones execute the overlapping pieces of code.
      6. Classify requirements in terms of type.
      7. Types indicate likely cooperation and conflict in a semantic web.
      8. Hence able to express trade-off situations.

      EgyhazyEyestoneMartino01

      1. Csaba Egyhazy & Scott Eyestone & Janet Martino
      2. Defining Team Processes using OO Metaphors
      3. IEEE Software Magazine V18n3(May/June 2001)pp74-83
      4. =EXPERIENCE Object-Oriented PROCESS
      5. Object based ideas of classes, responsibillites, and collaborations can be used to define a software development process.

      EgyhazyMukherji04

      1. Csaba Egyhazy & Raj Mukherji
      2. Interoperability architecture using RM-ODP
      3. Commun ACM V47n2(Feb 2004)pp93-97 =EXPERIENCE GCPR GOVERNMENT MILITARY MEDICAL RECORDS ARCHITECTURE INTEROPERABILITY
      4. RM-ODP CORBA
      5. RM-ODP::="Reference Model for Open Distributed Processing", [Putnam01].|-Need to address policies and procedures (especially security and authentication ) not just interfaces, data, design, and programming.
      6. Viewpoints::={enterprise, information, computational, engineering, technology}.
      7. Alphabet soup! Class diagrams, IDL, sequence diagrams, tables of metadata, usecases, deployment d iagrams.
      8. |-No commercial tools were up to the job.
      9. |-UML could not be used for RM-ODP.

      EhrigMahr8589

      1. H. Ehrig and B. Mahr
      2. Fundamentals of Algebraic Specification Vols I and II
      3. Springer Verlag Berlin 1985 & 1989 ADTs
          Vol 1 Equations and initial semantics rewrite methods

          Vol2 "Abstrakter Datentyp, Algebraische Spezifikation, Constraint, Modul"


      EickEtal01

      1. Stephen G Eick & Todd L Graves & Alan F Karr & J S Marron & Audris Mockus
      2. Does code Decay? Assessing the Evidence from change Management data
      3. IEEE Trans Software Engineering V27n1(Jan 2001)pp1-12
      4. =EXPERIENCE EVOLUTION MAINTENANCE COST MODULE
      5. 16 years 100MLOC C/C++ 50 subsystems 5K modules. describes maintenance process and data collection.
      6. Each module is a directory full of files.
      7. Analysis of 100 modules 2,500 file 130k deltas 500 login ids to find that costs increased, faults increased, and if changes start to span more modules. Large span meant larger effort.
      8. changes := adaptive | corrective | perfective.
      9. causes of decay: wrong architecture, changes in reality, imprecise requirements, time, tools, organizations, programmers, bad process.
      10. symptoms: bloat, frequent changes, frequent faults, dispersed changes, kludges, numerous interfaces.
      11. risk factors: size, age, inherent complexity, churn, porting and reuse, requirements load, inexperience.

      EickEtal02

      1. Stephen G Eick & Todd L Graves & Alan F Karr & Audria Mockus & Paul Schuster
      2. Visualizing Software Change
      3. IEEE Trans Software Engineering V28n4(Apr 2002)pp396-412
      4. =EXPERIENCE TOOL GRAPHIC CODE TECHNICAL DELTAS EVOLUTION IMR
      5. IMR::= "Initial Modification Request".
      6. How to understand changes in 20M lines of code in 5000 modules across 15 years.
      7. views: matrix, cityscape, bar and pie charts. filtering. perspectives.
      8. For N[i,j]:= number of IMRs effecting both i and j, N[i] number effecting i, strength_of_linkage[i.j] := N[i,j]/sqrt(N[i]*N[j])).

      EickelmenAnant03

      1. Nancy Eickelmen & Animesh Anant
      2. Statistical Process Control: What you don't measure can hurt you
      3. IEEE Software Magazine V20n2(Feb/Mar 2003)pp49-51
      4. =HISTORY STATISTICS PROCESS QUALITIES QC Kiviat σ INSPECTION SQA

      Eilenberg74

      1. S Eilenberg
      2. Automata Languages & Machines
      3. Volume A Academic Press 1974
      4. =theory languages

      Eischen02

      1. Kyle Eischen
      2. Software Development: and Outsiders View
      3. IEEE Computer Magazine V35n5(May 2002)pp36-44
      4. =HISTORY SOCIOLOGY ECONOMICS CRAFT RATIONALIZATION
      5. The fact that software is still produced without using the rationalized/managed/defined processes indicates a fundamental schism between rationalized manufacturing and craftsman-like design in software.
      6. requirements and design are difficult and involve knowledge and translation of non-software domains -- cultures.
      7. Software benefits from peer review.
      8. Much s already working.
      9. Competition is essential to get both innovation and accurate evaluation of process and product.
      10. Need build and borrow tools that evaluate and translate domain knowledges.
      11. Design is inherently buggy and difficult -- in all areas.
      12. Education should include: human skills, cross disciplinary work and research.
      13. Sidebar: 3 analogies: university, Hollywood, and construction.

      EisenbarthKosckeSimon03

      1. Thomas Eisenbarth & Rainer Koscke & Daniel Simon
      2. Locating Features in Source Code
      3. IEEE Trans Software Engineering V29n3(Mar 2003)pp210-224
      4. =DEMO TEST SCENARIO TRACE CODE MODULES CONCEPT MAINTENANCE
      5. Proposes a technique to isolate parts of code involved in particular features.
      6. Select scenarios with and without features of interest; list features as set in each scenario; run them and trace; record set of modules executed for each.
      7. Describes formal concept analysis [GanterWille99]
      8. Defines a context @(Features><Modules)
      9. Do concept analysis on this context to generate lattice of @Features >< @Modules.
      10. Categorize the lattice nodes relevant to features: for feature f, nodes >== specific | relevant | conditionally_specific | shared | irrelevant.
      11. Combine with static dependency analysis to develop a map of where each feature is implemented (or at least involved).
      12. Shows how to iteratively grow lattice by adding features.

      Eisenstadt97

      1. Marc Eisenstadt
      2. My Hairiest Bug War Stories
      3. Comm ACM V40n4(Apr 1997)pp30-37 CR9711-0918
      4. =POLL RISKS QUALITIES DEBUGGING
      5. Very interesting.
      6. Internet POLL for bugs classified for difficulties(long cause-effect chain and hampered tools being commonest) + how found(gathered data and ispeculation leading) + root cause(memory, vendor, design,logic, initialization ...) +interaction(use data gathering when cause-effect chain is likely to be long or the tools are hampered)

      Eisner05

      1. Howard Eisner
      2. Managing Complex Systems: Thinking Ouside the Box
      3. Wiley Hoboken NJ 2005 TA168.E387 ISBN-13 978-0-471-69006-1 ISBN-10 0-471-69006-6
      4. =HANDBOOK MANAGEMENT THINKING
      5. Many interesting ideas and pointers to details but a little thin in places.

      El-FakihYevtushenkoBochmann04

      1. Khaled El-Fakih & Nina Yevtushenko & Grego v Bochmann
      2. FSM-Based Incremental Conformance Testing Methods
      3. IEEE Trans Software Engineering V30n7(Jul 2004)pp425-436
      4. =THEORY =EXPERIMENT FSM/STD SPECIFICATION EVOLUTION TEST

      ElEmamLaitenberger01

      1. Khaled El Emam & Oliver Laitenberger
      2. Evaluating capture-recapture models with two inspectors
      3. IEEE Trans Software Engineering V27n9(Sep 2001)pp851-864
      4. =SIMULATION MODEL QUALITIES V&V INSPECTION ERRORS STATISTICS CAPTURE-RECAPTURE

      Elfatatry07

      1. Achmed Elfatatry
      2. Dealing with change: components versus services
      3. Commun ACM V50n8(Aug 2007)pp35-39
      4. =ESSAY components services EVOLUTION RISKS EFFICIENCY
      5. Components selected before run but services are selected during the run. So services are easier to change but less efficient and less trustworthy.
      6. (dick)|-Sounds like a hacker can offer an evil service and get it accepted

      EllisJ94

      1. John R Ellis
      2. Objectifying Real-Time Systems
      3. SIGS Publications NY 1994 $44
      4. review IEEE Software magazine V13n3(Mar 1996)p123: down to earth and based on WardMellor RTSA with DFDs ERDs etc

      Ellison95

      1. Karen S Ellison
      2. Developing real-time embedded software in a market driven company
      3. John Wiley & Sons NY NY 1994 $39.95 ISBN 0-471-59459-8 CR9511-0829

      EllisStroustrup90

      1. Margaret A Ellis & Bjarne Stroustrup
      2. The Annotated C++ Reference Manual (ARM)
      3. Addison-Wesley Redwood City CA 1990 (Copyright AT&T Bell Labs 1990) LC 90-33932 ISBN 0-201-51459-1

      ElmasQadeerTasiran10

      1. Tayfun Elmas & Shaz Qadeer & Serdar Tasiran
      2. Goldilocks: a race-aware Java Runtime
      3. Commun ACM V53n11(Nov 2010)pp85-92 [ 1839676.189698 ]
      4. =DEMO JAVA NONSEQUENTIAL SHARED MEMORY HAZARDS DETECTION EXCEPTIONS
      5. See also [Adve10] and [FlanaganFreund10]

      ElshoffMarcotty82

      1. ?? Elshoff & ?? Marcotty
      2. Improving Computer Program Readability to Aid Modification
      3. Commun ACM V25 n8( pp512-521)
      4. =THEORY STRUCTURED CODE QUALITY

      Emam05

      1. Khaled El Emam
      2. The ROI from Software Quality
      3. Auerbach Pub, Boston MA, 2005 ISBN 0849332982 CR 0612-1195
      4. =UNREAD HOWTO MEASURE VALUE QUALITY IMPROVEMENT

      EmamBenlarbiGoelRai01

      1. Khaled El Emam & Saida Benlarbi & Mishith Goel & Shesh N Rai
      2. The Confounding Effect of class size on the Validity of Object-Oriented Metrics
      3. IEEE Trans Software Engineering V27n7(Jul 2001)pp630-650
      4. =CASESTUDY METRICS OO SIZE
      5. Size accounts for fault proneness as well as more common metrics: chidamberKemerer o LorenzKidd

      EmamBirk00

      1. Khaled El Emam & Andreas Birk
      2. Validating the ISO/IEC 15504 measures of software requirements analysis process capabillity
      3. IEEE Trans Software Engineering V26n6(Jun 2000)pp541-566
      4. =STATISTICS IMPROVEMENT MEASURES PRODUCTIVITY
      5. In large organisations controling requirements llinked to higher productivity

      EmamEtal02

      1. Khaled El Emam & Saida Benlarbi & Nishith Goel & walcelio Melo & Hakim Lounis & Shesh N Rai
      2. Th Optimal Class size for Object-Oriented Software
      3. IEEE Trans Software Engineering V28n5(May 2002)pp494-509
      4. =CASESTUDY STATISTICS C++ Java CODE Object-Oriented METRIC
      5. size measured by statements, LoC, #methods and #attributes.logistic Logistic function: Pr[class size S=s has a fault] =1/(1+exp(-(β0+β1*size)))
      6. vs Threshold model:....
      7. Both size and faults were skewed toward 0.
      8. The theory that small pieces are more faulty was previously shown to be an artifact of the data!
      9. There is no empirical evidence in this experiment that large classes have more faults either.

      EmamGoldenson00

      1. Khaled El Emam & Dennis R Goldenson
      2. An Empirical Review of Software Process Assessments
      3. Advances in Computers V53(2000)pp320-423
      4. =SURVEY CMM SPA effectiveness ISO/IEC15504 SPI IMPROVEMENT
      5. SPA Sponsors expect SPA to be useful.
      6. Organizations have too high expectations for SPA.
      7. Evidence that SPA results are consistent.
      8. Ample evidence that higher levels are linked to improved performance.

      EmamKoru08

      1. Khaled El Emam & A Gunes Koru
      2. A Replicated survey of IT Software Project Failures
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp84-90
      4. =POLL 2006 2007 PROJECTS SUCESS FAILURE SIZE LENGTH STATISTICS
      5. Published work overestimates failure rate.
      6. In this poll about 16% were cancelled in 2005 and 12% were cancelled in 2007.
      7. Reasons given: uninvolved senior management, requirements/scope changes, lack of management skills, over budget, lack of technical skills, system not needed afterall, etc..

      Embleyetal92

      1. David W Embley & Barry D Kurtz & Scott N Woodfield
      2. Object-Oriented Systems Analysis: A Model-driven Approach
      3. Prentice Hall Englewood Cliffs NJ 1992
      4. OSA
      5. Reviewed Am Math Monthly V99n8(Oct 1992)p807 CR 9202-0686(K.6.1)
      6. CR9404-0198

          [Embleyetal95]


      Embleyetal95

      1. David W Embley<embley@cs.byu.edu> & Robert B Jackson & Scott N Woodfield(BYU)
      2. Object-Oriented Systems Analysis: Is it or isn't it
      3. IEEE Software Magazine V12n4(July 1995)pp19-33 + correspondence with Shlaer & Mellor IEEE Software Magazine V12n5(Sep 1995)pp8+10
          Note: REALITY OOA NONSEQUENTIAL STD/FSM SURVEY FORMAL

          advocates OSA as OOA, book Embleyetal92 claims design features have contaminated other OOA methods... that they are preliminary design methods. Defines Systems analysis as "the study of a system for the purpose of understanding and documenting its essential characteristics"

          OSA: formal semantics, executable, no attributes, all sets of {objects, relationships, states, transitions,...), high level(abstract) views. semantics of the real world(ERD+ isa+part-of), object behavior(FSD+time+exceptions, concurrent), object interaction(digraph(classes, messages)), properties(cardinallity), real-time constraints, allowing degrees of formalism, choices of notations, top-down or not,...

          p20: "relationship sets, together with high-level object classes, can represent the information captured by attributes, but attributes can not represent arbitrary relationship sets. Attributes, however, let us represent important design optimisations".

          OSA has been used to model itself.

        1. OOS-L::=Object-oriented Specification Language::= formal, also natural versions

        2. IPOST::=Interaction Prototyping Object-oriented Specification Tool

          Comparison of features of several methods: subjective.

          p25: "All systems are embedded, either in the way we normally think about embedded computer systems or are in an organisation such as a business[so] the larger environment should always be considered, especially for analysis, which emphasizes the comprehension and documentation of entire systems."

          p32: Goal: "A software-engineering environment based on a single formal model.


      EmbleyNagy81

      1. ?? Embley & ?? Nagy
      2. Behavioral aspects of text editors
      3. ACM Computer Surveys 13 1 (Mar 1981) pp33-70
      4. =SURVEY USER EDITOR

      Emery69

      1. F E Emery (ed)
      2. Systems thinking: selected reading
      3. Penguin books, Harmondsworth Middx UK, Baltimore Md USA1969
      4. =READINGS SYSTEM CYBERNETICS
      5. Of historical value... but [Weinber75] largely supersedes it.

      EmeryTrist60

      1. F E Emery & E L Trist
      2. Socio-technical Systems
      3. Management Science, Models and techniques, V2(?? 1960)pp83-97
      4. =ESSAY SYSTEMS PEOPLE TEAM
      5. Similar observations in British coal mining and Indian textile mills: a composite group/team oriented organization with complex roles and interaction outperforms a rigid hierarchical organization. Also less rigid form ad less symptoms of stress (illness, accidents, etc).
      6. Managers should manage interactions between teams rather than micro-manage the internal structures of teams.
      7. (dick)|-probably applies to agile vs rigid processes.

      EmmerichAoyamaSventek08

      1. Wolfgang Emmerich & Mikio Aoyama & Joe Sventek
      2. The Impact of Research on the Development of Middleware Technology
      3. ACM TOSEM Trans Software Eng & Methodology V17n4(Apr 2008)#19pp1-48 [ 13487689.13487692 ]
      4. =SURVEY HISTORY MIDDLEWARE J2EE CORBA IBM BEW Oracle Nicrosoft Tibco Websohere RMI .NET etc RESEARCH PhDs
      5. 20 year lag between academic research and large mainstream market.
      6. PhD. Theses are important!

      EmmerichEtal99

      1. Wolfgang Emmerich & Anthony Finkelstein & Carlo Montangero & Stefano Antonelli & Stephen Armitage & Richard Stevens
      2. Managing Standards Compliance
      3. IEEE Trans Software Engineering V25n6(Nov/Dec 1999)pp836-837
      4. =THEORY MODEL LOGIC FLEA TOOL DOORS DXL STANDARDS in PROCESS
      5. uses STATECHART UML~OCL+1st_order_logic PETRI Net LISP (AP5)
      6. FLEA::="Formal Language for Expressing Assumptions".

      Endres93

      1. Albert Endres
      2. Lessons Learned in an Industristrial Software Lab
      3. IEEE Software Magazine V10n5(Sep 1993)pp58-61
          How IBM Boeblingen reduced its error rate by a factor of 10 while doubling productivity and halving project duration.

          Millions of lines of code.

          Formal methods: VDM & Harlan Mills. Complete training. Added tools. Used method+tool to separate module specification from module implementation... hance C++ and Ada rather than a separate language for design

          Reuse. Has to be planned for. Rules: encapsulation, parameterized, generalized. Opposite of old technique. Centrally maintained Boeblingen Building blocks - zero defects, in use through out IBM.

          Process: Well documented, publicized (Radice) and now online.

          Academe vs practice? Also no sharing of practices.


      Engelsetal92

      1. G Engels & C Lewerentz & M Nagl & W Schafer & A Schurr
      2. Building Integrated S Development Environments Part 1: Tool Specification
      3. ACM Trans Softw Eng Methodol V1n2(Apr 1992)pp135-167
          IPSEN(Integrated Project Support Environment) PROGRESS Attributed Graphs visual data base CFG+CS rules on attributes in graph, object oriented is-a, prime as new node, Path expressions, atomic transactions, Factoring out common rules, logical vs representation graph.


      Engel99

      1. Gerald L Engel
      2. Program Critrria for Software engineering Accreditation Programs
      3. IEEE Software Magazine V16n6(Nov/Dec 1999)pp31-34
      4. =ADVERT SWEEP ENGINEERING EDUCATION

      EnrightWilkens93

      1. Aaron G Enright & Linda M Wilkens
      2. Engineering the Transition to Better Software
      3. ACM SIGSOFT Software Engineering Notes V18n3(Jul 1993)ppA47-49
      4. Notes the fallacies and problems of using a faulty process model (rush to code) to the improvement of the software process. pA47 col2 "Why not just engineer the transition"

      EomHollingsworth01

      1. Hyeonsang Eom & Jeffrey K Hollingsworth
      2. A Tool to Help Tune where Computation is Performed
      3. IEEE Trans Software Engineering V27n7(Jul 2001)pp618-629
      4. =CASESTUDY Net DISTRIBUTE PERFORMANCE LBF
      5. LBF::="Load Balancing Factor".

      Epstein94

      1. Richard L Epstein
      2. The Semantic Foundations of Logic: Predicate Logic
      3. Oxford U Press Inc NY NY ISBN 0-19-508760-7 CR9601-0018
      4. philosophical translation of Natural language into various predicate calculi

      Epstein01a

      1. Richard L Epstein
      2. Predicate logic: The semantic foundation of Logic
      3. Wadsworth Belmont CA 2001 ISBN 0-534-55846-1 BC181.E67 2001 $40.95 pp412 CR0011-0555 F.4.1
      4. =TEXT =REFERENCE LOGIC PC MODAL
      5. x is a dog notation!
      6. CSUSB CS556/656 [Epstein94]

      Epstein01b

      1. Richard L Epstein
      2. Propositional logic: The semantic foundation of Logic
      3. Wadsworth Belmont CA 2001 ISBN 0-534-55846-1 BC181.E67 2001b
      4. =TEXT =REFERENCE LOGIC PC MODAL
      5. CSUSB CS556/656

      Epstein06

      1. Richard L Epstein
      2. Classical mathematical logic: The semantic foundation of Logic
      3. Princeton UP Princeton NJ 2006 ISBN 0691123004 CR 0803-0245
      4. =UNREAD =TEXT =REFERENCE LOGIC
      5. Compare [Epstein01b] [Epstein01a] [Epstein94]

      EpsteinJAxtell96

      1. Joshua M Epstein & Robert Axtell
      2. Growing Artificial Societies: Social Science from the Botom up
      3. The Brooking Inst Washington DC 1996
      4. CR9710-0776

      Erdogmus05

      1. Hakan Erdogmus
      2. The Economic Impact of learning and flexibility on Process decisions
      3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp76-83
      4. =ESSAY MATH ONESIZE Economics PROCESS ITERATIVE vs SEQUENTIAL COST-BENEFIT
      5. Calculated values of projects.
      6. Iteration & learning can make a project profitable in an uncertain situation.

      Erdogmus07

      1. Hakan Erdogmus
      2. Novelty in sameness
      3. IEEE Software Magazine V24n3(May/Jun 2007)pp5-7
      4. =EDITORIAL IID ITERATIVE INCREMENTAL EVOLUTION Royce70
      5. Notes the difficulty of understanding and using new ideas.
      6. Good definition & discussion of iteration and increments.
      7. Compare with [Meyer97] (Quality First), [JacobsonBoochRumbaugh98] (RUP), [Larman04] (Evo, ...).

      Erdogmus08

      1. Hakan Erdogmus
      2. Must software research stand divided
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp4-6
      4. =ESSAY EMPIRICIST VS CONSTRUCTIONIST RESEARCH
      5. Gives a good description of the two types of research into software development.

      Erdogmas09

        [Erdogmus09]

      Erdogmus09

      1. Hakan Erdogmas
      2. A process that is not
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp4-7
      4. =EDITORIAL Tiki COLLABORATION TOOL OPEN SOURCE ANTIPROCESS F/OSS BAZAAR
      5. An example of an unusually open project. No onion....
      6. Tiki::= See http://tikiwiki.org/

      Erdogmus10

      1. Hakan Erdogmas
      2. Can all sequential processed grow up to be iterative and incremental
      3. IEEE Software Magazine V27n4(Jul/Aug 2010)pp2-5
      4. =ESSAY NONSEQUENTIAL PROCESSES Kanban scrumban LEAN stage-gate v-model
      5. Refers to [Beck99] Break process down into parts and apply sequence to parts many times.
      6. Refers to [Ladas08] (Scrumban).
      7. Divisibility of work. Unravelling principles: ( pipelining, workflow-schedule independence).
      8. Split up, make parallel, add buffers, and add integration steps.
      9. Compare with "Pipe and Filter" architecture and Jackson's methods in the 1970s and 1980s.

      ErdogmusJohnston91

      1. M Hakam Erdogmus & Robert Johnston
      2. On the Specification and Synthesis of Communicating Processes
      3. IEEE Trans SE-16 n12(Dec 1990)pp1412-1432

      ErdogmasMorisioTorchiano05

      1. Spelling mistake for [ErdogmusMorisioTorchiano05]

      ErdogmusMorisioTorchiano05

      1. Hakan Erdogmus & Maurizio Morisio & Marco Torchiano
      2. On the Effectiveness of the Test-First Approach to Programming
      3. IEEE Trans Software Engineering V31n3(Mar 2005)pp226-237
      4. =EXPERIMENT TESTING AGILE TFD TDD
      5. Summarizes previous studies: test-first makes no difference or improves quality and may or may not improve productivity.
      6. This paper has a controlled experiment comparing test-first with test-last development of a series of user stories.
      7. Test-first programmers broke stories into a series of tests and added one test and then added code to make program pass test. Test last coded complete story and then carried out all tests.
      8. Experiment: 40PCs Java JUnit ECLIPSE CVS, 35 3rd year volunteer students, 11 dropped out.
      9. Quality measure via hidden acceptance tests.
      10. Productivity in terms of number of stories per unit time.
      11. Theories: Test-first may tend to increase the number of tests, the quality, and productivity. However more tests anyway may increase quality and productivity.
      12. My translation of their statistics results:
        1. quality >= 0.55 + tests/10. NOTE: not a linear equation but an inequality.
        2. More tests increase the minimum number of tests passed in the acceptance testing.
        3. Other factors can improve quality as well as tests.
        4. productivity= 0.255 + 0.659 tests.
        5. Test-first programmers did more tests on average.
        6. Test-first programmers where more productive and produced the same quality code.
        7. 30% dropped out -- "morbidity"

      Erickson94

      1. Martin Erickson
      2. An Introduction to Combinatorial Existence Theorems
      3. Mathematics Magazine V67n2(Apri 1994)pp118-123 Math Assoc of America

      Erickson96

      1. Thomas Erickson
      2. Design as Storytelling
      3. ACM interactions V3n4(Jul/Aug 1996) pp30-35
      4. CR9703-0195: USER tell stories of unpredicatable computer systems

      EricksonA09

      1. Aaron Erickson
      2. The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting
      3. Addison-Wesley Professional; 1 edition (May 15, 2009) ISBN 0321606396 [ 0321606396 ]
      4. =UNREAD CONSULTING IT ICT TECHNOLOGY PEOPLE ECONOMICS
      5. Help [click here [socket symbol] EricksonA09 if you can fill this hole]

      EricksonMcDonald08

      1. Thomas Erickson & David W McDonald (Eds)
      2. HCI Remixed -- Essays on Works that have influenced the HCI Community
      3. The MIT Press Caambridge MA 2008 QA76.9.H85H4125 ISBN 978-0-262-05088-3
      4. =HISTORY =ESSAYS USERS Human Computer Interfaces HCI
      5. (dick)|-Any book with an essay on Ted Nelson's Computer Lib/Dream Machines must be good!

      EricksonSiau07

      1. John Erickson & Keng Siau
      2. Theoretical and practical complexity of modeling methods
      3. Commun ACM V50n8(Aug 2007)pp47-51
      4. =POLL UML DIAGRAM USAGE COMPLEXITY
      5. People use only some parts of the UML: class statechart, sequence, use case,...
      6. Subset scores only 40% of complete complexity.

      EriksonBorstlerBorg06

      1. Magnus Erikson & Jurgen Borstler & Kjell Borg
      2. Software Product Line modelling made practical
      3. Commun ACM V49n12(Dec 2006)pp49-53
      4. =CASESTUDY SWEDISH PRODUCT LINE MODEL FEATURE USECASE PLUSS
      5. PLUSS::="Product Line Use case modelling for Systems and Software engineering".
      6. Hierarchy of features. Features map to use cases and steps in use case.
      7. Need moreformalism to model a complete product line.
      8. Threat of losing of ownership of individual existing products can lead to resistance.
      9. Notes

      ErnstBadrosNotkin02

      1. Michael D Ernst & Greg J Badros & David Notkin
      2. an empirical Analysis of C Preprocessor Use
      3. IEEE Trans Software Engineering V28n12(Dec 2003)pp1148-1170
      4. =EMPIRICAL TECHNICAL STATISTICS C PREPROCESSOR MACROS

      ErnstHookwayOgden94

      1. George W Ernst & Raymond J Hookway & William F Ogden
      2. Modular Verification of Data Abstractions with Shared Realizations
      3. IEEE Trans SE-30n4(Apr 1994)pp288-307
          Note ADTs export types modula RESOLVE From Abstract: "The abscence of side-effects must be explicitly proven by the verification method. This requires the specification language to provide for quantification over the currently active (allocated) instances of an abstract type"

          Abstraction is a mixture of code and specification

          invariant, require, and ensure assertions

          Automatic initializations

          IntegerSet example

          Quantification for Q x:1..alloc( ... R[x] ....) Variable x (an object of exported type) is replaced by R[x] inside. Assume and Confirm statements MetaTheory ??Lamport/Lam Shankar?? ->p304: "A valid program is a collection of valid modules in which each item imported by a module is exported by precisely one other module, and in which the specs of imported and exported items are compatible"


      EscuderoNegroSatriani01

      1. Marina Blanco Escudero & Pedro Gutierrez Negro & Giuseppe Satriani
      2. SPI Patterns: Learning from Experience
      3. IEEE Software Magazine V18n3(May/June 2001)pp28-35
      4. =EXPERIENCES IMPROVEMENT WWW STATISTICS PATTERNS CMM PIE Vasie
      5. PIE::=Process Improvement Experiment", a project that aims to demonstrate the benefits of of improvement by experiment.
      6. Vasie::= See http://www.esi.es/vasie, a repository of more than 250 European PIEs.
      7. impact analysis: one year later. Quality can be improved - especially by mature organizations.
      8. Technical goals are more likely to be achieved than business goals.
      9. There are many paths to improvement.

      Eshuis06

      1. Rik Eshuis
      2. Symbolic Model Checking of UML Activity Diagrams
      3. ACM TOSEM Trans Software Eng & Methodology V15n1(Jan 2006)pp1-38
      4. =DEMO V&V SQA Model checking UML1.5 activity diagrams NuSMV PLTL-X
      5. Page 8 describes the shift in semantics from UML1.5 to HML2.0 but not the state machine vs activity diagram ambiguity in UML2.0.
      6. Describes two translations into hypergraphs using WAIT states --activity machines.
      7. Hypergraph:=Net{Node:Set, Hyper_Edge:Set, source:Hyper_edge->@Node~{{}}, target:Hyper_edge->@Node~{{}} }.
      8. Defines two semantics: maximal parallel instantaneous unqueued actions vs queued single-event steps-take-time.
      9. Shows these equivalent in special cases.
      10. Claims to derive CRUD constraints from activity+class diagrams. Evidence is weak.
      11. Tool shows that the queued single-event semantics does not scale. 19 activities is too many.

      EtzioniGoldenWeld97

      1. Oren Etzioni & Kieth Golden & Daniel S Weld
      2. Sound and Efficient closed-world reasoning for Planning
      3. Arif Intell V89n1-2Z(Jan 1997)pp113-148
      4. when the data base is complete it is ok to use the closed world assumption about that "local" database
      5. a sound efficient but incomplete system of reasoning

      EugsterGuerroaui04

      1. Patrick T Eugster & Rachid Guerroaui
      2. Distributed programming with typed events
      3. IEEE Software Magazine V21n2(Mar/Apr 2004)pp-
      4. =DEMO NET DATAFLOW TYPED PUBLISH/SUBSCRIBE TPS GDACs Generic Java rpc lynda
      5. decouple processes in time, space, & flow.

      Evans82

      1. ?? Evans
      2. Software Engineering for the COBOL environment
      3. Commun ACM v25 n12 (Dec 1982)
      4. sequential

      Evans01

      1. Gary K Evans
      2. Palm-sized Process: Point-of-sale gets agile
      3. Software Development Magazine V9n9(Sep 2001)pp28-32
      4. =CASESTUDY AGILE POS ITERATIVE EVOLUTION Java PEOPLE LITE RUP UML Modeling LEGACY SYSTEM
      5. Unexpected complexity. 14 deliveries, one per 4 weeks, small team, good manager, cubicles+war-room w white boards.
      6. (above)|-next project will reduce modeling further.

      Evans03

      1. Gary K Evans
      2. UML2.0 Primer
      3. Software Development Magazine V11n4(Apr 2003)pp36
      4. =SIDEBAR UML Parts Ports Connectors
      5. UML2_0::= See http://www.u2-partners.org/.
      6. A part is a set of objects contained within another object called the owner. Owners are composed of parts.
      7. Parts have ports (small squares). Ports can be connected by connectors. Ports can have interfaces: provided to others, required from others.
      8. A Connector is an association indicating communication between parts and/or thru ports. Connectors can be assembly or delegation connectors

      EvansGuttagHorningTan94

      1. David Evans & John Guttag & Jame Horning & Yang Meng Tan
      2. LCLint: A Tool for Using Specifications to Check Code
      3. SIGSOFT'94 Proc 2nd ACM SIGSOFT Symp on Foundations of Software Engineering & ACM SIGSOFT Software Engineering Notes V19n5(Dec 1994)pp

      Evanco03

      1. William M Evanco
      2. Comments on "The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics"
      3. IEEE Trans Software Engineering V29n7(Jul 2003)pp670-672
      4. =CRITIQUE STATISTICS QUALITY CODE SIZE OBJECT-ORIENTED METRICS
      5. (1) Need studies of how several metrics effect quality.
      6. (2) Select variables with a view to causality (as shown by timing) even if there is a correlation.
      7. Example: LoC correlates with Number of Methods. But Number of Methods drives size of Code rather than Vice versa.

      EvansEtal03

      1. Gary Evans & Allen Vander Meulen & Donna L Davis & Scott Meyers & Name Withheld
      2. Curse of the Living Code: Five Bone Chilling Tales of IT
      3. Software Development Magazine V11n10(Oct 2003)pp29-31
      4. =ANECDOTEs AGILE REQUIREMENTS USER RISKS COMMENTS EVOLUTION
      5. Agile development meets big design up front - of a database. Godzilla meets Bambi? Management may require agile development but force a complete set of requirements first!
      6. Programmer removes comments placed by colleague to preserve job security.
      7. User interface has 11 or more different ways to close a window.
      8. When a programmer chooses a bad user interface, the user and organization pays, not the programmer.
      9. There is no such thing as a one-off solutions.... "not only did it survive, it mutated into a two-headed beast".

      EvansLarochelle02

      1. David Evans & David Larochelle
      2. Improving Security Using Extensible Lightweight Static Analysis
      3. IEEE Software Magazine V19n1(Jan/Feb 2002)pp42-51
      4. =CASESTUDY C gets TOOL Splint was LCLint taint
      5. Common and detectable defects lead to exploitable security holes.
      6. defect stats: buffer overflow 19%, malformed input 16%, memory leaks, format bugs 6%, ...
      7. Splint::GPL ::= See http://www.splint.org.
      8. C source code + annotations /*@,,,@*/ static checked assertions.

      EvansSammutEtal05

      1. A Unified Superstructure for UML
      2. Andy Evans & Paul Sammut & James S. Willans & Alan Moore & Girish Maskeri
      3. Journal of Object Technology Vn1(Jan 2005) [ article6 ]
      4. =DEMO UML SYNTAX vs SEMANTICS
      5. Proposes providing a common abstract syntax for all structural diagrams and a different one for all behaviorial diagrams.

      EvaristoDesouzaHollister05

      1. J Roberto Evaristo & Kevin C Desouza & Kevin Hollister
      2. Centralization momentum: the pendulum swings back again
      3. Commun ACM V48n2(Feb 2005)pp67-71
      4. =HISTORY DECENTRALIZATION
      5. Notes

      EveleensVerhoerf10

      1. J Laurenz Eveleens & Chris Verhoef
      2. The rise and fall of the Chaos Report figures
      3. IEEE Software Magazine V27n1(Jan/Feb 2010)pp30-36
      4. =CRITIQUE STATISTICS PROJECT SUCCESS CHALLENGED ESTIMATION
      5. Provides evidence that the process used by the Standish group to measure the percentage of projects that succeed is actually measuring the accuracy of the estimates at the start of the project not the real success of the project.
      6. Problems with a closed data set.
      7. Tendency to sensationalize results when advocating new methods.

      EvermannWand05

      1. Joerg Evermann & Yair Wand
      2. Toward formalizing domain modeling semantics in language syntax
      3. IEEE Trans Software Engineering V31n1(Jan 2005)pp21-37
      4. =IDEA REALITY DOMAIN Bunge ONTOLOGY LANGUAGES MODEL UML STATE CHART METAMODEL
      5. Map ontology of the real domain into constraints on modeling languages to minimize "impedance mismatch" between analysis and design.

      FaegriHanssen07

      1. Tor Erlend Faegri & Geir Kjetil Hanssen
      2. Collaboration, Process Control, and Fragility in Evolutionary Product Development
      3. IEEE Software Magazine V24n3(May/Jun 2007)pp96-104
      4. =EXPERIENCE Evo GILB EVOLUTION METRICS IMPROVEMENT
      5. Reports on a two-year process of introducing and adapting Tom Gilb's Evo (1981) Process.
      6. Evo has a strict weekly schedule, defines increments in terms of measurable stakeholder needs.
      7. It needs efficient tools to support the rapid weekly cycle of adding requirements and testing solutions.
      8. May need to add "Green weeks" where system is tested without new functions being added. May need to have some 2 week iterations.
      9. Evo depends on the presence of the stakeholders.
      10. Evo improves customer satisfaction.


      11. (dick)|-for a good comparison of Evo with other agile methods see [Larman04]

      Fafchamps94

      1. Danielle Fafchamps(HP labs)
      2. Organizational Factors & Reuse
      3. IEEE Software Magazine V11n5(Sep 1994)pp31-41
          Various organisations, optimised and compared.

          Reccommend a special reuse team - interacting with (groups and individuals) and prioritized by by customer teams. Must be respected programmers. sample solutions. Provides documentation.


      Fagan76

      1. M E Fagan
      2. Design & Code Inspections to Reduce Errors in Program Development
      3. IBM Sys J. V15N3(1976) pp 182-211( IBM Reprint Order No. G32)
      4. =EXPERIENCE SQA QUALITY
      5. Compare [Fagan99] (23 years later).

      Fagan99

      1. M E Fagan
      2. Design & Code Inspections to Reduce Errors in Program Development
      3. IBM Sys J. V38N2(1999)pp182-211 [ scholar?hl=en&lr=&cluster=1567005265693599201 ]
      4. =EXPERIENCE SQA QUALITY
      5. Compare [Fagan76] (23 years earlier).
      6. A precisely defined and proven method of examining code to find out the defects within it.

      Fairbairn87

      1. ?? Fairbairn
      2. Making Form follow Function: An Experiment in Functional Programming Style
      3. Software - Practice and Experience V17n6(Jun 1987)pp379-386
      4. =EXAMPLE design PURPOSE

      FairleyWilshire05

      1. Richard E (Dick) Fairley & Mary Jane Wilshire
      2. Iterative Rework: The Good, the Bad, and the Ugly
      3. IEEE Computer Magazine V38n9(Sep 2005)pp34-41 =ESSAY PROCESS STATISTICS QUALITY CONTROL CHARTS REWORK EVOLUTION ITERATION RE FACTORING REWORK AGILE ITERATIVE Too much (>20%) or too little rework(<10%) means something is wrong. So track % rework on a statistical control chart (Shewart 1920s) with upper and lower control levels. Trends, spikes, and random walks over the same limit trigger ro ot cause analysis and improvement.
      4. All types of rework can be good, bad, or ugly!
      5. Rework= Evolutionary_rework | Avoidable_rework.
      6. Evolutionary_rework::=response to changing world.
      7. Avoidable_rework::=Retrospective_rework | Corrective rework.
      8. Retrospective_rework::= work that could have been before.
      9. Corrective rework::= work the fixes defects in current or previous versions Distinctions are not very objective but good enough to suggest process improvements.

      FangSoKreindler96

      1. F W(Walter) Fang & Andrew C So & R Jordan Kreindler
      2. The Visual Modeling Technique(VMT) : An Introduction and Overview
      3. JOOP (Jul-Aug 1996)pp48-57+73
      4. VMT::=OMT+Use cases+RDD+CRC+object types(entity|interface|control)+event traces+pre/post-conditions. [CRC]

      FarenhorstVliet08

      1. Rik Farenhorst & Hans van Vliet
      2. Experiences with a Wiki to Support Architectural Knowledge Sharing
      3. 3rd Workshop on Wikis for Software Engineering (Sep 2008) .See http://farenhorst.eu/publications/Farenhorst-vanVliet-Wikis4SE2008-CRC.pdf (download November 24th 209).
      4. =EXPERIENCE WIKI ARCHITECTURAL DECISIONS NPK
      5. How to make it easy for a team to store, retrieve and develop architectural decisions and their rationales using a Wiki.
      6. Knowledge = Decisions + Design.
      7. Concern=Net{Description, #Alternative, Ranking Criteria, O(Decision)}
      8. Decision=Net{Id, Status, #Relationship, Rationale}.
      9. Do start small.
      10. Do allow and stimulate all types of knowledge.
      11. Do strive for integration.
      12. Don't impose too much structure.
      13. Don't restrict access

      Farquhar05

      1. Cynthia Patrice Farquhar
      2. An Empirical Study: usage of the Unified Modeling Language in the Bachelor of Science and Master of Science Degree Programs at California State University, San Bernardino
      3. CSUSB CSci Masters Thesis March 2005
      4. =EMPIRICAL CSUSB STUDENT UML USAGE PEDAGOGY
      5. All undergraduates and most(96%) of graduate students know what the UML is.
      6. Was the UML used as a blueprint, sketch, programming language, or required documentation? [Martin Fowler 2003]
        Table
        Usage% of time
        Required83%
        Sketch78%
        Blueprint76%
        Language38%

        (Close Table)

      Farley01

      1. Jim Farley
      2. Picking a Winner: .NET vs J2EE
      3. Software Development Magazine V9n3(Mar 2001)pp36-42
      4. =COMPARISON PLATFORM Microsoft XML C# CLR Sun Java Beans JVM
      5. J2EE::="Java 2 Enterprise Edition".
      6. "Surprisingly similar".
      7. J2EE works with Windows+Linux and Solaris, .NET works with windows only.
      8. J2EE needs Java code, .NET accepts C++, VB, and C#.
      9. XML is central to .NET and peripheral to J2EE.

      Farmer03

      1. William M Farmer
      2. A Basic Extended Simple Type Theory
      3. McMaster University Hamilton Ontario CA (29 Sep 2003)
      4. =IDEA LOGIC TYPES
      5. BESTT::= CSTT with HOL, sets, lists, & tuples.
      6. CSTT::= Church's Simple Type Theory.

      Farmer06

      1. Eugene Farmer
      2. The Gatekeeper's Guide,or How to Kill a Tool
      3. IEEE Computer Magazine V39n10(Oct 2006)pp12-13
      4. =JOKE TOOLS FAILURE
      5. proposes 10 ways to stop a tool being adopted
        1. Make it Optional.
        2. Economize on Training -- a lecture with 50 Powerpoiont slides and no workshops, handson experience, or real examplesof use.
        3. Don't use a real project.
        4. Never integrate the tool into the workflow or with other tools.
        5. Use it sporadically.
        6. Call it a "quality initiative"
        7. Marginalize the champion.
        8. Capitalize on early misteps.
        9. Make only a small investment
        10. Exploit fear, uncertainty, doubt, laziness, and inertia.

      FarmerMohrenschildt00

      1. William M. Farmer and Martin v. Mohrenschildt
      2. Transformers for Symbolic Computation and Formal Deduction
      3. Presented at a Workshop on the Role of Automated Deduction in Mathematics, CADE-17, Carnegie Mellon University, Pittsburgh, Pennsylvania, June 2000 [ transformers.pdf ]
      4. =IDEA LOGIC DEDUCTION COMPUTATION TERM TRANSFORMERS
      5. STTM::="von-Neumann-Bernays-Goedel set theory". This has terms and formulas. Terms may be undefined, but formulas are always defined and are either true or false.
      6. Transformers are total functions which may or may not preserve meaning or logistic properties like being (provably) true or false.

      Farrell95

      1. Joseph Farrell
      2. Arguments for Weaker Intellectual Property Protection in Network Industries
      3. StandardView V3n2(Jun 1995)pp46-49
          defines economic network effects and first-mover advantage and analyses the effect a patent has as a result

      Farrow84

      1. Rodney Farrow
      2. Generating a Production Compiler from an Attribute Grammar
      3. IEEE Software Magazine (Oct 1984) pp77-93
      4. DDD

      Faulketal92

      1. Stuart Faulk & John Brackett & Paul ward & James Kirby Jr
      2. The CORE Method for Real-Time Requirements
      3. IEEE Software magazine V9n6(Sep 1992)pp22-33

        [SPC93]


          [SPC93] Reality QUALITY PURPOSE graphic formal non-algorithmic readable rigorous mathematics virtual machines

        1. CORE::=Consortium Requirements Engineering Paul Ward's CASE + David Parnas
        2. CASE::= Ward+Mellor Parnas - four variables: monitored, controlled, input and output constraints Nat: from nature and Req from required Relations

          Objects encapsulate design decisions

          Context, ERD, STD, forms for objects, Independent of any format, standard or notation.


      FaulkHietmeyer97

      1. Rigorous Requirements for Real-Time Systems: Evolution and Application of the SCR method
      2. Tutorial [ICSE'97]
      3. Derived from CORE

      FavaroPfleeger98

      1. John Favaro & Shari Lawrence Pfleeger<s.pfleeger@ieee.org>
      2. Making Software Development investment Decisions
      3. ACM SIGSOFT Software Engineering Notes V23n5(Sep 1998)pp69-74
      4. =THEORY COSTS IMPROVEMENT
      5. Making decisons: "Customer satisfaction alone is inadequate", "Market leadership alone is inappropriate".
      6. Compares rules used in SE litereature for estimating the value of an investment: Net Present Value, Payback, Average return on Book value, Internal rate of return, Profitability index. Reccommends first.
      7. NPV::= sum[t:Time]discounted(benefit(t), t) - initial_investment.

      Fayad02

      1. Mohamed Fayad
      2. Accomplishing Software Stability
      3. Commun ACM V45n1(Jan 2002)pp111-115+ letters V45n5(May 2002)pp11-12
      4. =EXAMPLE (kitchen) REALITY Object-Oriented ARCHITECTURE EBTs enduring BUSINESS THEMES BUSINESS OBJECTS
      5. In a kitchen there are certain enduring business themes (EBT) : food storage and preservation, cooking, cuisine, livability. Livability includes cleanliness, light, and convenience. Light is a class of business objects. Cuisine has Recipes as business objects.
      6. These themes are expressed by changeable industrial objects: cabinet, refrigerator, range, cook-top, sink, window, shelf, etc etc
      7. Themes are intangible, objects are not. Business is stable and implicit.
      8. See previous [FayadAltman01]

      FayadAltman01

      1. Mohamed E Fayad & Adam Altman
      2. An Introduction to software stability
      3. Commun ACM V44n9(Sep 2001)pp95-98
      4. =THEORY Object-Oriented DESIGN REALITY UML =CASESTUDY loans
      5. Another example: [Fayad02]
      6. stable designs fit the stable aspects of the environment well. More than cursory analysis needed.
      7. Stable designs need EBTs and BOs modeled by classes (not functions).
      8. EBT::concepts-"Enduring business Themes", examples: "friendship", "Finance", "solvency".
      9. BO::things="Business Objects", -- examples:"friend", "loan", "expenses".
      10. Proposes adding {enduring} and {business} "stereotype" to the UML.
      11. (dick)|-UML ERROR: should be <<enduring>> and <<business>>.
      12. (dick)|-perhaps some EBTs are better treated as ASPECTS.

      Fayadetal93

      1. Mohamed E Fayad & Louis J Hawn & Mark A Roberts & Jerry R Klatt (Macdonnel Douglas Corp)
      2. Using the Shlaer-Mellor Object-Oriented Analysis Method
      3. IEEE Software Magazine V10n2 (Mar 1993)pp43-52 + Correspondence V10n5(Sep 1993)pp6-7
      4. OBJECT-ORIENTED METHOD OOA review
        1. p43. consistently produced better abstract objects than other OOMethods
        2. p44. Best applied to information systems or to re-engineering; when the data objects are defined.

          **disputed in correspondence** Colberts ws succssful, but SAD not defined map from analysis to design, or use of Ada Packages. S-M: 2 months for ERA, rules:uniformit, more than name, no Ors, more than a list. Tangibles|roles|incidents|interactions|specifications

        3. p47 CASE tool:=Teamwork
        4. pp48-49 ->> Object selection(ERA) is sound TNF rules Get a complete information model first, Need more than names and few lowlevel object classes defined. Good in the RT area States -> the wicked problem (Ramamoorthy). Weak in the PQ and S area.
        5. p50. Data and process analysis linked, can express constraints, but DFDs become cluttered needed a data and process dictionary. State models can list duplicate processes. Need more views of objects. Semantics difficult: Just choosing descriptive words.
        6. p51 Interaction insufficiently documented. DFD not much help (*disputed*)with update/retrieval but resulting processes are cohesive. TWO MONTHS.

      Fayadetal94

      1. Mohamed E Fayad & Wei-Tek Tsai & Mark A Roberts & Louis J Hawn & Jay W Schooley
      2. Adapting an Object-Oriented Development Method
      3. IEEE Software magazine v11n3(May 1994)pp68-76
      4. =SURVEY METHODS Colbert OOSD MAINTENANCE

      Fayadetal95

      1. Mohamed E Fayad & Wei-Tek Tsai
      2. Object-Oriented Experiences
      3. Commun ACM V38n10(Oct 1995)pp51-53
      4. recommends software ENGINEERING+training: 40 hours training over 10 weeks+metrics+process+plan+SQA

      Fayadetal96

      1. Mohamed E Fayad & Wei-Tek Tsai & Milton L Fulgrum
      2. Transitions to Object-Oriented software Development
      3. Commun ACM V39n2(Feb 1996)pp108-121
      4. =EXPERIENCE EDUCATION PEOPLE
      5. chaos to OO process takes a year independently of project team and techniques

        [Racko95d]

      6. : "first step is to get process and then add OO"

      FayadLaitinenWard00

      1. Mohamed Fayad & Mauri Laitinen & Robert P Ward
      2. Software Engineering in the Small
      3. Commun ACM V43n3(Mar 2000)pp115-118 CR0102-0079
        =ESSAY Census data|-manysmall sooftware development companies
      4. Small companies and start ups need scaled down procedures that are faster and co-evolve requirements along with the code.
      5. Compare [Botting97a]

        [Botting95b]

      Feather98

      1. Martin S Feather
      2. Rapid Application of Lightweight Formal Methods for Consistency Analysis
      3. IEEE Trans SE V24n11(Nov 1998)pp949-959
      4. =EXPERIENCE NASA DATABASE LISP
      5. Wanted: moderate results extremely rapidly. Discover implicit causal loops.

      FeatherLamsweerde94

      1. Martin S Feather & Axel van Lamsweerde(eds)
      2. Succeedings of the seventh International Workshop on Specifiction and Design(IWSSD7)
      3. ACM SIGSOFT Software Engineering Notes V19n3(Jul 1994)pp18-20
          Keynote: Tom Maibaum "Taking More of the Soft out of Software Engineering" - Engineers usually make successful use of standard predefined models that hide teh mathematics. Requirements engineering, Colin Potts... Jackson<Jacksonma@attmail.att.com> and Zave. Jackson: system is a virtual device, translate user's domain model into evironmental events model. Elicitation for a new libray problem We deal with big, some would say, insoluable problems, such as the clarification of objectives...resolution of disagreements...validation. How to elicit or define requirements in the first place. Results: Set of notes, differeing perspectives, less than full agreement, "The experts did not descrine 'the' system that they wanted[...]but described many of the automation opportunities that were currently being provided"... many gaps and ambiguities. Real time systems: separating environment from system. "A front-end language, often graphical[...] is often used to produce an easy-to-understand specification of a real time system[...]automatically translated...more amenable to formal analysis Concurrency: "Start by identifying the events that concern the interface between a system and its environment"..."'If it is not taught to sophomores, can we expect it to be used?'" Formal Reasoning: "is becoming one of the key issues in many areas of software specification and design." Design Methods and Software Architectures: design fragments, 5 kinds of architecture: Conceptual, Module Interconnection, Code, Executiton, Hardware. "Modeling the relationships among the components is useful for understanding a method" [...] "The purpose of the process portion of design methods was to constrain human creativity."

      Feijs93

      1. Loe Feijs(Philips Reearch Laboratories Eindvoven)
      2. A Formalization of Design Methods: A λ-calculus Approach to Systems Design with an Application to Text Editing
      3. Ellis Horwood Chichester West Sussex UK 1993
      4. ISBN 0-13-106113-5
      5. Reviews CR9408-0498 IEEE Software magazine V11n5(Sep 1994)p130 by Anthony Hall(Praxis)
          Keywords: COLD-K, VDM, Z, Designs as DAGS, black box and glass box properties. Specification \square_less_than_equal Implementation

          λ-π


      FeijsJonkers92

      1. Loe M G Feijs & H B M Jonkers
      2. Formal Specification and Design
      3. Cambridge University Press (Cambridge UK & New York NY) 1992
      4. $48 ISBN0-521-43457-2
      5. Reviewed IEEE Software magazine v11n3(May 1994) & AMM Mar 1993 p296 & CR9412-0849
          COLD-K but not about notation but about formal spec and design algebraic vs state based readable and elegant introduction

      FeijsJong98

      1. Loe Feijs & Roel de Jong
      2. 3D Visualization of Software Architectures
      3. Commun ACM V41n12(Dec 1998)pp73-78
      4. =DEMO GRAPHIC 3D TOOL VRML RELATIONS LEGO GUCS
      5. Compare [CallaghanHirschmuller98]

      FeijsJonkers94

      1. Loe M G Feijs & H B M Jonkers & Cornellis A Middelburg
      2. Notations for Software Design
      3. Springer Verlag 1994
      4. =SURVEY COLD-1 FORMAL MATHEMATICS PICTORIAL

      Fekete93a

      1. Alan Fekete
      2. Reasoning about Programs: Integrating Verification and Analysis of Algorithms Into The Introductory Programming Course
      3. ACM SIGCSE Bulletin V25n1(Mar 1993) 24th Technical Symposium on Computer Science Education pp198-202

      Fekete93b

      1. Alan Fekete
      2. Formal Models of Communication Services: A Case Study
      3. IEEE Computer Magazine(Aug 1993)pp 37-47
          Input/Output Automata (Lynch Tuttle) Manual Has decomposition property that correctness is transitive and distributes over parallel composition.

          Case study: Atomic multicast cf CSP and CCS FSM


      FelberGuerraouiFayad99

      1. Pascal Felber & Rachid Guerraoui & Mohamed E Fayad
      2. Putting OO Distributed programming to Work
      3. Commun ACM V42n11(Nov 1999)pp97-101
      4. =ESSAY OBJECT-ORIENTED DISTRIBUTED TECHNICAL RELIABILITY
      5. failure as a 1stclass abstraction, push & pull techniques

      Felderetal94a

      1. Miguel Felder & Dino Mandroli & Angelo Morzenti
      2. Proving Properties of Real-Time Systems Through Logical Specifications and Petri Nets
      3. IEEE Trans SE V20n2(Feb 1994)pp127-141
      4. =FORMAL TIMING Temporal TRIO
          Basic temporal operator
        1. Dist( P, d )::=P is true d time units from (_),
        2. model of timed petrie nets
        3. proof that dining philosphers TPN is deterministic and every body eats every 7 units of time!

          compare with MATHS manual on Modal Logic

          Question: They prove a liveness property of the philosophers by proving a liveness property for one fork. Is this circular?


      Felderetal94b

      1. Miguel Felder & Angelo Morzenti
      2. Validating Real-Time systems by History-Checking TRIO Specifications
      3. Trans Softw Eng Methodol V9n4(Oct 1994)pp308-339
      4. =EXPERIENCE TIMING TRIO LOGIC SPECIFICATION PROOF
          Some experiences with Italian utility companies

          Semantic tableaus for proof and for history checking

        1. Futr(A,t)::=A(_+t), Past(A,t) ::=A(_-t)
        2. Table 1, p316 defines:
        3. AlwF, AlwP, Alw, SomF, SomP, Som,Lats,Lasted, since, Since[w], WithinP, Until, Until[w], UpToNow, FirstTimeF

      FelderPezze02

      1. Miguel Felder & Mauro Pezze
      2. A Formal design Notation for Real-Time systems
      3. ACM TOSEM Trans Software Eng & Methodology V11n2(Apr 2002)pp149-190
      4. =EXPERIENCE GRAPHIC TIMING NOTATION SEMANTICS PETRI SA/RT ward-Mellor STATECHARTS Model-checking Cabernet

      FellerFitzgeraldHoek01

      1. Joseph Feller & Brian Fitzgerald & Adre van der Hoek
      2. Making Sense of the Bazaar: 1st Workshop on Open source Software Engineering
      3. ACM SIGSOFT Software Engineering Notes V26n6(Nov 2001)pp51-52 & IEEE Proceedings -- Software V149n1 & [ http://opensource.ucc.ie/icse2001/ ]
      4. =CONFERENCE OPEN SOURCE

      FeltyNamjoshi03

      1. Amy P Felty & Kedar S Namjoshi
      2. Feature Specification and automated Conflict Detection
      3. ACM TOSEM Trans Software Eng & Methodology V12n1(Jan 2003)pp3-27
      4. =CASESTUDY telecommunications SPECIFICATION FEATURES LOGIC LTL FSM Buchi MODEL Checking TOOL FIX COSPAN
      5. Features expressed in sugared LTL: pre/post conditions. including until/unless discharge requirements.
      6. Complex/careful definition of what it means for two features to conflict.
      7. FIX use LTL approximation to find witnesses for conflicts.

      FengEtAl11

      1. Xin Feng & David Lorge Parnas & T H Tse & Tony O'Callaghan
      2. A Comparison of Tabular expression-based testing strategies
      3. IEEE Trans Software Engineering V37n5(Sep/Oct 2011)pp616-634
      4. =THEORY =EXPERIMENT =ADVERT TABULAR EXPRESSIONS TESTING SUBSUMPTION
      5. Tables are already useful for writing specifications perhaps they tables can be used to derive test cases?
      6. Example based on western calendar.
      7. Strategies: partition, decision tables, basic meaningful impact, fault-based

      Fenton91

      1. Norman Fenton
      2. Software Metrics - A Rigorous Approach
      3. Chapman & Hall London UK 1991
      4. See Fenton94
          reccommended by Warren Keufel Software Development V3n4(Apr 1995)pp29-33

      Fenton94

      1. Norman Fenton
      2. Software Measurement: A Necessary Scientific Basis
      3. IEEE Trans SE V20n3(Mar 1994)pp199-206
      4. =THEORY METRICS COCOMO Function points
      5. Notes [ Fenton94.mth ]
      6. Compare with Matson, Barrett and Mellichamp SE-V20n4(Apr 1994) ->>p285:"The key point is that improved results may be achieved by unbundling the function point variable into its constituent components."

      Fentonetal94

      1. Norman Fenton & Shari Lawrence Pfleeger & Robert L Glass
      2. Science and Substance: A Challenge to Software Engineers
      3. IEEE Software magazine v11n3(July 1994)pp86-95+ Correspondence V11n5pp6+8 CR9509-0737
      4. =ESSAY critiscizing computer science's contribution to software engineering and lack of empirical data testing theories.
      5. Notes: [ Fentonetal94.mth ]
      6. Good communication and management count more than technology
      7. p 90:"Inspections are the cheapest and most effective testing techniques for finding faults"
      8. p93: Software Engineering Lab: 8 major projects using OO/Ada.. reuse rises dramatically (20%..80%) but OO/Ada requires significant domain analyisis and project tailoring

      FentonKrauseNeil02

      1. Norman Fenton & Paul Krause & Martin Neil
      2. Software Measurement: Uncertainty and Causal Modeling
      3. IEEE Software Magazine V19n4(Jul/Aug 2002)pp116-122
      4. =EXAMPLE STATISTICAL MODELS PROCESS PRODUCT Bayesian networks
      5. regression does not predict errors well in practice. A positive correlation overall can become negative when another factor is taken into consideration (Simpson's paradox 1899).
      6. (Bayes_theorem_simple): P(event given condition) = P(condition given event)*P(event)/p(condition).
      7. Causality modeled by graph(node=>events, arrows=>causes), cause mean that p(one given other) is non zero.
      8. Note: For a Bayesian Belief Network the formula is P(event given set of causes) not a set of P(event given one cause). [ maths/math_22_graphs.html#BAYESIAN_NETWORK ]
      9. Shows how a distribution of defects depends on complexity and on the number of defects found and fixed in unit testing.

      FentonNeil98

      1. Norman E Fenton & Martin Neil
      2. A Strategy for Improving Safety Related Software Engineering Standards
      3. IEEE Trans SE V24n11(Nov 1998)pp1002-1013
      4. =SURVEY STANDARDS RISKS
      5. Conformance vs risk assessment, product vs process vs resource standards
      6. Need for many ministandards not one big standard for all industries, software projects, and project phases

      FentonNeil99

      1. Norman E Fenton & Martin Neil
      2. A Critique of Software Defect Prediction Models
      3. IEEE Trans Soft Eng V25n5(Sep/Oct 1999)pp675-689
      4. =SURVEY SQA METRIC QUALITY RELIABILITY DEFECT PREDICTION
      5. problems:=following,
        1. how do defects relate to failures?
        2. weak statistical work
        3. Goldilock's Conjecture:=defect rate of large modules less than for very small ones.

      6. BBN:=Bayesian Belief Network.

      FentonOhlsson00

      1. Norman E Fenton & Niclas Ohlsson
      2. Quantitive Analysis of Faults and Failures in a complex software system
      3. IEEE Trans Software Engineering V26n8(Aug 2000)pp797-814
      4. =EXPERIENCES ANALYSIS SIZE METRICS RELIABILITY
      5. Hatton and others: empirical data opposes theory of modular programming that large modules have proportionally more errors.
      6. See [Adams84] most faults in use come from a few of defects.
      7. Pareto analysis of sizes, faults, testing failures, and failures in 1st year of use.

        two releases.

      8. 20% of modules account for 60% of the pre-release faults but only 30% of the size.
      9. 10% of modules account for 80..100% of the operational failures. But they were in the smaller modules mainly.
      10. Many pre-release faults predict fewer operational faults!
      11. faults/LOC don't correlate with any f(LOC) or complexity metrics.
      12. evidence that fault density does not change with time or release.
      13. 10 times as many found in testing as in operation.
      14. p812: There are no unbreakable laws of software engineering.

      FergusonHumphreyEtal97

      1. Pat Ferguson & Watts S Humphrey & Soheil Khajenoori & Susan Macke & Annettes Matvya
      2. Results of Applying the Personal Software Process
      3. IEEE Computer magazine V30n5May 1997)(pp24-31
      4. =EXPERIENCES with PSP IMPROVEMENT

      FerreJuristoWindlConstantine01

      1. Xavier Ferre & Natalia Juristo & Helmut Windl & Larry Constantine
      2. Usability Basics for Software Developers
      3. IEEE Software Magazine V18n1(Jan/Feb 2000)pp22-29
      4. =ADVERT USER QUALITIES
      5. usability >== { learn-ability, efficiency, user retention over time, error rate, satisfaction }.
      6. Must be analyses first, designed in at the front and tested for at the end with real users.
      7. Many reviews before design. Benchmarks.
      8. Conceptual design and visual design.
      9. specifications : Table = attribute><instrument><values><current><worst acceptable><planed target><best possible><observed.
      10. (Like Gilb!)
      11. Prototypes: paper, wizard of Oz, scenarios, storyboards, snapshots.

      FernandezRamsey97

      1. Mary Fernandez & Norman Ramsey
      2. Automatic Checking of Instuction Specifications
      3. TOOL SLED fields opcodes...assembler idioms checker [ toolkit ]

      FerrariGnesiMontanariPistore03

      1. Gian-Luigi Ferrari & Stefania Gnesi & Ugo Montanari & Marco Pistore
      2. A Model-Checking Verification Environment for mobile Processes
      3. ACM TOSEM Trans Software Eng & Methodology V12n4(Oct 2003)pp440-473
      4. =DEMO TOOL MODEL CHECKING MOBILE π-calculus FSM HD-Automata HAL π-logic ACTL

      FerrisFarrell03

      1. Christopher Ferris & Joel Farrell
      2. What are Web Service
      3. Commun ACM V46n6(Jun 2003)p31
      4. =SIDEBAR WEB/NET SERVICES W3C URI XML WSDL SOAP
      5. An application identified by a URI with interface and bindings defined described and discovered via XML.
      6. See
      7. Web_Services_Architecture_Draft::= See http://www.w3.org/TR/WD-wsa-xxx.
      8. Finding, publishing and working with services provided over the web.
      9. WSDL::="Web services description Language"

      Fetzer88

      1. J H Fetzer
      2. Program Verification: The Very Idea
      3. Communications ACM V31n9(Sep 1988)pp1048-1063
      4. algorithms can be proved but programs can not be. Used in Dasgupta91

      FeysFitch69

      1. RObert Feys & Frederic B Fitch
      2. Dictionary of Symbols of Mathematical Logic
      3. Amsterdam North-holland Pub Co 1969
      4. =DICTIONARY LOGIC SYMBOLISM LANGUAGE

      FiadeiroMaibaum95

      1. Jose Luiz Fiadeiro(Ilf@di.fc.ul.pt) & Tom Maibaum(tsem@doc.ic.ac.uk)
      2. Interconnecting Formalisms: Supporting Modularity& Reuse and Incrementality [Kaiser95]

      FichmanKemerer92

      1. Robert G Fichman & Chris F Kemerer
      2. Object-Oriented and Conventional Analysis and Design Methodologies
      3. (Special Issue: Object-Oriented Computing) IEEE Computer Magazine V25n10(Oct 1992)pp22-39

      FichmanKemerer97

      1. Robert G Fichman & Chris F Kemerer
      2. Object Technology and Reuse: Lessons from Early Adopters
      3. IEEE Computer Magazine V30n10(Oct 1998)pp47-59
      4. =EXPERIENCES OBJECT-ORIENTED REUSE
      5. authors visited 4 companies:steep OO learning curve+immature tools+reuse<OO vision
      6. lessons: Money for learning+complete architecture first+reuse is separate+adopting OO is R&D

      FickasHelm92

      1. Stephen Fickas & B Robert Helm
      2. Knowledge Representation and Reasoning in the Design of Composite Systems
      3. IEEE Trans SE-18n6(Jun 1992)pp470-482
      4. Composite::=hard+soft+human
      5. lift problem - difficult to evaluate our design
      6. Critter
      7. design states::= generative infrastructure and constraints

      8. CR9307-0467

      Fidge96

      1. Colin Fidge
      2. Fundamentals of Distributed System Observation
      3. IEEE Software Magazine V13n6(Nov 1996)pp77-83

      FidgeKearneyUtting97

      1. Colin Fidge & Peter Kearney & Mark Utting
      2. A Formal Method for Building Concurrent Real-Time Software
      3. IEEE Software magazine V14n2(Mar/Apr 1997)pp99-106
      4. Quartz DEMO nonsequential performance method. Does it resolve Parnas's Problem?

      FieldRamalingam99

      1. John Field & G Ramalinga
      2. Identifying Procedural Structure in COBOL Programs
      3. PASTE'99 & ACM SIGSOFT Software Engineering Notes V24n5(Sep 1999)pp1-10
      4. =ADVERT IBM VisualAge STRUCTURE LEGACY MAINTENANCE

      Fielding99

      1. Roy T Fielding
      2. Shared Leadership in the Apache Project
      3. Commun ACM V41n4(Apr 1999)pp42-43
      4. =EXPERIENCE PEOPLE PROCESS

      FieldsElvang-Goranson92

      1. Bob Fields & Morten Elvang-Goranson
      2. A VDM Case Study in Mural
      3. IEEE Trans SE-18n4(Apr 1992)pp279-295
      4. VDM Mural specification and proof system using LPF Manchester and Rutherford Labs UK
      5. slow
      6. unfriendly
      7. tedious time consuming
      8. no library..

      FilipenkoMorris92

      1. I Filipenko & F L Morris
      2. Domains for Logic Programming
      3. Theor Comput Sci V94n1(Mar 1992)pp63-99
      4. CR9304-0239"Original and sound"

      FilmanEtal02

      1. Robert E Filman & Stuart Barrett & Dianna D Lee & Ted Linden
      2. Inserting Ilities by Controlling Communications
      3. Commun ACM V45n1(Jan 2002)pp116-122
      4. =IDEA OIF Object-Oriented WEB/NET QUALITIES TOOL Pragma = EXPERIENCE CORBA/Java cf ASPECT
      5. OIF::="Object Infrastructure Framework",
      6. Theory:= iities can be injected as objects that act on communications between functional objects.
      7. Pragma maps high level properties into a suitable injector initializations.
      8. Annotations allow the object that implement ilities to share meta-data.

      FindlerLatendresseFelleisen01

      1. Robert Bruce Findler & Mario Latendresse & Mathias Felleisen
      2. Behavioral Contracts and Behavioral Subtyping
      3. ACM SIGSOFT proc ESEC-8 FSE-9 Software Engineering Notes V26n5(Sep 2001)pp229-236
      4. =THEORY REUSE RUNTIME V&V TOOLS Object-Oriented MODULES JAVA
      5. Assigning blame for errors to the caller, the called,or the hierarchy.
      6. Tools should report hierarchy errors as well as pre/post condition mismatches.
      7. Notation: method m in class C has precondition pC and postcondition qC expressed as sets of argument values. A call C.m(x) is correct if x in pC and is executed correctly if x in qC afterwards.
      8. If D is derived from C(D extends C), m is a method in D and C then( ( pC ==> pD)and (qD ==> qC).
      9. Most tools presume these conditions hold and replace pD by pD & pC, qD by qC | qD. --- this is wrong.

      Finkelsteinetal94

      1. Anthony C W Finckelstein & Dov Gavey & Anthony Hunter & Jeff Kramer & Bashar Nuseibeh
      2. Inconsistency Handling in Multiperspective Specifications
      3. IEEE trans on Soft Eng vSE-20n8(Aug 1994)pp569-578
      4. =IDEA REQUIREMENTS LOGIC SPECIFICATION See Nuseibehetal94
        1. VeiwPoint::=Net{Style, Work_Plan, Domain, Specification, Work_Record}.

      FinkHouse89

      1. C Fink & K House
      2. Expert Systems Development: The Next Generation
      3. System Builder (Oct/Nov 1989)pp14-26
      4. AI Reality

      Finney96

      1. Kate Finney
      2. Mathematical Notitation in Formal Specifications: Too Difficult for the Masses?
      3. IEEE trans on Soft Eng vSE V22(Feb 1996)pp158-9
      4. readable

      FioravantiNesi01

      1. Fabrizio Fioravanti & Paolo Nesi
      2. Estimation and Prediction Metrics for Adaptive Maintenance Effort of Object-Oriented Systems
      3. IEEE Trans Software Engineering V27n12(Dec 2001)pp1062-1084
      4. =ANALYSIS EXPERIENCE METRICS ESTIMATE MAINTENANCE Object-Oriented EVOLUTION MUSIC
      5. proposes tests and recommends a complex measure for predicting maintenance effort.
      6. Methods are more important for estimation than attributes. Complex interfaces are important.

      Firesmith90

      1. Donald G. Firesmith
      2. "OOD and Ada Bibliography"
      3. Ada Letters VXn6(July/Aug 1990)pp114-128
      4. (SIGADA) ACM Press

      Firesmith93

      1. Donald G. Firesmith
      2. Object-oriented Requirements analysis and logical design: A software engineering approach
      3. John Wiley & sons NY NY 1993 ISBN 0-471-57807-X CR9502-0058

      Firesmith05

      1. Donald G Firesmith
      2. Quality Requirements Checklist
      3. JOT V4n9(Nov-Dec 2005)pp31-38 [ column4 ]
      4. =HOWTO QUALITIES MODEL V&V
      5. Stresses the importance of specifying (1) the conditions when the requirement applies, (2) a measurement, and (3) the minimum threshold value.
      6. Quality_Requirement::= Net{conditions, criteria: Quality_subfactor, threshold: Quality_metric }.

      FiresmithEykholt95

      1. Donald G. Firesmith & Edward M Eykholt
      2. Dictionary of Object technology: the Definitive Desk Reference
      3. SIGS publications Inc NY NY 1995 $55 ISBN 1-884842-09-7 CR9506-0386

      Fishburne00

      1. William Fishburne
      2. Margination and Project Gutenberg
      3. Dr. Dobbs #312(May 2000)pp52+54-56
      4. =ALGORITHM ASCII optimal linebreaks word wrap
      5. Example of problems with informal specifications.
      6. For all lines l, if l.length>0 then 55<= l.length <=75.
      7. optimal lines l, l.length=65.
      8. ??aim for mean of 65 with standard deviation 5.
      9. more aesthetic=>ΤΕΧ, simple word wrap=> 'br'

      FislerKrishnamurth01

      1. Kathi Fisler & Shiram Krishnamurthi
      2. Modular Verification of Collaboration-Based Software Designs
      3. ACM SIGSOFT proc ESEC-8 FSE-9 Software Engineering Notes V26n5(Sep 2001)pp152-163
      4. =THEORY NONSEQUENTIAL CTL MODULE VERIFICATION FSM/AUTOMATA CROSSCUTTING FSATS

      FittingMendelsohn98

      1. Melvin C. Fitting and Richard Mendelsohn
      2. First-Order Modal Logic
      3. Kluwer 1998 paperback 1999
      4. =TEXT FORMAL LOGIC MODAL THEORY
      5. Modal predicate logic

      Fitzgerald03

      1. Michael Fitzgerald
      2. Trash your desktop
      3. MIT Technology Review V106n9(Nov 2003)pp42-46
      4. =IDEA EMAIL ORGANIZER PIM Chandler
      5. Mitch Kapor(Lotus 123), Andy Hertzfield(MacPaint, HyperCard, Magic OS)

      Fitzgerald04

      1. Brian Fitzgerald
      2. A Critical Look at Open Source
      3. IEEE Computer Magazine V37n7(Jul 2004)pp92-94
      4. =ESSAY OPEN SOURCE F/OSS
      5. Lists reasons why F/OSS is "doomed to fail": lack of talent, maintaining quality, coupling between modules, doing mundane tasks, little support, no standards.
      6. However: F/OSS developers are professional. Collaboration is high. Costs are lower. Code is highly modular. Quality control is in place.

      Fitzgerald11

      1. Brian Fitzgerald
      2. Open source software: lessons from and for software engineering
      3. IEEE Computer V44n10(Oct 2011)pp25-30
      4. =SURVEY F/OSS ENGINEERING MODULARITY CM PEER REVIEW EMAIL ONION CONTINUOUS RELEASE
      5. Evidence for value of version control, modularity, configuration management, peer review, status, iteration, etc.

      FitzgeraldEtal05

      1. John Fitzgerald & Peter Gorm Larsen & Paul Mukherjee & Nico Platt & Marcel Verhoef
      2. Validated designs for Object-Orients Systems
      3. Springer-Verlag NYNY 2005 ISBN 1852338814 CR 0605-0447 [ http://www.vdmbook.com/ ]
      4. =UNREAD =MANUAL VDM++
      5. Notes [click here [socket symbol] if you can fill this hole]

      FitzgeraldOKane99

      1. Brian Fitzgerald & Tom O'Kane
      2. A Longitudinal Study of Software Process Improvement
      3. IEEE Software Magazine V16n3(May/Jun 1999)pp37-45
      4. =EXPERIENCE CMM level 4 for Motorola cellular phone software Ireland
      5. CMM must be tailored, CSF (Critical Success Factors) help.
      6. Prompt process notation

      FitzgeraldRussoOKane03

      1. Brian Fitzgerald & Nancy Russo & Tom O'Kane
      2. Software development Method Tailoring at Motorola
      3. Commun ACM V46n4(Apr 2003)pp65-70
      4. =EXPERIENCE ENGINEERING ONESIZE PROCESS IEEE1074 V-SDLC CMM
      5. Tailoring methods takes part at the industry, organization, division and project level.
      6. Follows from [FitzgeraldOKane99]

      FlanaganFreund10

      1. Cormac Flanagan & Stephen N Freund
      2. FastTrack: efficient and precise dynamic race detection
      3. Commun ACM V53n11(Nov 2010)pp93-101 [ 1839676.1896939 ]
      4. =DEMO SHARED MEMORY HAZARDS VECTOR CLOCKS FAST PERFORMANCE
      5. See also [Adve10] and [ElmasQadeerTasiran10]

      FlanaganFreundQadeer05

      1. Cormac Flanagan & Stephen N Freund & Shaz Qadeer
      2. Exploiting Purity for Atomicity
      3. IEEE Trans Software Engineering V31n4(Apr 2005)pp275-291
      4. =THEORY NONSEQUENTIAL PURE ATOMIC REDUCTION

      Flatt12

      1. Mathew Flatt
      2. Creating languages in Racket
      3. Commun ACM V55n1(Jan 2012)48-56 [ 2043176.2063195 ]
      4. =DEMO ADVENTURE GAME RACKET LISP EXTENSION LANGUAGES

      Flor06

      1. Nick Flor
      2. Globally distributed software development and pair programming
      3. Commun ACM V49n10(Oct 2006)pp57-58
      4. =IDEA DISTRIBUTED PAIR PROGRAMMING
      5. Refers back to earlier theories of how side-by-side pair programming generates better solutions...
      6. Need to develop an environment that not only lets two people see and discuss a common artifact, but also lets the programmers see and hear each other's "gestures and mumbles".

      FloracCarletonBarnard00

      1. William A Florac & Anita D Carleton & Julie R Barnard
      2. Statistical Process Control: Analyzing a Space Shuttle Onboard Software Process
      3. IEEE Software Magazine V17n3(Jul/Aug 2000)pp97-106
      4. =EXPERIENCE SQA/V&V PROCESS SPC SEPG
      5. control charts, variations are predictable | abnormal
      6. know the process and its data

      Floyd67a

      1. Robert W Floyd
      2. Assigning Meaning to Programs
      3. pp19-32 of Proceedings of Symposia in Applied Mathematics Vol XIX
      4. formal logic PROOF

      Floyd67b

      1. Robert W Floyd
      2. Non-deterministic Algorithms
      3. J ACM V14n4 pp636-644(Oct67)
      4. =CLASSIC non-sequential non-determinism

      FloydC91

      1. Christiane Floyd
      2. Software Development as Reality Construction
      3. pp86-100 in [FloydCetal91]
      4. =THEORY PEOPLE STAKEHOLDERS VIEWS REALITIES EVOLUTION USER POSTMODERN
      5. multiple perspectives
      6. evolution and integrating production with use
      7. involving people "a web of design decisions"

      FloydCetal91

      1. Christiane Floyd & Heinz Zu"llighoven & Reinhard Budde & Reinhard Kiel-Sawic (Eds)
      2. Software Development & Reality Construction
      3. Springer Verlag NY NY 1992
      4. ISBN 0-387-54349-X QA76.76D47S633
      5. Post-modern

      FloydUllman82

      1. Robert W Floyd & Jeffery D Ullman
      2. The Compilation of Regular Expressions into Integrated Circuits
      3. J ACM (Jul 1982)
      4. regular non-sequential Technical

      FluriEtAl07

      1. Beat Fluri & Michael Wursch & Martin Pinzger & Harald C Gall
      2. Change Distilling: Tree Differencing for Fine-Grained Source Code Change Extraction
      3. IEEE Trans Software Engineering V33n11(Nov 2007)pp725-743
      4. =DEMO ALGORITHM TOOL Eclipse plugin AST STRING MATCHING

      FlynnHoverdBrazier90

      1. Mike Flynn & Tim Hoverd & David Brazier
      2. Formaliser - an Interactive Support Tool for Z
      3. pp128-141 in Nicholls90
      4. PC/AT WYSIWYG windows to LATEX with parsing smalltalk and type checking

      FocardiMarchesiSucci01

      1. Sergio Focardi & Michele Marchesi & Giancarlo Succi
      2. A stochastic Model of Software Maintenance and its Implications on extreme Programming Processes
      3. In [SucciMarchesi01] pp191-206
      4. =THEORY RANDOM GRAPH MODEL SOFTWARE MAINTENANCE CONTAGION

      Fogel03

      1. David Fogel
      2. Evolutionary Entertainment with Intelligent Agent
      3. IEEE Computer Magazine V36n6(Jun 2003)pp106-108
      4. =EXPERIENCE AI GAMES PERSONA EXPERT EVOLUTION AGENT NEURAL WEB/NET CHECKERS DRAUGHTS Blondie24
      5. =ADVERT book product
      6. After 840 generations moved to top 500 of 120,000 players on www.zone.com
      7. Needed to adopt a female persona to stop opponents swearing at the neural network.

      Fokkink07

      1. Wan Fokkink
      2. Modelling distributed systems
      3. Springer 2007 ISBN 978-3-540-73937-1 QA76.58 F65
      4. =TEXT NONSEQUENTIAL FORMAL microCRL ACP DATA TOOLS μ_CRL ALGEBRA

      FoleyDumigan01

      1. Simon N Foley & Robert Dumigan
      2. Are Hand-held viruses a significant threat
      3. Commun ACM V44n1(Jan 2001)pp105-107
      4. =DEMO RISKs PALM TECHNICAL

      FongCameron01

      1. Philip W L Fong & Robert D Cameron
      2. Proof Linking: Modular verification of Mobile Programs in the Presence of Lazy, Dynamic Linking
      3. ACM TOSEM Trans Software Engineering & Methodology V9n4(Oct 2000)pp379-409 CR0105-01777
      4. =THEORY MODULE PROOF of LINKING NET/WWW bytecode verification DEMO Java

      Foo87

      1. Norman Y Foo
      2. Algebraic Specifications as Solutions of Implementaion Equations
      3. IEEE Trans Soft Eng VSE-13n12(Dec 1987)pp1364-1369
      4. if finite algebraic spec exists than can derive it from an implementation by algebra using equivalence relations. works with initial and final algebras. method fails when no finite spec. unsolvable problem: whether algebra is free(no equations)+how many eqns needed

      Foo93

      1. Norman Y Foo
      2. Comments on "Defining Software by Continuous Smooth Functions"
      3. IEEE Trans SE 19 n3(Mar 1993)pp307-309
          Symmetric difference, hamming distance, UNIX diff,
        1. sensitivity(T)::= sup[x:design_parameters~{0}](norm(T(x))/norm(x))

          refs to: R A De Millo R J Lipton, Defining Software by Continuous Smooth Functions, IEEE Trans SE 17 n4(Apr 1991)pp383-384.


      Ford91

      1. Gary Ford
      2. The SEI Undergraduate Curriculum in Software Engineering
      3. SIGCSE Bulletin V23n1(Mar 1991)pp375-385
          Goal "to stimulate discussion" , nearly fits CSAB and ABET, but not for a Liberal Arts College (22.5% Math & Basic Sciences(27semester hours)+ 37.5% Softe Eng Science and Software Engineering Design (45semester hours)+ 25% Humanities&Social Sciences(30hurs), 15% Electives(18) ), Maths = (1year discrete+ 1 Year Calculus+ 1 Year Provabillity, stats and numerical methods). Science = physics+biology+chemistry. SE Courses: Software Analysis(9semester hours), Software Architecture(12semester hours), Computer Systems(9semester hours), Software Process(12semester hours), SE Elective(3hours).

      Ford04

      1. Bryan Ford
      2. Parsing expression grammars: a recognition-based syntactic foundation
      3. ACM 31st SIGPLAN-SIGACT symposium on Principles of programming languages(2004)pp111-122 [ 964001.964011 ]
      4. =IDEA PRIORITIZED CHOICE reduces AMBIGUITY PARSING CFG GRAMMAR
      5. PEG::="Parsing Expression Grammar", [ Parsing_expression_grammar ]
      6. Use "/" instead of "|" to express an "or" where the left hand parsing is taken whenever possible
      7. Other techniques to handle "and" and "or".

      FormicaMissikoff02

      1. Anna Formica & Michele Missikoff
      2. An extended XML approach to ontology engineering

        [SCI2002] V1(Jul 2002)

      3. =IDEA DATA XML ONTOLOGY OPAL

      Forte97

      1. Gene Forte
      2. Managing change for Rapid Development
      3. IEEE Software magazine V14n2(Mar/Apr 1997)pp120-122
      4. control/communicate/feedback change+timebox+plan/design for change

      Fortnow09

      1. Lance Fortnow
      2. The status of the P versus NP problem.
      3. Commun ACM V52n9(Sep 2009)pp78-86 [ 1562164.1562186 ]
      4. =SURVEY THEORY PERFORMANCE COMPLEXITY NP NP-HARD NP-COMPLETE P=NP?
      5. "What we would gain from P = NP will make the whole Internet look like a footnote in history."
      6. "Since all the NP-complete optimization problems become easy, everything will be much more efficient. Transportation of all forms will be scheduled optimally to move people and goods around quicker and cheaper. Manufacturers can improve their production to increase speed and create less waste."
      7. probably P<>NP. But no proof yet.
      8. Quantum computers probably won't do it.
      9. For practice see [MalikZhang09]

      Foster77

      1. M A Foster
      2. The Game Players of Zan
      3. DAW books no. 236, Donald A. Wollheim New York NY 1977
      4. =FICTION cellular automata life

      FossStensrudKitchenhamMyrtveit03

      1. Tron Foss & Erik Stensrud & Barbara Kitchenham & Ingunn Myrtveit
      2. A Simulation Study of the Model evaluation Criterion MMRE
      3. IEEE Trans Software Engineering V29n11(Nov 2003)pp985-996
      4. =SIMULATION EMPIRICAL STATISTICS MMRE HARMFUL
      5. Provides evidence that software engineers should use traditional goodness of fit statistics rather than inventing their own measures.

      Fosteretal91

      1. I Foster & C Kesselman & S Taylor
      2. Concurrency: Simple Concepts and Powerful Tools
      3. Comput Jnl V33n6(Dec 1990)pp501-507. monotonic variables (single assignment)+interleaving+choice+encapsulated sequences => "permit the design of powerful programming tools"

      Fouts00

      1. Jason W Fouts
      2. An "Out-Of-Box" Experience
      3. Commun ACM V43n11(Nov 2000)pp28-29
      4. =ANECDOTE USER
      5. developers shoud take users goals and environment into account, including other software that may
      6. be running.
      7. Ref to alan cooper

      Fowler97

      1. Martin Fowler
      2. Analysis Patterns: Reusable objects models
      3. Addison Wesley Longman MA 1997
      4. PATTERNS SYSTEM REALITY OBJECT-ORIENTED

      Fowler98

      1. Martin Fowler with Kendall Scott...
      2. UML Distilled: Applying the standard Object Modeling Language
      3. Addison Wesley Longman Inc (9th printing) 1998 ISBN 0-201-32563-2 [ 0-201-32563-2 ]
      4. Introduction to UML and OOA/D. Omits much. Adds much. See [Alhir98].

      Fowler99

      1. Martin Fowler
      2. Refactoring
      3. Addison-Wesley Longman 1999 ISBN 0-201-48567-2 CR0301-0021
      4. =REFERENCE Object-Oriented CODE EVOLUTION

      Fowler00

      1. Martin Fowler
      2. Put Your Process on a Diet
      3. Software Development Magazine V8n12(Dec 2000)pp32-36
      4. =SURVEY LIGHT METHODS
      5. p34: side-bar -- resources -- Crystal, Open source, AD, Scrum, FDD( Feature Driven Development).
      6. New methods tend to be adaptive and people-oriented, and minimize the production of untested artifacts.
      7. Iterative development handles changing and unknown requirements.
      8. New methods may not apply to larger teams.

      Fowler01

      1. Martin fowler
      2. Avoiding Repetition
      3. IEEE Software Magazine V18n1(Jan/Feb 2000)pp97-99
      4. =EXAMPLE THEORY DESIGN Object-Oriented CODE
      5. DRY::="Don't repeat Yourself".
      6. (XP)|-"Once and Only Once".
      7. "A simple principle that leads to good design".

      Fowler01b

      1. Martin Fowler
      2. Is design... dead?
      3. Software Development Magazine V9n4(Apr 2001)pp42-46
      4. =ESSAY XP UML
      5. Continuous integration, testing, and refactoring enable evolutionary design.
      6. documentation is another User Story.
      7. UML diagrams as posters when useful.

      Fowler01c

      1. Martin Fowler
      2. Separating User Interface code
      3. IEEE Software Magazine V18n2(Mar/Apr 2000)pp96-97
      4. =ESSAY MODULES USER REALITY XML SQL HTML
      5. p.96: Separate presentation code from domain code.
      6. increases maintainability, portability, testing.
      7. Problems: VB, Delphi,... don't do this. WEB server pages that contain business logic.
      8. HTML vs XML.

      Fowler01d

      1. Martin Fowler
      2. Separating User Interface Code
      3. IEEE Software Magazine V18n2(Mar/Apr 2000)pp96-97
      4. =ESSAY MODULES USER vs DOMAIN HTML vs XML vs WIMP

      Fowler02

      1. Martin Fowler
      2. Public vs Published Interfaces
      3. IEEE Software Magazine V19n2(Mar/Apr 2002)pp18-19
      4. =ESSAY INFORMATION HIDING MODULES TECHNICAL
      5. Published information has to be frozen because it allows intermodule dependencies.
      6. Minimize published.
      7. Add rather than change or remove.
      8. Strong code ownership in a team creates published interfaces inside the team and inflexible structure.

      Fowler03

      1. Martin Fowler
      2. When to Make a Type
      3. IEEE Software Magazine V20n1(Jan/Feb 2003)pp12-13
      4. =ESSAY DATA TYPES DESIGN REFACTOR
      5. Useful but normally missing types include money, range, dimensions, dates, ... but where to stop.
      6. Create a type when it has special behavior, when it communicates intention clearer, when other types have unwanted operations, when the data can be used in many places.

      Fowler03b

      1. Martin Fowler
      2. Errant Architectures
      3. Software Development Magazine V11n4(Apr 2003)pp38-41
      4. =DEMO NET DISTRIBUTED COMPONENTS PERFORMANCE LATENCY QUALITIES
      5. Remote calls take time, traffic, etc.
      6. Instead distributing classes, cluster the objects into applications and distribute multiple copies across servers.
      7. Use the Remote Facade pattern to hide unneeded remote service calls behind coarse grained classes and objects.
      8. Using web services (OAP over XML over HTTP for example) is handy and handle incompatible encoding but is heavy-weight. OO RPC is lightweight and ok when no code translation will be needed.

      Fowler03c

      1. Martin Fowler
      2. Who needs an Architect?
      3. IEEE Software Magazine V20n5(Sep/Oct 2003)pp11-13
      4. =ESSAY AGILE ARCHITECTURE
      5. So what is architecture any way? Things you want to get right early in a project because they are hard to change later.

      Fowler03d

      1. Martin Fowler
      2. Data Access Routines
      3. IEEE Software Magazine V20n6(Nov/Dec 2003)pp96-98
      4. =DEMO MODULES HIDING ENCAPSULATION getters setters C# Java Ruby In C# can declare a public variable with attached get and set functions that w ork in expressions and assignments.
      5. In Java, do not return a collection, return a clone.
      6. Or Return a casted version of the data.
      7. Or Provide an iterator to avoid exposing a collection of data.
      8. Avoid writing accessors to parts of a collection or structure.
      9. (dick)|-forgot to mention the Law of Demeter: Don't talk to strangers!

      Fowler03e

      1. Martin Fowler
      2. UML Distilled: A brief Guide to the standard object modeling language
      3. Addison-Wesley Longman, Boston MA 2003 ISBN 0321193687 CR 0408-0893
      4. =REFERENCE UML2.0
      5. Second edition updated to UML 2.0, Previous edn by Fowler and Scott.

      Fowler04

      1. Martin Fowler
      2. Module Assembly
      3. IEEE Software Magazine V21n2(Mar/Apr 2004)pp65-67 + Correspendence V21n4(May/Jun 2004)pp8-9
      4. =HOWTO MODULES LINKERS DLL dependency injection Object-Oriented
      5. 3 ways to select an implementation for a needed module.
        1. use a linker.
        2. dependency_injection::= clients declare dependency and assembler module loads implementation, like? Factories(GoF).
        3. Object-Oriented polymorphism (GoF)

      FowlerHighsmith01

      1. Martin Fowler & Jim Highsmith
      2. The Agile Manifesto
      3. Software Development Magazine V9n8(Aug 2001)pp28-32 + letters V9n9(Sep 2001)p12 + V9n10(Oct 2001)pp13+16 + V9n11(Nov 2001)pp13+17
      4. =ADVERT PEOPLE > PROCESS & METHODS AGILITY XP SCRUM Crystal
      5. manifesto in sidebar on p30 signed by: kent beck, mike bedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C Martin, steve Mellor, Ken Schwaber, Jeff sutherland, & Dave Thomas.
      6. "Helpers not tellers"
      7. "delivery is not release"
      8. Long term agility relies on maintaining technical excellence and good design.
      9. "Maximize what is not done"
      10. agile_alliance::= See http://www.agileAlliance.org.
      11. Agile_Manifesto::paraphrase=following,
        Net
        1. Value individuals and interactions more than process and tools.
        2. Value Working software more than comprehensive documentation.
        3. Value customer collaboration over contract negotiation.
        4. Value responding to change over following a plan.
        5. But -- some value to lesser items above.
        6. Highest priority early, continuous, and long term delivery of currently valuable software.
        7. teamwork, review, support, interaction....
        8. ...


        (End of Net)

      FowlerKobryn02

      1. Martin Fowler & Cris Kobryn
      2. Customizing UML for Fun and Profit
      3. Software Development Magazine V10n7(Jul 2002)pp-
      4. =DEMO UML TABULAR stereotype metaclass tags constraints
      5. A Stereotype is defined as <<stereotype>>ing a <<metaclass>> in the UML meta-model.
      6. A Stereotype has a name, zero or more tags (attribute) and zero or more constraints.
      7. Use UML class diagram. Use generalization for special kinds of previous stereotypes.
      8. Can Use table to list the stereotype, base class, parent, tags, constraints and description.
      9. Can use a table to specify tags by stereotype, type, multiplicity and description.

      Fox66

      1. Fox(Ed)
      2. Advances in Programming & Non-Numerical Computation
      3. Pergamon Press Oxford UK
      4. =SURVEY formal logic

      FoxR00

      1. Robert Fox
      2. Paper Still King
      3. Commun ACM V43n11(Nov 2000)p10
      4. =NOTE EXPERIMENT PEOPLE READABILITY
      5. reading and writing on a computer each and together reduces the comprehension of text. Ohio State U.

      FoxFrakes97

      1. Christopher Fox & William Frakes
      2. The Quality Approach: Is It Delivering
      3. Commun ACM V40n6(Jun 1997)pp25-29
      4. editorial introduction definitions bibliography and links. QUALITY

      Frailey94

      1. Dennis J Frailey<frailey@mkcase1.desg.ti.com>
      2. Apparent Contradictions in Transfering Technology
      3. IEEE Software Engineering Technology Transfer Newsletter V2n3(Winter 1995)pp2-3
          conflict handling by comparing ( goals; means; Assumptions; practice); and then resolve.

          Proces vs empowerment

        1. similar objectives: customer satisfaction, efficiency, quality, predicatability
        2. means: clear boundaries but not micromanagement
        3. assumptions: educated preactitioners
        4. practice:
        5. (1) extremes and over the edge
        6. (2) apply techniques not know assumptions
        7. Process: overspecify when faced by ignorance, committees to choose the one true method
        8. Empowerment: Freedom but forget the knowledge Conclussions: Few people actually accept their need to continuously learn about things outside the usual context and training.
        9. Arrogance and expertise vs continuous braod education
        10. Pity education is seen as an expensive overhead....

      Frailey95

      1. Dennis J Frailey<frailey@acm.org>
      2. Proving Software Engineering's Legitimacy(Letter)
      3. IEEE Software Magazine V12n1(Jan 1995)pp14
          Request for evidence of research in software engineering:
        1. journals, topics, organisations, sources of funding (also on Internet?)

      Frailey00

      1. Dennis J Frailey (ed Larry Constantine)
      2. Reducing Cycle Time
      3. Software Development Magazine V8n8(Aug 2000)pp80+78-79
      4. =EXPERIENCE PROCESS bottlenecks systemic
      5. reinvents O&M from 1950s!
      6. WIP:="work in process".
      7. |-average_cycle_time = WIP / throughput. Little's law?
      8. cycles of learning := its faster to have many small iterations or increments because early iterations provide learning to speed later ones.
      9. small batch principle: no economies of scale because of requirements creep.
      10. smooth flow is more important than local optimization.

      FrakesFox95

      1. William B Frakes & Christopher J Fox
      2. Sixteen questions about Software Reuse
      3. Commun ACM V38n6(Jun 1995)pp75-87+112
          113 people, 28 organisation, 1991-92, wide range of experience, all science tech edication Things that help: perceived economic value, education and training. Industry has a strong effect Thing that may help: shared process. Developers prefer reuse

          PL/1 and assembler may discourage reuse. UNIX is reused most.


      FrakesFox96

      1. William B Frakes & Christopher J Fox
      2. Quality Improvement Using a Software Reuse Failure Modes Model
      3. IEEE Trans Softw Eng VSE22n4(Apr 1996)pp274-279
      4. =THEORY QUALITY IMPROVEMENT REUSE
      5. Pareto analysis assuming successful_reuse(p)::=attempt; exists(p); available(p); found(p); understood(p); valid(p); integration(p). Many small chances to fail add up to a large overall chance of failure. SURVEY show mostly no attempt is made to reuse; next the part can not be integrated. encorporate into (plan;do;check;act).

      FrakesIsoda94

      1. William B Frakes & Sadahiro Isoda
      2. Success Factors of Systematic Reuse
      3. IEEE Software Magazine V11n5(Sep 1994)pp15-18 Bib p16
      4. =EXPERIENCE REUSE
          Critical factors
        1. *management
        2. *Measurement
        3. *Economics
        4. *Design for Reuse
        5. *Libraries

          p17: Insufficient reliable data on the benefits and costs of reuse

          p18: Japan's experience: critical factors: senior management, selection of domain, modules systematically derived from the domain, several years effort.


      FrakesKang05

      1. William B Frakes & Kyo Kang
      2. Software Reuse Research: Status and Future
      3. IEEE Trans Software Engineering V31n7(Jul 2005)pp529-536
      4. =SURVEY =POLL =HISTORY REUSE

      FrakesLea94

      1. Bill Frakes<frakes@sarvis.cs.vt.edu> & Doug Lea<lea@sunyo.edu>
      2. Design for Reuse and Object-Oriented Reuse Methods (Report on working group at WISR'93: 6th Ann Workshop on Sofware Reuse)
      3. ACM SIGSOFT Software Eng Notes V19n1(Jan 1994)pp55-56
        1. 3C::=Net{Concept, Content, Context} Key relationships: encapsulated, component, service, client, interface, helper, import spec or contract, Parameterized, generate. 50 design rules(WISR 5?) into taxonomy: 1. Component Structure
        2. identify and encapsulate comonality and variability, Separate interfaces and implementations, separete context and polict from functionallity, link documentation to code, link tests to code, use tools when language are inadequate

          2. Interfaces

        3. minimise |names per name space|, minimize implementation dependance, refine by extending and adding properties, optimize by specializing

          3. Composition

        4. Identify and min (import specs, interference between helpers), use layering, implement policy on top of mechanisim

          4. Parametrization

        5. Use to abstract away contextual variability, Use instanciation to generate components

      FrakesTerry94

      1. Bill Frakes<frakes@sarvis.cs.vt.edu> & Carol Terry
      2. Software Reuse: Metrics and Models
      3. ACM Computing Surveys V28n2(Jun 1996)pp415-435

      FramlingEtAl07

      1. Kary Framling & Timo Ala-Risku & Mikko Karkainen & Ian Holmstrom
      2. Design Patterns for managing Product life cycle Information
      3. Commun ACM V50n6(Jun 2007)pp75-79
      4. =DEMO OBJECT-ORIENTED GoF PATTERNS OBSERVER COMPOSITE WEB/NET AGENTS SOAP JAVA HTML
      5. Gof.Observer and GoF.Composite were useful for organizing networks of agents.

      France92

      1. Robert B France
      2. Semantically Extended Data Flow Diagrams: A Formal Specification Tool
      3. IEEE Trans SE-18n4(Apr 1992)pp329-346 DFD CR9308-0580(D.2.1)

      FranceHorton95

      1. Robert B France & Thomas B Horton
      2. Applying Domain Analysis and Modeling: An Industrial Experience [SamadzadehZand95] pp206-214
      3. =EXPERIENCE REUSE DOMAIN ARCHITECTURE DSSA pagers
          Process is iterative within and about the "stages", significant overlap. Expect the DSSA to CHANGE. Aim for an evolving document from the beginning.

          Show current model as basis for interviews! Review models! mulitple perspectives. Group interviews. Intertwine modeling with information gethering. encourage domain experts to model their perceptions of concepts and note the notations used. Don't tie up their time. Go beyond the developers.

          Scoping was the hardest part.

          Need presentations that are clear, precise, and communicate understanding of the domain to those expert in the domain.

          Abstract space and transtisions model. found common behavior.


      Francez86

      1. Nissim Francez
      2. Fairness
      3. Springer Verlag NY NY 1986(Texts & Monographs in Comp Sci). ISBN 0-387-96235-2
      4. (UCR) QA76.6.F7226
      5. ACM(D.1.3 D.2.4 D.3.1 D.4.1 F.1.2 F.3.1 F.3.3)
      6. termination safety liveness temporal logic

      FranchCarvallo03

      1. Xavier Franch & Juan Pablo Carvallo
      2. Using Quality Models in software Package selection
      3. IEEE Software Magazine V20n1(Jan/Feb 2003)pp34-41
      4. =ADVERT QUALITIES COTS PACKAGES ISO/IEC9126-1
      5. Refine ISO/IEC qualities into metrics fro a particular need and evaluate rival packages.
      6. Case study: Mail servers.

      FrankelWinant97

      1. Mike Frankel & Becky Winant
      2. Domain Partitioning and Reuse Taxonomy
      3. Object Magazine V7n1(Mar 1997)pp38+42-45
      4. vocabulary shift indicates domain shift
      5. real-world vs technology vs axiomatic
      6. object dependancy hierarchy indicates boundaries of reusabillity.

      FranceGhoshSongKim03

      1. Robert France & Sudipto Ghosh & Eunjee Song & Dae-Kyoo Kim
      2. A Meta-modeling approach to pattern-based model refactoring
      3. IEEE Software Magazine V20n5(Sep/Oct 2003)pp52-58
      4. =DEMO PATTERNS MODEL METAMODEL REFACTOR
      5. examples: bridge, observer, abstract factory, GoF Maze Game
      6. Metamodel defines a set of source models and target models and the transformation between them.
      7. Tool with 2 user interfaces: pattern engineer(metamodel) and application engineer(model)

      FranceKimGhoshSong04

      1. Robert B France & Dae-Kyoo Kim & Sudipto Ghosh & Eunjee Song
      2. A UML-Based Patterns Specification Technique
      3. IEEE Trans Software Engineering V30n3(Mar 2004)pp193-206 CR 0503-0328
      4. =DEMO SPECIFICATION PATTERN MODEL UML2.0 class sequence diagrams OCL METAMODEL SPS IPS Observer Visitor
      5. SPS::="Structural Pattern Specification".
      6. IPS::="Interaction Pattern Specification".
      7. Patterns specialize the UML metamodel. Create special meta-models defined by UML diagrams. Patterns are used by presenting variants as conforming class diagrams.
      8. Ignores UML parameterized collaborations.
      9. Experience: used by graduate students, on top of Rational Rose, problem with missing OCL tools.
      10. Students able to create specs after two lectures... uncontrolled.
      11. Behaviors localized in methods (eg FactoryMethod) needs state machines.
      12. UML2.0 sequence diagrams better than UML1.4 -| no need for recursion.
      13. Explored domain model: library check-in/check-out

      FranceEtal06

      1. Robert B France & Sudipto Ghosh & Trung Dinh-Trong & Arnor Solberg
      2. Model-Driven Development Using UML 2.0: Promises and Pitfalls
      3. IEEE Computer Magazine V39n2(Feb 2006)pp59-66
      4. =ESSAY MODELING MDD UML2.0 meta-models semantics
      5. MDD::="Model-Driven Development", the next level of abstraction above 3rd generation programming languages.
      6. Good survey of UML2.0
      7. Interaction modeling hard to extract from the metamodel.
      8. Semantics still too loose -- variation points.
      9. Need metamodeling tools to enable MDD

      Fraseretal91

      1. Martin D Fraser & Kuldeep Kumar & Vijay K Vaishnavi
      2. Informal and Formal Requirements Specification Languages: Bridging the Gap
      3. IEEE Trans SE-V17n5(May 1991)pp454-466
      4. synergy
      5. acceptance VDM+DFD&SA need to relate discrete flows to VDM variables

      Fraseretal94

      1. Martin D Fraser & Kuldeep Kumar & Vijay K Vaishnavi
      2. Strategies for Incorporating Formal Specifications in Software Develpment
      3. Commun ACM V37n10(Oct 1994)pp74-86 CR9509-0705
          Note -- quotes examples limitted to VDM+XYZ Footnote 1: Specification in terms of system components, options,... vs Spec as callection of user's "functional requirements" p75: past research has focussed on notation and rules of inference not on methods and tools, "The Softaware engineer is lef to his or her own devices to discover the software requiements and structure them into a requirements architecture." p75: Most need discrete math and logic which most SwEngs don't know.

          Table 1

        1. Page77: defines methods, lists 10: VDM, Z, Larch, FSM, Petri Nets, Temporal Logic, Transition Axioms, CSP, CCS, PAISLEY
        2. Page 78. Lists 9 strategies of use Table 2, page 79: informal vs semi-formal vs formal: definition and examples (JSD as semiformal) Morphological analysis Table 3: Formalization Processes (taxonomy= { direct, transitional={sequential, parallel}}) Table 4: Support: Unassistted vs Computer Assisted Table 5: Table 3 >< Table 4 -> references

          25 refs


      FraserLeishmanMcLellan95

      1. Steven Fraser & Deborah Leishman & Robert McLellan
      2. Patterns, Teams and Domain engineering
      3. In [SamadzadehZand95] pp222-224
      4. =EXPERIENCE ARCHITECTUR EXPERIENCES
          Use teams with varieties of experts, Physical and mental models

          must record the rationale why design solution is appropriate.


      FraserManci08

      1. Steven Fraser & Dennis Manci
      2. No Silver Bullet: Software Engineering Reloaded
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp91-94
      4. =REPORT OOPSLA PANEL HISTORY STATUS Brookes Werewolf
      5. Fred Brookes + David Parnas + Linda Northrop + Aki Namioka + Dave Thomas + Ricardo Lopez + Martin Fowler.
      6. Guess who turned into a werewolf!
      7. Video on YouTube!
      8. All because of [Brooks87]
      9. Also see [Cox90a] [Harel92]

      FraserVaishnavi97

      1. Martin D Fraser & Vijay K Vaishnavi
      2. A Formal Specifications Maturity Model
      3. Commun ACM V40n12(Dec 1997)pp95-103

      Frazier01

      1. George F Frazier
      2. Cross-Platform coroutine in C++
      3. Dr. Dobbs #322(Mar 2001)pp72+74+76+78-80
      4. =EXAMPLE NONSEQUENTIAL NT Solaris parsing

      Freed95

      1. Ken Freed
      2. Client/Server Analysis and Design Patterns
      3. Software Development Magazine(Jul 1995)pp35-37
      4. =IDEAS PEOPLE PATTERNS
      5. Refers to Ed Yourdon and others: The big picture nearly always turns on a few critical details: "itterate between the big picture and the implementation details". D A Deards's Lift Method C1972!

      Freedman83

      1. Roy S Freedman
      2. The Common Sense of Object Oriented Languages
      3. Computer Design pp111-118
      4. structures object-oriented logic

      Freeman75

      1. Peter Freeman
      2. Software Systems Principles - A survey
      3. Chicago SRA 1975

      Freeman87

      1. Peter Freeman
      2. A conceptual analysis of the Draco Approach to Constructing Softwre Systems
      3. IEEE Trans Soft Eng VSE-13n7(Jul 1987)pp830-844
      4. uses SADT to advertise on Nieghbors system and the philosophy of reuse via analyzing famlies of related software and generating specification languages and their tools for the family

      Freeman07

      1. Peter A Freeman
      2. Risks are your Responsibility
      3. Commun ACM V50n6(Jun 2007)p104
      4. =SERMON RISKS MODELS INCOMPLETE Limited Calculation SIMULATION MODULES ARCHITECTURE
      5. When working on a part need to be able to understand the whole -- and we don't have good tools for doing that with software.

      FreemanGaudel91

      1. Peter A Freeman & Marie-Claude Gaudel
      2. Editorial:Building a Foundation for the Future of Software Engineering
      3. Commun ACM V34n5(May 1991)pp32-33

      FreemanHart04

      1. Peter Freeman & David Hart
      2. A Science of Design for Software-Intensive
      3. Commun ACM V47n8(Aug 2004)pp19-21
      4. =ADVERT NSF Science of Design

      FreemanL03

      1. Lee A. Freeman
      2. A refresher in data flow diagramming: an effective aid for analysts
      3. Communications of the ACM V46n9 (Sep 2003) pp147-151: Virtual extension
      4. Full text Pdf (171JKB) Retrieved Sep 3rd 2003 from [ 903893.903932 ]
      5. =EXPERIMENT REQUIREMENTS ANALYSIS DFDs
      6. Review CR 0405-0558
      7. Reminding novice analysts about the rules of DFDs increased simulated client's satisfaction and the accuracy (as judged by experts) of the DFDs produced

      FreemanLewis80

      1. ?? Freeman & ?? Lewis
      2. Software Engineering
      3. Academic Press NY NY 1980
      4. =text

      Frenkel93

      1. Karen Frenkel
      2. An Interview with Robin Milner
      3. Comm ACM V36n1(Jan 1993)pp90-97
      4. =HISTORY LCF ML Objects CCS LANGUAGES
          p94: Eventually [the ML definition] took 100 pages.

          p97 "You don't just take things out of academis and apply them. You use the industrial experience as a guide. Thats the experiment. That's what computer science *is* at the moment -- one large experiment. And its a very uncontrolled experiment. The whole richness of the subject comes from the interplay between practice and theory.."[p97 ]

          p97 "Computer Science is not only the study of a basic theory, and it is not just the business of making things happen. Its actually a study of how things happen. So the advice is: Don't lose the link."[p97 ]


      FreimutBriandVollei05

      1. Bernrd Freimut & Lionel C Briand & Ferdinand Vollei
      2. Determining Inspection cost-effectiveness by combining project data and expert opinion
      3. IEEE Trans Software Engineering V31n12(Dec 2005)pp1074-1092
      4. =CASESTUDY INSPECTIONS SQA COST VALUE ECONOMICS
      5. Inspecting early artifacts had a clear positive value but code inspections may not be as valuable.
      6. Involving developers in the inspection tuning process was a good idea.
      7. Proposes a complex formula based on Kusumoto's (cost s