[CSUSB]>> [CNS]>> [CSE]>> [R J Botting]>> bib
|| [News] || [Research]

Bibliography Retrieval Engine(Beta)

Items in bibliography identified by a string matching [Cc]onsisten

Barrett87
.Open Barrett87
 Geof Barrett
 Formal Methods Applied to a Floating Point Number System
 Technical Monograph 58 PRG Oxford 1987
 =EXPERIENCE PROOF Floating-point operations STANDARD
.Box
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?
.Close.Box
.Close

BayrakDavis03
.Open BayrakDavis03
 Coskun Bayrak & Chad Davis
 The Relationship between Distributed Systems and Open Source development
 Commun ACM V46n12(Dec2003)pp99-102
 =ESSAY OPEN SOURCE NONSEQUENTIAL PERFORMANCE OSD WWW/NET MARX MicroSoft W3C
 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.
 Tension between capital and craft..Close
.Close

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

BergClineGirou95
.Open BergClineGirou95
 William Berg & Marshall Cline & Mike Girou
 Lessons Learned from the OS/400 OO Project
 Commun ACM V38n10(Oct 1995)pp54-64
 =EXPERIENCE REQRITE OBJECT_ORIENTED OPERATING SYSTEM SOFTWARE
.Box
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: 
.Key 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.
.Close.Box
.Close

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

Charette95
.Open Charette95
 Robert N Charette
 How to Create a Successful Failure
 Commun ACM V38n5(May 1995)pp122(Inside RISKS)
 =HISTORY RISKS DISASTERS FAILURES COSTS PROCESS
.List
 Never Plan,
 Exhibit extreme confidence,
 Take the most expedient solutions,
 Be simple Minded,
 Spawn situations with subtly interlinked decisions,
 Change decisions frequently,
 Practice Foolish inconsistency.
.Close.List
.Close

ChechikGannon01
.Open ChechikGannon01
 Marsha Chechik & John Gannon 
 Automatic analysis of consistency between Requirements and Designs
 IEEE Trans Software Engineering  V27n7(Jul 2001)pp651-672 CR0203-0314
 =CASESTUDY SCR REQUIREMENTS V&V DESIGN TOOL CORD ALGORITHM LANGUAGE LIGHTWIEGHT FORMAL
.Close

ChesnevarMaguitmanLoui00
.Open ChesnevarMaguitmanLoui00
    Carlos Ivan Chesnevar & Ana Gabriela Maguitman & Ronald Prescott Loui 
    Logical models of argument 
    ACM Computing Surveys V32n4(Dec 2000)pp337-383 
 =HISTORY 1950-99 FORMAL DIALECTIC DEFEASIBLE CONSISTENCY REASON ARGUMENT PLAUSIBLE AGENTS AI LAW NONMONOTONIC
 Formal logic is reasoning that can not be defeated. Normal reasoning is not like this.
 Detailed, difficult and hard to read.
 No ref to work on inconsistent requirements.  Small comment on OO inheritance.
.Close

CimattiRoveriSusiTonetta12
.Open CimattiRoveriSusiTonetta12
  Alessandro Cimatti & Marco Roveri & Angelo Susi & Stefano Tonetta
  Validation of Requirements for Hibrid Systems: A Formal Approach
 ACM TOSEM Trans Software Eng & Methodology V21n4(Nov 2012)#22:1-34
.See http://doi.acm.org/10.1145/2377656.2377657
  =CASE STUDY UML OTHELLO ETCS LTL LINEAR TIME LOGIC TRAINS TOOLS ROSE SMT WORD Requisite Pro
 UML used to describe domain, a natural language form of LTL.
 Requirements classified: Glossary, Relationship, Action, Configuration, Behavior, Scenario, Property, Annotation.
 Formalized as UML class diagram plus LTL logic constraints.
 Tools check for consistency and completeness of requirements.
 Discover unexpected scenarios and cases where unwanted behaviors are allowed by the requirements.
 Example constraint
	for all t in trains 
.( in the future t.front.end != t.MA.EOA.location and
.( in the future t.front.end = t.MA.EOA.location
.)
.)
 Experts learned to use the tools and method and liked them.
.Close

Cockburn00
.Open Cockburn00
 Alistair Cockburn
.See arc@acm.org
 Characterizing People as Non-Linear, First-Order Components in Software Development
 Humans & Technology, HAY Technical Report 1999.03(Oct 21 1999) 
and Proc SCI/ISAS2000 VI pp728-736
.See [SCI00]
 =EXPERIENCE 20 projects PEOPLE AGILITY ONESIZE
 A commonly observed pattern by methodologists and tool smiths
.Box
 The people on the projects were not interested in learning our system.
 They were successfully able to ignore us, and were still delivering software, anyway.
 Almost any methodology can be made to work on some project.
 Any methodology can manage to fail on some project.
 Heavy processes can be successful.
 Light processes are more often successful, and more importantly, the people on those projects credit the success to the
lightness of the methodology.
 people are
.List
 are communicating beings, doing best face-to-face, in person, with real-time question and answer.
 have trouble acting consistently over time.
 are highly variable, varying from day to day and place to place.
 generally want to be good citizens, are good at looking around, taking initiative, and doing "whatever is needed"
 need both think time and communicating opportunities.
 work well from examples.
 prefer to fail conservatively than to risk succeeding differently
 prefer to invent than to research
 can only keep a small amount in their heads, and do make mistakes
 find it hard to change their habits.
.Close.List

 Individual personalities easily dominate a project.
 A person's personality profile strongly affects their ability to perform specific assignments.
 paper documentation is the least effective communication medium available.
.Close.Box
.Close

CugolaNitoEtal96
.Open CugolaNitoEtal96
 Giampaolo Cugola & Elizabetta di Nitto & Alfonso Fuggetta & Carlo Ghezzi
 A Framework for Formalizing Inconsistencies and Deviations in Human-centred Systems
 ACM TOSEM V5n3(Jul 1996)pp191-230
 =THEORY USER REQUIREMNTS FORMAL Z: REALITY vs SYSTEM PETRIE GRAPHICS
.Close

DemskyRinard06
.Open DemskyRinard06
 Brian Demsky & Martin C Rinard 
 Goal-Directed Reasoning for specification-based Data Structure Repair
 ICSE'05 & IEEE Computer Magazine  V39n12(Dec 2006)pp931-951  
 =DEMO DATA SPECIFICATION SETS RELATIONS ABSTRACTION INVARIANTS CONSTRAINTS REPAIR FAULT AbiWorld CTAS Freeciv File System 
 In some cases it is better to repair a broken data structure incorrectly and continue running rather than crash and stop running.
 Data structures can be repaired by using formal abstract specification in terms of Sets and Relationships.
 Comparison with bespoke/domain specific fsck and chkdsk.
 Fix each broken constraint in turn and use a 
