Bishop's coat of arms

CS 410, Software Engineering

This is the on line page for the Bishop's Software engineering class.
cs 410 class, Fall 2018

Presentations Nov 16, 21, 23

Each project has 15 minutes. Volunteer now to go first, soon I will assign your slots, ready or not.

>Last Quiz 3 on Friday, Nov. 9

covering testing and maintainence

Course Outline

Assignment 3, individually, one piece of code...

Now overdue. I wanted it by Nov. 2

Assignment 1, read something...

Short review of a current software engineering article.
Go to the library, find an interesting article about software engineering in one of the journals, and write a brief summary (and your comments, if any), by Friday,  January 14, 2018. A web source will be acceptable if it is seriously interesting. We will put these summaries in the binder kept in J-9(?).
Please include Author, Year, & Publication (book, journa, or web reference.)

At the library, go left past the circulation desk, continue into the room that says "Periodical Room"
Before you sit down on a comfy sofa, keep going until you come to the last round table on your right, behind that are shelves. (MPS as of Sept. 2014)
January 2017: The library is now in temporary location near the sports complex.
The recent Computer journals are on shelves, under QA76. (Older copies are bound and in the basement -- now unavailable, ask about electronic access.)

January 2018 The library is back. Ask directions to find the periodicals!

Kyle says: "I was surprised by the actual good amount of periodicals the library has for computer science, physics and music!"


This page now needs revision as to steps and dates...

I believe you have now formed yourselves into groups.
By Friday, 21 September, 2018 Will each group please submit to me a brief description of what you hope to do, and the names of the group members. If you are not part of a group, please let me know that.

2017 Projects Guidelines for what to submit

Progects will be presented near the end of the semester

Assignment 2, Requirements and Design

An on-line voting system for Canadian federal elections: Risks, problems, and solutions.

To be done in 2 parts: At beginning of class, to allow discussion.
  1. For Monday, January 30, Your view of requirements. What must this system do, what should it do. What are the constraints of the Canadian environment and of "over the web" systems? What are the risks?
  2. Design using Scenario's, Use Case and module or class decomposition. For Wednesday, February 1.

Project Documents (Winter 2013)

  1. Neural Nets
  2. Line 'Em Up
  3. J-9 Social Networking
Active design rewiews, Tuesday, 26 February -- Please look at these in advance, and be prepared
  1. as reviewers to answer questions posed by the designers, as well as make suggestions,
  2. as designers, to ask qestions to the reviewers, as well as explaining your design to them.
Each team might want to decide who will represent them as designer, and who will review each other project.

Fall 2014

  1. Guitar Frets
  2. Adventures of Lolo (reconstructing a classic video game)
    1. Class Diagram
  3. Classroom Finder
  4. Magic, the Gathering

Online voting sequence diagram

Showing the state of the blackboard, 9:50 Feb. 21. Thanks, Tegan.
The solid arrows show the normal scenario of a successful vote. The double-dashed arrows hint at abnormal scenaria of invalid credentials or voter trying to vote twice. We discussed the risk of too-strict authentication making it hard to vote, or too-lax allowing fradulent votes.

Useful Links

ACM code of ethics

Many readings - A useful course website
"Not a regular software engineering course," many papers for discussion.In particular, No Silver bullet.

Parnas & Clements,A rational design process: How and why to fake it

.. One of many on-line sources. Do your own Google search ...

Parnas, Software Aging

Seven Sins of the Specifier 

Humour: How Specs Live Forever

Maze problem description (2003)

This is the requirements for the project I suggested. In addition, the city rat project may want to use the same maze file format, for flexibility of changing the maze of sewer pipes.

By November 2, all your project documentation and code must be submitted, paper copies of documentation is optional, and printouts of code are unnecessary.

Order of preference:
  1. submit csc310 yourdirectory
  2. e-mail
  3. Access to a subversion repository
  4. Floppy disk
  5. Documents by Owl

Maintenance phase

Each group will get the project from another group, the above link is to the file with instructions and changed requirements. This phase will continue until June 16 at the latest. On June 17 there will be one last quiz, and each maintenance group will demonstrate their work.

References to some material on formal methods, from 2002 (what's left)
Petri nets, the best way to model concurrent and non-deterministic systems

Links on petri nets and other formal methods

The current project schedule is:  Behind schedule? -- Get it done by end of November


"What you plan to do." Should be written up and agreed to by me, Reviewed by a student outside the group -- by the class - done


Design documentation is needed for maintenance, it should answer somebody's question, "How do I find where that feature is implemented?" e.g. "Where is the logic for verifying that a chess move is legal?"

Top Level: (Architecture) by 23 February
Detailed (Module design) by - (hopefully done)

User documentation

How do I actually run it, what should I expect it to do? This should be developing in sync with the Req/Design/Implementation.


Parnas says the coding should go fast, remember? Working code by 22 November, with specification and design documentation that corresponds.  (see "How and Why to Fake it")


All the time!

Beta version: Goal of the Construction Phase, by the last week of classes

Here's how it will work.
  1. Each group will designate one person to act as resource and guide for their project.
  2. Other group members will be assigned to test another project. Give them the requirements and user manual by Tuesday at 4:30, and be prepared to help them get started, should the manual be unclear.
  3. All documentation and code should be accessible. One way to do this is to use the csc310 Subversion repository, as we did earlier in the lab. Some printed copies might be handy.
  4. Testers will proceed to try out the project, playing the game, writing articles or reading the online newspaper, etc.
  5. In the spirit of the Software Engineering Code of Ethics, "Be fair and supportive of your colleagues. In particular, ... review the work of others in an objective, candid, and properly documented way", as you all "participate in lifelong learning, ... improving your ability to create safe, reliable, and useful quality software ... and produce accurate, informative, and well-written documentation." (From principles 7: Colleagues, and 8: Self)
  6. Produce a joint report noting problems found, suggestions for improvement, and designating someone to look into each thing as appropriate. (Given the time constraints, some issues may be noted as subjects for future maintenance.)
  7. This report should be sent to me, the project group, and the testers by Friday morning.
  8. Work can continue in the Lab Friday afternoon, I will be there after 3:00 (pension meeting before that).


Based upon the reports received, each of you will be given a modest maintenance task.

by Lin Jensen. e-Mail: