CSSE 120 — Introduction to Software Development, Robotics

Capstone Robotics Team Project (in Python) — Winter 2010-2011

Music Delivery Service

Project Process et al

Project Requirements	Process and Due Dates	Deliverables	Sharing your work in your SVN team repository	Grading	Suggestions and Resources

• This document explains the process and due dates, deliverables, sharing your work in your team SVN repository, grading, and gives some suggestions and resources that may be helpful.
• The Requirements document gives the Requirements for the project.

Process and Due Dates

Much of this process is derived from Agile Software Development, especially Extreme Programming and Scrum.

• Teams: of 3 or 4, as assigned by your instructor.
• Sprints and Deadlines: You must implement by using iterative enhancement (add a little bit of code, test that it functions correctly, and repeat) in three Sprints (segments of work, see details below):
  • Sprint 1: ends Saturday, January 22
  • Sprint 2: ends Saturday, January 29
  • Sprint 3: ends Sunday, February 6
• Release Plan: Each Sprint begins by deciding what features the team intends to implement in each remaining Sprint. Those decisions are recorded in the Release Plan.
  • For each feature in the upcoming Sprint, the team also estimates how many hours it will take to implement that feature.
  • The Release Plan is a plan, not a contract.
  • At the beginning of each Sprint after the first, the team re-plans, revising their list of what features they intend to implement in which Sprint.
  • The revisions are based in part on the project velocity — the sum of the estimated times for the features that the team implemented in the previous Sprint.
• Structure Chart: At the beginning of each Sprint, after making/revising the Release Plan, the team makes a Structure Chart or other such diagram. This chart organizes the software that they plan to develop during that Sprint into functions and shows the relationships between the functions.
  • This chart need not be complete or polished.
  • It should reflect a couple of hour's work or so, possibly plus some revision during the Sprint.
• Task Lists: Throughout the project, each person maintains her own Task List — a list of:
  • what she is to do,
  • by when,
  • its current status,
  • a guess for how long it will take, and
  • how long it actually took (to the nearest hour).
  It should not take more 2 minutes to update your Task List at each work session. Of course, it will take the team quite some time to determine what are the right tasks.
• Stand up meeting: At each class session, the team holds a very short stand up meeting, in which each team member answers the questions:
  • Did you accomplish your tasks due so far?
  • If not, what impediments did you encounter and what can the team do about them?
  You don’t carry out the solutions during the meeting; just determine the conversations that need to occur after the stand up meeting. Standing up helps keep the meeting short.
• Individual Accountability: Each team member must:
  • contribute their fair share to each deliverable, and
  • understand the code that is submitted by the team.
  In particular, each team member must be the lead or individual coder for at least some of the code in each Sprint.

  Further, each team member is responsible for ensuring that your team members obey the above. If a team member is not obeying the above, contact your instructor as soon as possible if you are not able to change your teammate's behavior.

• Pair programming: is encouraged. Programming in more than pairs is generally a bad idea; it hurts your learning and the team's progress.

Deliverables

All the following, except for the code itself and the Angel surveys, should be in your team's project repository in the Process folder. For the Release Plan and Task Lists, use the text files that we already placed there.

• Release Plan — updated throughout the project, with re-planning at the beginning of each Sprint.
• Task List for each team member — updated throughout.
  • There are 4 TaskList documents in your Process folder. Each member should choose one (and put your name in it).
• Structure Chart or other such diagram, for each Sprint, created at the beginning of the Sprint.
• Early in Sprint 1, a rough Screen Sketch to show the basic idea of the GUI that you intend to implement.
  • Scanned hand-drawn diagram, Paint, whatever.
  • Being pretty does NOT matter. Do just enough so that the team is all on the same page regarding the form of the GUI.
• Very short Angel survey completed by each team member individually at the end of each Sprint, indicating whether or not teammates are carrying their weight and being effective team members. The survey at the end of the last Sprint will be longer.
• Working code, with:
  • every function having a doc-comment that briefly specifies WHAT that function does (not HOW it does it), and
  • every module having a doc-comment at the top that briefly describes that module.
  Further, all your code should meet the standards imposed by Source ~ Format Code (control-shift-F) in Eclipse. Finally, your code should generally conform to the coding standards that we have demonstrated throughout the term. For example, you should have no magic numbers.

