Deliverables and Due Dates for CS 440 Spring 2026

Summary Table for Spring 2026

Table Notes:

• The design project will have three major report releases, covering the design project general description, requirements, and a final report including a detailed system design.
  • Design project reports will be due on Saturdays at the end of the 6th, 10th, and 14th weeks.
  • The first and final report releases will include in-class presentations, during the 6th and 13th weeks respectively.
  • ( The design project actually has one big report, developed in three stages. The 2nd and 3rd stages add to the growing report. )
• The implementation project has three releases, each culminating in a demonstration.
  • Each release is composed of four sprints, where each sprint lasts one week.
  • The first two releases will implement increasing functionality, and will each commence with a written scenario predicting the functionality to be demonstrated at the end of the release. The third release may add some functionality, but is primarily for testing, debugging, polishing, and report preparation.
  • The first and second releases will be demonstrated to the TA, on Fridays.
  • The final release will be demonstrated in class, during the 15th week
  • There will also be a implementation project final report and summary due Saturday at the end of the 15th week.
• All major reports ( 3 for the design project and 1 for the implementation project ) are to be accompanied by a 2-page summary.
• Peer Evaluations will be due the end of the 7th week, 11th week, and at the final exam. Details to follow.
• A midterm exam will be held during the 9th week, covering material from the first 8 weeks. The final exam will be during finals week. All exams are cumulative, in-person exams.

Detailed Schedule for Spring 2026

The table below shows the planned schedule for CS 440 for Spring 2026, with all deliverables and due dates. Please note the following:

• The dates listed in the first column are the Sundays on which each week starts.
• The "Due" column lists all deliverable due dates and times, with links to further details for each assignment.
• The "Implementation" and "Design" columns indicate what students should be working on for each project at any given time.
• Anything scheduled for the future is subject to change. Items listed for the near future are more reliable than those listed for the far future.
  • Details regarding each assignment follow the table, in the order encountered.

• Note regarding git submissions: Only the main branch will be accessed for grading purposes, so anything that is required to be turned in via git must be kept on the main branch. You may create additional branches for your own use, but you need to merge them into the main branch if you want those materials graded.

Assignment Details

In chronological order of first occurance

Group Assignment Questionnaire

• Complete and submit by the end of class the second week of classes, via Google Forms.
• If you need to resubmit a revised version, label it clearly as an updated revision ( with a date. )
• Review the Archive of 440 Projects in order to complete the preferred project list at the end.
  • For Spring 2026, DO NOT select implementation projects involving underground environments.
• If you submit the form and then later drop the course, please submit an updated form indicating that you have dropped.

Design Project Brainstorming Assignment

• The general design project topic for Spring 2026 is Software Pertaining to Underground Environments.
• This is an individual assignment, designed to get you started thinking about your semester desisgn project during the two weeks before groups can be formed.
• By the time groups are formed, each member should come to the table with one or more good ideas for potential design projects.
• You are limited to a maximum of two pages. It is up to you whether to use those pages describing one or two ideas to greater depth, or more ideas at a shallower level.
• If you can identify a real person outside your group to act as a domain expert and/or pseudo "client", it will help you immensely when it comes time to develop design project requirements.
  For example, if you have a friend or neighbor who is a spelunker, they could help you determine the needs of software designed to help explore caves.
• The design project report template that you will be using is originally intended for business-oriented clients, and may be more difficult to fill out for non business-oriented applications such as games.

Implementation Project Schedule and CASE tool Information ( for CS 440 Spring 2026)

• Local server: jira.cs.uic.edu
• Need VPN to access off campus. Get Cicsco AnyConnect for UIC at the WebStore.
• Log in with your UIC NetID and password credentials.
• Doing scrum with Jira tutorial: https://www.atlassian.com/agile/tutorials/how-to-do-scrum-with-jira-software

The overall project dates for Fall 2025 are from Sunday September 14 to Saturday April 27. Specific dates for sprints and releases are as follows:

