Demo Data from EDBT 2026 / reviewers in the wild / expert
Colin Tully
dblp:83/6049 · also Colin J. Tully
· DBLP profile ↗
11ranked-venue papers
6as first author
0since 2021 · last 2003
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 9 · 5 first-authorSystems, architecture and hardware · 1Applied, interdisciplinary, general and emerging computing · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
4 papers |
Software maintenance and evolution · 71% Empirical software engineering · 29% |
Topics — the 2 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software maintenance and evolution
software reuse |
0.1 | 2 | 2003 | Comments on "More Success and Failure Factors in Software Reuse" · IEEE Trans. Software Eng. 2003 Success and Failure Factors in Software Reuse · IEEE Trans. Software Eng. 2002 |
Empirical software engineering
software engineering practice |
0.0 | 1 | 1991 | Non-Technological Issues in Software Engineering · ICSE 1991 |
Methods — techniques the papers use, named apart from their topics
data mining · 0.0structured interviews · 0.0empirical study · 0.0industrial experience synthesis · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2003 | Comments on "More Success and Failure Factors in Software Reuse"abstractFor original paper see ibid., p. 474. This is a clear example of how research in software engineering can progress when empirical methods are applied. Menzies and Di Stefano apply a number of data mining tools to the data set. While, inmost cases, their results are in agreement with ours, in some cases they are not. Our first and main observation is that our interpretation of the data set is based not only on the data set itself but also on the knowledge gathered during the interviews with project members. The main problem with the data set is its size: 23 data points. Although this data set is the largest one available about reuse projects, it is too limited to base analysis only on data mining techniques; data mining is usually applied to data sets with thousands if not millions of data points. Maurizio Morisio, Michel Ezran, Colin Tully |
IEEE Trans. Software Eng. | 3 |
| 2002 | Success and Failure Factors in Software ReuseabstractThis paper aims at identifying some of the key factors in adopting or running a company-wide software reuse program. Key factors are derived from empirical evidence of reuse practices, as emerged from a survey of projects for the introduction of reuse in European companies: 24 such projects performed from 1994 to 1997 were analyzed using structured interviews. The projects were undertaken in both large and small companies, working in a variety of business domains, and using both object-oriented and procedural development approaches. Most of them produce software with high commonality between applications, and have at least reasonably mature processes. Despite that apparent potential for success, around one-third of the projects failed. Three main causes of failure were not introducing reuse-specific processes, not modifying nonreuse processes, and not considering human factors. The root cause was a lack of commitment by top management, or nonawareness of the importance of those factors, often coupled with the belief that using the object-oriented approach or setting up a repository seamlessly is all that is necessary to achieve success in reuse. Conversely, successes were achieved when, given a potential for reuse because of commonality among applications, management committed to introducing reuse processes, modifying nonreuse processes, and addressing human factors. Maurizio Morisio, Michel Ezran, Colin Tully |
IEEE Trans. Software Eng. | 3 |
| 1999 | Failure and Success Factors in Reuse Programs: A Synthesis of Industrial ExperiencesabstractNo abstract available. Michel Ezran, Maurizio Morisio, Colin Tully |
ICSE | 3 |
| 1998 | Software Process Improvement: Practical Guidelines for Business Success, by Sami Zahran, Addison-Wesley, 1997 (Book Review)
Colin Tully |
Softw. Test. Verification Reliab. | 1 |
| 1995 | Desert Island Column
Colin Tully |
Autom. Softw. Eng. | 1 |
| 1993 | Editorial
Colin Tully |
Inf. Softw. Technol. | 1 |
| 1992 | Trends in Computer-Based Systems EngineeringabstractIt is argued that problems in the development of large computer-based systems indicate that a new discipline is needed at the systems engineering level. Designing systems with distributed processing and databases requires analysis of critical end-to-end processing flows to determine feasibility and proper allocation. An expanded skills base would be required to perform either systems, software, or hardware engineers to perform the necessary tradeoff studies. This paper informs managers, engineers, educators, and researchers about the need for computer-based systems engineering and the strategic opportunities this discipline provides for systems engineering improvement.> Stephanie White, Mack W. Alford, Brian McCay, David Oliver, Colin Tully, Julian Holtzman, C. Stephen Kuehl, David Owens 0004, Allan Willey |
ICCD | 5 |
| 1991 | Non-Technological Issues in Software Engineering
Marc I. Kellner, Bill Curtis, Tom DeMarco, Kouichi Kishida, Maurice Schlumberger, Colin Tully |
ICSE | 6 |
| 1991 | A Failure of Management Nerve and Vision
Colin Tully |
ICSE | 1 |
| 1987 | Prospects for Future Environments: Introduction to Panel Session
Colin Tully |
ICSE | 1 |
| 1985 | Information, Human Activity and the Nature of Relevant TheoriesabstractThis paper discusses the need for a sound and effective theory about information and human activity, to underpin research, teaching and practice in information systems. It tries to undertake a preliminary clearing of the present conceptual jungle. Definitions are offered of some formal concepts; contributory areas of theory are identified; and the dimensions of the required theory are suggested. Colin Tully |
Comput. J. | 1 |