CS345 - Software Engineering

CS345 - Software Engineering - Assignments

Last updated: Tuesday, 29-Apr-2008 10:46:36 EDT

For Wednesday April 30th - Final Exam

i4 due by 10:30a EDT. Please include the list of stories and notes about which stories work, work partially, or don't work.
In addition to the story cards for i4 I'd like you to complete the two items I asked about recently in an email:
Lastly please check the wiki to be certain the the building, running, testing documentation is accurate and complete.

For Sunday April 27th

i4 due by 12p EDT. Please send me release notes via email detailing how to build and use the software. Please include the list of i4 stories and notes about which stories work, work partially, or don't work.

For Saturday April 26th

Revolution OS quiz, found here.

For Tuesday April 22nd

Brad, Miki, and DylanL - Produce a 3-4 page design description, including the principle data structures, principle source files, tied to diagram, and prose tying it all together.
In a separate document describe what, in terms of the principle calls and data structures, each of the following entails:
1. A drone figures-out what is nearby it or where an asteroid is
2. A drone moves one square in space
3. Fuel is transferred from an asteroid to a drone
4. Fuel is transferred from an drone to the basestation
5. Startup, that is what happens from ./autonomy to the user being given control?
Bring a printout of both parts to class on Tuesday.
Will, Fitz, and Aaron - Create the ADL scripts and driver necessary to automate the process of running Autonomy with the following behavior:
1. Create 4 asteroids with 400 units of fuel each
2. Create 4 drones with an ADL script that randomly moves around until it's out of fuel.
3. Create 4 drones with an ADL script that looks for an asteroid with fuel, mines it, and then returns to the basestation and unloads their fuel.
The driver should ensure that Autonomy runs long enough that all the drones which could mine an asteroid have, and at least some have returned to the base station.
Run Autonomy built with gcc -O0 under gprof using that scenario, where is it spending most of the time? Repeat with gcc -O3, what changed?
Bring the two reports from gprof and a short write-up of what you observed to class on Tuesday.
Maduna, DylanP, Matt, Nathan - Group defect fixing tour. Like before, 6 each for a total of 24. Make sure that you work together a significant portion of the time. Use defect as the type within trac so they can be identified.
In class on Tuesday be prepared to discuss group defect fixing compared to doing it on your own, pros and cons.

For Sunday April 20th

i4 due. Someone besides Dylan should be the release wrangler.

For Friday April 18th

Document and fix at least 6 defects in Autonomy. Use trac as we discussed in class and on the class listserv. You can either fix defects which are already listed, create new ones and then fix them, or some mix.
For each defect you fix a test should be created. Document the name of the test in the defect's trac entry. Note the mechanism I described in email for how I look for the defects within trac and make sure yours appear as they should.
Bonus points for finding and entering new defects in addition to the assignment.
Reflect on your experience, what tools/facilities/information would have made understanding the problem and then fixing the source easier? Come to class with at least one concrete suggestion for improving the Autonomy debugging process.
Nota Bene: If you completed this when it was originally assigned you can fix additional bugs for extra credit. If you didn't, please do so now.
Bring the architectural diagram up-to-date.

For Tuesday April 15th

Document and fix at least 6 defects in Autonomy. Use trac as we discussed in class and on the class listserv. You can either fix defects which are already listed, create new ones and then fix them, or some mix.
For each defect you fix a test should be created. Document the name of the test in the defect's trac entry.
Bonus points for finding and entering new defects in addition to the assignment.
Reflect on your experience, what tools/facilities/information would have made understanding the problem and then fixing the source easier? Come to class with at least one concrete suggestion for improving the Autonomy debugging process.
Bring the architectural diagram up-to-date.
Considering the clean-up, tighten-up mantra I espoused in class on Friday come to class with a list of proposed stories for i4. Assume that it will be due over the weekend as before. I'll also develop a list.

For Friday April 11th

Autonomy i3. Please send me release notes via email detailing how to check-out, build, and use the software. Please include the list of i3 stories and notes about which stories work, work partially, or don't work.
Read chapter 5, Debugging, in TPOP.
Read the article on Enbugging from the journal IEEE Software.

For Tuesday April 8th

