References of Experiences

@InProceedings{	  antonini.canfora.ea:re-engineering,
  author	= {P. Antonini and G. Canfora and Aniello Cimitile},
  title		= {Re-engineering Legacy Systems to Meet Quality
		  Requirements: An Experience Report},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1994},
  year		= {1994},
  pages		= {146-153},
  publisher	= {IEEE Computer Society Press},
  month		= sep,
  abstract	= {The paper is a summary of a third party re-engineering
		  project aiming to adjust a legacy system to the new quality
		  standard established by the customer. The quality standard
		  is defined in the form of a set of metrices each associated
		  with a range of acceptable values. A set of 100 programs
		  has been restructured and modularised to meet the quality
		  requirements. When possible, automated tools have been used
		  in order to reduce the costs, standadise the results, and
		  ease the transfer of techniques and methodologies to the
		  customer. The re-engineered programs habe replaces the
		  orginal versions in the customer production environment.
		  Their quality, and in particular their understandability
		  and maintainability, is considerably increased as confirmed
		  by the customer's technical personnel.
		  
		  The work described here is a preliminary step towards the
		  definition of a larger re-engineering project to bring the
		  customer's software portfolio into line with the new
		  quality standard.},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  antonini.canfora.ea:reengineering,
  author	= { P. Antonini and G. Canfora and A. Cimitile },
  title		= { Reengineering Legacy Systems to Meet Quality
		  Requirements: An Experience Report },
  booktitle	= { Proceedings of the International Conference on Software
		  Maintenance {\rm (Victoria, B.C., Canada; September 19-23,
		  1994)} },
  year		= { 1994 },
  editor	= { Hausi A. M\"{u}ller and Mari Georges },
  pages		= { 146-153 },
  class		= {Reengineering_in_General, Experiences }
}

@InProceedings{	  arango.baxter.ea:maintenance,
  author	= {Guillermo Arango and Ira Baxter and Peter Freeman},
  title		= {Maintenance and Porting of Software by Design Recovery},
  booktitle	= {CSM'85: Proceedings of the 1985 Conference on Software
		  Maintenance, {\rm (Washington, DC; November 11-13, 1985)}},
  year		= {November 1985},
  pages		= {42-49},
  abstract	= {DRACO paper on porting through transformation from source
		  code to abstraction back to new code. Captures
		  domain-specific knowledge.},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Code, Program_Transformations,
		  Software_Reverse_Engineering, Reverse_Design,
		  Knowledge-Based_Concept_Assignment,
		  Human_Oriented_Concept_Assignment_by_Informal_Reasoning },
  keywords	= {domain modeling, domain analysis, DRACO}
}

@Article{	  arango.baxter.ea:tmm*1,
  author	= {Guillermo Arango and Ira Baxter and Peter Freeman and
		  Christopher Pidgeon},
  title		= {{TMM}: Software Maintenance by Transformation},
  journal	= {IEEE Software},
  month		= {May},
  year		= {1986},
  volume	= {3},
  number	= {3},
  pages		= {27-39},
  abstract	= { . Another DRACO-based paper. . Uses least common
		  abstractions. },
  keywords	= {domain modeling, domain analysis, DRACO},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Code, Program_Transformations,
		  Software_Reverse_Engineering, Reverse_Design,
		  Knowledge-Based_Concept_Assignment,
		  Human_Oriented_Concept_Assignment_by_Informal_Reasoning}
}

@Article{	  arnold:software*4,
  author	= { Robert S. Arnold },
  title		= { Software Reengineering: A Quick History },
  journal	= { Communications of the ACM },
  volume	= { 37(5) },
  pages		= { 13-14 },
  year		= { May 1994 },
  class		= {Reengineering_in_General, Experiences }
}

