CS 440 Spring 2013
"Current" Events
New material is added here first, and later moved elsewhere
or removed entirely as it becomes old or obsolete. Some information
is considered sufficiently important to never expire.
- Final Exam Friday 10 May, 10:30 to 12:30, Lecture Center C4.
- Unit Tests and Inspection Report Due Monday 29 April
- Each team member must select a reasonably significant method or function that they have written, and demonstrate their ability to perform unit testing by applying the white box and black box testing techniques that we have studied to their code. Each test to be performed shall be documented with a name, inputs, expected outputs, and any other information needed to run the tests and evaluate the results. Include the reasoning behind the tests chosen, e.g. equivalence partitioning, boundary testing, branch testing, etc. See sample exam answers posted on Blackboard for an idea of the scope of tests expected.
- Also include the results of running the tests, including regression testing if any tests needed to be repeated, ( presumably after fixing the bugs identified in an earlier run. )
- Each piece of code tested in the first bullet point must also be inspected by the remainder of the team. Include in the report the author of the code, the reviewers who inspected the code, and the compiled findings of the inspection team. Each member of the team is expected to inspect one piece of code from each of their team mates. ( It is suggested that the preliminary inspection be done via e-mail, and then one review meeting be held to review all of the inspections together. )
- Acceptance Tests and Final Report Due Friday 3 May
- Expand your existing project document to include a section on Testing. Include in this section the acceptance tests planned to determine whether or not the finished product meets specification. Each acceptance test should be linked to one or more requirements, and each requirement should be covered by at least one acceptance test.
- If your planned project is larger in scope than a team of students can reasonably be expected to finish in two sprints of 4 weeks duration each, then you should focus on defining two realeases, with detailed acceptance tests for the accomplishments expected at the end of each release. Overall project acceptance tests should still be included, but may be more general and less specific.
- Add another section to your final report titled "Conclusions and Development Process Review". In this section you should review and document what procedures and methods you carried out this semester that worked well, that you would want to implement again in future projects, and what you did that did not work out so well that you would want to do differently next time. Any insights or recommendations you have for how similar software engineering projects should be conducted in the future should be documented here.
- Polish and fine-tune your overall report, to address any weaknesses discovered in previous reports, and to ensure that the final document is complete, consistent, clearly well written, and without redundancies.
- Also submit a separate two-page summary of your work for this semester ( on the requirements project. )
- Schedule Adjustment - As discussed in class on 8 April 2013:
- The due date for the Design Report is pushed back until Monday, April 15th. Time unchanged.
- The third release of the project will be a bug-fix and refinement release. Our activities for the last 3 weeks will focus on testing, inspection, and polish, and the completion of any uncompleted ( or not completed well ) tasks from releases 1 and 2. You can add support for Actors if you wish, but it is not expected. ( Although restructuring and refactoring the existing code as a first step towards providing support for Actors would be appropriate, as well as ensuring that the code is all well-documented, and that the documentation matches the actual code. For example you might want to modify how Artifact inventories are handled, to make it easier to add multiple characters each with their own inventories and/or the possibility of non-player characters moving things around when the player isn't looking. )
- The final report for the requirements thread of the project will include acceptance tests that you would use to confirm that the programmer's you hire have actually created the product that you have envisioned.
- There will also be a separate testing report due the final week of classes, documenting the results of unit ( and integration ) tests and inspections that you have completed on the code that you wrote for release 1 and 2 of the coding thread of the project, ( along with any regression testing that was done after fixing bugs in release 3. )
- In order to keep from having two reports due on the exact same day, one report will be due on Monday of the last week of classes, and the other on the Friday, as follows:
- Monday April 29th -
- Friday May 3 -
- Further details on the expectations for the final project reports will follow.
- CS 340 HW4 from Spring 2008 - To be discussed in class
- Demo Schedule Signup: http://www.doodle.com/xkpbbvpwv6yd6g42
- Design Documentation Requirements: Due Friday 12 April - 9:30 electronically and paper docs in class
- By the date listed above, please modify your Requirements document as follows:
- Add a new major section documenting the "System Design"
- This section should document the overall design ( architecture ) of the system, and show all major classes and how they are organized into subsystems. ( A class diagram with packages is probably suitable. )
- Document the design goals that were selected, and how the chosen design addresses those goals.
- If alternatives were considered, document what they were, and the rationale for choosing the design that you did.
- The overall responsibilites ( services provided ) of each subsystem should be document.
- This section should not document any internal details of individual classes / objects. I.e. the class diagram just contains the names of the classes and the links between them.
- Minor support classes may be omitted from this section if necessary for clarity.
- Add another new section documenting "Object Design"
- It is probably best to organize this section on a subsystem-by-subsystem basis
- For each subsystem, document all of the classes within that subsystem, in as full of detail as you can, including required data members, services ( methods ), and responsibilities.
- Include constraints ( pr-conditions, post-condition, and invarianats ) to the extent that they are known and within reason.
- The design should be sufficiently detailed for a competent group of programmers to begin developing the classes described. ( Think of writing a homework assignment for the next batch of students, or a work assignment for a group of contract programmers to be hired. )
- All classes must be documented, though some could be left off of the class diagram if necessary forclarity.
- At least one class diagram per subsystem will probably be required, showing data member and method details to the extent that they are known.
- Revise any old sections of the document for which you have received feedback, ( or if you just want to rewrite sections to make them better. )
- Write a new two-page summary of the system and object design.
- Hand in electronically ( blackboard and git ) the full revised document and summary.
- Print out the two new sections, the new summary, and any other sections that have either undergone major changes or are important to the understanding of the new sections. The last point includes at a minimum the full table of contents and probably the overall project description and glossary if it is significant
- If the Volere Template is physically difficult to work with you may develop your own Microsoft-Word compatible document, but in this case you must conform to the geenral organization of the Volere Template in terms of sections and subsections, etc. ( Subject to the understanding that you are now adding two new sections that Volere did not originally include, and you may not need all of the sections in the original Volere Template. ) Your entire report must be consistently formatted and organized in any case.
- References to the Colossal Cave Adventure game that started the genre
- New Programming Project Files
- Requirements Memo - Due Friday March 15th by 9:30 a.m.
- MIDTERM EXAM II FRIDAY 5 APRIL FROM 10:00 TO 10:50
- LECTURE CENTER C4
- All material covered prior to Spring Break is fair game.
- Project Proposal Memo - Due Friday February 8th by 9:30 a.m.
- iceScrum
- git
- StarUML - http://staruml.sourceforge.net/en/
- Programming Project
- First Scenario
- Data File Format
- Data File Example
- References From Old Classes
- Spring 2008
- Spring 2007
- Fall 2007
- Schedule:
- Demo 1 - Friday 1 March, end of 7th week
- Release 1 dates Monday Feb 4 to Friday 1 March
- Sprint 1 Monday Feb 4 to Friday Feb 15
- Sprint 2 Monday Feb 18 to Friday 1 March
- Demo 2 - Wednesday 3 April, middle of 11th week ( after Spring Break )
- Release 2 dates Monday 4 March to Wednesday 3 April
- Sprint 1 Monday 4 March to Friday 15 March
- Sprint 2 Monday 18 March to Wednesday 3 April
- Testing and Inspection Report on Release 2 code due 14th week, ( exact date TBD. )
- Demo 3 - Friday 3 May, end of 15th week
- Release 3 dates Monday 8 April to Friday 3 May
- Sprint 1 Monday 8 April to Friday 19 April
- Sprint 2 Monday 22 April to Friday 3 May
- Midterm Exams on Fridays, 22 Feb and 5 April, end of 6th and 11th week.
- Planning Project Schedule
- Project Description due Fruday 8 February, end of 4th week
- Requirements Document due Friday 15 March, end of 9th week
- Design Document due Friday 12 April, end of 12th week
- Final Report including Test Plans due Friday 3 May, end of 15th week.
- Lecture Schedule ( and assignments due ):
- Week 4 - CASE Tools - Project Descriptions due Friday
- Week 5 - Requirements
- EXAM 1 COVERS ALL MATERIAL UP TO THIS POINT
- Week 6 - Analysis - Midterm exam on Friday
- Week 7 - System Design I - Demo 1 on Friday
- Week 8 - System Design II
- Week 9 - Object Design I - Requirements Doc due Friday
- Week 10 - Object Design II
- SPRING BREAK
- EXAM 2 COVERS ALL MATERIAL UP TO THIS POINT
- Week 11 - Mapping Models to Code - Demo 2 on Wednesday, Midterm exam on Friday
- Week 12 - Testing - Design Doc due on Friday
- Week 13 - Rationale Management
- Week 14 - Configuration Management - Coding project test report due this week
- Week 15 - Classical Management, Methodologies, etc. - Demo3 and Final Report including Test Plan due on Friday.
-
Course Policies - Includes
instructor information and original planned schedule.
Questionnaire - Used for group formation.
John Bell's Home page,
including office information and links to current schedule.
TA 's Web Page
The Volere Web Site has free downloads of the specification template and the atomic requirement template, a.k.a. "shell" or snow card. Academic users ( i.e. students and teachers ) are exempt from the $50 requested donation, but you should be good enough to register your download(s) with your real contact information.
Programming Resources - Including Volere, IceScrum, RCS, VMware, Ubuntu, and more
Microsoft Software Program:
- Dale
Reed's Microsoft Software Program page
- MSDNAA Direct Web Site:
- Go to https://msdn01.e-academy.com/uic_cs
- Your login name is your CS e-mail address ( including the "@cs.uic.edu" ) This may be a temp account if you are enrolled in CS classes but are not a CS major.
- Your password should have been mailed to you at the beginning of the semester. ( To your CS account. ) If you need them to e-mail it again, there is a button on the page to do that.
ACM Web Site
Linux Users Group ( LUG ) Web Site
Project and Homework Documents
Old Pages