Reflective Software Engineering

Project 6 Feedback

Last modified: Tue Sep 14 09:50:19 HST 1999

The P6 programs are definitely improved over the P5 programs. Only one that I have seen so far actually addresses the inefficient screen real estate problem in its entirety. The P7 assignment will hopefully nudge the rest of you toward a good solution to this problem.

  1. Several people clearly need to spend more time doing research on GUI construction. I sent out pointers last time, and recommended you visit the bookstore. Most of you could benefit from another 3-5 hours of research on GUI design and construction. You have even more experience now and will benefit even more from the time spent. One student even sent me an email asking for help with their GUI, and before helping him, I asked the student to tell me which resources they'd looked at so I could make my help appropriate. Well, it turned out that the student hadn't looked at any resources at all! And when the student did, they found the answer to their question in about an hour.

  2. Few people understand the GQM fields at this point. The goal of the GQM fields are to document the rationale behind the collection of all of your data. Several people have turned in assignments where the GQM information concerns only GUI design. While this is a laudable goal, if this is the only goal, then there's no reason to collect size data! So, your GQM fields should justify all of the Leap data you are collecting, as well any additional goals you are working on for that specific project. (BTW, you can't simply stop collecting size data because it's not a goal! The point is that now, unlike earlier in the semester, you are now responsible for explicitly documenting the reason you are collecting size, time, and defect data.)

  3. Many people have been doing a poor job of collecting defect data. Recall that you are supposed to be collecting and recording the most important 2-3 defects per phase, and so there should be at least 8-10 defects recorded per project. This may take a little reflection, but the effort will provide you with lots of good insight. Note that you should always fill in the description field with at least a rough outline of the problem.

  4. Several people are still not using the "Error" field for total time estimates very well---filling in a small number like "20" (indicating they believe the estimate would be accurate to within 20 minutes) when their prior data indicates that a better number would be something like 200 minutes. I want to some thought put into this field on the next couple of projects so that you can come out of this class with the ability to provide a high quality range of values when you start estimating as part of your professional activities.

  5. In going over the estimation results with people, I have found cases where people may need to start filtering out some old projects that appear to be outliers, or to stop simply "splitting the difference" between a couple of estimates. In other words, I am finding that if people had interpreted their prior data differently, they could have estimated their current project more accurately. Of course, this is what's known as "20-20 hindsight", but the point is that you should always be reflecting upon how your estimates turned out and thinking about ways to do a better job next time.

  6. Although I thought this should go without saying, I have decided it might be good to say it: I am expecting each of you to be striving toward the implementation of a professional GUI interface to this system. Several people have turned in GUIs with elements that are quite clearly amateurish and, well, lame. Of course, I understand that there is a learning curve involved here, but I want you all to understand that your final system should exhibit a professional look and feel that demonstrates that you are capable to doing professional-level development.

    It is also very clear to me that all of you know what I'm talking about when I say a "professional look and feel". During the interviews, I have repeatedly asked people, "Would you expect to see this kind of interface problem in software that you paid money for?" In every case, the person admitted that they could see there was a problem. The only thing you need to do is shift your perspective from "student who just wants to turn something in that runs" to "developer who wants to demonstrate they can develop a professional application." I know that every one of you has the ability to get there, and the rewards will be great from the effort.


Philip Johnson