@InProceedings{	  bar.bauer.ea:sanierung,
  author	= {Holger B{\"a}r and Markus Bauer and Oliver Ciupke and
		  Thomas Gen{\ss}ler and Radu Marinescu and Benedikt Schulz
		  and Joachim Weisbrod},
  title		= {{S}anierung objektorientierter {S}ysteme},
  booktitle	= {Proceedings of the 1st German Workshop on
		  Software-Reengineering},
  editor	= {J{\"u}rgen Ebert and Bernt Kullbach and Franz Lehner},
  series	= {Fachberichte Informatik},
  year		= {1999},
  organization	= {Universit{\"a}t Koblenz-Landau, Institut f{\"u}r
		  Informatik},
  month		= jul,
  address	= {Bad Honnef, Germany},
  pages		= {53--58},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  benander.benander:empirical,
  author	= { A.C. Benander and B.A. Benander },
  title		= { An Empirical Study of Cobol Programs via a Style
		  Analyzer: The Benefits of Good Programming Style },
  journal	= { Journal of Systems and Software },
  volume	= { 10 },
  year		= { 1989 },
  pages		= { 271-279 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General, Experiences }
}

@Article{	  britcher:re-engineering,
  author	= {Robert N. Britcher},
  year		= {1990},
  journal	= {IBM Systems Journal},
  pages		= {551-567},
  title		= {Re-engineering Software: A Case Study},
  volume	= {29(4)},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@Book{		  brodie.stonebraker:migrating,
  author	= {M.L. Brodie and M. Stonebraker},
  title		= {Migrating Legacy Systems --- Gateways, Interfaces \& The
		  Incremental Approach},
  publisher	= {Morgan Kaufmann Publishers, Inc.},
  year		= {1995},
  note		= {This book gives a detailed description of strategies for
		  migrating legacy systems. It advocates an incremental
		  approach for the migration instead of doing it in {\em one}
		  step. The legacy system is analyzed and the components to
		  be updated are identified. The legacy system and the new
		  system work in parallel and are connected via gateways.
		  Migrated components are removed from the legacy system and
		  added to the new system. The crucial steps in this process
		  are establishing the right ordering of the components to be
		  migrated and the use of powerful gateways. It is preferable
		  not to develop these gateways yourself but to obtain them
		  from third party software producers. A number of
		  case-studies is presented and these case-studies
		  demonstrate that these gateways are crucial even if all the
		  code of the legacy system becomes obsolete. The book
		  concludes with an extensive list of third party software
		  producers which produce gateways},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Design}
}

@Article{	  buss.de-mori.ea:investigating,
  author	= {E. Buss and R. {De~Mori} and M. Gentleman and J. Henshaw
		  and H. Johnson and K. Kontogiannis and E. Merlo and H.
		  M\"{u}ller and J. Mylopoulos and S. Paul and A. Prakash and
		  M. Stanley and S. Tilley and J. Troster and K. Wong},
  title		= {Investigating Reverse Engineering Technologies: The CAS
		  Program Understanding Project},
  journal	= {IBM Systems Journal},
  volume	= {33(3)},
  year		= {February 1994},
  pages		= {477-500},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@TechReport{	  buss.henshaw:experiences,
  key		= {Buss \& Henshaw, 1992},
  author	= {Erich Buss and John Henshaw},
  title		= {Experiences in Program Understanding},
  institution	= {IBM Canada Ltd. Laboratory, Centre for Advanced Studies},
  year		= {1992},
  number	= {TR 74.105},
  address	= {895 Don Mills Road, North York, Ontario, Canada M3C 1W3},
  month		= jul,
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  buss.henshaw:experiences*1,
  author	= {Erich Buss and John Henshaw},
  title		= {Experiences in Program Understanding},
  booktitle	= {{CASCON'92}: Proceedings of the 1992 CAS Conference, {\rm
		  (Toronto, Ontario; November 9-12, 1992)}},
  year		= {November 1992},
  pages		= {157-189},
  publisher	= {IBM Canada Ltd.},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@TechReport{	  buss.henshaw:experiences*2,
  author	= {Erich Buss and John Henshaw},
  title		= {Experiences in Program Understanding},
  institution	= {IBM Software Solutions Toronto Laboratory Centre for
		  Advanced Studies},
  number	= {TR-74.105},
  year		= {July 1992},
  abstract	= { . Early version of their CASCON'92 paper. },
  class		= {Reengineering_in_General, Experiences }
}

@TechReport{	  buss.henshaw:software,
  key		= {Buss \& Henshaw, 1991},
  author	= {Erich Buss and John Henshaw},
  title		= {A Software Reverse Engineering Experience},
  institution	= {IBM Canada Ltd. Laboratory, Centre for Advanced Studies},
  year		= {1991},
  number	= {TR 74.065},
  address	= {895 Don Mills Road, North York, Ontario, Canada M3C 1W3},
  month		= sep,
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  buss.henshaw:software*1,
  author	= {Erich Buss and John Henshaw},
  title		= {A Software Reverse Engineering Experience},
  booktitle	= {Proceedings of CASCON~'91, {\rm (Toronto, Ontario; October
		  28-30, 1991)}},
  year		= {October 1991},
  pages		= {55-73},
  publisher	= {IBM Canada Ltd.},
  abstract	= { . Introduction . Ongoing need for adaptive, perfective,
		  and corrective maintenance . Maintainer must try to
		  understand the intent of the original author without the
		  benefit of his or her advice and guidance. . Most
		  production software in the marketplace can be characterised
		  as being in the maintenance phase of the software life
		  cycle. . Maintain the product's "conceptual integrity"
		  while operating under traditional time, productivity, and
		  quality-related objectives. . Reverse engineering:
		  terminology and concepts . Definition of RE, FE,
		  redocumentation(*), design recovery, restructuring,
		  re-engineering, PU . Diagram showing relationship between
		  terms and life-cycle phases. . Reverse engineering concepts
		  . PU takes place within the context of an "application
		  problem domain" and an "environmental domain." (Fodder for
		  thesis and D-R RE.) . Application PD employs specialised
		  terminology and paradigms, which determine software
		  artifact representations; application semantics
		  (implementation language, terminology, business rules, ...)
		  . Environmental semantics (OS, type of hardware,
		  configuration, ...) . Since RE is an open-ended,
		  context-dependent activity, it is important that toolkits
		  be similarly open-ended, flexible, extensible, and
		  versatile. . RE is "a solution looking for a problem": the
		  appplication of this technology requires a real-world
		  problem on which to focus. . Why is RE difficult? . Lists
		  10 reasons why (from another paper [11]). . (Use this as
		  introductory material in my thesis, "The problem.") . When
		  to re-engineer? . Lists 11 key indicators (from another
		  paper [2]). . The PU project . Integrate new FE technology
		  into existing "legacy" software. . Three options: (1) stay
		  the course; (2) replace part or all; (3) PU . The right
		  customer . Opportunity to use SQL/DS as the "real world"
		  subject system. . Successful RDBMS with a traditional
		  maintenance history. . Developers working under demanding
		  quality-related objectives, and are eager to take advantage
		  of new technologies. . SQL/DS is a proprietary IBM product,
		  therefore COTS tools not suitable. . They opted for REFINE
		  since it allows the requisite product-specific
		  customization (D-R RE): a customizable toolkit was a
		  necessity. . Their initial focus was on error detection. .
		  They hoped this would be integrated into the SQL/DS
		  maintenance process. . The SQL/DS product . SQL/DS:
		  Structured Query Language/Data System. . Uses many concepts
		  originally created in System R [15]. . They include a
		  useful diagram showing evolution of SQL/DS, from System R
		  (1976, PL/I, VM, prototype), to SQL/DS V1.0 (1982, PL/S,
		  190K, VM/SP, PP), to SQL/DS V3.2 (1991, PL/AS, >500K
		  (2.3M), VM/SP,VM/XA,VM/ESA,VSE, PP). . Erich says 2,079,369
		  lines of PL/AS in 1,147 modules (without comments); with
		  comments, 4,485,488 lines of PL/AS, over 247M of source
		  code! . Hence, SQL/DS is now 12 years old, and over two
		  million lines of code (in expanded form); it has code that
		  is 18 years old in it from System R. . Runs on S/370, but
		  several different OS's; mandates dual-path code which must
		  be maintained in sync. . There are about 8,000 SQL/DS
		  licenses worldwide (1991) (Probably more now with DB2 and
		  DB2/6000). . Implemented in PL/AS, a proprietary PL/I-like
		  dialect allowing imbedded S/370 assembler. A "close to the
		  metal" systems PL. Hence, COTS tools not applicable to
		  PL/AS. . SQL/DS has roughly 1,150 compile units, roughly
		  partitioned into three large units (and several smaller
		  ones). Clearly, this amount of code is far greater than any
		  individual can comprehend by themselves. It is necessary
		  for the developer to specialise in a particular component,
		  despite the fact that the various components interact! .
		  Application data "flows" through global data structures,
		  and is manipulated in concert by many different software
		  modules. . The devloper looks at code that is over 90\%
		  control logic, but the compiler sees over 90\% as data
		  structure declarations, placed in shared files and
		  \%INCLUDE'd. . Efficiency (speed) is of paramount
		  importance, especially given the industry-wide perception
		  that relational databased are sluggish. . They have too
		  much documentation: too much to maintain, and too much to
		  pissibly read and digest. . It is a typical legacy code
		  system: successful, mature, supporting an existing customer
		  base while growing in terms of supported environments and
		  functionality. . Good quote from Lehman and Belady paper
		  [18] on degenerating software structure as maintenance
		  continues. . The RE toolkit . Most application problem
		  domains have unique and specialised characteristics, thus
		  RE toolkits must be extensible and versatile. . it is
		  highly unlikely that a "turn key" reverse engineering
		  package will suffice for many users. Maybe this is why CASE
		  tools are better at FE than RE. Even the most sophisticated
		  CASE tools are currently capable of accepting only general
		  data definitions. . The tools and toolkit affects the way
		  you think about the problem domain [E. Dijkstra]. . Should
		  should know either exactly what you want to accomplish, or
		  you should place a premium on toolkit flexibility. . They
		  chose the Software Refinery by Reasoning Systems Corp. .
		  They include a diagram describing the three pieces of the
		  SF: DIALECT (for parsing), REFINE (the OO-DB), and
		  INTERVISTA (the UI). . (Note that given this breakdown, we
		  have similar pieces, and could concievable
		  replace/integrate Rigi with the SF's components). .
		  (Include such a diagram in the paper, but for Rigi.) .
		  DIALECT requires a grammar for the input PL nd a domain
		  model (a description of the object base, i.e. how the AST
		  should look like). It includes a reverse-parser which can
		  produce code out of the db. . The core of the SF is the
		  REFINE specification language, a multi-paradigm HLL. It has
		  the syntax of LISP (in fact, it gets translated to LISP to
		  run on the underlying LISP system), but included
		  Prolog-like logic, sets, and so on. . A significant major
		  feature of the SF is its extensiblity; this has been
		  demonstrated by its capability to integrate into various
		  commerical application domains (which ones?). . DIALECT =
		  rigireverse REFINE = rigiserver/rigiedit INTERVISTA =
		  rigiedit . A software RE experience . Their ultimate goal
		  was the qualitative and quantitative improvement of the
		  SQL/DS base code and maintenance process. . They key is
		  analysis, and they use the SF to convert the SQL/DS code
		  into something that is tractable and can be manipulated. .
		  They were guided (somewhat) by SQL/DS management to direct
		  their research to specific problem areas. . They spent
		  considerable time creating a parser for PL/AS: it is
		  context-sensitive, there is no formal grammer (there are
		  several dialects), and the imbedded assembler complicates
		  matters. They first built a special scanner to recognize
		  multiple symbols for the same keyword, skipping the
		  imbedded assembler and PL/AS listing format directives. .
		  They have a full-page process diagram of PL/AS on VM to SF
		  population. . (We need to include a similar picture, and
		  rationale as to why it is so much simpler.) . When they
		  encountered bizarre parsing errors, they went back and
		  fixed the source (it turned out to be wrong in some way
		  anyhow). . They found several errors in the source just
		  while testing their parser. . (It would be nice to get a
		  copy of the reports they submitted to SQL.) . One of their
		  most clearly stated conclusions is that any RE toolkit must
		  be extensible to meet your problem domain. . Future
		  directions . Stuff to work on (in increasing order of
		  difficulty). . (Address some of these issues in my thesis!)
		  . Static analysis. (Some of my work). . Code standard
		  checker (IBM Watson work); allow partially automated code
		  inspections against a specified standard. They considered
		  this the most promising area for immediate future work. .
		  Code flow analysis. The extraction of this information from
		  a single module is "easy"; representing and presenting this
		  information is hard. . Data flow/Structure analysis: map
		  the data structures and their relationships. Especially
		  important for SQL/DS due to its use of global data
		  structures to pass information, causing increased
		  complexity. . Test case generation. . Create REFINE/PLAS,
		  similar to REFINE/C and REFINE/FORTRAN. (These are examples
		  of instantiated D-RE RE environments for a specific
		  application domain.) . Performance analysis and tuning. .
		  Redundant code identification. . Program transformation. .
		  Program translation: produce a C equivalent of the PL/AS
		  source to SQL/DS. . Program reuse and generation. . Summary
		  and conclusions . Software maintenance is an economic
		  survival issue. . The PU project is analysis-oriented. .
		  Must control and minimise maintenance costs, understand
		  embedded business rules. . RE is not a well-understood
		  concept. In addition to the introduction of the basic
		  terminology, it is essential to manage the expectations of
		  the approach; many expectations in the area are
		  unrealistic. . Key is the conversion from source code to a
		  more tractable medium; they chose the SF's object base. (I
		  choose Rigi views, and must allow the user to choose others
		  as well.) . Mention "software archeologists," and offer an
		  interesting analogy: archeologists cannot usually
		  (after-the-fact) ask "why" something is the way it is, and
		  are forced to invent rational models for the existence of
		  particular artifacts. RE's have much the same task. },
  class		= {Reengineering_in_General, Experiences }
}

@Article{	  buss.mori.ea:investigating,
  author	= {E. Buss and R. De Mori and W. M. Gentleman and J. Henshaw
		  and H. Johnson and K. Kontogiannis and E. Merlo and H. A.
		  M\"{u}ller and J. Mylopoulos and S. Paul and A. Prakash and
		  M. Stanley and S. R. Tilley and J. Troster and K. Wong},
  title		= {Investigating Reverse Engineering Technologies for the
		  {CAS} Program Understanding Project},
  journal	= {IBM Systems Journal},
  volume	= {33},
  number	= {3},
  year		= {1994},
  pages		= {477-500},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@Article{	  byrne:software,
  author	= {Eric J. Byrne},
  title		= {Software Reverse Engineering: a Case Study},
  journal	= {Software---Practice and Experience, Wiley},
  year		= {1991},
  volume	= {21},
  number	= {12},
  pages		= {1349-1364},
  abstract	= {This paper presents lessons learned from an experiment to
		  reverse engineer a program. A reverse engineering process
		  was used as part of a project to develop an Ada
		  implementation of a Fortran program and upgrade the
		  existing documentation. To accomplish this, design
		  information was extracted from the Fortran source code and
		  entered into a software development environment. The
		  extracted design information was used to implement a new
		  version of the program written in Ada. This experiment
		  revealed issues about recovering design information, such
		  as, separating design details from implementation details,
		  dealing with incomplete or erroneous information,
		  traceability of information between implementation and
		  recovered design, and re-engineering. The reverse
		  engineering process used to recover the design, and the
		  experience gained during the study are reported.},
  note		= { Experience report describing the problem of
		  reimplementing a Fortran program in Ada. Instead of a
		  one-to-one translation, the original Fortran program is
		  analyzed and design information is extracted which is then
		  used to reimplement the program in Ada.},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  byrne:software*1,
  author	= { E.J. Byrne },
  title		= { Software Reverse Engineering: A Case Study },
  journal	= { Software --- Practice and Experience },
  year		= { December 1991 },
  pages		= { 1349-1364 },
  abstract	= { },
  class		= {Reengineering_in_General, Experiences }
}

@InProceedings{	  chen:repository-based,
  author	= {Yih-Farn Robin Chen},
  title		= {Repository-Based Reverse Engineering: An Experience
		  Report},
  booktitle	= {Proceedings of the 4th Reengineering Forum},
  year		= {1994},
  address	= {Victoria, Canada},
  pages		= {33.1 - 33.10},
  month		= sep,
  note		= {only slides},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  configuration-management-system:olin,
  author	= {Reengineering a Configuration-Management System},
  title		= {Olin Bray and Michael Hess},
  journal	= {IEEE Software},
  year		= {1995},
  volume	= {12},
  number	= {1},
  pages		= {55-63},
  month		= {January},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Design, From_Mainframe_to_Client-Server_Architecture}
}

@Article{	  dedene.vresse:realities,
  author	= {Guido Dedene and Jean-Pierre De Vresse},
  title		= {Realities of Off-Shore Reengineering},
  journal	= {IEEE Software},
  year		= {1995},
  volume	= {12},
  number	= {1},
  pages		= {},
  month		= {January},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  dunn.knight:software,
  author	= {M. F. Dunn and J. C. Knight},
  title		= {Software Reuse in an Industrial Setting: A Case Study},
  booktitle	= {Proceedings of the 13th  International Conference on
		  Software Engineering },
  pages		= {329-338},
  year		= {1991},
  class		= {Reengineering_in_General, Experiences}
}

@Book{		  knöll.schwarze:re-engineering,
  author	= {H.-D. Knöll and M. Schwarze},
  title		= {Re-Engineering von Anwendungssoftware},
  publisher	= {BI Wissenschaftsverlag},
  year		= {1993},
  edition	= {1},
  abstract	= {Fallstudie, CASE-Tools im Vergleich},
  language	= {German},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  lakhotia:understanding,
  author	= {Arun Lakhotia},
  title		= {Understanding Someone Else's Code: Analysis of
		  Experiences},
  journal	= {Reverse Engineering Newsletter},
  pages		= {Rev-6 -- Rev-8},
  inhalt	= { Erkenntnisse: 1) Der Programmierproze\3 besteht darin,
		  Abbildungen zu konstruieren (vom Anwendungsbereich in die
		  Implementierung). 2) Ein Programm zu verstehen involviert
		  die Rekonstruktion all dieser Abbildungen. 3) Der
		  Rekonstruktionsproze\3 ist erwartungsgesteuert durch
		  Schaffung, Bestätigung und Verfeinerung von Hypothesen.
		  
		  Anforderungen an die Organisation/Struktur zum besseren
		  Verständnis von Programmcode: Ebenen der Abbildungen
		  sollten reflektiert werden in einer Kombination aus -
		  physischer Organisation (Verzeichnisstruktur auf
		  Dateiebene) - modulare Dekomposition des Programmcodes
		  
		  Tools: - thesaurusbasiertes Tool, das nach Symbolen sucht,
		  deren Bedeutung nahe bei funktionsbeschreibenden Phrasen
		  liegt. - cross-reference-Information, die durch *
		  Datenbankanfragen oder * hypertextorientierten Browsern zur
		  Verfügung gestellt wird. - Tool, das das Design ermittelt,
		  das am natürlichsten ist, um den Problemtyp zu beschreiben.
		  Z.B.: * Proze\3orientierte Anwendung -> Endliche Automaten
		  * Datenintensive Anwendung -> ER-Diagramme - Tool sollte
		  den Systemgenerierungsproze\3 (Makefile) berücksichtigen -
		  das Tool sollte partielle Rekonstruktion des Designs
		  ermöglichen },
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  meltz:assessment,
  author	= {Peter Meltz},
  title		= {Assessment of the Options for Hardware Software
		  Reengineering of two KSG/GfS Full Scope Simulators},
  booktitle	= {1st  European Conference on Software Maintenance and
		  Reengineering 97},
  month		= mar,
  year		= {1997},
  publisher	= {IEEE Computer Society Press},
  abstract	= {Due to the problems in maintaining software and hardware
		  it was tried to port the individual software of two
		  powerplant simulators onto new hardware platforms within a
		  reeingineering project. The examinations that had been
		  carried out surprisingly lead to the result, that the least
		  risky, most economic and best result would not be achieved
		  by reengineering but by newly generating the software on
		  the base of actual powerplant data. },
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  regelson.anderson:debugging,
  key		= {Regelson \& Anderson, 1994},
  author	= {Elaine Regelson and Andrew Anderson},
  title		= {Debugging Practices for Complex Legacy Systems},
  pages		= {137-143},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1994},
  year		= {1994},
  publisher	= {IEEE Computer Society Press},
  month		= sep,
  abstract	= {Modern software development can require large numbers of
		  people over long periods of time to create complex
		  products. Industry trends showing rapid movement of people
		  between companies and job assignments and use of
		  specialized software maintenance groups for all maintenance
		  activities frequently mean that the software engineers
		  supporting (debugging, fixing, enhancing, and completing)
		  products were not involved in the original design or
		  coding. Hence it is important for engineers to be able to
		  quickly find defects in unfamiliar code and to safely make
		  changes. This paper describes results from an industrial
		  survey initiated to collect information about software
		  debugging and maintenance best practices. It describes
		  failure reproduction, defect isolation, and debugging
		  practices and tools. The paper is based on numerous actual
		  examples and results of problem solving and exercices.},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  slovin.malik:reengineering,
  author	= {M. Slovin and S. Malik},
  title		= {Reengineering to Reduce System Maintenance: A Case Study},
  journal	= {IEEE Transactions on Software Engineering},
  year		= {1991},
  month		= {July/August},
  pages		= {14-24},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  sneed.kaposi:study,
  author	= {Harry M. Sneed and Agnes Kaposi},
  title		= {A study on the Effect of Reengineering on
		  Maintainability},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1990},
  year		= {1990},
  pages		= {91-99},
  organization	= {IEEE},
  publisher	= {IEEE Computer Society Press},
  abstract	= {The report presented here on the effect of reengineering
		  upon software maintainablility stems from a laboratory
		  experiment conducted within the METKIT research project of
		  the European ESPRIT program for the study and promotion of
		  the use of metrics in Software-Engineering. The experiment
		  was conducted as a case study in measuring software
		  complexity and maintainablility. However, the results also
		  serve to assess the benefits of reengineering old programs.
		  Maintainability is defined as the effort to perform
		  maintenance tasks, the impact domain of the maintenance
		  actions and the error rate caused by those actions.
		  Complexity is defined as a combination of code, data, data
		  flow, structure, and control flow metrics. From the data
		  collected it demonstrates that reengineering can decrease
		  complexity and increase maintainability, but that
		  restructuring has only a minor effect on maintainability.},
  class		= {Reengineering_in_General, Experiences,
		  Software_Reverse_Engineering, Reverse_Design,
		  Metric-Based_Methods_in_Reverse_Design, Metrics,
		  Maintenance_Metrics}
}

