-
Notifications
You must be signed in to change notification settings - Fork 0
/
2003.html
280 lines (236 loc) · 13.1 KB
/
2003.html
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
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
<!-- This document was automatically generated with bibtex2html 1.96
(see http://www.lri.fr/~filliatr/bibtex2html/),
with the following command:
bibtex2html -dl -nodoc -nobibsource -nokeys -nokeywords -nofooter 2003.bib -->
<p><a name="csdl2-01-02"></a>
Philip M. Johnson, Mette L. Moffett, and Brian T. Pentland.
Lessons learned from VCommerce: A virtual environment for
interdisciplinary learning about software entrepreneurship.
<em>Communications of the ACM</em>, 46(12), December 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2001/01-02/01-02.pdf">.pdf</a> ]
<blockquote><font size="-1">
The Virtual Commerce (VCommerce) simulation environment provides
a framework within which students can develop internet-based
businesses. Unlike most entrepreneurship simulation games, the objective
of VCommerce is not to maximize profits. The environment, which is
designed for use in interdisciplinary classroom settings, provides an
opportunity for students with different backgrounds to build (virtual)
businesses together. Elements of VCommerce, such as its open-ended
business model and product; significant technical depth; external
players; and severe time constraints combine to create a surprisingly
realistic and effective learning experience for students in both computer science and management. This article overviews the VCommerce environment and
our lessons learned from using it at both the University of Hawaii and
Michigan State University.
</font></blockquote>
<p>
</p>
<p><a name="csdl2-02-07"></a>
Philip M. Johnson, Hongbing Kou, Joy M. Agustin, Christopher Chan, Carleton A.
Moore, Jitender Miglani, Shenyan Zhen, and William E. Doane.
Beyond the personal software process: Metrics collection and analysis
for the differently disciplined.
In <em>Proceedings of the 2003 International Conference on Software
Engineering</em>, Portland, Oregon, May 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2002/02-07/02-07.pdf">.pdf</a> ]
<blockquote><font size="-1">
Pedagogies such as the Personal Software Process (PSP)
shift metrics definition, collection, and analysis from
the organizational level to the individual level. While
case study research indicates that the PSP can provide
software engineering students with empirical support for
improving estimation and quality assurance, there is
little evidence that many students continue to use the PSP
when no longer required to do so. Our research suggests
that this “PSP adoption problem” may be due to two
problems: the high overhead of PSP-style metrics
collection and analysis, and the requirement that PSP
users “context switch” between product development and
process recording. This paper overviews our initial PSP
experiences, our first attempt to solve the PSP adoption
problem with the LEAP system, and our current approach
called Hackystat. This approach fully automates both data
collection and analysis, which eliminates overhead and
context switching. However, Hackystat changes the kind of
metrics data that is collected, and introduces new
privacy-related adoption issues of its own.
</font></blockquote>
<p>
</p>
<p><a name="csdl2-02-06"></a>
Joy M. Agustin.
Improving software quality through extreme coverage with JBlanket.
M.S. Thesis CSDL-02-06, Department of Information and Computer
Sciences, University of Hawaii, Honolulu, Hawaii 96822, May 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2002/02-06/02-06.pdf">.pdf</a> ]
<blockquote><font size="-1">
Unit testing is an important part of software testing that aids in the
discovery of bugs sooner in the software development process. Extreme
Programming (XP), and its Test First Design technique, relies so heavily upon
unit tests that the first code implemented is made up entirely of
test cases. Furthermore, XP considers a feature to be completely coded
only when all of its test cases pass. However, passing all test cases does
not necessarily mean the test cases are good.
<p>
Extreme Coverage (XC) is a new approach that helps to assess and improve the
quality of software by enhancing unit testing. It extends the XP requirement
that all test cases must pass with the requirement that all defect-prone
testable methods must be invoked by the tests. Furthermore, a set of flexible
rules are applied to XC to make it as attractive and light-weight as unit
testing is in XP. One example rule is to exclude all methods containing one
line of code from analysis. I designed and implemented a new tool, called
JBlanket, that automates the XC measurement process similar to the way that
JUnit automates unit testing. JBlanket produces HTML reports similar to JUnit
reports which inform the user about which methods need to be tested next.
<p>
In this research, I explore the feasibility of JBlanket, the amount of effort
needed to reach and maintain XC, and the impact that knowledge of XC has on
system implementation through deployment and evaluation in an academic
environment. Results show that most students find JBlanket to be a useful tool
in developing their test cases, and that knowledge of XC did influence the
manner in which students implemented their systems. However, more studies are
needed to conclude precisely how much effort is needed to reach and maintain
XC.
<p>
This research lays the foundation for future research directions. One
direction involves increasing its flexibility and value by expanding and
refining the rules of XC. Another direction involves tracking XC behavior to
find out when it is and is not applicable.
</font></blockquote>
<p>
</p>
<p><a name="csdl2-03-03"></a>
Aaron Kagawa.
The design, implementation, and evaluation of CLEW: An improved
collegiate department website.
B.S. Thesis CSDL-03-03, Department of Information and Computer
Sciences, University of Hawaii, Honolulu, Hawaii 96822, May 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2003/03-03/03-03.pdf">.pdf</a> ]
<blockquote><font size="-1">
The purpose of a collegiate department website is to provide prospective
students, current students, faculty, staff, and other academic and industry
professionals with information concerning the department. The information
presented on the website should give the user an accurate model of the
department, even as it changes overtime. Some of these changes include:
adding new faculty members, new students, new courses, etc. The more
accurately the website models the department, the more aware the website's
users will be of the department.
Traditional collegiate department websites have two primary problems in
creating an accurate model of their department. First, only a few people,
usually the department webmasters, can add information to the website.
Second, it is difficult to enable website users to be informed of changes
to the website that might be of interest to them. These two problems
decrease the accuracy of the model and hamper its effectiveness in alerting
users of changes to the website. As a result, user awareness of the
department is also decreased.
The Collaborative Educational Website (CLEW) is a Java web application
intended to support accurate modeling of a collegiate department. CLEW is
designed to solve the traditional collegiate department website's two main
problems. First, it provides interactive services which will allow users
to add various kinds of information to the website. Secondly, CLEW
addresses the notification problem by providing tailored email
notifications of changes to the website.
CLEW was developed by a Software Engineering class in the Information and
Computer Science Department at the University of Hawaii at Manoa.
My role in this development as project leader is to design and
implement the framework for the system. CLEW currently contains
approximately 28,000 lines of Java code and it contains upwards of
500 web pages. In the Spring 2003 semester, CLEW replaced the
existing Information and Computer Science Department website. I
evaluated CLEW to measure its effectiveness as a model of the
department using a pre and post release questionnaire. I also
evaluated usage data of the CLEW System to assess the functionality
provided by CLEW.
If CLEW provides a more accurate model of a collegiate department,
then the next step is to provide the CLEW framework to other
collegiate departments worldwide. It is my hope that the users' of
CLEW will get a clue about their department!
</font></blockquote>
<p>
</p>
<p><a name="csdl2-03-06"></a>
Philip M. Johnson.
Hackystat metric collection and analysis for the MDS harvest CM
system: A design specification.
Technical Report CSDL-03-06, Department of Information and Computer
Sciences, University of Hawaii, Honolulu, Hawaii 96822, August 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2003/03-06/03-06.html">.html</a> ]
<blockquote><font size="-1">
This proposal describes the requirements and top-level design for a Hackystat-based system that automatically monitors and analyzes the MDS development process using data collected from the Harvest CM system.
</font></blockquote>
<p>
</p>
<p><a name="csdl2-03-07"></a>
Philip M. Johnson.
The Hackystat-JPL configuration: Overview and initial results.
Technical Report CSDL-03-07, Department of Information and Computer
Sciences, University of Hawaii, Honolulu, Hawaii 96822, October 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2003/03-07/03-07.html">.html</a> ]
<blockquote><font size="-1">
This report presents selected initial results from Hackystat-based
descriptive analyses
of Harvest workflow data gathered from the Mission Data System software
development project from January, 2003 to August, 2003. We present the
motivation for this work, the methods used, examples of the analyses, and
questions raised by the results. Our major findings include: (a) workflow
transitions not documented in the "official" process; (b) significant
numbers of packages with unexpected transition
sequences; (c) cyclical levels of development "intensity" as
represented by levels of promotion/demotion; (d) a possible approach to
calculating the proportion of "new" scheduled work versus rework/unscheduled work
along with baseline values; and
(e) a possible approach to calculating the distribution of package "ages" and days spent in the
various workflow states, along with potential issues with the representation of
"package age" based upon the current approach to package
promotion.
The report illustrates how our current approach to analysis can yield
descriptive perspectives on the MDS development process. It provides a first
step toward more prescriptive, analytic models of the MDS software development
process by providing insights into the potential uses and limitations of MDS
product and process data.
</font></blockquote>
<p>
</p>
<p><a name="csdl2-03-09"></a>
Philip M. Johnson.
The review game: Teaching asynchronous distributed software review
using eclipse.
Technical Report CSDL-03-09, Department of Information and Computer
Sciences, University of Hawaii, Honolulu, Hawaii 96822, November 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2003/03-09/03-09.html">.html</a> ]
<blockquote><font size="-1">
Presents an approach to teaching software review involving an Eclipse plug-in called Jupiter and automated metrics collection and analysis using Hackystat.
</font></blockquote>
<p>
</p>
<p><a name="csdl2-03-11"></a>
Takuya Yamashita.
Jupiter users guide.
Technical Report CSDL-03-11, Department of Information and Computer
Sciences, University of Hawaii, Honolulu, Hawaii 96822, December 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2003/03-11/03-11.html">.html</a> ]
<blockquote><font size="-1">
Provides a users guide for the Jupiter code review plug-in for Eclipse.
</font></blockquote>
<p>
</p>
<p><a name="csdl2-03-13"></a>
Philip M. Johnson.
Results from the 2003 classroom evaluation of Hackystat-UH.
Technical Report CSDL-03-13, Department of Information and Computer
Sciences, University of Hawaii, Honolulu, Hawaii 96822, December 2003.
[ <a href="http://csdl.ics.hawaii.edu/techreports/2003/03-13/03-13.html">.html</a> ]
<blockquote><font size="-1">
This report presents the results from a qualitative evaluation of ICS 413
and ICS 613 students at the end of Fall, 2003. The students had used
Hackystat-UH for approximately six weeks at the time of the evaluation. The survey requests their
feedback regarding the installation, configuration, overhead of use,
usability, utility, and future use of the Hackystat-UH
configuration. Results provide evidence that: (1) Significant problems
occur during installation and configuration of the system; (2) the
Hackystat-UH configuration incurs very low overhead after completing
installation and configuration; (3) Analyses were generally found to be
somewhat useful and usable; and (4) feasibility in a professional
development context requires addressing privacy and platform issues.
</font></blockquote>
<p>
</p>