Autonomy i3. Please send me release notes via email detailing how to check-out, build, and use the software. Please include the list of i3 stories and notes about which stories work, work partially, or don't work.

For Sunday April 6th

Autonomy i3, due by 12p EDT. Please send me release notes via email detailing how to check-out, build, and use the software. Please include the list of i3 stories and notes about which stories work, work partially, or don't work.

For Friday April 4th

If you haven't read the sections from the Apple Human Interface Guidelines yet please do so before class.
Complete task cards for each accepted i3 story. Keep them up-to-date as you work on i3.

For Tuesday April 1st

If you haven't read the sections from the Apple Human Interface Guidelines yet please do so before class.
Complete and polish the design documents for Autonomy. This should include a complete diagram that's keyed to the prose in the wiki. There should also be a high-level bit of prose that succinctly describes the overall architecture and serves as an introduction to the more detailed diagram and detailed wiki-based prose.
Each of you should contribute to this effort, whether it's being the original author of prose, and/or a proof-reader, and/or an organizer.
Send me an email when this is ready for review, I'd like to have it before 8p on Monday so I can look at it before class on Tuesday.
Review the i3 stories, these will be ready by Sunday evening.

For Friday March 28th

Read the article on game design with story-boards from Computer, come to class with 2 questions/observations about how to relate aspects of their approach to our game project.
Read the Apple Human Interface Guidelines - Part 1, sections Characteristics of Great Software and Human Interface Design
Work on Autonomy, in particular develop a design document that uses prose and diagrams to layout the overall system architecture. Pay particular attention to the interfaces between the major components.

For Friday March 14th

Class will meet today in D128 at 1:30p EDT.
Iteration 2 of the game project due at 8p EST. Please send me a pointer to the static binary and instructions for installation and use.

For Tuesday March 11th

Read Brian Kernighan's article on code testing. Come to class with at least one well thought-out question or observation for us to consider.
Read chapter 6, Testing, in TPOP. Be prepared to discuss how you are structuring, using, and automating the test harness for the game.

For Friday March 7th

Iteration 1 of the game project due at 8p EST.

For Tuesday March 4th

Completed Task Cards due. Each one should include a very brief description of what's to be done (not how it's to be done), an estimate of the amount of time, and the appropriate Wiki linkages between each Task Card and related Story Card(s).
Document the XP principle or practice assigned to you in class on Friday. Cover what it is, what the goals are, what is requires, what it supports, and most importantly how it will manifest itself within the game project.
Read the article on simplification. Come to class with at least one well thought-out question or observation related to it to share with us.

For Friday February 29th

Read pages 44 through 81 in the XP Pocket Guide.
Review and edit the list of Story Cards on the game project wiki. Decorate each of them with an ideal number of hours. This will permit us to sort them into Iteration 1 and Iteration Future during class on Friday.

For Tuesday February 26th

Read the Forward, Preface, and pages 1-44 in the XP Pocket Guide.
Read the Bakeoff article by Malcolm Gladwell.
Consider exercises 7.6 and 7.7. The next assignment will be a blend of these which we'll discuss in class on the 19th. I'd like to see us consider a variety of languages/compilers/interpreters for 7.6, and compilers and compiler options for 7.7.

For Tuesday February 19th

Finish reading chapter 7, "Performance", in TPOP. It's only 20 or so pages long but there is a lot of material there, schedule yourself accordingly.

For Friday February 15th

Complete the sorting algorithm assignment which was due on February 8th.
Add a second sorting algorithm to your program, any of the n(log(n)) sorts will do. You can implement it yourself or copy it from elsewhere.
Instrument your code so that both of your sorting algorithms keep track of the number of compares and exchanges they do.
Add the ability to process commandline arguments to your sorting program using getopt(). Plumb it so that you can specify which of the two sorting algorithms to use and a verbose option. When verbose is enabled your program should print a summary which includes:
- the sorting alrogrithm chosen
- the number of items sorted
- the number of compares
- the number of exchanges
- the wall time taken
Bring a printout of the code and a typescript showing runs from 100 items using each of the two sorting algorithms with verbose enabled.
Read chapter 7, "Performance", in TPOP. It's only 20 or so pages long but there is a lot of material there, schedule yourself accordingly.

