Old News: CIS 422/522, Software MethodologyFall 2006
|
This week is for presentations — two on Tuesday, two on Thursday. We will meet in the colloquium room in Deschutes. There is a possibility we will be snowed out Tuesday, in which case we will fit all four presentations on Thursday.
This is an open presentation. I hope you will invite friends to see what you have done and cheer you on.
I propose the following presentation schedule:
If this schedule does not suit you, let me know. The condition for changing is that the group you want to switch with must also be willing.
Although we have time for more, a typical presentation is 15-20 minutes. This should not be off-the-cuff. You should plan for it and give a well-organized presentation. Typically this will include slides and a live demonstration, although you have some flexibility (e.g., in some situations screen shots work better than live demonstration). Be sure to test your laptop with the projection equipment in the colloquium room. If you borrow a laptop for the presentation, test your slides and demo on it. If you want use my laptop (an older Apple TiBook), that's fine, but I'll need some advance notice so I can give you a login and lend it to you.
It is difficult to coordinate presentation by many individuals (sometimes called a &lquo;tag team&rquo; presentation), but it can also be difficult for one presenter to adequately describe different facets of a project. A typical end-of-term presentation has two or three presenters.
Your presentation should include (yes, yet again) a basic overview of what your project is, who its intended users are, and why your users would choose your product. Imagine, if you like, that you have used your first round funding to build a working prototype, and are now making a pitch for second round VC funding. (Or imagine something else if you like ... maybe you're convincing your boss to let you keep working on an open source project, or maybe you're reporting on your project at a developer conference ... either way you need to start from the beginning with your objectives and rationale.)
The most fun part, for you and for your audience, is usually the live demo. It takes careful planning to show off your product in a short time. Be sure to show what is cool and novel about your product, as well as what is useful. It's ok to also show some features that are not inherently interesting to the end user, but which were significant technical challenges. Spend enough time showing off the product to be convincing and interesting, but don't let it drag on and on. Especially be sure that the audience doesn't have to sit through a long, boring configuration and setup session at the beginning. Do allow some time for questions during the actual demonstration, as well as at the end.
In addition to the features of your product, tell us something about the way your team tackled it. What significant technical decisions did you make? What significant non-technical decisions did you make? What went as planned, and what surprised you? What would you do the same if you were starting over, and what would you do differently?
Also say a few words about future trajectory for your project. Are there extensions and enhancements that someone else might want to make? Are there things you plan or might like to do with it? And are there lessons from this project that you will apply in future software projects?
We will meet in room 100 Deschutes on Tuesday. There is no lecture; I figure you wouldn't be listening this close to deadline anyway. It's just a last minute hack-fest (and I include text-hacking in that). If you're all done with the project, you might drop by anyway to get a cup of coffee and cheer on your classmates.
I am back from my conference and in catch-up mode. I understand Yannis Smaragdakis lectured on design patterns last Tuesday, and it sounds like it went well. The lecture schedule for Tuesday the 14th says I will covering user documentation. I may do some of that, though we did talk about it a little early in the term, and will probably add a lecture on performance engineering --- after presentations by each team on their projects.
You should be able to give a pretty solid presentation on progress and status of your projects by now. Hopefully you all have working prototypes and are improving them. If you have encountered any unexpected problems, we can discuss them in class or, if you prefer, we can set up meetings outside of class to discuss them. (For technical problems, I prefer to at least start in class, but for some coordination and inter-personal problems an out-of-class meeting may be more appropriate.)
Readings for this week are now linked from the course schedule page. I have selected three chapters from a forthcoming book. The total length of the reading is a little more than we have most weeks, but it is in “textbook” style, less dense than research papers, so I think it shouldn't be too heavy.
This is a small excerpt from a 500+ page manuscript. I will happily make the whole thing available to anyone interested in reading it, provided you do not distribute it further without permission.
Spot a problem or confusion in the chapters? Suggestions and bug reports are very welcome.
There are just three questions. Each of your answers should be no more than 100 words. Shorter is often better. Write clearly to demonstrate that you have thought clearly.
Large projects are often broken into incremental delivery phases. For example, if we were developing an information management system for public schools over a two-year period, we might develop and deliver core features used only by teachers and administrators in the first year, and in the second year add the web-based interface for students and parents, as well as additional features for teachers. A key constraint in such a project plan is that each incremental delivery is a fully usable product in its own right. To what extent is this compatible with the spiral development model? Do you see any tensions or conflicts between incremental delivery and the spiral approach to incremental development?
You have been asked to develop the control system for an espresso machine. Part of this software involves maintaining proper conditions in the boiler chamber. The boiler chamber is normally filled 1/3 with water, and the rest with steam. There are two sensors in the chamber, one for determining water level, and one for determining pressure. Temperature is determined indirectly, as a function of pressure (because a higher temperature raises the steam pressure). There are two effectors, a heating element (which can be turned on or off) and a water pump (which adds water to the chamber). Water should be added whenever it falls below the minimum level, and the heating element should be turned on whenever the water is above the minimum level and temperature is below the desired temperature.
Jackson uses Venn diagrams to show relations between phenomena in the world, phenomena in the machine, and interfaces. Without drawing a diagram, describe the relationships among water level, steam pressure, and variables in the control software, including which entities are in the world, the machine, and the interface.
Your company, with branches in Milan and Eugene, is developing an on-board GPS navigation system for Alpha Romeo automobiles. Experts in mapping and route-finding are concentrated in the Eugene branch, while experts in GPS device interfaces and automobile interfaces are concentrated in the Milan branch of your organization. The Eugene and Milan branches have not worked together on the same project before.
Your organization uses the spiral development model. What are some things you might do in early "turns" of the spiral, given the special challenges of developing with this internationally distributed team.
(Don't just repeat Herbsleb's recommendations. You need to understand both papers to answer this question.)
The project is due Wednesday at 5pm. Here's how to turn it in:
Here's how grading sessions work:
You set up an appointment with Daya and me. (An appointment with Daya alone is possible, but I prefer if we are both there.) It is not necessary for your whole team to be there, although you may prefer that. I'll give Daya my available times and let him handle the schedule negotiations.
We try to keep these meetings to to half an hour, and if everything goes smoothly we could be done in 10 or 15 minutes.In the ideal scenario, you watch Daya read part of your user documentation, install your product, and use it. Then you watch him read some technical documentation and try to figure out how to make a minor change to your system, which involves finding the right source code to read and reading it. Everybody is happy, you go home having done no work whatsoever.
In the not quite so ideal (but more common) scenario, Daya has to ask you a couple questions where things aren't completely clear. Maybe not everything works absolutely smoothly the first time. This goes ever so much more smoothly if you are there to answer questions and trouble-shoot any little glitches.
Daya will take notes during the grading session, but I will do the actual scoring later, based on those notes together with other judgments that are more efficient to make off-line. I do try to complete the project grading within a few days of the grading session, so that the experience is still fresh.
Tuesday class: This is a fairly free-form discussion of teams and projects for the second half of the term. I know you are probably fairly focused on project 1 right now, but try to spend some time thinking about project 2 and come ready to discuss your ideas. Getting a good head start on project 2 is very helpful.
Tuesday in class we will begin with brief presentations from each group on how they have scoped out the project. Things to describe include:
Please try to keep the presentation within 7 minutes (you may have to be selective about what you cover and what you don't), and I'll allocate 10 minutes total for each presentation plus questions directed to individual groups. I'll also plan some time for a more general discussion in the whole class, for up to an hour total. (This means I may not have time for a real lecture, again, so let me know if there is something about the readings that you would like me to be sure to cover in class.)
We've been scooped — see Google Transit. This was not available before class Tuesday. It was available later in the same day, though! Thanks to Asia for finding it.
So what can we do? Even though Google Transit doesn't have all the features we might have built, it addresses the basic problem at least for one-time trips. It seems very unlikely that we can produce something “better enough” to be attractive to many users, or to LTD. I think we need to ditch it and find something else.
What to do? Here are two proposals we can talk about. I'll also entertain other ideas, but we really need to make a decision Thursday so you can get a start.
JUnit is a widely used test harness. Most JUnit test cases are written by hand. Some are generated, but as far as I can tell even tools that generate JUnit test cases do so from descriptions of individual test cases. There are, on the other hand, several tools for automatically generating combinations of parameter values. Typically they generate a set of n-tuples that cover all the pairwise combinations of parameter values. However, they are either wired into a development environment (e.g., Eclipse) or they just generate combinations in some kind of tabular form, and translating them into actual test cases is a separate (and sometimes manual) step.
The basic idea is to bridge the gap, so that one can use a combinatorial test generation tool to generate a JUnit test suite. You may want to use an off-the-shelf combinatorial test generator (some tools are listed at http://www.pairwise.org/tools.asp), or you might decide to build a simple one on your own. Even if you build your own, the interface between generating the combinations and generating JUnit code should be narrow and clean enough to make it reasonably straightforward to integrate with a different combination generator. The more challenging part, probably, is designing the input language for specifying not only what the parameters and possible values are, but also how a JUnit test case is generated to match a particular combination.
Chandler is an open source “interpersonal information manager” currently in development. The vision is for something that does everything Microsoft Outlook does, plus make better coffee, but for now there is just a bare-bones calendar that the developers call “dogfoodable”, meaning it should be used primarily by the developers themselves to get a better idea of what seems to work well and what is broken, fragile, or annoying. Eventually Chandler should have a host of import/output filters, or conduits, for various formats, but currently it has few. I think it might be interesting to build a few. For example, if you use some kind of scheduling tool (like Microsoft Project, ugh) or to-do list manager (like that in Palm desktop, or Omni Outliner), it would be nice (?) to export a to-do list with dates or durations into a Chandler calendar.
Last edit: Thu, 6 October, 2005 / Version identifier: $Id: oldnews.html,v 1.6 2006/12/04 23:04:00 michal Exp $