Meeting Times

Lectures: Tuesday/Thursday 1-2:30pm in Agriculture 2C71
Tutorials: Wednesdays, 4-5:20pm in Physics 127

Instructors

Class Instructor: Nathaniel Osgood, Thorvaldson 280.6, 966-6102, osgood@cs.usask.ca
Office Hours: Thursday 3:30 – 5pm and by appointment.
Tutor & Marker: Yudi Xue, yudi.xue@usask.ca

Texts

Because of the diversity of material and topics covered, there are two recommended texts for CMPT 371, one required and one recommended. Each of the books listed is an outstanding reference for future work, and students are recommended to acquire both of the texts, although neither is required.

McConnell, S. (1998). Software Project Survival Guide. Redmond, Wash, Microsoft Press. ISBN 1-57231-621-7.
Available through the U of S library.

DeMarco, T. and Lister, T. Peopleware: productive projects and teams. Dorset House, 1999, 2nd edition. ISBN: 0932633439.
Available through the U of S library.

Additional readings from a variety of sources will be provided as PDFs on the course website.

Course Contents

The course follows up some of the software engineering issues discussed in CMPT 370. The focus is on the critical human side of software engineering: coordination and management of the software development process, project planning and estimation, risks and risk analysis, team building, contract design and negotiation, testing and software quality assurance, productivity, behavioral considerations, software configuration management, deployment and maintenance, training and help, software process standards, and software process improvement.

The completion of a significant group project, and the management and documentation of this project, and the staged delivery of quality products, are an essential part of the class. The project is focused on planning and measurement, the later stages of the software development process, as well as maintenance and deployment issues. Assignments and class participation will also contribute significantly to students’ grades.

All students must be properly registered in order to attend lectures and receive credit for this course.

Project

The project will continue the design and implementation of a course project from CMPT 370 or CMPT 371. As described more fully in the final section of this document, the project will be carried out in large project groups. There will be several stages in the development of the project (note that several of the stages are on-going throughout the project and some may be done in parallel):

• Gaining familiarity with the current state of the analysis, design, implementation, and testing of the project. This review should place a strong emphasis on reviewing the documents describing best practices, post mortems, and design recommendation from previous years.
• Planning new iterations in the development of the project, including adding new requirements. These iterations should be risk-driven, taken into account value delivered to users and salient uncertainties. The students required to offer deliverables at least 4 times during the term. To help keep you on course, we recommend (but do not absolutely require) more frequent deliverables, associated with sprints of 1 or 2 weeks in duration.
• Clear documentation of requirements
• Simple prototypes for the UI (mostly on paper) and for areas of particular risk
• Where possible, initial and ongoing contact with users to validate the requirements and receive feedback on product progress
• Carrying out these iterations, including appropriate testing and measurement to ensure the quality of the software that is developed, and active updating of documentation.
• Meeting 4 times during the term with “senior management” (professor and especially tutor) in a series of briefings to interact with them on the state of the project (please note that a possible consequence of such meetings could be changed or new requirements added during the project)
• Aggressive up-front and ongoing risk management, including through an accountable risk officer. This should include risk scanning on a periodic basis (at least once for each deliverable).
• Creation and updating of the identity and status of clear binary “mini-milestones” for the product
• Use of a version control system (e.g. subversion) for use by with all parties. It is essential that this system be used in a way that fosters not just individual version control, but team-wide coordination. The version control system will be available for ad hoc review by the instructor & tutor, and will be used for the following:
  1. Code Check-ins. Such check-ins will refer to design specification and the defect database
  2. an updated “Top 10 Risks” enumeration
  3. the project schedule
  4. task assignments to individuals
  5. mini-milestone list and status
  6. build/smoke test status
