CS 5150
Software Engineering
Fall 2012

Assignments


Schedule of Quizzes, Reports, and Presentations

Quiz 1

  • Monday, September 17 at 7:30 p.m.

Report 1, Feasibility Study and Plan

  • Report, due Friday, September 21 at 11:00 p.m.

Milestone 2

  • Presentation, Thursday October 11 to Friday October 12
  • Report, due Friday, October 12 at 11:00 p.m.
  • Teammate Feedback, due Friday, October 12 at 11:00 p.m.

Quiz 2

  • Monday, October 22 at 7:30 p.m.

Milestone 3

  • Presentation, Thursday November 8 to Friday November 9
  • Report, due Friday, November 9 at 11:00 p.m.
  • Teammate Feedback, due Friday, November 9 at 11:00 p.m.

Quiz 3

  • Monday, November 19 at 7:30 p.m.

Milestone 4, Demonstration and Handover

  • Presentation and demonstration, Thursday November 29 to Friday Thursday November 30
  • Project delivery, due Friday, December 7 at 11:00 p.m.
    • With permission from your client and course staff, this deadline can be pushed back a few days. Do not ask for this permission at the last minute; it will not be granted in that case.
  • Teammate Feedback, due Friday, December 7 at 11:00 p.m.

Assignments

The reports and presentations are group assignments corresponding to major project milestones. The first assignment is a report. The other three assignments consist of both a presentation and a report or other documentation.

  1. Assignment 1 includes completion of a feasibility study. See below for more information about what to include in a feasibility study.

  2. What you complete for milestone 2 will depend on the process your team is using and the details of your plan. If you are going for a more sequential approach, you should have detailed requirements and design documents. If you are going for a more incremental approach, you should have working prototypes for at least one or two pieces of functionality.

  3. What you complete for milestone 3 will depend on the process your team is using and the details of your plan. Whatever process you are following, you should have at least some working code and the client should have a clear understanding of exactly what the project will do at the end of the semester (diety willing and the creek don't rise).

  4. Assignment 4 consists of a presentation in which you will demonstrate your system in operation followed by the handover of the completed system and documentation to the client.

Presentations

During the semester each team will give three presentations with associated reports on the work completed. You will make a 45 minute presentation to the client, the Instructor and the Teaching Assistant.  Everybody is expected to be a presenter at least once. Since each team has more members than the number of presentations, each presentation will have to be broken up into pieces that are given by different team members. However, it is probably a bad idea to have every team member give a part of every presentation, because it would be too choppy. I recommend having a different two or three team members lead each presentation.

We are going to attempt to do presentation scheduling by public Google spreadsheet. Please let the course staff know if you experience any problems with this system. The first step is to find out who your primary TA is. You can find that information in this Google spreadsheet (which is hopefully read-only to the world): https://docs.google.com/spreadsheet/ccc?key=0AtqPR-AueRXKdDVfRnVJcUZicVZBanNHRlI2STBaekE. The first sheet has the mapping between student names and group IDs and the second sheet has the mapping between group ID and primary TA.

The next step is to choose a time and sign up your team on this Google spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AtqPR-AueRXKdHdqU2g4aTFNbkRLNXgydldxMzlUOUE. You will need to sign up for 3 slots; one for each milestone. Note: The TAs have requested that all of their groups be scheduled on a single day, so please observe which day (Thursday or Friday) is assigned to which TA and sign up during the appropriate day.

It is your responsibility to ensure that the client is available at the time you schedule. The room will be provided with a computer projector with Internet connection.

Before the first presentation, there will be a discussion in class of the goals of the presentations and how to prepare for them.

The presentations will be scored as follows:

  • Content (30%). Does all the following information come across during the presentation?
    • Context. Is there a good, quick summary of what your project is about? (General advice for your professional life: begin every presentation with a very quick (maybe 1 minute) explanation to the audience of what you are going to tell them and why they should care.)
    • Progress. What has the team accomplished? You can go into some technical detail here, if it is appropriate.
    • Planning. Are you ahead of schedule? Behind? Have you adjusted your plan?
    • Issues. Have any unforeseen issues arisen?
  • Organization (20%). Is all the above information presented in an easy-to-digest way? Does the audience need to ask a lot of questions to get at important information? (This is more about the structure of your presentation than its style.)
  • Style (20%). Do the superficials contribute to or detract from the presentation? This isn't about whiz-bang graphics. You need to speak clearly and use visuals appropriately so that they contribute to your message, rather than detract from it. I will try to come up with some good questions during the presentation; do you do a good job of answering them?
  • Client satisfaction (30%). At the end of the presentation, I will ask your client how satisfied they are with your overall management of the project and how clearly you communicated about it in your presentation. If you know anything about your client's preferences it is appropriate to cater to them.

Final Presentation Checklist

Here are the elements we expect to see in the final presentation, in approximate priority order (not presentation order).

  • Demo. If it makes sense to give the client an opportunity to 'drive', that's nice.
  • A comparison of planned and completed work.
  • A plan for the remaining week, if you expect to use it for the project.
  • A description of what software and documentation you plan to hand over to the client.
  • A description of the validation/testing that you have done.
  • The legal arrangement between the team and the client. This should have been settled long ago, but it's useful to double-check that everyone is on the same page.
  • A quick description (a line or two) of each team member's primary role in the project.

Reports

All members of the project team should share in the production of the reports (though if some team members are stronger writers, feel free to spread the work unevenly). When you have completed a report:
  • Deliver it to the client.
  • Send it by email to the Instructor and your group's primary Teaching Assistant
  • Commit it to your teams repository (yes, repositories are not just for code) for future reference.

Feasibility Study and Plan

The exact form of the feasibility study is up to you. The length of the report is likely to be between three and eight pages. It should include the following:

  • The client for whom the work will be done.
  • List of team members and email addresses.
  • A statement of the task to be undertaken. (at most a few paragraphs)
  • A preliminary requirements analysis.
  • Suggested deliverables.
  • Process to be followed. The process is often implied by your plan, but you should commit at least a couple of paragraphs to explaining the reasoning behind your plan (e.g. "we're going to use two iterations because the client was a little fuzzy on exactly which features are required").
  • Project plan, showing principal activities and milestones. The resolution of the plan should be tasks that you expect to take one or a few full person-work days.
  • Visibility plan. How will you keep in contact with the client and report progress?  How will you communicate among your team?
  • Discussion of business considerations (see the Projects page on the Web site). 
  • Risk analysis. What is most likely to go wrong? What is your fallback plan?
  • Probable technical requirements

Here are some example of reports from earlier classes. They are very different in style, but each provides a good example of an effective report. They are placed here with the permission of the student teams.

Reports for Milestones 2 and 3

The report for each milestone should include:

  • Review of progress since the previous milestone
  • Revised schedule and plan for the remainder of the project
  • Preliminary versions of the documentation for those parts of the project that have been worked up to the current milestone

In writing each report, pay particular attention to the following:

  • The report must be understandable by the client.
  • The requirements must be the client's, not your own concepts, and must be specified in sufficient detail to test against the implementation.
  • Design concepts must be clearly separated from requirements.
  • The design should include both system and program design.
  • Requirements may be partitioned into those that must be met by the first release and those that are optional.

Here are some issues you should make sure you address in your milestone 3 report.

  • You should be devoting a substantial fraction of the last few weeks of the semester to validation. In this report you should get specific about your testing/validation plan, if you haven't already. What kinds of testing have you done or do you plan to do? Have you tried your project on all the platforms (operating systems/web browsers) that you expect it to work on? Have you tried it with lots of different inputs/environments? How much automated testing do you have?
  • What is your deployment/handover plan? This is important for milestone 3 so that your client definitely has time to respond before the end of the semester. The big picture question to address here is: Can your client use the project after you are long gone? How much modification/customization can the client do on their own, versus finding programmers to continue developing the project?
  • If there is non-trivial functionality that you have not started working on by milestone 3, you should consider it likely that you will not be able to finish that functionality by the end of the semester. If you find yourself in this situation, make sure you discuss backup plans.

Here are some example of reports from earlier classes. They are very different in style, but each provides a good example of an effective report. They are placed here with the permission of the student teams.

Final Documentation for the Handover of the Project

During the semester you will be developing a set of documentation for your project. Because every project is different, the exact form of the document is up to you, but it should be well written and suitable for handover to your client. The final report checklist is below.

Final Grading

The client's satisfaction will make up a significant portion of your grade for 5150. This email is the primary way that we will elicit feedback from your client.


Dear [5150 client's name],

This email is a solicitation of your feedback regarding the Cornell Software Engineering course project that you participated in as a client this year. After you receive the final report and software deliverable(s), please take some time to read the report and give the software a thorough tire-kicking. I especially encourage you to try to use the software without any team members around to help. It is easy to overlook usability problems if a developer is present to explain things.

It can be hard to accurately evaluate software. If you have any questions or concerns about how to do this evaluation, please contact the course staff. For the numerical evaluations, feel free to use fractions.

  1. Does the software and documentation the team delivered meet your expectations in terms of functionality? Some specific points to consider:
    • Do you expect to use the software written by the team?
    • If the project is not complete according to the design from the beginning of the semester, did the team complete a useful subset of the functionality?
    • If the project was not well defined at the beginning of the semester, generating detailed requirements may have been a significant part of the team's contribution.
    • Similar to the previous point, a good design can be a valuable deliverable, even if pieces of the implementation are not complete.
    • Did the team give you everything you need to use the software (installation instructions/scripts, account information, etc)?
    • If the project was a piece of a larger project, please focus on just the piece that the team worked on.

    Please make some comments on this topic:

    In addition to your comments, please give a score:

    1. Little of the expected functionality was completed. It will be hard to get any non-trivial value out of the delivered software and documentation.
    2. Some important pieces were completed, but a significant portion of the expected functionality was not. There is some value in what the team delivered, but much of the work that I expected to be completed remains to be done.
    3. Much of the expected functionality was completed, but significant gaps remain. A non-trivial amount of work remains to be done.
    4. The team completed all or almost all of the expected functionality. At most a very small amount of work remains to implement the project plan.
  2. Are you confident about the reliability, robustness and usability of the software? Some specific points to consider:

    • Does the software suffer from reliability and/or robustness problems, like crashing, corrupting data, displaying incorrect results?
    • If user interface was a part of the project, is the interface usable by the expected user population?
    • Accurately evaluating reliability, robustness and usability can be hard. The team should have done testing to verify these properties of the project. Did the team describe its testing activities in its report(s)?
    • Did the team test with an appropriate range of input data, use environments and/or potential users?

    Please make some comments on this topic:

    In addition to your comments, please give a score:

    1. Even though theoretically components are implemented, the software effectively does not work. It has problems building, crashes often, or has severe usability problems that make it effectively unusable.
    2. The software partially works, but has substantial reliability, robustness or usability problems.
    3. The software seems to work well, but there are some minor issues. If the team has done little verification work, you should assume the software has some lingering reliability, robustness and/or usability problems.
    4. The software seems to work well and the team did a credible job of verifying its reliability, robustness and usability.
  3. Was the team sufficiently communicative and responsive over the course of the semester, and were your interactions with them productive?

    Please make some comments on this topic:

    In addition to your comments, please give a score:

    1. The team was largely unresponsive. The communication we had was largely ineffective.
    2. The team did communicate about its work and/or respond to requests, but not very well. It took the team an unreasonably long time to respond to requests and/or their communication about the state of the project was not very clear.
    3. Interaction with the team went reasonably well, but there were some gaps or weaknesses in their responsiveness or clarity.
    4. Interaction with the team went well. I understood the state of the project and was not unpleasantly surprised at any point about what the team had been working on.

Please provide some feedback regarding your impression of each team member. These comments will not be forwarded directly to the team. Over the course of the semester, the students have written constructive feedback for their teammates that will be anonymized and aggregated at the end of the semester. Your comments may be added to that collection. Do not feel obligated to write a lot of text, but please attempt to write something about each teammate.

Finally, do you have any comments that do not fit in any of the preceding categories?

In addition to your final comments, please give a score that reflects your overall satisfaction with the project and your experience with the team.

  1. Participating in this project was a waste of my time.
  2. I got something out of this project, but it was much less than I hoped for.
  3. I did not get everything I wanted out of this project, but I did get a signification portion of it.
  4. The team and what they produced met or exceeded my expectations for this project.

Thanks for your time.

Benjamin Ylvisaker


The 5150 clients are a diverse bunch, which raises some legitimate concerns about the fairness of giving them so much influence over students' grades. Here is the main reason why client satisfaction is heavily weighted in spite of potential fairness issues:

The most important lesson that 5150 has to offer is that when you are making software for someone else, the most important metric of success is the user/customer/client's opinion of the software. Whatever intrinsic technical value the software might have is secondary. Being a professional software engineer (or manager of software engineers) involves frequent judgment calls about whether it is more important to implement this feature, write that documentation, track down some bug or do some other validation. These decisions should be informed first and foremost by your understanding of what will be most valuable for users/customers/clients. This is sometimes frustrating to engineers who would prefer to focus on the most interesting work, or pursue their own sense of what is most valuable. The more deeply you absorb the lesson that the user/customer/client's impression is paramount, the more successful you will be as a software professional.

The course staff will sanity-check the clients' evaluations. If an evaluation is way out of line with our impression of the team's work, it will be adjusted appropriately. In particular, none of the clients has expressed strong dissatisfaction with their project, so I will view any very low scores from clients with skepticism.

Checklist for final report

  • You should keep two audiences in mind while writing the report: your client and future developers and project managers who might try to extend your work in some way. The course staff will attempt to read the report from the latter perspective.
  • The final report should be comprehensive in the sense that the client should not need to refer to any other document (like an earlier report) to get important information about the project. Feel free to copy from your earlier reports, though do put some effort into integrating everything into a single coherent document. Technical references, tutorials, manuals and the like should be included as appendices.
  • Project background. What is the project about, for someone who doesn't know anything about it? Do not cover domain-specific background information too extensively, but do at least mention things that are relevant.
  • Completed work. What did you do?
    • A feasibility study
    • Requirements analysis and specification
    • System and program design
    • User interface design and testing
    • Test plan, test examples, and results
  • Documentation
  • Dependencies. What systems, libraries, frameworks, etc does your project need to work?
  • Either transfer of the rights in the system to the client or an unrestricted license for the client (see the Projects page on the Web site).
  • Work breakdown. For each team member, list their primary contributions to the project. Consider both technical and non-technical contributions. This would typically not be a part of a real-world project report, but 5150 is a course and so we do have to come up with grades.

Final grading numerical break-down

Team score (40 total):

  • 2 Feasibility Report
  • 2 Milestone 2 Presentation
  • 2 Milestone 2 Report
  • 2 Milestone 3 Presentation
  • 2 Milestone 3 Report
  • 3 Milestone 4 Presentation
  • 3 Milestone 4 Report
  • 24 Client's evaluation

The course staff portions of the grade are more focused on form and presentation than technical content.

Individual score (40 total):

  • 1 Did you write teammate evaluations?
  • 1 Did you present?
  • 38 Did you contribute your fair share to the project?

Your individual contribution score will be chosen by the course staff. We will consider the team's self-assessment in the final report, the client's assessments, and our impressions gathered from the presentations and any other interactions we have had. The TAs have lobbied that the 38-point individual contribution part be further broken down into concrete pieces. We are working on that.

As has been announced in lecture, the mapping from final numerical scores to letter grades will be done subjectively by the instructor. If your client is happy with what your team did and you contributed your fair share to the project, you will definitely get a good grade.


[ Home ]