.Key Repair Dependence Graph
to avoid infinite loops of repairs.
 Lists actions to repair data structure.
 Focuses on internal consistency rather than "REALITY" and as a consequence the whole application may work incorrectly.
 Compare
.See [KuncakLamZeeRinard06]
that uses a similar abstraction/specification but includes domain constraints to model bot internal data structure consistency and external domain constraints.
.Close

EmamGoldenson00
.Open EmamGoldenson00
 Khaled El Emam & Dennis R Goldenson
 An Empirical Review of Software Process Assessments
 Advances in Computers V53(2000)pp320-423
 =SURVEY CMM SPA effectiveness ISO/IEC15504 SPI IMPROVEMENT
 SPA Sponsors expect SPA to be useful.
 Organizations have too high expectations for SPA.
 Evidence that SPA results are consistent.
 Ample evidence that higher levels are linked to improved performance.
.Close

Fayadetal93
.Open Fayadetal93
 Mohamed E Fayad & Louis J Hawn & Mark A Roberts & Jerry R Klatt (Macdonnel Douglas Corp)
 Using the Shlaer-Mellor Object-Oriented Analysis Method
 IEEE Software Magazine V10n2 (Mar 1993)pp43-52 + Correspondence V10n5(Sep 1993)pp6-7
 OBJECT-ORIENTED METHOD OOA review
.Box
 p43. consistently produced better abstract objects than other OOMethods
 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
 p47 CASE tool:=Teamwork
 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.
 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.
 p51 Interaction insufficiently documented. DFD not much help (*disputed*)with update/retrieval but resulting processes are cohesive.
TWO MONTHS.
.Close.Box
.Close

Feather98
.Open Feather98
 Martin S Feather
 Rapid Application of Lightweight Formal Methods for Consistency Analysis
 IEEE Trans SE V24n11(Nov 1998)pp949-959
 =EXPERIENCE NASA DATABASE LISP
 Wanted: moderate results extremely rapidly. Discover implicit causal loops.
.Close

Finkelsteinetal94
.Open Finkelsteinetal94
 Anthony C W Finckelstein & Dov Gavey & Anthony Hunter & Jeff Kramer & Bashar Nuseibeh
 Inconsistency Handling in Multiperspective Specifications
 IEEE trans on Soft Eng vSE-20n8(Aug 1994)pp569-578
 =IDEA REQUIREMENTS LOGIC SPECIFICATION See Nuseibehetal94
.Box
VeiwPoint::=Net{Style, Work_Plan, Domain, Specification, Work_Record}.
.Close.Box
.Close

FreyEtal02
.Open FreyEtal02
 Peter Frey & Radharamanan Radhakrishnan & Harold W Carter & Philip A Wilsey & Perry Alexander
 A Formal Specification and Verification Framework for Time-Warp-Based Parallel Simulation
 IEEE Trans Software Engineering  V28n1(Jan  2002)pp58-78
 =DEMO SPECIFICATION DESIGN VERIFICATION  SIMULATIONS PVS
 PVS: allows conservative extension of theories -- adding a new function and axiom preserves consistency.  67 axioms and 459 theorems spread over 9 theories.
.Close

GrottkeTrivedi07
.Open GrottkeTrivedi07
 Michael Grottke & Kishor S Trivedi 
 Fighting Bugs: Remove, Retry, Replicate, and Rejuvenate
 IEEE Computer Magazine  V40n2(Feb 2007)pp107-109  + letter V40n5(May 2007)pp6-7
 =SURVEY DEBUGGING 
 Different types of bugs need different strategies.
 Bohrbugs: use testing to find and remove faults that consistently manifest bugs in well defined conditions.
 Mandelbugs: No replication.fault->internal error-> error propagation-> platform interactions -> chaotic behavior. So can often avoid bug by retrying the software.  Can try replicated software in different platforms.
 Age-Related Bugs: Rejuvenate =  restart. Same two type: Bohr and Mandel.
 In letter, Lawrence Stabile, criticizes the "Rejuvenate" tactic as not an "engineering solution".
.Close

GunterGunterJacksonZave00
.Open GunterGunterJacksonZave00
 Carl A Gunter & Elsa L Gunter & Michael A Jackson & Pamela Zave
 A Reference Model for Requirements and Specifications
 IEEE Software Magazine V17n3(May/Jun 2000)pp37-43
 =THEORY REQUIREMENTS SPECIFICATION REALITY WRSPM
 W, R, S refer to the environment. S, P, M refer to the system.
 Actual expression of descriptions can take many forms.
 Designated terms -- typically designate states, events, and/or individuals.
`e` -- controled by environment, `s` -- controled by system.
 Shared terminology.
 Three properties of adequacy and consistency define a contract between the
buyer and seller of the software.
 Similar, relative, properties constrain the specification and imply the
three fundamental properties.

.See http://www/dick/notes/GunterGunterJacksonZave00.html
 See also 
.See [ZaveJackson97b]
.Close

HamiltonHackler08
.Open HamiltonHackler08
 Margaret H Hamilton & William R Hackler 
 Universal Systems Language: Lessons Learned from Apollo
 IEEE Computer Magazine V41n12(Dec 2008)pp34-43
 =HISTORY CORRECT DESIGN EVOLUTION HOS USL FUNCTIONAL DECOMPOSITION
 Apollo space mission 1961-1975.
 Functions and maps decomposed using three structures: Join, Include, Or.  (=~= ";", "&", "|" in MATHS).
 Theories of correctness and tools to check such decomposition.
 Still blindsided by events.  Reality had unexpected properties.
 The power of a global reset when an inconsistent state occurs.
 Asynchronous process and asynchronous software,
 (dick)|- further developed into language AXES, tool USE.IT and company HOS in the 1980's.
.Close

Harel92
.Open Harel92
 David Harel
 Biting the Silver Bullet: Toward a Brighter Future for System Development
 IEEE Computer Magazine V25n1(Jan 1992)pp8-20 CR9304-0261"Needs an example"
 =ESSAY MODELING SIMULATION TOOL STATECHART
.Box
 Reply to Brooks86: history,vanilla approach to modeling, reactive systems, model behavior, model data, visual, objects as an exotic flavor, analysis of model - execution, temporal verification, cose generation verifying consistency,
.Close.Box
.Close

Hehner93
.Open Hehner93
 Eric C R Hehner
 A Practical Theory of Programming
 Springer Verlag NY NY 1993 ISBN 0-387-9106-1 CR9405-0276 F.3.0
 =TEXT FORMAL DDD 
.Box Review
.Author F Aribaud Paris France
 undergraduate text on theory that a PL is sublanguage of a specification language,
 state and temporal variables,
 dynamic predicates like,
 Modus ponens becomes refinement,
 fuzzy presentation of wffs - quantification over infinite domains so risk of inconsistency,
 terse disussion of fixed points for recursion,
 lightened the maths too much,
 less formal and interesting