Sprint	Week	Sprint Dates, Sun to Sat	Release Dates
Project	4-15	February 1 to May 2
Planning	3
R1-1	4	Feb 1-7	Feb 1 - 28
R1-2	5	Feb 8-14
R1-3	6	Feb 16-21
R1-4	7	Feb 23-28
R2-1	8	Mar 1-7	Mar 1 - Apr 4
R2-2	9	Mar 8-14
R2-3	10	Mar 15-21
S P R I N G       B R E A K
R2-4	11	Mar 29 - Apr 4
R3-1	12	Apr 5-11	Apr 5 - May 2
R3-2	13	Apr 12-18
R3-3	14	Apr 19-25
R3-4	15	Apr 26 - May 2

* - When setting up Jira during the spring term it may be easisest to plan 5 weeks for the second release, and simply not schedule any work for spring break week.

CASE Tool Evaluations

Jira projects will be evaluated periodically for quality and activity, according to the following criteria: ( To be adjusted for Spring 2026 . )

( The following criteria are from past semsters using iceScrum. A new rubric will be developed for Jira use. )

• 1 pt - Project is created, has team members, a proper description & vision, etc.
• 1 pt - Project timeline has been set up properly with requested number of sprints, releases, etc.
• 1 pt - There are items in the sandbox. (*)
• 1 pt - There are items in the product backlog (*)
• 1 pt - There are stories assigned to sprints in the release plan (*)
• 1 pt - Tasks have been created in the sprint plan (*)
• 2 pt - Tasks have been allocated to all members. (*)
• 2 pt - All members show ( recent ) activity on the project dashboard. (*)
• Total is on a 10-point scale each time the iceScrum project is checked.
  • Scores will be averaged and scaled, and will contribute towards the overall course grade as specified in the course policies.
  • IceScrum may be checked as frequently as once per week, or possibly less frequently depending on circumstances.
• (*) Items marked with a star are expected to change from week to week

Weekly Activity/Progress Reports

• Beginning the third week of classes, you are expected to meet with your group physically at least once a week outside of class, and submit a group activity/progress report documenting the meeting and individual progress and current action items.
• A form is provided in the github repository, which will include at a minimum:
  • Date, time, and location of the meeting. Note that this must be an in-person meeting, not Zoom, Discord, Slack, etc.
  • Members present on time, or tardy, or not present.
  • Individual reports on progress accomplished since the previous meeting.
  • Individual assigned action items to be accomplished before the next meeting.
  • Note that the report should document individual accountability, i.e. a record of each individual team member's activities, assignments, and contributions.
  • The progress reports should cover progress and activitiy for both projects. It is understood that the balance may shift from one project to the other from week to week, but overall, all members need to contribute to both projects.
• It is recommended that the role of note taker rotate among group members, but that is up to each group to determine.

New Grading Rubric for Meeting Minutes, starting Fall 2022: ( To be adjusted for Spring 2026. )

• 2 Points - Minutes submitted properly and on time.  In the proper directory, and the file name indicates the date of the minutes.

• 2 Points - All members present and on time. ( Document any reasons for missing members, such as hospitalizations. )
• 2 Points - Each individual member shows accomplishments since the last meeting.
• 2 Points - Each individual member leaves the meeting with specified action items.
• 2 Points - Minutes are overall clear and well written, and well organized. Accomplishments and goals attributed to individuals, not to "we".

Implementation Project Scenarios

• Scenarios are simple stories describing how someone would use the product at a certain point in development. They serve as acceptance tests for agile development.
• For this semester the implementation project will have two major releases, each with its own scenario, plus a third final release. The scenario is written at the beginning of the release, and then the program is evaluated at the end of the release to determine if the given scenario can be carried out as described.
• This is a long-term implementation of the practice of Test-Driven Development, TDD:
1. Write a test at the beginning of the time period, that the product cannot initially pass. ( Scenario in this case. )
2. Conduct development work towards passing the test.
3. Demonstrate by the end of the time period that the product passes all tests. ( Demonstration to the TA at the end of each release in this case. )
• Follow the file naming and formatting guidelines.
• Recall also the guidelines for the value of a report.
• Good First Example - Properly formatted, with a meaningful title and group # and group members names. Tells a clear story. Diagram and sample data file ( referenced ) are helpful for overall understanding.
• Bad First Example - This was the original version of the above, written as a class assignment. It has basically the same information, but the title is pretty useless and there is no authorship. The sample data file and diagram were released separately at a later date. The file name is much less descriptive.
• Bad Second Example - This was the scenario for the second release of the aforementioned examples. It suffers from the same problem as the first bad example, but it does now document that the data file format has been updated to a newer, more complex version to support the added features of the second release.

