-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path1997.bib
200 lines (185 loc) · 9.13 KB
/
1997.bib
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
@comment{{This file has been generated by bib2bib 1.96}}
@comment{{Command line: bib2bib -ob 1997.bib -c year=1997 csdl-trs.bib}}
@inproceedings{csdl-96-06,
author = {Philip M. Johnson and Danu Tjahjono},
title = {Assessing software review meetings: A controlled experimental study using {CSRS}},
pages = {{118-127}},
url = {http://csdl.ics.hawaii.edu/techreports/1996/96-06/96-06.pdf},
keywords = {FTR, CSRS, Publications-Conferences},
booktitle = {Proceedings of the 1997 International Conference on Software
Engineering},
year = {1997},
month = {May},
address = {Boston, MA.},
abstract = {Software review is a fundamental component of the software quality
assurance process, yet significant controversies exist concerning
efficiency and effectiveness of various review methods. A central question
surrounds the use of meetings: traditional review practice views them as
essential, while more recent findings question their utility.
We conducted a controlled experimental study to assess several measures of
cost and effectiveness for a meeting and non-meeting-based review method.
The experiment used CSRS, a computer mediated collaborative software review
environment, and 24 three person groups. Some of the data we collected
included: the numbers of defects discovered, the effort required, the
presence of synergy in the meeting-based groups, the occurrence of false
positives in the non-meeting-based groups, and qualitative questionnaire
responses.
This paper presents the motivation for this experiment, its design and
implementation, our empirical findings, conclusions, and future directions. }
}
@techreport{csdl-96-19,
author = {Philip M. Johnson},
title = {{PSP}/{B}aseline: Software Requirements Specification},
institution = {Department of Information and Computer Sciences,
University of Hawaii, Honolulu, Hawaii 96822},
year = {1997},
number = {{CSDL}-96-19},
month = {January},
url = {http://csdl.ics.hawaii.edu/techreports/1996/96-19/96-19.html},
keywords = {Leap},
abstract = {PSP/Baseline is a system design that predated Project LEAP
by about a year. The PSP/Baseline system was intended to
provide an approach to empirical software process
improvement inspired by, but different from, the Personal
Software Process.}
}
@article{csdl-97-02,
keywords = {FTR, CSRS, Publications-Journals},
author = {Adam A. Porter and Philip M. Johnson},
title = {Assessing Software Review Meetings: Results
of a Comparative Analysis of Two Experimental Studies},
journal = {{IEEE} Transactions on Software Engineering},
year = {1997},
volume = {23},
number = {3},
pages = {129-145},
month = {March},
abstract = {Software review is a fundamental tool for software quality assurance.
Nevertheless, there are significant controversies as to the
most efficient and effective review method. One of the most
important questions currently being debated is the utility
of meetings. Although almost all industrial review methods
are centered around the inspection meeting, recent findings
call their value into question. In prior research the authors
of this paper separately and independently conducted controlled
experimental studies to explore this issue.
This paper presents new research to understand the
broader implications of these two studies. To do this,
we designed and carried out a process of ``reconciliation''
in which we established a common framework
for the comparison of the two experimental studies,
re-analyzed the experimental data with respect to this
common framework, and compared the results. Through
this process we found many striking similarities between
the results of the two studies, strengthening their
individual conclusions. It also revealed interesting
differences between the two experiments, suggesting
important avenues for future research.}
}
@techreport{csdl-97-05,
keywords = {CSDL},
number = {{CSDL}-97-05},
author = {Philip M. Johnson},
title = {An Annotated Overview of {CSDL} Software Engineering},
url = {http://csdl.ics.hawaii.edu/techreports/1997/97-05/97-05.html},
institution = {Department of Information and Computer Sciences,
University of Hawaii, Honolulu, Hawaii 96822},
year = {1997},
month = {November},
abstract = {Current software engineering activities in CSDL can be viewed as consisting
of two basic components: product engineering and process
engineering. Product engineering refers to the various work products
created during development. Process engineering refers to the various
measurements and analyses performed on the development process. This
document describes activities within
CSDL over the past five years to better
understand and improve our process and product engineering within our
academic research development environment.}
}
@techreport{csdl-97-06,
number = {{CSDL}-97-06},
keywords = {Leap},
author = {Philip M. Johnson},
title = {{LEAP} Initial Toolset: Software Requirements Specification},
url = {http://csdl.ics.hawaii.edu/techreports/1997/97-06/97-06.html},
institution = {Department of Information and Computer Sciences,
University of Hawaii, Honolulu, Hawaii 96822},
year = {1997},
month = {October},
abstract = {
This SRS for the LEAP Toolset is based heavily upon the ideas specified in
the PSP/Baseline SRS.
Conceptually, the LEAP toolset is a variant of the PSP/Baseline toolset in
two major ways. First,
the LEAP toolset is substantially more simple to implement and use. It
will serve as a prototype for proof-of-concept evaluation of the ideas in
the PSP/Baseline toolkit. Second,
the LEAP toolset emphasizes group review and minimization of
measurement dysfunction to a greater extent than the PSP/Baseline toolset.}
}
@techreport{csdl-97-08,
number = {{CSDL}-97-08},
author = {Philip M. Johnson},
title = {Project {LEAP}: Lightweight, Empirical, Anti-measurement
dysfunction, and Portable Software Developer Improvement},
institution = {Department of Information and Computer Sciences,
University of Hawaii, Honolulu, Hawaii 96822},
year = {1997},
month = {October},
keywords = {Leap},
url = {http://csdl.ics.hawaii.edu/techreports/1997/97-08/97-08.pdf},
abstract = {Project LEAP investigates the use of lightweight, empirical,
anti-measurement dysfunction, and portable approaches to software developer
improvement. A lightweight method involves a minimum of process
constraints, is relatively easy to learn, is amenable to integration with
existing methods and tools, and requires only minimal management investment
and commitment. An empirical method supports measurements that can lead to
improvements in the software developers skill. Measurement dysfunction
refers to the possibility of measurements being used against the
programmer, so the method must take care to collect and manipulate
measurements in a ``safe'' manner. A portable method is one that can be
applied by the developer across projects, organizations, and companies
during her career.
Project LEAP will investigate the strengths and weaknesses of this approach
to software developer improvement in a number of ways. First, it will
enhance and evaluate a LEAP-compliant toolset and method for defect entry
and analysis. Second, it will use LEAP-compliant tools to explore the
quality of empirical data collected by the Personal Software
Process. Third, it will collect data from industrial evaluation of the
toolkit and method. Fourth, it will create component-based versions of
LEAP-compliant tools for defect and time collection and analysis that can
be integrated with other software development environment
software. Finally, Project LEAP will sponsor a web site providing distance
learning materials to support education of software developers in
empirically guided software process improvement. The web site will also
support distribution and feedback of Project LEAP itself.}
}
@techreport{csdl-98-03,
number = {{CSDL}-98-03},
keywords = {CSDL},
author = {Philip M. Johnson},
title = {A Proposal for {CSDL2}: A Center for Software Development Leadership through Learning},
institution = {Department of Information and Computer Sciences,
University of Hawaii, Honolulu, Hawaii 96822},
year = {1997},
month = {July},
url = {http://csdl.ics.hawaii.edu/techreports/1998/98-03/98-03.html},
abstract = {This document describes the design of CSDL2: a social, physical, and
virtual environment to support the development of world class software
engineering professionals. In CSDL2, a "multi-generational learning
community" of faculty, graduate students, and
undergraduates all collaborate within a structured work environment for
practicing product, process, and organizational engineering.}
}
@comment{{csdl2-08-06,
author = Robert S. Brewer,
title = Literature review on carbon footprint collection and analysis ,
institution = "Department of Information and Computer Sciences,
University of Hawaii, Honolulu, Hawaii 96822",
NUMBER = CSDL-08-06,
KEYWORDS = Sustainability,
MONTH = December,
YEAR = 2008,
URL = http://csdl.ics.hawaii.edu/techreports/2008/08-06/08-06.pdf,
abstract = Obsolete. Please see by Technical Report 09-05.
}}