I have retitled the Fall 2008 blog to Fall 2009 ... if you are still following posts from last year, you might want to un-follow to avoid notification of stuff you don't care about.
First lecture is today, with a course overview and team assignment questionnaire.
Wednesday, September 30, 2009
Saturday, December 13, 2008
Final exam grading notes
I've just finished a pass through all the final exams. Overall, I'm pleased.
I expected the first question to be pretty easy. You can't put everyone on the same floor (within the 30 meter "asymptote" mentioned by Herbsleb), but you can try to arrange offices to make the most critical interactions as frequent as possible, and you can do some other things to create opportunities for interaction. The cafeteria on the first floor was a big hint, and many of you took it. One of the interesting ideas (which I didn't think of, but more than one of you did) was having staggered lunch times to try to create specific groupings of people (either within a team, or across teams) to talk. Another idea was having big meetings in the main conference room just before lunch. A couple of you also had some good specific ideas about how to encourage people to move from floor to floor, e.g., by having different snack foods or other facilities available on each floor. There were also good ideas about using the smaller conference rooms on each floor in ways that encourage informal meetings, such as giving each team a space in a conference room in which they could keep up material on walls and whiteboards. Some of you also mentioned that, since the time in which the evidence Herbsleb relies on was gathered, "virtual" interactions like IM have become better and more widely used. I liked these ideas that were specific to the circumstances of this company (number of teams and employees, facilities on each floor) and creative in the ways you addressed the problems we have discussed.
The second question drew directly from some in-class discussions, and a lot of you did recall and adapt that, with discussions of root-cause analysis and adjusting the process to avoid certain classes of errors as well as detecting them more effectively. Some of the answers discussed looking at the history to assess maintenance of old code, but didn't really address how to use the information for new systems. A lot did address using it for new systems, but were pretty light on discussing how ... which shouldn't surprise me, because we didn't talk much about how error reports are triaged and classified to make that possible. Several answers underestimated the difficulty of searching for relevant bug reports (similar symptoms don't necessarily indicate similar causes), but I didn't hold that against you.
I expected the third question to be the hardest, and I think it was. Some of the answers were pretty generic and didn't address the peculiar challenges and opportunities in this specific problem (final hardware available only late in development, and a brand new user interface which will depend on the functionality of that hardware). I dropped a big hint in saying that the functionality was already available, but in a larger form factor, and a few (but not many) of you took advantage of that in the way I was hinting at: We can work with full functioning prototypes that just don't fit in a watch. Maybe we can hang part of the hardware on a user's belt, maybe we need someone running along beside the user carrying some of the hardware, but we can do some pretty good usability testing using the hardware that is available early. While this specific approach was not mentioned much, there were other pretty reasonable tactics, like building the software with a bare minimum of functionality and based on a bar minimum (and hopefully stable) specification of what the hardware could deliver.
An interesting note on that last question is that many answers either suggested or assumed that it had a much larger than usual development team (often the whole software division), and one made a (pretty good) argument that it should be done by a smaller than usual team.
I expected the first question to be pretty easy. You can't put everyone on the same floor (within the 30 meter "asymptote" mentioned by Herbsleb), but you can try to arrange offices to make the most critical interactions as frequent as possible, and you can do some other things to create opportunities for interaction. The cafeteria on the first floor was a big hint, and many of you took it. One of the interesting ideas (which I didn't think of, but more than one of you did) was having staggered lunch times to try to create specific groupings of people (either within a team, or across teams) to talk. Another idea was having big meetings in the main conference room just before lunch. A couple of you also had some good specific ideas about how to encourage people to move from floor to floor, e.g., by having different snack foods or other facilities available on each floor. There were also good ideas about using the smaller conference rooms on each floor in ways that encourage informal meetings, such as giving each team a space in a conference room in which they could keep up material on walls and whiteboards. Some of you also mentioned that, since the time in which the evidence Herbsleb relies on was gathered, "virtual" interactions like IM have become better and more widely used. I liked these ideas that were specific to the circumstances of this company (number of teams and employees, facilities on each floor) and creative in the ways you addressed the problems we have discussed.
The second question drew directly from some in-class discussions, and a lot of you did recall and adapt that, with discussions of root-cause analysis and adjusting the process to avoid certain classes of errors as well as detecting them more effectively. Some of the answers discussed looking at the history to assess maintenance of old code, but didn't really address how to use the information for new systems. A lot did address using it for new systems, but were pretty light on discussing how ... which shouldn't surprise me, because we didn't talk much about how error reports are triaged and classified to make that possible. Several answers underestimated the difficulty of searching for relevant bug reports (similar symptoms don't necessarily indicate similar causes), but I didn't hold that against you.
I expected the third question to be the hardest, and I think it was. Some of the answers were pretty generic and didn't address the peculiar challenges and opportunities in this specific problem (final hardware available only late in development, and a brand new user interface which will depend on the functionality of that hardware). I dropped a big hint in saying that the functionality was already available, but in a larger form factor, and a few (but not many) of you took advantage of that in the way I was hinting at: We can work with full functioning prototypes that just don't fit in a watch. Maybe we can hang part of the hardware on a user's belt, maybe we need someone running along beside the user carrying some of the hardware, but we can do some pretty good usability testing using the hardware that is available early. While this specific approach was not mentioned much, there were other pretty reasonable tactics, like building the software with a bare minimum of functionality and based on a bar minimum (and hopefully stable) specification of what the hardware could deliver.
An interesting note on that last question is that many answers either suggested or assumed that it had a much larger than usual development team (often the whole software division), and one made a (pretty good) argument that it should be done by a smaller than usual team.
Friday, December 5, 2008
Final exam: 10:15 Tuesday
Our final exam is schedule from 10:15 Tuesday until noon. It will be in our regular classroom.
You can expect something roughly like the midterm in terms of approach. Instead of one question, expect 3-5 somewhat shorter questions (with shorter answers). Material that may be covered includes the two papers we read, plus anything we discussed in class.
You can bring any kind of reference material you want to the exam --- books, notes, whatever, in printed or electronic form. The only thing off limits is web searches.
You may take the exam entirely on paper (bring some paper to write on, and something to write with), or you may type your answer on a laptop computer.
If you use a computer, I prefer a plain text file. (If it is significantly faster for you to use a word processor, go ahead, but produce a PDF for me as well as the original word processor file.) The name of the file you produce should be your family name followed by the class number. For example, if I were taking the exam, I would turn in a file called "YoungCIS422.txt".
I will try to remember to bring one or more USB keys to gather electronic copies of exams. In case I forget, it wouldn't be a bad idea if you had one handy too.
You can expect something roughly like the midterm in terms of approach. Instead of one question, expect 3-5 somewhat shorter questions (with shorter answers). Material that may be covered includes the two papers we read, plus anything we discussed in class.
You can bring any kind of reference material you want to the exam --- books, notes, whatever, in printed or electronic form. The only thing off limits is web searches.
You may take the exam entirely on paper (bring some paper to write on, and something to write with), or you may type your answer on a laptop computer.
If you use a computer, I prefer a plain text file. (If it is significantly faster for you to use a word processor, go ahead, but produce a PDF for me as well as the original word processor file.) The name of the file you produce should be your family name followed by the class number. For example, if I were taking the exam, I would turn in a file called "YoungCIS422.txt".
I will try to remember to bring one or more USB keys to gather electronic copies of exams. In case I forget, it wouldn't be a bad idea if you had one handy too.
Monday, December 1, 2008
Rehearse/discuss Monday, present Wednesday, in Deschutes
Reminder: We decided to use today (Monday) to prepare presentations, and we will fit all of our presentations into Wednesday ... it will be a little tight, but nice to have them all together. We will meet both days in the colloquium room on the second floor of Deschutes hall.
Tuesday, November 25, 2008
OSB data in simple text format
I merged and tweaked a couple of example programs from the open source "shapelib" project for reading ESRI shape files, and Anthony ran the program over the OSB data to produce the text file in
http://www.cs.uoregon.edu/classes/08F/cis422/data/OSBShpExtract.txt
This is not in xml, but it's a very simple format that can be parsed with either a scripting language like Python, Perl, or Awk, or with Java's "tokenize" method --- each line can be identified by the first token on the line, and the important fields (x and y coordinates of points, in particular) are separated by blanks.
Of course no one is obligated to do anything with this data at such a late date, but there it is if you want to take a shot at it. Later (probably during holiday break) I'll see about making a version of the extractor program that produces XML in a form close enough to the campus map XML input files to "fool" the data readers you have produced.
http://www.cs.uoregon.edu/classes/08F/cis422/data/OSBShpExtract.txt
This is not in xml, but it's a very simple format that can be parsed with either a scripting language like Python, Perl, or Awk, or with Java's "tokenize" method --- each line can be identified by the first token on the line, and the important fields (x and y coordinates of points, in particular) are separated by blanks.
Of course no one is obligated to do anything with this data at such a late date, but there it is if you want to take a shot at it. Later (probably during holiday break) I'll see about making a version of the extractor program that produces XML in a form close enough to the campus map XML input files to "fool" the data readers you have produced.
Monday, November 24, 2008
This week: No lecture, meet in Deschutes room 100
Just a reminder: This week we will not have lectures. I suggest you use our scheduled lecture time for a group "code party" in room 100 Deschutes, integrating and trouble-shooting and filling in anything that still needs doing. I'll be there.
Friday, November 21, 2008
Data, again
Many thanks to Daniel, who apparently knows the magical incantations necessary to transform ESRI shapefile data into XML files. If you look in
http://www.cs.uoregon.edu/classes/08F/cis422/data/OSBxml/
you will find the full collection as osb_gis_xml.tar.zip or you can look in the osb_gis_xml directory to get individual xml files.
It's very late, and I understand if you are not able to incorporate this into your project before the deadline. On the other hand, it would be great if at least some of you could do so, or at least give it a try and document what problems need to be solved to make it work.
Update: I've looked through the XML data and I'm not so sure we're making progress. As near as I can tell, what we have is "PolygonB" objects that are represented as byte arrays (and I don't know how to interpret those byte arrays). It seems that "PolygonN" objects have a field called "Rings", which are arrays of (x,y) coordinate pairs, and that's what we were expecting. I don't know how to turn "PolygonB" objects into "PolygonN" objects. Maybe someone does?
http://www.cs.uoregon.edu/classes/08F/cis422/data/OSBxml/
you will find the full collection as osb_gis_xml.tar.zip or you can look in the osb_gis_xml directory to get individual xml files.
It's very late, and I understand if you are not able to incorporate this into your project before the deadline. On the other hand, it would be great if at least some of you could do so, or at least give it a try and document what problems need to be solved to make it work.
Update: I've looked through the XML data and I'm not so sure we're making progress. As near as I can tell, what we have is "PolygonB" objects that are represented as byte arrays (and I don't know how to interpret those byte arrays). It seems that "PolygonN" objects have a field called "Rings", which are arrays of (x,y) coordinate pairs, and that's what we were expecting. I don't know how to turn "PolygonB" objects into "PolygonN" objects. Maybe someone does?
Subscribe to:
Posts (Atom)