Design Project Description Document

• Find the design project report template on the project resources page.
  • Version 2.3 with full instructions - PDF
  • Version 2.3 with minimal instructions - PDF
  • Version 2.3 package ( Zipfile with 2 Word and 2 PDF files )
• Complete the first 8 sections of the template provided. ( I.e. all of part I )
• Remove instructions, etc. from the template ( first 8 sections only for now. Remove from other sections as they are completed. )
• If you have information for the later sections of the document, e.g glossary, bibliography, ideas for solutions, etc., go ahead and add them in whenever they become available.
• The theme of the design projects for the fall 2025 semester is "Software Pertaining to Large Animals".
  • See separate documentation related to the first assignment.
  • Your project will need to be complex and significant enough that it will require a team to develop it, so think big. Do not limit yourself to what a group of students can get done in a single semester, and certainly develop something beyond the abilities of a single programmer working alone. ( You may want to think about possible subsystems, such as an overall gameplay controller, a communications subsystem, the AI logic for non-player characters, perhaps a module that would access real-world data in real time, etc. )

Two-Page Summaries

• Each major project report ( Design Project Description, Requirements & Acceptance Tests, and Final Report for the design project and the Testing and Inspection Report for the implementatin project ) must be accompanied by a separate two-page summary.
• Follow the file naming and formatting guidelines.
• Summaries should be separate documents from their corresponding reports.
• Don't report on the work that you did or how you spent your time. Report instead on the results of that work. I.e. discuss the deliverables not the efforts required to generate them.
• Hand in summaries both electronically via git and Gradescope and as a hardcopy in class.
• The Requirements & Acceptance Test summary should include a brief ( 1 to 2 sentence ) paragraph describing the project, and then focus primarily on the requirements and acceptance tests.
• The Final Project summaries for both design and implementation projects should summarize the entire final documents, including all important sections.

Design Project Oral Presentations

• Each major design project report ( description, and the final report ) will be presented with a ( nominal 5-minute ) Powerpoint presentation. Exact time will vary by semester according to the number of groups enrolled.
• E-mail your presentations to jbell@uic.edu no later than the assigned deadline, and also upload a copy to your git repository.
• Please make sure to include "CS 440" and your group number in the subject of the e-mail, and include your group number and a descriptive title in the file name of your presentation.
• ( Hint: If you save your presentation as a PowerPoint "show", it will launch directly without going through the PowerPoint program. Alternatively you can right-click on a ppt file and select "show" insted of "open". )
• Full attendance is required on all presentation days, whether your group is presenting or not.
• Everyone should be prepared to present on the first presentation day of the week, and must attend the rest of the week even after having made their presentation.
• It is not required that all members speak during the presentation, but all members must be present and prepared to answer quesitons.
• Please no open laptops, discussions, or other activities during student presentations - Give the speakers your attention.
• The requirements & test plan presentation should have only a very brief ( 1 slide ) description of the project.
• The final presentaiton should cover the entire semester's work, with emphasis on the final system design. ( Students from future semesters may be invited to the final semester presentations, and they will also be recorded for future student to watch at a later date. )

Presentation Evaluations

• As you watch oral presentations you will be asked to evaluate what you see, and to provide feedback to the speaker(s) on forms provided.
  • Sample Form
• The main purpose of this is to aid the speakers in giving better presentations in the future.
• Your comments will be given anonymously to the presenters. Your comments will not affect their grade.
• You will be given a grade based on how completely you fill out the form, not on the "accuracy" of your comments.
  • In order to get full credit you must provide at least one compliment and at least one suggestion for improvement for each presentation ( other than your own ), as well as circling scores.
  • There will not be a lot of points involved, and most students should get full credit most of the time, but they will add up if you do not fully participate.