@InProceedings{	  sneed:bank,
  author	= {Harry M. Sneed},
  title		= {Bank Application Reengineering and Conversion at the Union
		  Bank of Switzerland},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1991},
  year		= {1991},
  pages		= {60-72},
  organization	= {IEEE},
  publisher	= {IEEE Computer Society Press},
  abstract	= {This paper describes a large software reengineering
		  project at the Union Bank of Switzerland. Seven bank
		  applications with 203 programs and 432 files were renovated
		  and migrated from a UNIVAC-494 to a UNISYS-1100. The
		  programs were restructured to fit a JSP-DELTA generator.
		  The data was remodelled to fit into a CODASYL database with
		  a data dictionary and a common COPY library.},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  sneed:measuring,
  author	= {Harry M. Sneed},
  title		= {Measuring the Performance of a Software Maintenance
		  Department},
  booktitle	= {1st  European Conference on Software Maintenance and
		  Reengineering 97},
  month		= mar,
  year		= {1997},
  publisher	= {IEEE Computer Society Press},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  sneed:software,
  author	= {Harry M. Sneed},
  title		= {Software Renewal: A Case Study},
  journal	= {IEEE Software},
  year		= {1984},
  pages		= {56-63},
  month		= jul,
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  solinger.engberts.ea:transferring,
  author	= {Mary Solinger and Andre Engberts and Jim Q. Ning},
  title		= {Transferring Re-engineering Technology to a Software
		  Development and Maintenance Organization: an Experience
		  Report},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1994},
  year		= {1994},
  pages		= {100-108},
  publisher	= {IEEE Computer Society Press},
  month		= sep,
  abstract	= {Technology transfer does not happen spontaneously after
		  resaerch results and prototypes have been demostrated.
		  Resaerchers need to get more actively invovled in ``pushing
		  technology out of the door.'' This paper describes an
		  experiment that we conducted in 1993 to facilitate
		  technology transfer. There are two aspects of this
		  experiment: 1) the integration of a re-engineering process
		  into an existing software development and maintenance
		  organization and 2) the evaluation of a research prototype
		  in a ``real world'' situation. The experiment resulted in
		  recommendations on adapttation of the tool functionality
		  and on a configuration for use by different teams within
		  the target organization.},
  class		= {Reengineering_in_General, Experiences}
}