For Tuesday February 12th

Complete one of the tutorials from the game engine you are considering. Make sure you work through enough material to generate something reasonably complex.
You should do this independently. Come to class prepared to demonstrate your work for us. We'll discuss how to turn it in then.
Individually and in groups continue to think and talk about game ideas. List important characteristics, features, capabilities you think of, consider spaces (e.g. weather, climate, biology, computer science, physics, etc.)
The more I read and think about which space to work in I'm drawn to the notion of going with what we know, that is computer science. I think this is just a reflection of the importance of the disciplinary scientist to science-based educational game design. Since we're collectively closer to being computer scientists than anything else maybe we should look closely at that space for ideas.

For Friday February 8th

Exercise 2-4 from chapter 2 of TPOP. Note all the conditions described in the text. Bring a printout of your code, including an analysis of your algorithm's time complexity, and the a screen shot of a run with 100 random integers using time to capture the wall time.
If you need a pointer to how to easily generate random integers send email to the class list.
Research an open source game engine:
Write-up a short document (2-4 paragraphs and lists) that covers all of the following:
1. What are the capabilities and features - physics, rendering, sound, 2D/3D, scriptable or libraries.
2. Source langage(s), build language(s).
3. Maturity - how long has it been around? Are there lots of outstanding bugs? Are bugs getting fixed?
4. Are people using it? Do they cite examples? What does a Google search yield? CiteSeer?
5. What tutorials or sample programs are provided?
Be prepared to copy/paste your prose into the class wiki in class on Friday. You can find my write-up on the wiki page for this class, http://wiki.cs.earlham.edu/index.php/Cs345-2008.
Think about ideas for games with a science education basis. Consider the game play, the science, and the pedagogy. Come to class prepared to contribute your idea(s) to a brainstorming session by describing the essential elements of it to us in 1 minute or less.

For Tuesday February 5th

OSS bug fix kit. This will probably be a text file that describes the bug, your fix, and lists the affected files, and a set of patch diffs, one for each of the modified files.
To turn this in bring a printout of your text file to class. Send a tarball of the full kit to me via email before class on Tuesday.
Read the article about Will Wright from the New Yorker. Come to class prepared to discuss it in the context of the group project.

For Friday February 1st

Choose the particular bug you will fix for the open source software bug fix lab. Send the URL to me before 8a EST on Friday morning.
Explore the science game of your choice and write-up a short description of it. Consider what the game is designed to teach, what the game principles are, the pros, and the cons. Come to class prepared to describe and discuss it. Remember to send me the name RSN so I can reserve it for you.
Read chapter 2 of TPOP.

For Tuesday January 29th

Read the three articles from CACM on science, games, and education. Come to class prepared to talk about what sort of project we might do in this space.
Complete (or re-do as the case may be) the array traversal lab.
Pick an open source software project for the bug fix lab, send me the name and the project URL via email before 8a EST Tuesday morning.

For Friday January 25th

Read Eric Raymond's The Cathedral and the Bazaar, the first of three essays in a book by the same name. The URL to the on-line version of the book is http://www.catb.org/~esr/writings/cathedral-bazaar The URL to the start of the XHTML version is http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.
There are 13 (short) chapters to read, the first is titled The Cathedral and the Bazaar, the last is Epilog: Netscape Embraces the Bazaar.
Catch-up on any assignments you haven't completed to-date.

For Tuesday January 22nd

Lab 1, Array Traversals, due in class.

For Friday January 18th

Exercises from chapter 1 of TPOP - 1-1, 1-2, 1-4, 1-6, and 1-8.
Take a recent program of yours, say 50-100 lines of code, and print it out. Label it clearly as "Before". Use the Un*x command "wc" to count the number of lines and characters, write those two values under the "Before" label. Now apply all the principles and guidelines found in chapter 1 of TPOP to your program. When you are done print it and clearly label it "After". Use "wc" again to count the lines and characters, write those two values under the "After" label.

For Tuesday January 15th

Read the preface and chapter 1 in TPOP, Come to class with questions.
Write-up a paragraph or two telling me what your computer science/software itches are, and your interests in life generally. Send it to me via email before 9a EDT on Tuesday the 15th.