recommended to instructors not beginners
.Close.Box
.Close

Heimdahl96
.Open Heimdahl96
 Mats P E Heimdahl
 Experiences & Lessons from the Analysis of TCAS II
 Proc 1996 Int Symposium on Software Testing & Analysis(ISSTA) & ACM SIGSOFT SENotes V21n3(May 1996)pp79-83
 =EXPERIENCE REQUIREMENTS SQA RSML StateCharts And/Or Tables
 "Identified problems in requirements specification[...]that had undergone extensive manual verification"
 tends to find to many holes and ambiguities and inconsistencies that can be difficult to correct.  Should allow extended entries and AND/OR tables perhaps.
 See also
.See [Levesonetal94]
 
.See [HeimdahlLeveson96]
.Close

HeimdahlLeveson96
.Open HeimdahlLeveson96
 Mats P E Heimdahl & Nancy G Leveson
 Completeness and Consistency in Hierarchical State-based Requirements
 IEEE Trans Softw Eng VSE22N6(Jun 1996)pp  revised from ICSE-17 1995 CR9707-0519 D.2.1
 =EXPERIENCE TCAS experiences and formal definition of analysis
 
.See [Heimdahl96]

.See [Levesonetal94]
.Close

HeitmeyerEtal96
.Open HeitmeyerEtal96
 Constance L Heitmeyer & Ralph D Jeffords & Bruce G Labaw
 Automated Consistency Checking of Requirements Specifications
 ACM TOSEM V5n3(Jul 1996)pp231-261
 SCR TABULAR CR9705-0365
.Close

Holmes08
.Open Holmes08
 Neville Holmes
 The European Union and the Semantic web
 =ADVERT UNIVERSAL LANGUAGES E-speranto ITL
 IEEE Computer Magazine V41n8(Aug 2008)pp108+106-107 + Letter and rebuttal
V41n10(Oct 2008)pp6-7
 E-speranto::="a simplification of Esperanto".
 Esperanto::="the most popular artificial universal language".

 Letter from Patrick Durusau: 
People add ambiguity and idiosyncracies to any language they use -- 
including mathematics.
 Reply  -- Usage as an intermediate language should stop semantic drift and creative inconsistencies
 Also see evidence of evolution/drift in invented languages --
.See [Okrent09]
.Close

Humphrey95b
.Open Humphrey95b
 Watts S Humphrey (SEI)
 Making Process Improvement Personal
 IEEE Software Magazine V12n5(Sep 1995)pp82-83
 =ADVERT for 
.See [Humphrey95a]
.Box
One semester graduate level course....
Consistent improvements...