@PhDThesis{	  wong:reverse,
  author	= {Kenny Wong},
  title		= {The Reverse Engineering Notebook},
  school	= {University of Victoria},
  year		= {1999},
  abstract	= {Software must evolve over time or it becomes useless. Much
		  of software production today is involved not in creating
		  wholly new code from scratch but in maintaining and
		  building upon existing code. Much of this code resides in
		  old legacy software systems.
		  
		  Unfortunately, these systems are often poorly documented.
		  Typically, they become more complex and difficult to
		  understand over time. Thus, there is a need to better
		  understand existing software systems. An approach toward
		  this problem would be a first step toward easing changes
		  and extending the continuous evolution of these systems.
		  
		  This dissertation addresses the problem by enabling
		  continuous software understanding. There should be a base
		  of reverse engineering abstractions that are carried
		  forward during evolution.
		  
		  The proposed approach seeks to redocument existing software
		  structure, capture the analysis decisions made, and support
		  personal, customizable, and live perspectives of the
		  software in an online journal called the Reverse
		  Engineering Notebook.
		  
		  The premise that software reverse engineering be applied
		  continuously throughout the lifetime of the software has
		  major tool design implications. Thus, tool integration,
		  process, and adoption are key issues for the Notebook. In
		  particular, data integration requirements, control
		  integration via pervasive scripting, presentation
		  integration through the management of views, user roles,
		  methodology, end user needs, and goal-directed framework
		  for the Notebook are described.
		  
		  A major theme of the dissertation is learning from the
		  successes and failures of studies involving tool
		  integration and reverse engineering technologies. Case
		  studies and user experiments helped to evaluate various
		  aspects of the Notebook approach and provide feedback into
		  software understanding tool requirements.
		  
		  },
  keywords	= {reverse engineering, program understanding, tool
		  requirements},
  class		= {Interoperability Reengineering_in_General Using_graphs
		  Reverse_Engineering_Tools Rig Process_Models
		  Software_Reverse_Engineering
		  Intermediate_Representations_of_Source_Code Experiences }
}