A.Hornof - April 3, 2003
This project is due on April 30, at 10 PM, including all source code files and documentation. Follow the submission instructions. The initial SRS/SDS/ProjectPlan is due in class on Tuesday, April 15, along with a class presentation of the document.
Students taking computer science classes need to routinely submit their completed programming assignments to the instructor for evaluation and grading. There are many advantages to submitting these projects electronically so that the instructor can compile, run, and test the programs.
Electronic submission of assignments presents a number of administrative challenges. The students are one set of stakeholders, and the problem can be considered from their perspective. Each student must have a clear and straightforward way to submit their work, and for their submission to be clearly separated from those of other students. Each student's submission must be secure; that is, other students should not be able to see it. Each student should also have a means of confirming that their submission was successful, and that they submitted the intended files.
The instructor is another stakeholder. He or she needs to be able to compile, run, and test all of the programs submitted by students in a secure location that the students cannot see. He or she needs to provide feedback to the students on how their programs performed, and to maintain a list of all the scores, both internally with the students' names, and externally so that the students can see their progress, but by using a randomly assigned name or number. Also, the "instructor" will often be a small staff of more than one person, including GTFs (graduate teaching fellows, or teaching assistants) and graders.
The systems support administration staff, who maintain the shared computer system used by the students and instructor, are another set of stakeholders. This staff's job is to maintain a working and secure shared system. They will not endorse a turnin system that creates any sort of security weakness.
There are numerous challenges in solving this problem. The system is not a "one off," or something that will be just set up and left to run indefinitely. The solution will need to be reconfigured every term for numerous classes by numerous instructors, with little or no training. The system will need to accommodate multiple classes at the same time. Instructors will need to reconfigure the system for each homework assignment, and archive data at the end of the term. A turnin system that fails, such as by losing data or creating a security breach, will be banished from a department. Instructors will have little patience with a turnin system that imposes itself on the design of a class, such as by not accommodating a project with thirty source code files, or a system that requires source code files to be named to fit a fixed scheme.
The problem grows even more difficult as you start to consider the special cases that will arise. For example, students may sometimes be required to submit a hierarchy of files that must be reconstructed for grading (such as a Java program organized into packages), and instructors will have different late policies, perhaps even from assignment to assignment, and may impose different penalties even from project to project.
There are many possible technical solutions to the problem, and your job is to identify, design, build, test, document, and deliver one working solution. You may use any programming language or packages, or any combination of such, and reuse any code that you find, provided that you clearly cite your sources and clearly delineate and cite the source of your reused code. But your solution should follow from your design, rather than your design conforming to some reusable code that you find.
A number of turnin programs are already available and used in the CIS department. You may look to these for ideas and inspiration, provided you cite the sources of your ideas as best as possible. Each of the current programs has its strengths and weaknesses. Your solution should provide as many of the strengths and as few of the weaknesses as is possible.
Professor Sugih Jamin, at the University of Michigan, wrote two C programs that work together to facilitate the automated submission of assignment files. The system has been successfully used by the current 422 instructor as well as by other faculty in the CIS department here at the UofO, and will in fact be used to submit projects in this version of 422. The first C program is "turnind". The 'd' stands for daemon, a program that lies dormant in Unix waiting for a condition to occur. The instructor must start up the daemon before students can submit their assignments. The second program is "turnin", which students invoke from the Unix command line, along with a few arguments, to submit their code. The daemon has already been started for this project. Feel free to try it out.
Advantages
Disadvantages
Professor David Atkins, here at the University of Oregon, wrote a web-based "e-turnin" system that he and other 200-level instructors (including the current instructor of this course) have used successfully for collecting homework projects in these introductory programming courses. The program is written in MAWL. It is a web-form-based system that runs as a CGI script. It is a more complex system than the Unix-daemon-based Solution #1, but it also has more features.
Advantages
Disadvantages
The e-turnin system has been configured and set up for CIS 422, but just for experimental purposes. A user named "test" has been created, with the password of "test". Since it will not be used for submitting any homeworks, feel free to try out this account or to create a test account of your own, but do not use your real student ID number because it will be visible to other students.
The source code is available. Also, the solutions directory has been made publicly readable, so you can look inside and see what the instructor would see when he or she goes to do the grading. Normally, the solutions directory would not be public-readable. This is why it is important that you don't use your real student ID. The student ID is part of each student's directory name.
A non-functional copy of the main administrative web page is viewable at admin_sample.html. A nonfunctional copy of the administrative student list that gets created is at student_list_sample.html. Since you did not get to these pages by logging on as the administrator, you will quickly run into errors if you try to execute any of the functions that appear to be on these pages.
You can also set up either of these systems by following the setup instructions for each, and thus see the full-blown instructor experience of using each system. Your solution to Project 1 should be at least as good as either of these solutions, and preferably better. You should also produce better user and technical documentation. The real test will be whether instructors in the department--and the instructor of this 422 class--can quickly and easily install, configure, set up, and test the reliability of your system to the point that he or she would be completely comfortable having students in a class submit their homework assignments via this system, and would prefer it over the two other systems currently available. Note that fancy colorful graphics, bold claims, advertising-type language boasting the features of a system, nicely-formatted but content-free and useless user or technical documentation will not help your product a bit, and would in fact likely detract from the quality of the product. The most important thing is that your system work flawlessly under all possible scenarios (file types, browsers, command shells, through rebooting of systems, multiple simultaneous projects and classes, etc.), provide a useful set of features, and be easy to configure and easy to use.
Sugih Jamin's Unix-daemon-based "turnin" program is very well-written, simple, and concise. It is barely documented at all, but this may be its only shortcoming as a distributable, reusable piece of software. It is a great tool. It gets the job done well, and reliably.
In the course of using Professor Atkins' "e-turnin" program last term for a programming class of about 50 students, a number of issues came up. Many or most of these would be excellent candidates for requirements to satisfy in your project. They will be listed here in no particular organization or order. You may prioritize them, break them into functional and non-functional issues, or use them in any way you see fit. Note that few of them are currently written as requirements, but more just as ideas.
One of the biggest challenges in this project is going to be finding good ways to divide up the programming and other technical work. Aside from this, you must also assign responsibilities to team members. It is not a good strategy to simply share all responsibilities. Although all team members should contribute to some extent to every aspect of the project, it is essential to have one person with central responsibility for each major part of the task. Among the responsibilities to be assigned include:
The mapping of people to roles is not necessarily one-to-one. For example, it is common in small teams for the user documentation and user interface roles to be combined. You may wish to identify additional roles. You may also want to spell out responsibilities more clearly, e.g., shall the user documentation or technical documentation person be in charge of the final presentation?
The person with ultimate responsibility for one of these functions does not have to do the whole job alone. For example, the system architect does not design the whole system alone, and the product build manager does not do all the implementation; they are managers of different aspects of the project.
Risk control is an important part of project management. One of the largest risks to any software project is the loss of a key person. Therefore, while it is important that a single person be ultimately responsible for each role, it is a very good idea to assign a "backup" for each role also. The backup person assigns the main person responsible for a role, and should be knowledgeable enough about that role to take over responsibility if the primary person is lost or unable to fulfill his responsibility. The backup role is also an opportunity for "cross-training" in preparation to take a lead role in a later project.
The SRS / SDS / Project Plan document is a small combination of elements that might appear in several different documents in a larger project: A proposal, a feasibility study, a project plan, a requirements statement, a specification and/or external design, and an architectural design overview. This document should convince management, a client, or an investor that this project is worth funding. The quality and content of the document will communicate the likelihood of success of the project if it were to be approved.
Your SRS / SDS / Project Plan should include at least the following:
Each group will prepare an in-class presentation that covers each of these six topics. The presentation, as with the document, should be intended to convince the audience that your project is worth their support. In both the document and the presentation, solid ideas and good content will go much further than e-marketing mumbo jumbo.
The group should keep a record of meetings. This record should briefly note the agenda of the meeting, the date and time, who showed up (and who showed up on time), and what was accomplished during the meeting. Set ending times for meetings to help you get through the agenda items.
The group should also keep a record of each of the tasks that are assigned to each group member. This should be in the form of a spreadsheet or table with the following columns: The task, assigned to whom, when assigned, when due, when completed, who did it, who signed off on it.
The cheapest, most dependable and least risky software components are those you don't build. You can find many nifty things freely available on the web. I strongly suggest you take advantage of them. On the other hand, you must do so in a way that is legal and ethical, and while I won't set an upper bound on how much of your project code can be reused, you must certainly provide some "value added" and not merely repackage software available elsewhere.
To be legal, you must obey all copyright restrictions in software you use. Beware that a document or file need not contain an explicit copyright statement to be protected by copyright law; you have a right to copy or reuse something only if the author has specifically granted you that right. I am absolutely firm on this, and will not hesitate to fail an individual or a whole team for unethical conduct as regards intellectual property. If you have any questions about what you may or may not do, ask me.
Your product must be freely distributable under the Gnu copyleft agreement. In some cases this may mean that you cannot make use of some software which is otherwise perfect. In other cases it may mean that your product will depend on other software packages that you cannot directly distribute. (Be careful of such dependencies, especially on commercial software, as they can make your product more difficult to install and use.)
To be ethical, you must clearly document the original source of all software and other documents. Every source file must contain header comments clearly identifying its author(s). Derivative work (e.g., code written by you but adapted from a book) must clearly cite each source used in its creation. Falsely identifying yourself as the author of something that is someone else's work, or failing to properly cite a reference on which you based part of your work, is plagiarism and will be dealt with very severely.
It is entirely possible to follow these guidelines, making only legal and ethical use of other people's work, and still to avoid a lot of design and coding that would be required if you built this project "from scratch." Sometimes you will find that, even if you cannot directly reuse code (e.g., because it is written in a different programming language), you can still reuse design. You should properly cite the sources of reused design as well as reused code.
Before meet with your team, start thinking about the project on your own. Design work and brainstorms are usually more productive if group members first do some thinking on their own, without the inertia of groupthink to pull everyone down a single path. Work on the issues that will be in your product concept document due at the end of week 2. Further analyze the strengths and weaknesses of the current systems. Try to find other systems to consider as well. What is the competition? Also, identify useful components that you can reuse. Think about the most effective development strategy. Should a couple team members learn MAWL and overhaul Atkins' e-turnin? Should you launch two independent development strategies in case one fails?
You are going to need at least a couple of intense team meetings to agree on your product concept, in addition to more individual research. Think seriously about the feasibility issues: How is your team going to divide up the work and tackle the problems? Produce the SRS/SDS/Plan document and present it to the class on Tuesday, April 15.
You should by now have already made substantial progress towards the final product. Delivery is less than two weeks away, and deadlines that looked easy before are starting to get scary. Don't panic. Do make a plan that includes early production of a running prototype (no matter how limited in functionality, it just needs to work) and frequent revisions. Make contingency plans for the failure of anything that isn't already running. You really, really want a running prototype before class on Thursday of this week, so that you are ready to discuss any remaining problems.
It's crunch time. You're on a daily build-and-smoke schedule now. You have an agreed meeting time each day for putting together everyone's pieces and testing the current system version. The build-master is sweating bullets, but has it under control so that, if it all blows up on Wednesday, the Tuesday build is still good to go. You schedule intense reviews of documents and outstanding design issues. On Wednesday, you declare victory and turn in your project. On Thursday, May 1, you will present your project to the class.
The reuse guidelines and approximate schedule are derived from a previous assignment designed by Michal Young.