PSP::abreviation=`Persona;l Software Process`.
PSP::=( PSP0; O(PSP0.1; O(PSP1; O(PSP1.1; O(PSP2; O(PSP2.1; O(PSP3) )))) ).

PSP0::=learn to make and value simple measurements
PSP0.1::=estimating and measuring program size
PSP1::=historical data->linear_regression->estimator
PSP1.1::=estimating and scheduling+eaarned value+progress of work to date
PSP2::= design and code reviews & checklists & Pareto analysis & other methods of SQA
PSP2.1::=design completenes and correctness(trace tables, execution tables, proofs); selecting methods of design and review
PSP3::=scaling up to industrial sized projects; team work; project level work.

Lots of good (but not new) advice
.Close.Box
.Close

HunterNuseibeh97
.Open HunterNuseibeh97
 Anthony Hunter & Bashar Nuseibeh
 Analysing Inconsistent Specifications
.See [RE'97] pp78-86
 =FORMAL REQUIREMENTS LOGIC
 REQUIREMENTS LOGIC must not include `ex falso quodlibet` and should track all inferences from stated requirements to conclusions and so aid diagnosis of inconsistencies
 QC::="Quasi Classical Logic"
.Close

HunterNuseibeh99
.Open HunterNuseibeh99
 Anthony Hunter & Bashar Nuseibeh
 Managing Inconsistent specifications: Reasoning, Analysis, and Action
 ACM ToSEM V7n4(May 1999)pp335-367
 =IDEA labelled QC Quine FORMAL LOGIC SPECIFICATION
 Label requirements and record deductions so that you can back track when
inconsistent ones emerge.
.See [QC]
 Compare with the way mathematicians handle inconsistencies in
.See [Lakatos76].
 (dick)|- my MATHS notation uses
.As_is 		(reason, reason, ...)|-(label): statement.
to record such connections but does not allow the same freedom
in abandonning and adjusting the logic.
.Close

Huth04
.Open Huth04
 Michael Huth 
 Mathematics  for  the Exploration of Requirements  
 ACM SIGCSE Bulletin V36n2(Jun 2004)pp34-39 
 =EXAMPLE Uncertain Mathematical Specifications Alloy TOOL =CASESTUDY .NET cache
 =ADVERT 2nd edition 
.See [HuthRyan00]
.See http://www.cis.ksu.edu/~huth/lics/
 Checking Specifications  for inconsistency and to see if they meet goals and objectives. 
 Shows that tools & languages for requirements drive discussions rather than solve problems. 
Some tools will generate spurious diagnostics.
.Close

JacksonD00
.Open JacksonD00
 Daniel Jackson
 Automating first-Order Relational Logic
 
.See [FSE8]
pp120-139
 =THEORY LOGIC RELATIONS PREDICATE Z OCL =DEMO TOOL 50KLOC Java SAT Alloy Analyzer Nitpick UML COM
Mobile IP
 Shorter than SMV by 10 times.
 Quantifiers make logic easier to use. Analysis s faster than Nitpick as well.
 Describes syntax, type rules and semantics of the logic.
 In place of composition of relations ( R; S = rel[x,z](some y, x R y S z)), defines navigation ( R . S = rel[x,z](some y, y R z and y S x))
 scalar variables are replaced by singleton set variables.
 analysis:= normalize and skolemize; boolean formula; conjunctive normal form; SAT solver; map back to relational.
 Alloy_Analyzer::=http://sdg.lcs.mit.edu/alloy
 Proved UML meta-model is consistent in less than 20 seconds.
 See also 
.See [JacksonDSullivan00]
.Close

JacksonD06a
.Open JacksonD06a
 Daniel Jackson
 Software Abstractions: Logic, Language, and Analysis
 The MIT Press Cambridge MA 2006 ISBN 0262101149 $CR 0802-0116 0806-0536
, rev edn 2012 ISBN 0262017156 $CR 1211-1092 1212-1193
 =TEXT Alloy LIGHT FORMAL MODEL CHECKING METHODS TOOLS
 A neat way of finding bugs in specifications and requirements.
 Small_scope_hypothesis::=`Most bugs have small counterexamples`.
 Notes the difficulty of creating consistent formal models that
have the desired properties.
 Alloy::language=`a formal first order relational logic expressed in ASCII with tools in Java`.
 Alloy_examples::=http://softwareabstractions.org.
 Alloy_analyzer::=http://alloy.mit.edu.
.Close

JonesCB96
.Open JonesCB96
 Cliff B Jones(U of Manchester mailto:cliff@cs.man.ac.uk)
 A Rigorous Approach to Formal methods
 IEEE Computer Magazine V29N4(Apr 1996)pp20-21
.Box
Understand the formal basis but use a less than formal approach. minimal notational detail describe the systems state. used to justify early data structure design rather than for proofs of design.

"I have had bad expreriences seeing systems architects propose designs in natural language and ask others to foramlize them.  The inevitable effect was that the people constructing the formal document generated many questions and corrections to the architect's natural languag description and were thanked only with more pages of ambiguous and inconsistent natural language.
...
follow pattern of OR.... team of domain specialists and foramlist

Education in the use of abstraction.
.Close.Box
.Close

KilovRoss94
.Open KilovRoss94
 Haim Kilov<haim@cc.bellcore.com> & James Ross
 Information modeling: an object-oriented approach
 Prentice-Hall 1994  ISBN 0-13-083033-X
reviewed SIGSOFT SEN V21n2(Mar 1996)pp91-92 "beneficial and entertaining"
 =ADVERT IBM METHOD DATA OO
.Box
EMailed blurb from haim@dancer.cc.bellcore.com (kilov,haim)
The book is about making analysis as disciplined as programming.
... specification that is understandable and formal.
how to avoid
complex, incomplete, and inconsistent specifications with semantics hidden in
application code.

 separation of concerns between
specifying business rules and implementing systems based on them
"patterns of reasoning" in
information modeling -- generic associations encountered in any application.


.Close.Box
.Close

Kobryn00b
.Open Kobryn00b
 Chris Kobryn
 UML Meets EJB and COM+
 Software Development Magazine V8n12(Dec 2000)pp49-50+52+55
 =ADVERT OMG UML 1.4 RTF COMPONENTS
 Argues that UML does not allow component modeling in design diagrams and has too many ways to model EJB and COM+ components
 p52. fig 3. shows a package with interface and implementation ( with fork symbol) and stereotype realization links. Realization is shown as a dependency inconsistent with UML1.3.
.Close

KoruTian04
.Open KoruTian04
 A Gunes Koru & Jeff Tian
 Defect Handling in Medium and Large Open Source Projects
 IEEE Software Magazine V21n4(Jul/Aug 2004)pp54-61
 =POLL 52 OPEN SOURCE DEFECTS
 All projects keep a data base of defects and most use it for almost all defects.
 The records tend to be complete and consistent.
  Defects are recorded in source code, design documents, requirements documents.  But KDE and Gnome are mainly source code defects.
.Close

KrishnanKellner99
.Open KrishnanKellner99
 M S Krishnan & Marc I Kellner
 Measuring Process Consistency: Implications for Reducing Software Defects
 IEEE Trans Software Engineering V25n6(Nov/Dec 1999)pp800-815
 =EMPIRICAL IMPROVEMENT  DEFECTS VS CMM KPA C
 45 systems software projects in one company
 small projects, highly capable people, and attention to CMM Key Process areas lead to fewer defects
 Defects were repeatable customer problems in first 24 months after release
.Close

Kristensen02
.Open Kristensen02
 Jan Kristensen
 Evolutionary Information Systems: Maintaining consistency when structural transformations force integrity rules to break
 
.See [SCI2002]
V1(Jul 2002)pp
 =EXPERIENCE EVOLUTION DATA MODEL
 Since it is common that optimal data designs break after a long time,one should deliberately loosen up data base designs to handle changes.
.Close

KuncakLamZeeRinard06
.Open KuncakLamZeeRinard06
 Victor Kuncak & Patrick Lam & Karen Zee & Martin C Rinard 
 Modular Pluggable Analysis for Data Structure Consistency
 IEEE Computer Magazine  V39n12(Dec 2006)pp988-1005  
 =DEMO TOOL Hob MODULAR PROVING REALITY SETS RELATIONS ABSTRACTION PALE Bohn Isabelle flag ADTs Minesweeper httpd etc 
 Shows that the theories of ADTs from the 80s are the basis for a set of tools.
 Modules have three parts:  implementation, specification, and abstraction.  
 The code inside modules is proved to support certain assertions expressed in the language of set theory. The abstraction section defines higher level formulas using sets and the calculus of relations -- like Alloy.
 Programs are proved using the higher-level properties.
 Page 989. "One somewhat unusual feature of these abstract properties is that are outward looking: the capture important features of the system that are directly meaning ful to the users.
.Close

LamsweerdeLetier00
.Open LamsweerdeLetier00
 Axel van Lamsweerde & Emmanuel Letier
 Handling Obstacles in Goal-Oriented Requirements Engineering
 IEEE Trans Software Engineering  V26n9(Sep 2000)pp978-1005
 =CASESTUDY  REQUIREMENTS REFINEMENT EXCEPTIONS TEMPORAL LOGIC KAOS
 Requirements can assume too much  reliability in parts of system.
 Should calculate things that can go wrong and allow for them in their requirements.
 p983: "an obstacle defines a set of undesirable behavior; a negative scenario produces a behavior in this set". Obstacles imply a goal is not met but obstacles  must not be inconsistent with the domain - exists a scenario
 Goals have form "at all times...." but obstacles have form : "at some time...."
.See [KjaerMadsen95]
 `user anti-story`!
.Close

LangeChaudronMuskens06
.Open LangeChaudronMuskens06
 Christian F J Lange & Michel R V Chaudron & Johan Muskens 
 In Practice: UML Software Architecture & Design Description
 IEEE Software Magazine V23n2(Mar/Apr 2006)pp40-46
 =POLL 80 Architects +14 CASE STUDIES UML QUANTITY QUALITY METRICS 
 80% used usecase & logical, 50% component & scenarios, 17% deployment.
 Loose adherence to standard.
 Survey presumed a "waterfall" process.
 Problems mentioned in poll. scattered information, incompleteness, disproportion, inconsistency, diagram quality, informality, no conventions. 
 40%+ plan to use more UML metrics.
 Defects in case studies: classes do not fit sequence diagrams, classes with no methods.
 Experiment: most students & practitioners can't detect mismatches between class and sequence diagrams.
 See "Effects of defects in UML models"  in ICSE06 by  Lange & Chaudron.
.Close

Lilly99
.Open Lilly99
 Susan Lilly
 Use-Case pitfalls: top 10 problems
 IEEE CS TOOLS USA 99 (1999)
 =EXPERIENCE  USECASE SCENARIO REQUIREMENTS
  fuzzy boundary, system's view, actor names inconsistent, too many, 
spiders web, scenario too long, confusing, actors entitled to too much, 
user doesn't understand, unfinished
.See 
.See [Lilly00]
.Close

MiddletonLeeIrani04
.Open MiddletonLeeIrani04
 Peter Middleton & Ho Woo Lee & Shahruck A Irani
 Why culling Software Colleagues is popular
 IEEE Software Magazine V21n5(Sep /Oct 2004)pp28-32
 =Simulation Process People
 erratic performance has an intuitively bad effect on downstream work.
 Many small consistently timed work products improved whole stream.
 (dick)|- elementary queuing theory!
.Close

Miranda01
.Open Miranda01
 Eduardo Mianda
 Improving subjective estimates Using Paired Comparisons
 IEEE Software Magazine V18n1(Jan/Feb 2000)pp87-91
 =DEMO MATHEMATICS ESTIMATION
 Use pairwise comparisons to form a judgment matrix. Review internal inconsistencies and then derive ratio scale.  Use scale and known reference values to get better estimates.
 Map verbal judgments to ratios: equal+>1 | bigger+>1.75 | smaller . 0.57 | slightly bigger +> 1.25 | slightly smaller +> 0.80 | much bigger +> 4.0 | much smaller +> 0.25 | extremely bigger > 7.00 | extremely smaller +> 0.13
 judgment_matrix:= matrix(1..n><1..n -> ratio ).
 geometric_mean[r] =v[r],
 v[r] =  a[r,*] **(1/n).
 ratio[r] = v[r]/v[+].
 inconsistency := sqrt(+[r] (+[c:r+1..n] (ln(a[r,c]) - ln(v[r]/v[c]) ))) /((n-1)*(n-2)/2).
.Close

Morales01a
.Open Morales01a
 Alexandra Weber Morales
 Demonstrates that partial and under-defined functions can not be used consistently with normal axioms of \lambda calculus. Proposes remedies -- essentially limiting substitutions to particular proper values and functions.
 disclaimer: page 700: "We Thank David Watt and Richard Botting for reviewing drafts of this article."
 cf 
.See [Owreetal95]
.See [Parnas93]
.See [RushbyOwreShankar98]
.Close

Morse95
.Open Morse95
 Dave Morse(mailto:dmorse@raima.com)
 OODBSs and the Marriage of Network and Relational Database Models
 IEEE Computer Magazine V28n10(Oct 1995)pp66-67
 =SURVEY DATA MODEL ACID OBJECTS NONSEQUENTIAL
.Box
Refers to Jim Gray's ACID principles of DB transations.
ACID::principle="Atomic, Consistent, Isolated, and Durable".
 missing in some OODBs

 Extremes: map objects to RDBMS tuples..make table appear like a class of objects.
.Close.Box
.Close

MyrtveitStensrudShepperd05
.Open MyrtveitStensrudShepperd05
 Ingun Myrtveit & Erik Stensrud & Martin Shepperd 
 Reliability and Validity in Comparative  Studies of Software Prediction Models
 IEEE Trans Software Engineering  V31n5(May 2005)pp380-391 
 =SIMULATION =SURVEY RESEARCH EFFORT ESTIMATION COST PREDICTION
 Shows that there is no consistent recommendation's in the literature for estimating cost/effort  
 Simulated the typical research procedure for evaluating and/or comparing ways of predicting the effort needed to produce software.
 Shows that the particular measure of goodness of fit chosen determines the "best" model.
 Shows that the particular sample of data also determines the "best" model.
.Close

NentwichEtAl03
.Open NentwichEtAl03
 Christian Nentwich & Wolfgang Emmerich & Anthony Finckelstein & Ernst Ellmer
 Flexible Consistency Checking
 ACM TOSEM Trans Software Eng & Methodology V12n1(Jan 2003)pp28-63
 =DEMO WEB/NET DOCUMENTATION XML xlinkit webservice LOGIC CONSISTENCY MANAGEMENT DIFFERENCING TOOL UML Java EJB
 Links are not placed in documents. Connect elements in other documents.
 Four kinds of constraint: standard, extension, integration, custom.
 xlinkit::webservice=http://www.xlinkit.com.
.Close

Nuseibehetal94
.Open Nuseibehetal94
 Bashar Nuseibeh & Jeff Kramer & Anthony Finkelstein
 A Framework for Expressing the Relationships between Multiple Views in Requirements Specification
 IEEE Trans SE-V20n10(Oct 1994)pp760-773
.See [Finkelsteinetal94]
 =ADVERT REQUIREMENTS SPECIFICATION METHODS CORE FUSION
 Inconsistency management
 p769:"The real world (the domain of requirements engineers) forces us to work with inconsistencies"
 Compare with the way mathematicians handle inconsistencies in
.See [Lakatos76].
.Close

NuseibehEasterbrookRusso00
.Open NuseibehEasterbrookRusso00
 Bashar Nuseibeh & Steve Easterbrook & Alessandra Russo
 Leveraging inconsistency in Software Development
  IEEE Computer Magazine V33n4(Apr 2000)pp24-29
 =ESSAY
 A foolish consistency is the hobgoblin of small minds
.Close

Olsen11
.Open Olsen11
 Kai A Olsen
 Programmed Politeness
 IEEE Computer Magazine V44n7(Jul 2011)pp108+106-108
 =ESSAY ANALOGIES USER INTERACTION DESIGN
 Politeness as a protocol and a form of respect that makes systems popular.
 Email sent needs a response, normally.
 Warn up-front if a transaction is likely to fail with no backup.
 Especially if it is an unlikely user input!
 Speak the customers language consistently.
 Avoid long user input -- system arrogance.
 Don't silently reorganize the users life or system unlike Adobe Acrobat and Apple Quicktime.
 Don't interrupt!
 Remember people. Avoid reinputting previously input data.
 Compare
.See [Olsen08]
.Close

Parnas96
.Open Parnas96
 David Lorge Parnas
 Why Software Jewels are Rare
 IEEE Computer Magazine V29N2(Feb 1996)pp57-60
 =EXPERIENCE QUALITY USER 
.Box
Jewels::=consistent, simple,kludge-free, organized.modifiable code chunks.
Why so few?
.List
 software rot, aging due to unforeseen changes
Added features should: leave useful features, use what exists, and be ignorable
 we need compatibility with past and with other systems
 Performance goals and Hardware limitations
 Failing to stand on anothers shoulders.  Time spent studying previous efforts can pay off.
 Unnecessary creativity - thru ignorance enthusiasm or egotism
 Making a language rather than doing a design.  Languages are not panaceas.
.Close.List
Making jewels: upfront design work: documented, reviewed, analyzed. Plus inspect implementation vs design.
.Close.Box
.Close

Parnas11
.Open Parnas11
 David L Parnas 
 The risks of stopping to soon
 Commun ACM V54n6(Jun 2011)pp31-33
.See http://doi.acm.org/10.1145/1953122.1953136
 =ESSAY PROCESS RISKS
 Incomplete, unclear, inconsistent requirements.
 Diagrams help understanding but  a vague, unclear, and need text or tables to accurately describe software. 
 Drawing "the" architecture when you needs several different views. 
 Documentation leaves questions unanswered. Odd cases. Missing tedious details!
 Not enough testing. Not enough inspection. 
 Books and talks give incomplete and unclear advice. No tedious detail work. No math.
 To do it right need to use mathematics and discipline to complete each job and each part of each job. 
.Close

Pike06
.Open Pike06
 Lee Pike 
 A Note on the inconsistent axioms in Rushby's "Systematic Formal Verification for Fault-Tolerant Time-triggered Algorithms"
 IEEE Trans Software Engineering  V32n5(May 2006)pp347-348 
 =CORRECTION LOGIC ERRORS TIMING PVS 
 Refers to J. Rushby's paper in IEEE Trans Software Engineering  V25n5(May 1999)pp651-660   
 Evidence that it is difficult to get axioms right,
and that social processes correct and improve them... not tools and logic.
 The axioms model the behavior of clocks.
 The PVS tool was used to test for consistency by constructing a model that satisfies the new
axioms.
.Close

Polack01
.Open Polack01
 Fiona Polack
 A Case Study using Lightweight formalism to Review an Information System Specification
 Software - Practice & Experience V31n8(10 Jul 2001)pp757-780
 =CASESTUDY V&V SPECIFICATION SAZ Z SSADM Ordnance Survey UK
 Lightweight formal review can detect many problems: unmet requirements, inconsistencies, contradictions, ambiguity, ...
 Original documents generated 100page Z+text +questions review.
 Uncovered missing constraints, ambiguities, conflicts, inconsistencies, ...
.Close

SchreflStumptner02
.Open SchreflStumptner02
  Michael Schrefl & Markus Stumptner
 Behavior-Consistent Specialization of Object Life Cycles
 ACM TOSEM Trans Software Engineering & Methodology V11n1(Jan 2002)pp92-148
 =THEORY   Object-Oriented DYNAMIC MODEL ANALYSIS DESIGN DAD INHERITANCE OBD PETRI vs UML
 Using labeled Petri nets to model object behavior defines criteria and forms of inheritance:
 refinement and extension.
 observational and invocational consistencies.
.Close

Seidewitz03
.Open Seidewitz03
 Ed Seidewitz
 What Models Mean
 IEEE Software Magazine V20n5(Sep/Oct 2003)pp26-32
 =ESSAY MODEL SEMANTICS INTERPRETATION THEORY METAMODEL UML 
 SUS:="System under study".
 A`model` is a set of statements about a SUS.  It is`correct` if all the statements are true of the SUS. 
 If a model acts as a `specification` of a SUS then the SUS is `valid` relative to the specification if all the statements are true.
 An`interpretation` is a mapping from model elements to the SUS.  It come from a UML profile and/or local standards.
 If an interpretation is invertible the model is a `representation` of the SUS.
 A `theory` is a way to derive new  true statements from a correct model.
 A model `conforms` to a theory if the theory only adds statements that are consistent with previous statements.
 If a model conforms to a theory and is interpreted by a SUS then the theory can derive new facts about the SUS.
 A `modeling language` expresses models for a class of SUS.
 A `metamodel` is a model that specifies a family of models for a given class of SUS.
  A `reflexive metamodel` describes a modelling language, using that modelling language.
 So `meaning` can mean interpretation or theory.  
.Close

ShapiroHardy02
.Open ShapiroHardy02
 Jonathon S Shapiro & Norm Hardy
 EROS: A Principle-Driven Operating System from the ground Up
 IEEE Software Magazine V19n1(Jan/Feb 2002)pp26-33
 =EXPERIENCE QUALITY SECURITY TRUST KeyKOS TECHNICAL REQUIREMENTS ARCHITECTURE capabilities  modules components
 Goal: To know how and why the system worked.  able to trace every piece of code to a principle or constraint.
 clean design gave high-performance.
 One security mechanism has been formally verified.
 Principles act as requirements and had at least on inconsistency.
 EROS::=http://www.eros-os.org.
.Close

ShullEtAl10
.Open ShullEtAl10
 Forrest Shull & Gregory Melnik & Burak Turhan & Lucas Layman & Madeline Diep & Hakan Erdogmas
 What do we know about test-driven development
 IEEE Software Magazine V27n6(Nov/Dec 2010)pp16-19
 =SURVEY INTERVIEW EXPERIENCE TDD TESTING PROCESS QUALITY
 Careful survey of the literature & interview with an experienced expert. 
 Moderate evidence that TDD tends to improve observable quality. 
 No consistent trend for internal quality in papers but expert claims benefits. 
 No consistent evidence that TDD reduces productivity but inconsistent positive evidence.  Expert thinks it pays off in long term anyway. Claims TDD tends to force people to be more reflective. 
.Close

Spinellis11a
.Open Spinellis11a
 Diomedis Spinellis 
 Choosing and Using Open Source Components 
 IEEE Software Magazine V28n3(May/Jun 2011)p96+95
 =HOWTO CHOOSE F/OSS COMPONENTS
 Like choosing a spouse!
 Factors
.List
 Legal status and license vs your situation.
 Binary or source. Time to build binary from source? Portability. 
 Quality: popularity, wise opinions, documentation, support
 Release history=heart beat. Is it alive? Does it allow a choice of stable and cutting edge versions? 
 Project community = the family you are marrying into. One man show? Team work? Democracy or autocracy?
 How open to submissions? How to reintegrate? 
 Style. Consistent? Commented? Names? Easy to use? Easy to adapt? Avoid complexity!
 How to reuse? All or some? Tweaks only! Use version control branches. Tracking new releases? 
.Close.List
.Close

TianRudrarajuLi04
.Open TianRudrarajuLi04
 Jeff Tian & Sunita Rudraraju & Zhao Li
 Evaluating Web Software Reliability Based on Workload and Failure Data Extracted from Server Logs
 IEEE Trans Software Engineering  V30n11(Nov 2004)pp754-769
 =EXPERIENCE WEB/NET RELIABILITY WORKLOAD LOGGING DATA STATISTICS SMU/SEAS KDE
 Access logs provide evidence of problems in content: "permission denied" and "file does not exist".
  Errors consistent with a Poisson process with time varying parameters,
  Can measure the growth in reliability.
  (Goel-Okumoto model):  expected_number_of_errors(time) = N*(1-exp(-b*time)) for some N and b.
  Similar models of work load for two different web sites: weekly cycle.
  Similar reliability models.
  What measures workload? Bytes served, hits, users, sessions?
.Close

TsaiWiegertJang92
.Open TsaiWiegertJang92
 Jeffrey J P Tsai & Thomas Weigert & Hung-chin Jang
 A Hybrid Knowledge Representation as a Basis of Requirement Specification and Specification Analysis
 IEEE Trans SE-V19n12(Dec 1992)pp1076-1100A
 =SUVEY FRORL LOGIC FORMAL SPECIFICATION OBJECT-ORIENTED non-monotonic hierarchy
.Box
 ORIENTED non-monotonic hierarchy(general with exceptions) frames for objects and activities complete and sound.
 Compare Kaindl93 arguing for frames to support informal preparations.

Section I Introduction(pp1076-1077)
 p1076: "Software development usually begins with an attempt to recognize and understand the user's requirements[...] Software developers are always forced to make assumptions about the user's requirements[...] Often the user has an incomplete understanding[...]"
Goguen and Meseguer's work on FOOP 1987 (Functions+objects+relational methods)
 p1077: "an_instance_of", "a_kind_of", "a_part_of". "formal correctness checking is desirable[...]surpass the expressiveness of standard first order logic"... "complete and sound with respect to these semantics[Horn clause logic+nonmonotonicity]. [...] the users can automatically analyze various properties of a FRORL specification."

Section II Demands(pp1077-1078)
 p1077 "domain model[vs]specification" "theorems [---] facts"

Section III The language(pp1078-1081)
 p1078 "Given an informal description of the problem domain" operational and decalrtive interpretations possible.
 p1079 Refers to Booch91 and Kowalski's book

Section IV Semantic foundations(pp1081-1085)
 Predicates and Consistency (\para_symbol) statements, Horne clauses, Herbarnd interpretations, fixed points of a theory operator. some model theoretic semantics. Some computational procedure to indicate if a clause is a logical consequence of a theory

Section V Mapping FRORL into Semantics(pp-)

Section V Analysis of specifications(pp1085-1090)
 reachability, reversibillity, liveness, and consistency. State space or problem reduction. Use abstracted attributes.

Section VII Software Environment(pp1090-1093)
	Sun SparcStation Open Look

Section VIII Related work (pp1093-1096)
	Survey based on Wing88. Mentions with KATE, CAKE, LARCH, Ina Jo, GIST, SASCO, PLEASE, SXL,...

Section IX Conclusions and plans(pp1096)

Section X. Appendix BNF(pp1096-1097)

Section XI Appendix B Soundness and Completeness (pp1097-1099)

54 References (pp1099-1100)
.Close.Box
.Close

ValacichEtAl07
.Open ValacichEtAl07
 Joseph S Valacich & D Veena Parboteach & John D Wells 
 The Online Consumer's Hierarchy of Needs
 Commun ACM V50n9(Sep 2007)pp- 
 =POLL USERS NEEDS WEB/NET PURPOSES QUALITIES ONESIZE OCHN 
 OCHN::="Online Consumers Hierarchy of Needs".
 All users
want "Functional Convenience" -- being able to get things done.  
 "Utilitarian" websits like Banking and Bill Paying what matters is
reliability, correct operation, explicit security, response time, ... and other
evidence of "Structural Firmness". 
 Another extreme are "Hedonic"
websites (Music, Movies, Games, Gambling, ...) where the users
want "Representational Delight" most -- consistent look and feel, visual 
appeal, creative design, Good colors, rich media, ... 
 "Hibrid" sites (news, shopping, auctioning, Travel, ...) wher the users
want a dregree of "Delight" mixed with some "Structural Firmness". 
.Close

VesseyJarvenpaaTractinsky92
.Open VesseyJarvenpaaTractinsky92
 Iris Vessey & Sirkka L Jarvenpaa & Noam Tractinsky
 Evaluation of Vendor Products: CASE Tools as Methodology Companions
 Commun ACM V35n4(Apr 1992)pp90-105
 =EXPERIENCE CASE TOOLS METHODS
 little impact on productivity or quality,
 match between method and tool,
 dozen compared,
  oldest least restrictive,
 all with internal inconsistencies
.Close

VesseySravanapudi95
.Open VesseySravanapudi95
 Iris Vessey & Ajay Paul Sravanapudi
 CASE Tools as Collaborative Support Technologies
 Commun ACM V38n1(Jan 1995)pp83-95
 =EXPERIENCES TOOLS COLLABORATION
 p83: "It is now well-established that, [...] much of the available resource is consumed by the sheer effort of maintaining communication and control"
 p94: Not much work on how teams actually do the job.

 Coordination = access control &  information sharing & monitoring & cooperation.
 information sharing =  Data & Consistency enforcement & Concurrency control.
 monitoring= Product & User.
 cooperation = communication & timing & meeting management
.Close

Weidenback94
.Open Weidenback94
 Christoph Weidenbach
 First-Order Tableaux with Sorts
 Submitted to IGPL usenet group June 1995 ftp://dcs.ox.ac.uk/sorttab.ps.g(??)
 =THEORY LOGIC SEMANTIC TABLEAUX TREES TYPES
.Box
Gensen style natural induction (cf hodges) extended by adding sorts to variables,
 Each variable has a set of sorts assoicated with it.
 Each sort is interprtted as a unary predicate.  s(x)=finite@(U->@)...
	for all x (p) +> for all x ( if and(s(x)(x)) then p).
	for some x (p) +> for some x ( and(s(x)(x)) and p).
Modified derivation rules
	for all x (p(x)), and( s(x)(t) ), t any term |- P(t)

	for some x (p(x)), new v |- p(v), and( s(x)(v) )

Gives much simpler proofs

Proved to be as complete and consistent as the original

.Close.Box
.Close

WeidenhauptEtal98
.Open WeidenhauptEtal98
 Klaus Weidenhaupt & Klaus Pohl & Matthias Jarke & Peter Haumer
 Scenarios in Systems Development: Current Practice
 IEEE Software Magazine V15n2(Mar/Apr 1998)pp34-45
 =POLL 15 European projects re use of SCENARIOS
.Box
use scenarios as bridges between people in software process
 scenarios used when abstract models fail then add prototypes+glossaries
 scenarios enforce interdisciplinary learning and validate static models
 they reduce complexity by tackling development of each scenario separately
 may have to provide multiple stakeholder views of large scenarios
 scenarios can facilitate consistency and resolution of different goals
 scenarios evolve
 should base tests on scenarios but scenarios may be out of date by testing time

.Close.Box
.Close

WiederholdWegnerCeri93
.Open WiederholdWegnerCeri93
 Gio Wiederhold & Peter Wegner & Stefano Ceri
 Toward Megaprogramming 
 Comm ACM V35n11(Nov 1992)pp89-99 
.See [CR]
9312-0929 D.2.2
 =ESSAY COMPONENTS ARCHITECTURE DOMAIN
 A megamodule is an internally homogeneous, consistent, independantly maintained software systems  
with goals, knowledge and traditions. Each describes externally accessible data and 
operations. The concepts, terminology and interpretation paradigm is called its ontology
.Close

Williams03
.Open Williams03
 Laurie Williams 
 The XP Programmer: The Few-Minutes Programmer
 IEEE Software Magazine V20n3(May/Jun 2003)pp16-20
 =EXPERIENCES XP iterative incremental agile pair-programming
 Describes XP practices.
 Compares XP to "The One-Minute Manager": rapid consistent simple feedback -- from requirement  to test to code to client very rapidly.
 Save time on big early phases by keeping them small and use the saved time to incrementally grow to what the user wants, even as the user learns what they need and moves the target...
  Anecdotes claim that growing a big working system one story at a time costs no more than trying to get the whole thing right first.  Research in progress.
.Close

WilliamsL94
.Open WilliamsL94
 Loyd G Williams
 Assessment of Safety-Critical Specifications
 IEEE Software magazine v11n1(Jan 1994)pp51-60
 =SURVEY FORMAL SPECIFICATION METHODS SCR VDM WLMS
 SCR:=Software Cost Reduction (Parnas!).
 VDM:=Viena Definition Method, after the VDL language for programming language semantics(IBM).
 WLMS:=Water-Level-Monitoring-System.
.Box
Both had discrepancies, with SCR worst.
 *methods for safety-critical need well defined criteria for completeness and consistency
 *Putative Theorem Proving - worth while
 *Reviews are an effective means of detecting errors
 *A formal spec should include formal safety requirements
 *Case tools can eliminate simple syntactic errors.
.Close.Box
.Close

Winograd95
.Open Winograd95
 Terry Winograd
 From Programming Environments to Environments for Design
 Commun ACM V38n6(Jun 1995)pp65-74
 =HISTORY USER+SYSTEM as a starting point
 constructing a joint REALITY via PROTOTYPES and coherent consistent CONCEPTUAL MODELS
 coevolution of organisation people and their tools
.Close

Wu04
.Open Wu04
 Fangjun Wu 
 Empirical Analysis of Entropy distance Metric for UML Class Diagrams
 ACM SIGSOFT Software Engineering Notes V29n5(Sep 2004)p35
.See http://doi.acm.org/10.1145/1022494.1022524
 =EMPIRICAL UML METRIC Zhou banking understanding
 Abstract: "[...]we provide empirical evidence for supporting the role of the structure complexity metrics for UML class diagrams, specifically Zhou's metric. Our results, based on data related with bank information system, indicate that the metric is basically consistent with human beings' intuitions. "
.Close

Yamazakietal93
.Open Yamazakietal93
 Seichi Yamazaki & Kiyohiko Kajihara & Mitsutaka Ito & Ryuichi Yasuhara
 Objected-oriented Design of Telecommunication Software
 Special Theme "Making OO Work" IEEE Software V10n1(Jan 1993)pp81-87
 =EXPERIEMENT OBJECT-ORIENETD ROOD Real-time vs FD
 Object models==<{logical model, integration model} vs Physical model,
 Static(ER)+dynamic(FSM)+message sequences,
 Case study compared OO(in Ada 83)+FD on 10K LOC: OO gave greater extendabillity,
 lesser performance,
 more smaller and simpler modules (No inheritance),
 difficult to grasp the entire model and check consistency.
.Close

Young97
.Open Young97
 William D Young
 Comparing Varification Systems: Interactive Consistency in ACL2
 IEEE Trans Softw Eng VSE23n4(Apr 1997)pp214-223
 =DEMO PROOF LOGIC LISP 
.See [ACL2]

.See [KaufmanMoore97]
hardware CLI
 advantages of no types and LISP-like notation vs 
.See [PVS]
Rushby
.Close

Zave97
.Open Zave97
 Pamela Zave
 Classification of Research Efforts in Requirements
 ACM Computer Surveys V29n4(Dec 1997)pp315-321
 =SURVEY REQUIREMENTS Research
.Box
Note
 first_dimension: problems_in (1:investigation+2:specification+3:evolution)

 investigation:(1.1:communication+1.2:generate strategies to meet vague goals+1.3:priorities and satisfactory ranges+1.4:allocation of requirements to resources+1.5:costs/risks/schedules+1.6: completeness
 specification:(2.1:multiple views and representations+2.2:evaluating alternatives+2.3:good_specifications(complete&consistent&unambiguous)+2.4:check specification vs requirements+2.5:fit to design and implementation)
 evolution:(3.1:reuse as system evolves+3.2:reuse in other systems+3.3:reconstructing requirements)

second_dimension:contribution (A:State of the art | B:proposed process change | C:proposed product change | D:case study applying solution to example | E:Evaluation and comparison | F:Proposal for measurement changes)

.Close.Box
.Close

ZickertBeck12
.Open ZickertBeck12
  Frank Zickert & Roman Beck
  Coping with existing systems in information systems development
  IEEE Trans Software Engineering  V38n5(Sep/Oct 2012)pp1027-1039
  =CASESTUDY FINANCIAL SYSTEMS ISD SOLUTION COMPLEXITY PATTERNS INTEGRATE EXTEND REENGINEER PROBLEM SPACE 
 Bottom-up may be better than top-down when analyzing existing systems. 
 Problem space: issues (existing vs new) requires and or inconsistent not-sufficient...
.Close

ZimmermannWeibgerberDiehlZeller05 
.Open ZimmermannWeibgerberDiehlZeller05 
 Thomas Zimmermann & Peter Weibgerber & Stephan Diehl & Andreas Zeller
 Mining Version Histories to Guide Software Changes
 IEEE Trans Software Engineering  V31n6(Jun 2005)pp429-526 
 =EMPIRICAL EVOLUTION OPEN SOURCE TOOL ROSE CVS ECLIPSE GCC GIMP JBOSS JEDIT KO
FFICE POSTGRES PYTHON
 ROSE::Eclipse_plugin=http://www.st.cs.uni-sb.de/softevo/
 By analyzing data
collected from version histories can predict what else is likely to be 
changed if one location is changed. Top 3 predictions cover correct
predictions 79% of the time.
 Detects undocumented couplings.
 May help prevent incomplete/inconsistent changes.  Few false alarms.
 Fine grain prediction works best on stable systems.  But even unstable systems the files can be predicted,
 Works best in maintenance.
.Close

Search for bibliographic items containing a matching string.


(Search uses POSIX regular expressions and ignores case)

To see the complete bibliography (1Mb+) select:[Bibliography]