This page describes a project for an introductory course on software engineering. It focuses on learning the software process and the inter-relatedness of the activities in a project, rather than placing emphasis on the product itself.
The process emphasises
There are three or four iterations. Each iteration produces a working system: the increment.
The project is team-based. Each team of approximately 9 to 12 students is organised into three subteams of size 3 to 4.
There are three roles on the project:
Each subteam assumes a role of either Tester, Documenter, or Developer for the duration of an iteration. During the course of the three iterations, each subteam will play each of the three roles.
Note that the project is a team effort:
The standard software development environment in the department consists of
Your background should mean that you know these languages and tools, or know similar languages and tools, and can easily learn to proficiently use these languages or tools.
You should be competent in object-oriented software development, and be capable of producing working, well-tested, documented source code for software systems of moderate size.
You should know how to design an interface for a class. You should know how to use classes and design your own classes for software systems of moderate size. You should know standard data structures and standard algorithms.
You should know how to create a desktop application that is commandline driven, as well as one that has a simple GUI.
You should know Linux and Windows.
Should our system do ....? Your team is your customer. Not me. Jointly decide what you think the system should do. Keep it simple.
Must we use ...? You must use Java, JUnit, Eclipse, Latex, and UML. I prefer you use Rational Rose for UML as everyone on the team has access to it.
Would you accept diagrams made with Visual Paradigm Community Edition instead of Rational Rose? It must use standard UML, and interchange files with rational Rose. The issue is not the tool but sharing work with fellow team members (see above).
Can we use XML binding libraries to import XML files? Yes, you can use available open-source Java libraries.
Are there any restrictions on the Java libraries we can use? You can use available open-source libraries. The issue is that this should be a team decision, and libraries and tools must be available to all team members, either on ENCS lab machines, or open source.
The tutor said to contact you to set up a CVS repository for our group Use Google groups.
I do not know Latex. Must we use Latex?
Yes. Latex is a powerful, wide spread tool for document preparation, especially for technical documents.
It is no harder to learn than any programming language.
Here are some links.
Coming to Grips with Latex
Dr Grogono's Latex notes
Kile - an Integrated LaTeX Environment.
My advice is to get started on learning Latex as soon as possible, and look at the examples.
Note
Read these instructions carefully. Follow them exactly.
For use of the electronic submission system, you will need an ENCS login name and password.
Get one immediately, if you do not have one.
This is also required for students not from Concordia but from other Montreal institutions.
Submit to the EAS category exactly as listed, and not to any other category.
Note that you can submit to EAS as soon as you wish, and can re-submit again (and again) as you improve your code and documents.
EAS will timestamp each submission, and keep versions separate.
Submit formats exactly as requested.
Documents must be as pdf files and be readable.
Source code must be compressed using tar and gzip as indicated; otherwise they can not be read.
The link for the electronic submission systems is here. Documents should be submitted as "Project 1" and Source code as "Program 1".
The use case document (see an example) should contain a use case diagram to provide the context for the overall system, together with a description of the actors and the major use cases. Choose an appropriate level of detail for each use case. The document should also include a (problem) domain model consisting of a UML class diagram and explanatory text.
Latex template for use case document is here. Use 'pdflatex' to produce a pdf file.
Submit a .tar.gz version of your source code (including JUnit tests).
The link for the electronic submission systems is here. Documents should be submitted as "Project 2" and Source code as "Program 2".
Example of a design document.
Latex template for design document here. In section 3 there is one subsection per subsystem. Remove (comment out) the explanatory text in the template.
Submit a .tar.gz version of your source code (including JUnit tests).
The link for the electronic submission systems is here. Documents should be submitted as "Project 3" and Source code as "Program 3".
Document is a short summary of your test plan and test results: basically tell me how thoroughly you tested and whether there are still outstanding bugs or issues.
Example of a test document.
Latex template for test document here.
Make sure that each test is individually numbered. Regard inputs
with multiple effects/results as multiple tests, and number them
individually.
Note that you may have some common situations/scenarios such as
sample file contents, sample documents, sample screen positions, etc
used in many tests. Document and number them in a section for reference
in the test cases.
The test plan should indicate which test cases apply to which requirements,
and make it abundantly clear (traceable) that each requirement is tested.
Submit a .tar.gz version of your source code (including JUnit tests).
During the project, each student must keep a diary detailing every activity undertaken in relation to the project. Supply the date and time for each activity, together with its duration, a list of the participants, and a brief description of the activity. Provide a summary of the total time spent on the project for each week of the semester.
Keep the diary up to date as the semester proceeds. Keep it as a Latex document.
For each increment from 1 to 3, each student must individually submit their diary as a pdf file. Submit it as "Theory 1", "Theory 2", and "Theory 3" respectively.
The project is to develop a Spreadsheet Utility. This is a very simple, very limited utility.
A spreadsheet consists of a rectangular array of cells, where the columns are indexed by letters A..K, and rows are indexed by integers 1..10. Each cell contains a formula or a primitive value. A cell which contains a formula also has an associated computed value. The features of the simple spreadsheet utility are limited: select a cell, enter a primitive value or formula, automatic computation of cell values, load and save spreadsheets to file, and quit.
The only primitive values are of type real. Primitive values are real numbers, which must have at least one digit before the decimal point, and if the real number has a decimal part then there is at least one digit after the decimal point. The numbers may be negative.
Each cell in the spreadsheet has a default value, namely 0.0.
The formulas follow a simple grammar. Formulas are distinguished from primitive values by a starting equals sign ``=''. Formulas are the usual arithmetic expressions, with the usual precedence of arithmetic operators. There is no unary minus operator.
Formulas may refer to a cell contents by its cell_name, which is composed of a letter for the column name and a digit for the row name. There is no need for a space between the column name and the row name.
The grammar is
formula ::= ``='' expression
expression ::= [ expression add_operator ] term
term ::= [ term mul_operator ] factor
factor ::= constant
| cell_name
| ``('' expression ``)''
add_operator ::= ``+'' | ``-''
mul_operator ::= ``*'' | ``/''
constant ::= [ ``-'' ] DIGIT^{+} [ ``.'' DIGIT^{+} ]
cell_name ::= column_name row_name
column_name ::= LETTER^{+}
row_name ::= DIGIT^{+}
The grammar is given in extended BNF:
terminal characters are given in quotes,
terminal symbols like digits and letters are given in uppercase,
optional things are bracketed by square brackets ``['' and ``]'',
alternative things are separated by a bar ``|'',
and the superscript plus sign ^{+} means that the thing may be repeated
one or more times.
Basic Functionality for Increment 1
Basic User Interface for Increment 2
A grid of cells displaying the value of each cell.
An input line where formulas and primitive values for the selected cell are entered. Entering a carriage return on the input line signifies the end of that particular input, and initiates the automatic updating of all cells.
The input line can also used to enter filenames for files associated with the load and save commands. Entering a carriage return on the {\em input line} signifies the end of that particular input, and initiates the loading or saving of files.
A message line for displaying error messages, warning messages, and informative remarks.
For simplicity, the window size may be fixed, and each column may be a fixed width. Any display of a value in a cell may be truncated if it is too large to fit in the fixed column width.
Additional Functionality Possible in Increment 2 and 3
Scrolling: The restrictions on the dimensions of a spreadsheet are removed, so scroll bars are added to the user interface to allow the user to scroll left-right and up-down the cells of the spreadsheet.
Cut, Copy, Paste: Individual cells may be cut, copied, and pasted from a clipboard. When cells are copied they may contain embedded cell names. These cell names will be treated as relative_cell_names unless they are preceded by an ``@'' in which case they are treated as absolute_cell_names. Note that this means an extension to the grammar for formulas.
Display Formats A cell value may have a format associated with it. The choices of formats for the user are
``:M'' to indicate monetary format, ``:S'' to indicate scientific format, ``:I'' to indicate integer format,and nothing for the default format.