• Maintenance of a continuous build regimen, including automated smoke testing. There should be a clearly defined build team, and an infrastructure (such as with TeamCity, Maven, etc.) to provide feedback to the team on the state of the build and the broader state of the project.
• Appointment of a project manager to help coordinate the project
• Widespread use of assertions in your code
• Adherence to Test-Driven Development (where tests are written prior to the code).
• Use of a project wiki (Atlassian confluence is available at https://wiki.usask.ca)
• Maintenance of a defect database (e.g. Jira, see http://www.atlassian.com/software/jira).
• A code coverage testing framework (such as Emma).
• A logging framework (e.g. Log4j).
• Use of a style-checking system (such as Checkstyle, http://checkstyle.sourceforge.net/) to be run together with (continuous integration) project builds.
• A series of peer deskchecks and inspections on artifacts (with each person in the team having at least one artifact that is the subject of an inspection), and documentation thereof. Note that inspections are not limited to code, and can begin almost immediately on a project, including one the following:
  1. Risk inventory
  2. Requirements documents
  3. Testing plans
  4. Test cases
  5. Design documents
• Clear planning and documentation of tests, ideally prior to implementation, including an appointed testing team. This should include planning not just the testing steps but also the interfaces (“hooks”) and scaffolding (“harnesses”) needed to drive the system through key elements of its functionality.
• Rigorously testing the product, and documentation of that testing, in the form of a series of documented, maintained, peer reviewed tests. While not all of these tests need to be automated (indeed, some should not be), they all need to be described and those that are automated need to have results checked. Students are encouraged but not required to develop most tests prior to creation of the software itself. use of a testing framework, such as jUnit, nUnit, etc.
• For at least the final deliverable, an estimate of the fraction of undiagnosed defects, and corresponding refinements to the QA process
• Use of a mocking framework (e.g. JMock, Mockito)
• An activity log should be kept throughout the project to help provide the necessary information to compile the estimates of individual effort.
• Adherence to a documented process for governing requirements changes
• Handing in all project documentation at significant milestones
• Submitting a fully documented, rigorously tested and critically reviewed version of the system for each deliverable. The feature sets associated with each such deliverable are less important than its reliability and conformance to stated requirements.
• Use of a “three strike” system that involves the use of (virtual) “Yellow” and “Red” cards to indicate escalated levels of warnings for individuals. Individuals with Red cards must talk to class TAs or the professor to avoid high marking penalties.
• Preparing for the deployment and maintenance of the software, thorough user documentation, and an approach to user training
• We suggest that teams consider maintaining a set of dedicated testers, who will devote themselves to testing projects. These would include, but are not limited to, the following:
  1. Planning test strategies & test cases
  2. Selecting and familiarizing themselves with testing tools
  3. Identifying test platforms
  4. Ensure that Test-Driven development is being practiced
  5. Establishing appropriate logging
  6. Helping maintain the continuous integration test suite
  7. Organizing bug parties

Workload

The anticipated due dates and weighting for submissions for Project Related Deadlines and Other Assignments are as below; all dates indicate a deadline of midnight at the close of the specified day.

Project-Related Deadlines

Other Deadlines

Participation

Classroom Participation

In addition to the above deliverables, a significant fraction (5%) of students’ grades will be based on participation. In recognition of differences in communication styles and interests among students, this participation score will reflect interaction in lecture, tutorials, in project meetings at the beginning of class, and in office hours.

While it is understood that occasional absence from lectures is unfortunately sometimes necessary for health or other extraordinary considerations, students who are absent from class will be missing both course material of importance to functioning productively in the project and the team meetings to be held in the first 10 minutes of class (please see below). Students who are chronically absent from class sessions will naturally be at a great disadvantage when it comes to learning (and the marks that reflect it), but can expect both to receive very poor scores for participation, and will also be viewed as contributing less to the team project.

Project Participation

Participation in the team project is mandatory for all students. Students deemed to have inadequately contributed to the mandatory course project will receive an escalating pair of warnings, beginning with the receipt of a yellow (virtual) warning card from the instructor. It is the obligation of a student who receives a yellow warning card to make immediate efforts to arrange for a meeting with the professor or teaching assistant to discuss and resolve their situation. Failure by the student to adequately resolve the underlying concerns regarding participation can be expected to lead to the issuance of a red warning card from the instructor. Students receiving such a red card are at imminent risk of failure of the course, and it is incumbent open them to act immediately to make a meeting with the instructor to address these concerns, and to make all efforts to contribute to the project. Failure of a student to respond to either of these warnings will be taken as an indication that they agree that they are failing to contribute adequately to the project.

Peer Review of Student Artifacts

Students must have at least one artifact undergo a peer deskcheck review (either with or without the author present) for each deliverable. These artifacts may be pieces of code, but could also be other substantial components for the project, including design elements (including class diagrams), requirements documents, a risk management plan, tests, a testing plan, etc. The reviewer and author must sign off on a form that indicates the results of the review (including brief description of defects found or rework to be performed) when the review is complete. These reports must be submitted with the deliverable. In addition, each student is required to be present as a reviewer or other participant in at least two formal inspections during the term:

• An artifact associated with the inherited system.
• Artifacts produced by themselves (or themselves in conjunction with another person).

These inspections must be documented and signed off on by the inspection team. Students whose artifacts are not inspected for the term will have marks deducted. Students will be expected to participate in other reviews of artifacts produced by their peers during the course of the project. We suggest the use of the doodle scheduler for scheduling peer reviews.

Please note that some of the most critical of these meetings must be held prior to the first milestone, with the results reflected in that milestone and milestone presentation:

• Management plan review
• Risk management review
• Test Plan
• Design changes

Finally, may be management meetings, to be held at a mutual agreeable time for students, instructor and (especially) TAs.

Topic Plan and Readings

Lecture slides will be provided via the course website when possible but are not guaranteed for all classes. Selections from the textbook and other readings distributed electronically are shown below. Additional readings and URLs will be shown in the notes for the topic in question. There will also be some guest lectures scattered through the term, and frequent meetings with project management. There will also be tutorials as particular topics warrant (see below). A substantial portion of the class grade will reflect student participation, so, students should come to recitation (as well as lecture) prepared to discuss the assigned readings.

A preliminary lecture schedule is included below. The schedule has been designed to provide students with knowledge and skills that will enhance project success. Students are strongly advised to apply the techniques covered within class within their projects.

Please note that the schedule below is tentative and we expect that it will be revised throughout the term. Updated versions will be posted on the WebCT/Blackboard site, and the class notified via email.

NB: The schedule above – including the contents and dates of both lectures and management meetings – is subject to change. On occasion, updated schedules may be provided.

“X.n” denotes chapter number n within the source abbreviated by X (as described by the section on readings below). “X.ppN-M” denotes page numbers N through M within the source abbreviated by X.

Tutorials

Tutorials in CMPT 371 serve a variety of functions. These include review of topics raised in readings, guest lectures, discussion of examples of concepts raised in lecture, student presentations. Because of this variety of goals and the likelihood of changes in guest lecturers’ schedules, the schedule for topics to be discussed in recitation is particularly variable.

Readings

Readings for the course will be drawn from a variety of sources. The schedule above uses the abbreviations shown in the first column.

Homework Submission and Evaluation

All homework will be distributed and submitted electronically using the WebCT/Blackboard System.

Completed assignments and other deliverables are to be submitted before 12 MIDNIGHT on their respective due dates also shown in the course outline. Because feedback on the answers provided will be provided directly in the submitted file, it is important that you submit your homework in a form that is editable by MS Word or Excel. If you do not have access to the appropriate software, please submit in PDF format.

The grade of the course will be assigned on an individual and team basis. For the term project, the work is done by a set of students working together as a company. The team grade of the term project is obtained from the term project documents. From the term project grade, each member will get an individual term project grade depending on her/his efforts and contributions as evaluated by her/his peers in the group. Each individual will receive a grade equal to the term project grade times a multiplier. This multiplier can be lower or greater than one. The average of the individual grades will be equal to the team grade. Working effectively in a team is a precondition to get a good grade, but in the case that circumstances on the team create a difficult environment, individuals will not be blamed for the fault of others.

Problem sets that are prepared by a team will also be graded accordingly. The term project, problem sets, class participation and final exam collectively account for 100% of the grade.

10% per day may be deducted from late term project phases up to a maximum of seven days. Term project phases received more than seven days late may not receive any credit. Under certain circumstances extensions may be granted. Please contact the instructor or tutor prior to the due-date if an extension is required. Failure to complete the assigned course work will result in failure of the course.

Collaboration among students on problem sets or term project phases to be completed individually is limited to discussing concepts and clarifying issues. Nonetheless, each student is expected to produce his or her own solutions to the homework problems. For a further discussion, please see the section on Academic Honesty.

Collaboration among students on problem sets or term project phases to be completed as a team is encouraged. The team needs to submit only one document for the whole team.

As mentioned before, project grades are adjusted for each individual based on each individual’s contribution to the project. To establish individual contributions, a peer evaluation is performed during the final project phase. This evaluations will ask each team member to distribute a financial “bonus” among the team members, provide a recommendation for each member of the team, evaluate the effect of each member to the morale of the team, evaluate the contribution of the team member to the term project and assign a “title” to each member of the team including the person filling out the form. There is the expectation that such evaluation will remain confidential. It is also expected that team members will behave professionally and honestly while filling the evaluation. No consultation is permitted with other team members when or before filling out the evaluation.

It is worth emphasizing that because this coefficient influences the points accrued to the student from across the entire group project, a student’s level of involvement in the project may have a substantial impact on their final grade.

In addition to the above, the course includes a final exam. Failure to write the final exam will result in failure of the course. The final exam will include both a take-home and an in-class portion.

Students are expected to adhere to University of Saskatchewan Academic Honesty policy.

Project Description

Project Overview

CMPT 371 is a course about the management of the software development process. Participation in a real-world project is important in helping students internalize course material.

The project in CMPT 371 will continue the design and implementation of one of the course projects from the Fall 2007 version of CMPT 370. The CMPT 371 project will be carried out in randomly selected larger (7-10 member) groups. Effective management of such a large group to achieve stated project objectives will be critical to the success of the project. After the group has been put together, the first order of business will be to decide which CMPT 370 project to further develop and to get formal permission from those who built it to continue to work on it. Original CMPT 370 project objectives will then have to be revisited and possibly new objectives set.

A plan will have to be devised and put into effect to achieve the stated objectives. It is expected that the plan will include a number of elaboration cycles each delivering a highly stable version of the software, and incorporating increasingly sophisticated functionality. As the project proceeds, the plan will guide activities, but will always be subject to updating as circumstances change, so it will likely be quite specific only for the immediately approaching development cycles and fairly general for later iterations. In the end, the final project will be a high quality working system, fully documented and tested and measured, complete with a deployment plan (although it won’t actually have to be deployed!)

The emphasis for this deliverable will be on quality and not on quantity of features – the final deliverable should be as close to “industrial strength” as you can make it, and include adequate documentation to permit extension by another team if so required. The higher quality that is expected will require extra levels of care and planning. For example, each person in the class will be required to have all significant artifacts peer reviewed (see below), and we expect formal defect tracking and defect removal estimation. Please scope your projects accordingly.

In addition to outside arrangements made amongst themselves, students can plan on holding brief time- boxed project “scrum” meetings will be held in the first 5 minutes of each day of class, unless otherwise noted. To make best use of these meetings, we suggest that students refer to the following reference:
http://www.martinfowler.com/articles/itsNotJustStandingUp.html

Workload

There will be three presentations and four project major milestones during the course, and regular meetings with management. The requirements for each of these are now outlined.

Milestone 1

Existing system with source code repository, daily build and smoke tests, a mini-milestone list, list of risks, risk report, requirements, documentation of team personnel roles (which may include more than one role per individual), tests and hooks, documentation of code reviews. Statement of requirements to incorporate in successive deliverables throughout the semester should be clearly spelled out. A report of testing results should be included, including a defect reports for defects found.

Paper or simple GUI prototypes should be presented to describe user-oriented functionality for the Incremental Deliverable 2. The deliverable should also include a detailed plan for achieving the next milestone objectives. This plan should include a project CPM schedule outlining steps (mini-milestones) in carrying out the project and a critical path through this network. The plan may have sub-plans, corresponding to sub-goals established by the various work units into which the project has been sub- divided. An initial estimate of the size of the software for Incremental Deliverable 2 and the effort required to produce it should also be made.

The first milestone should include an activity report summarizing work undertaken by each group member to date, and the activity log (giving time estimates).

Initial analysis and design artifacts for Deliverable 2 should also be described. Some of these may have been inherited from the CMPT 370 project, others will be modifications of CMPT 370 artifacts, and still others will be freshly built.

Presentation 1

The first presentation will provide a project overview to management and other class members of Milestone 1, and should include a demonstration of the system as it is currently present, as well as a demonstration of status report information.

Milestone 2

In milestone 2 all project artifacts created or modified since the first milestone should be handed in, including updated planning, analysis, and design artifacts, as well as new artifacts: updated risk analysis (including results of new scanning), the version control strategy, the test strategy and testing done to date (including test results), and the latest measurements of software quality (e.g. results of code reviews). Code and interfaces should also be included. In a manner similar to what was done for milestone 1, you should indicate in detail what is planned to accomplish between now and milestone 3.

Unless special arrangements have been made with the instructor, the system should be in a working and stable state for this and other milestones. It is important for this presentation that you summarize not only what has been accomplished for the work products, but also for refining the development process – what you have learned or changed in the development or management process.

[NB: In order to inform the measurements of software quality, you may find it useful to get an early head start on some of the required readings on testing and QA processes, despite the fact that the due date for these readings lies only shortly before the Milestone 2 due date.]

Presentation 2

The second presentation will provide a summary of milestone 2, and a demonstration of the milestone 2 deliverable.

Milestone 3

Milestone 3 is similar to milestone 2 in contents and should include detailed discussion of the lessons learned from the project.

Presentation 3

The third presentation will provide a summary of milestone 3, and a discussion of what is planned for milestone 4.

Milestone 4 (Final Milestone)

Milestone 4 is similar to milestone 3 in contents, except that it summarizes work to be completed by milestone 5.

Presentation 4

This presentation will provide a summary of milestone 4, and a demonstration of the working system.

Milestone 5 (Final Milestone)

Milestone 5 is similar to milestone 4 in contents, except that no summary of work to be accomplished prior to the next milestone is included. Milestone 5 should, however, include detailed discussion of the lessons learned from the project.

Presentation 5

This presentation will provide a summary of milestone 4, and a demonstration of the final, completed system.

Inspections

Each member of a team is expected to have at least one significant artifacts they create undergo peer review via a peer deskcheck per milestone. Artifacts to be reviewed include requirements specifications, design specifications, tests, code, bug fixes, etc. This review will require signoff by both parties involved, plus an indication of any issues that were identified that require changes (and subsequent peer review).

Each person must also have at least one artifact inspected via a formal process described in class and in the readings during the course of the term. This process will involve pre-inspection review of documents by team members, rigorous note-taking, and follow-up. A tutor (TA) should be present at each such session, which will be graded on a pass-fail basis.

Some Important Issues

Group Work

Your group should divide the tasks in the project appropriately so that each member can work independently or in a smaller sub-group much of the time. However, effective group interactions will still be mandatory to complete the project successfully, as in CMPT 370 only more so! You are encouraged to communicate electronically using your mechanism of choice in a private area. Each lecture meeting will provide an opportunity to meet during the first 10 minutes of class (12:55-1:05), but you should all also physically meet separately (at least once a week) to make sure that everybody is on the same page. An agenda for each such meeting should be prepared beforehand, and minutes of the meeting should be kept. If group problems (e.g. caused by personality conflicts, slackers, etc.) start to occur, they should be nipped in the bud before they develop into real obstacles to success. You should try to solve the problems yourselves, perhaps at the regular meetings. As a last resort, you should approach the “higher management” (tutor, and – if absolutely necessary – the professor). Remember that managing such a large group has its own special disadvantages (too many cats, all going their own direction) but also its own special advantages (one problem worker doesn’t usually bring down the whole group). While experience suggests that some members of the class may not participate fully at all times throughout the semester, they do so at their own peril, and it is important that the project members welcome those individuals when and if they choose to make an effort to contribute.

As noted below, the final exam will survey individuals in your team as to the roles played and levels of effort expended by yourself and your teammates.

Presentation Timing

Each of the presentations will be scheduled for a full hour during a tutorial period. There should be 5 minutes at most for set up, 30-35 minutes for the presentation, and a 5-10 minute question period. Not all members of the team need to take part in any given presentation, but over the term everybody should stand in front of the class at least once.

Hand-in

At each project milestone, and in the final project, all appropriate artifacts should be handed in, using the same system used for course problem sets. The project should be appropriately packaged so each component is clear. There should be some sort of overview document and/or index to help the marker to understand the various parts of the project (and in the final project this should also contain instructions for running the system). Critically, these should involve a readme file in the main folder to direct the reader to the appropriate starting point.

Marking

The marking of term work in the course will be based upon meeting the objectives set above for each presentation, milestone, and the overall project. We will be looking for realistic outlook, sensible and responsive planning, comprehensible documentation aimed at practical communication for future teams that will extend this project, appropriate (communicational) use of the analysis and design techniques explored in earlier computer science courses (in particular CMPT 370), and in the later presentations and milestones also a solid risk analysis, thorough testing and measurement, good deployment planning (including training and help material). These artifacts should all be continuously updated as the project proceeds. The system developed at each milestone will be judged for its robustness, maintainability, usability, utility, and adherence to requirements.

Although all members of the group will share in the overall group mark for each presentation, at each milestone, and in the final project, it is possible that group members who do not contribute equally will be assigned only a portion of the group mark. Each of you will be asked on the final exam to indicate in both a qualitative and quantitative fashion the contribution of each member of the group contributed during the year. This information will be combined with the activity tables handed in during the course and appropriate adjustments will be made.