Sharing your work in your SVN team repository

• Your team shares a single repository to which all team members have access.
• The name of your repository is:

       http://svn.csse.rose-hulman.edu/repos/csse120-201120-teamXX
  

  where XX is your 2-digit team number as announced by your instructor.
• Check out the MusicDeliveryService project. Notice that it has a Process folder for your process documents and a src folder for your code (as usual).
• Using SVN collaboratively, as a team, will take some getting used to. We'll discuss this more in class, but as a start:
  1. Find the TaskList1.txt and similarly named files in the Process folder. Determine who will use which (one for each team member). Each team member should independently:
     1. Update the file to be sure you have the latest version of it. (You will, of course, this time.)
     2. Edit your own TaskListX.txt file by putting your name in it at the spot indicated in the file. Save the file.
     3. Commit your work to the repository.
        • Whenever you commit, give a short but informative message to your teammates. This will greatly enhance your team communication and coordination.
     Use this Update-Edit-Commit cycle whenever you make changes to the files in your repository, including the modules containing your code.
  2. Now find the module musicDelivery.py within your project. Each team member should independently add his or her name to the comments at the top of the file. Since EACH of you will edit the SAME file, this requires careful use of SVN, as follows:
     1. The first team member does the update-edit-commit cycle.
     2. AFTER the first team member commits, the second team member does this same update-edit-commit cycle.
     3. And so forth for the third (and fourth) team members.
     4. AFTER the last commit, all team members do an update to get the most current version of the file.
     Use this Update-Edit-Commit cycle whenever you make changes to the files in your repository, including the modules containing your code.
• We will discuss in class what you should do when you get conflicts in your files.
• Consider creating separate modules for each person to use for each related chunk of work, and importing the modules into your musicDelivery.py module. We'll talk more about this in class.
• You can and should make additional folders and files as needed for your project. SVN makes it easy to share them!

Grading

Grades on the project will be based on the Music Delivery Grading Rubric.

Project grades will be based on both individual and group results.  Your team will get a group grade then grades will be adjusted based on your individual contributions.

We will check off project deliverables, including features implemented, throughout the project.

The final program will be graded based on the proper functioning of your program.

The program will also be graded on your design, coding style, and documentation, including SVN commit messages.

The grade can also be bumped up some due to your creativity. Sometimes students think of even cooler things to do to demonstrate their understanding. What challenges you?

Each team member will be required to complete an evaluation survey about his or her own performance and that of each of his or her teammates. We will use these surveys and our own observations to assign individual project grades.

Suggestions and Resources

• Plan first! Think about how to use top-down design and/or dictionaries. Get help early if you need it!
• If you are having trouble planning or getting started, get help. It is much better (and easier) to get help early and start off with a good plan than to try to hack a poor design into a semi-functional program in the final days before it is due.
• Functions are your friends. Well-written ones will make your life so much easier! Encapsulate functionality!
• You will likely have certain information that many functions will need to access. You may want to put all this information in a dictionary object and pass it into the functions. I created a robotInfo dictionary that contained the robot itself, its direction, its linear velocity, and if it was currently sending IR information. That worked well.
• Test early and test often. Don't write more than a handful of lines of code at a time without testing it. Sometimes, this will mean writing test code that doesn't make it into your final submission. Welcome to the real world of software development!
• You will likely want to keep track of the various states your robot is in, such as whether or not it is currently line following, delivering a song, connected, etc. You can use Boolean variables for these and check them each iteration of the event loop to see if you have to do that step, like drive a tiny bit around the track.

Links that you might want to explore (but don’t have to):

• The Rules of Extreme Programming, many of which we are using in simple form.
• This nice explanation of Scrum, an Agile Programming Methodology that uses the concepts of Sprints, Release Plans and Stand Up Meetings.
• A brief explanation of iterative enhancement.