( Midterm ) Exam(s)

• All exams will be cumulative, with emphasis on material not covered on previous exams.
• To the extent possible, all material covered in class, all assigned reading, and all material covered in project work will be covered on the exams.
• All exams are closed book and closed notes.
• Format will most likely include a mix of multiple-choice questions and practical implementation. There is not likely to be an essay type component.

Requirements & Acceptance Tests

• Extend your previous ( description ) report by completing section II.
  • Sample Requirement Test Correspondence Table - Zip
• Correct any deficiencies identified in your previous report. Uncorrected weaknesses may be penalized a second time.
• Don't forget to update the material at the end of the report ( Project Issues and following material ) as needed.
• Create a two-page summary as a separate document. ( See above. )

Graduate Student Research Papers

Graduate students receive an extra credit for this course ( 4 instead of 3 ) which they earn by writing a short research paper, and presenting it in the 14th week. Specifically:

• E-mail the professor with a chosen topic and list of 3 peer-reviewed literature references by Monday of the 5th week.
• Submit a rough draft by Monday of the 10th week. The paper must be based on at least 3 unique peer-reviewed sources, and is expected to be about 3 to 5 pages long.
• Submit the final draft along with a set of presentation powerpoints Monday of the 14th week, and present the results to the class on that Monday.

Design Project Final Report

• The final version of the design project should have all ( relevant ) sections completed.
• Correct any deficiencies identified in your previous report. Uncorrected weaknesses may be penalized a second time.
• Don't forget to update the material at the end of the report ( Project Issues and following material ) as needed.
• The corresponding two-page summary should summarize the entire report, not just the new sections.
• Submit both the final report and two-page summary via git no later than midnight on Saturday of the last day of classes.

Implementation Project Final Report

• New for Fall 2020 - A second draft of a template for this report has been created:
  • PDF Format
  • Zip file containing MS Word and PDF formats
  • The new version contains a new section II documenting the deliverables for the 1st and 2nd releases, and a comparison with the previous group's plans.
  • As this is a first preliminary draft, students should apply their best judgement to add, remove, or modify sections as appropriate.
• This document reports the delivarables produced for the implementation project, as well as the testing and inspection activities completed.
• Each team member should have some significant code to be tested and inspected.
• Each team member submits ( some of ) their code to the rest of the group to be inspected.
  • Each team member then serves on the inspection team for each of the remaining team members.
  • So for example if there are four members on a team, then there must be four ( significant ) pieces of code to be inspected, each authored by a different member of the team and each inspected by the remaining three team members. ( Each team member will need to inspect three different code submissions. )
• Each team member must also develop and execute unit tests for ( some of ) their code.
  • This code may be the same code that was submitted for inspection, but it does not have to be.
  • It is best if code is tested by someone other than the person who wrote it. I.e. each member of the team should test someone else's code.
• Create a two-page summary as a separate document. ( See above. )

Final Design Project Presentations

• The target audience for the final design project presentations are students who take this course in the future, and who would be implementing your projects.
• All sections should be covered, but description, requirements, and test plans should be brief, perhaps one or at most two slides each.
• Emphasis should be on the final system design, including subsystems, classes, and their relationships.
• Don't put in so much detail that your diagrams are unreadable. For example class diagrams might show only the names of the classes and not any internal details, unless focusing on a single class or small set of related classes.
• Presentations will be recorded for future review, so be sure to use the microphone provided.

Final Implemenation Project Demonstrations

• The final demonstrations of the implementation projects will be conducted in class.
• A brief introductory explanation of the project is probably in order.
• The use of slides is allowed but not required.
• A live demonstration is expected, and preferable if possible. However recordings may also be used, particularly if necessary to speed up slow or lengthy operations.
• Don't waste time on logins or account creation / setup. No one cares about those things. Focus on the special features that make this program different from other programs.
• Either the classroom podium computer or your own personal computers may be used.
• It is recommended that you practice ( with timing ) in the classroom ahead of time, to ensure that you know how to use the equipment, have all the right cables, etc.