View source for COMP354 - fall 2005

==Course Description==

'''COMP 354 Software Engineering I''' (4 credits)

Prerequisite: COMP 352; ENCS 282. Principles of software development and maintenance. Software lifecycle models and deliverables: requirements analysis and specification, architectural and detailed design, implementation, verification and validation. People, product, and process issues: team dynamics, communication, presentations, reviews. Lectures: three hours per week. Laboratory: two hours per week. Tutorial: one hour per week. NOTE: Students who have received credit for COEN 431 may not take this course for credit.

==Course Schedule and Contacts==

{| {{simpleTable}}
! {{tableHeaderCell}} | component 
! {{tableHeaderCell}} | day  
! {{tableHeaderCell}} | time 
! {{tableHeaderCell}} | location  
! {{tableHeaderCell}} | instructor
! {{tableHeaderCell}} | e-mail address
|-
|| lecture E       || <tt>-T-J---</tt> || <tt>11:45-13:00</tt> || <tt>CL-220</tt>     || Paquet, J. || paquet@cse.concordia.ca
|-
|| office hours    || <tt>---J—--</tt> || <tt>15:00-16:00</tt> || <tt>EV-3-221</tt>   || Paquet, J. ||
|-
|| tutorial EA     || <tt>-T-----</tt> || <tt>13:15-14:05</tt> || <tt>CL-225</tt>     || Vassev, E. || i_vassev@cse.concordia.ca
|-
|| laboratory EA-EI|| <tt>---J---</tt> || <tt>14:15-16:15</tt> || <tt>H-929</tt>      || Vassev, E. || 
|-
|| tutorial EF     || <tt>-T-----</tt> || <tt>13:15-14:05</tt> || <tt>CL-227</tt>     || Wan, K. || ky_wan@cse.concordia.ca
|-
|| laboratory EF-EJ|| <tt>---J---</tt> || <tt>14:15-16:15</tt> || <tt>H-929</tt>      || Wan, K. ||
|}

==Examinations Schedule==

{| {{simpleTable}}
! {{tableHeaderCell}} | week                     
! {{tableHeaderCell}} | date 
! {{tableHeaderCell}} | examination 
! {{tableHeaderCell}} | topics 
|-
|| week 6
|| oct 13
|| quiz #1 
|| 
*processes
*requirements 
|-
|| week 13
|| dec 1
|| quiz #2 
|| 
*specifications
*design
*testing
*maintenance
|}

==Homework and Project Assignments Schedule==

{| {{simpleTable}}
! colspan="2" {{tableHeaderCell}}| due
! {{tableHeaderCell}}| assignment 
! colspan="2" {{tableHeaderCell}}| available 
|-
|| week 4
|| sep 29
|| [[Media:Homework1.354.2005F.pdf|homework assignment #1]]
|| week 2
|| sep 13
|-
|| week 9
|| nov 1
|| [[Media:Homework2.354.2005F.pdf|homework assignment #2]]
|| week 6
|| oct 11
|-
|| week 11
|| nov 17
|| [[Media:Homework3.354.2005F.pdf|homework assignment #3]]
|| week 9
|| nov 1
|-
||
||
||
||
|| 
|-	
|| week 2
|| sep 15  
|| project proposal
|| week 1
|| sep 8
|-
|| week 5
|| oct 6
|| [[Media:Deliverable1F2005.doc|project deliverable #1]]
|| week 2
|| sep 13 
|-
|| week 9
|| nov 3
|| [[Media:Deliverable2F2005.doc|project deliverable #2]]
|| week 5
|| oct 4
|-
|| week 15
|| dec 12
|| [[Media:Deliverable3F2005.doc|project deliverable #3]]
|| week 9
|| nov 1
|}

==Lecture Schedule and Material==

{| {{simpleTable}}
! {{tableHeaderCell}}| wk 
! {{tableHeaderCell}}| date
! {{tableHeaderCell}}| event
! {{tableHeaderCell}}| topics
! {{tableHeaderCell}}| material
|-
|| week 1
|| sep 6<br>sep 8
|| 
*handout: project description
|| 
*[[Introduction to Software Engineering|introduction]]
*team project
||
|-
|| week 2
|| sep 13<br>sep 15
|| 
*due date: project proposal, team members
*handout: project deliverable #1
*handout: homework assignement #1
||
*[[Software Development Phases|development phases]]
*[[software process]]
*[[Build-and-fix model|build-and-fix model]]
*[[Waterfall Model|waterfall model]]
*[[incremental models]]
||
|-
|| week 3
|| sep 20<br>sep 22
||
||
*[[prototyping]]
*[[spiral model]]
*[[extreme programming]]
*[[unified process]]
||
*[[Media:RUP.pdf|unified process]]
|-
|| week 4
|| sep 27<br>sep 29
||
*due date: homework assignement #1
||
*[[requirements]]
*[[use case approach]]
||
*[[Media:SlidesUCDA.pdf|use case approach]]
|-
|| week 5
|| oct 4<br>oct 6
||
*due date: project deliverable #1
*handout: project deliverable #2
*handout: homework assignement #2
||
*[[specifications]]
*state transition diagrams
*decision tables
*the Z language
||
*[[Media:Specifications(slides).pdf|specifications]]
|-	
|| week 6
|| oct 11<br>oct 13
||
*quiz #1
||
*[[implementation]] 
*coding standards
||
|-
|| week 7
|| oct 18<br>oct 20
||	
||
*[[design]]
*architectural design
*conceptual design
*module interfaces
*detailed design
||	
*[[Media:Design(slides).pdf|design]]
|-
|| week 8
|| oct 25<br>oct 27
||
||	
*good design principles
*[[testing]]
*testing concepts
*testing phases
||
|-
|| week 9
|| nov 1<br>nov 3
||
*due date: homework assignement #2		
*due date: project deliverable #2
*handout: project deliverable #3
*handout: homework assignment #3
||	
*unit testing
||	
|-
|| week 10
|| nov 8<br>nov 10
||	
||	
*integration testing
*system testing
||
|-
|| week 11
|| nov 15<br>nov 17
||
*due date: homework assignment #3
||
*[[capability maturity model]]
||
*[[Media:CMM(slides).pdf|CMM]]
|-
|| week 12
|| nov 22<br>nov 24
||
||	
*[[maintenance]]
||
|-
|| week 13
|| nov 29<br>dec 1
||	
*quiz #2
*due date: project deliverable #3
*project demonstration
||
||
|}

==Tutorial and Laboratory Schedule==

{| {{simpleTable}}
|-
! {{tableHeaderCell}} | '''week'''
! {{tableHeaderCell}} | '''tutorial topic''' 
! {{tableHeaderCell}} | '''laboratory topic'''
|-
|| week 1
|| 
*project setup & information
*formation of teams
*process models
||
|-
|| week 2
|| 
*functional versus nonfunctional requirements
*use case (requirements & specifications) modeling
||
|-
|| week 3
|| 
*discussion on homework assignment #1
||
*use case modeling using Rose and Visio
|-
|| week 4
|| 
*discussion on project deliverable #1
||
*graphical rendering in the project
*Java/C++
|-
|| week 5
|| 
*material review for quiz #1
||
*Java/C++
|-
|| week 6
|| 
*discussion on homework assignment #2
*class (design) modeling
||
*Java/C++ and patterns
|-
|| week 7
|| 
*discussion on project deliverable #2
*class (design) modeling
||
*Java/C++ and patterns
|-
|| week 8
|| 
*discussion on project deliverable #2
||
*project support (Rose and Visio)
|-
|| week 9
|| 
*discussion on homework assignment #3
*testing
||
*project programming support
|-
|| week 10
|| 
*discussion of project deliverable #3
||
*project programming support
|-
|| week 11
|| 
*material review for quiz #2
||
*project testing support
|-
|| week 12
|| 
*discussion of project deliverable #3
*testing
||
*project testing support
|-
|| week 13
|| 
*general project support
||
*general project support
|}

==Course Material==

*[[Media:Syllabus.354.2005F.pdf|Course outline]]
*Unified Modeling Language [ [[Media:IntroUML.pdf|1]] ] [ [[Media:UMLBasicStructuralModeling.pdf|2]] ] [ [[Media:UMLBasicBehavioralModeling.pdf|3]] ] [ [[Media:UMLArchitecturalModeling.pdf|4]] ] [ [[Media:UMLAdvancedModeling.pdf|5]] ]
*[[Media:phase1final.pdf|Example for project deliverable 1]]
*[[Media:phase2final.pdf|Example for project deliverable 2]]
*[[Media:phase3final.pdf|Example for project deliverable 3]]
*[[Media:SherryWangMajorReport.pdf|Example using another template (3 phases in one document)]]

==Project Description==

You have to build a game that is an equivalent of the game "Conquest" [http://www.windowsgames.co.uk/conquest.html], a clone of the popular board game "Risk". You have to extract all requirements by downloading and inspecting the free version of the game. All features of the game must be listed in your initial requirements document in deliverable 1. You also have to analyze these requirements by giving them relative importance and an evaluation of the difficulty of implementation. When setting up your project plan (also in deliverable #1), you have to specify in what order the requirements will be implemented, as well as restricting the scope of the project by eliminating some features if you find that some are too much time consuming or difficult to implement. However, there are some mandatory features that are to be implemented in all projects (some not being part of the original game) :

# The game must be playable in text mode, using windows with fields showing the relevant information of the game, as well as buttons and menus to control the game execution.
# The map must be customizable, i.e. one can define what countries are part of the map, give them names, and specify their neighbouring countries. For example, this could be done using a matrix. The engine of the game execution must be able to run a game with any valid map configuration without recompiling the game. 
# A computer player must be available. It does not need to act intelligently, but must be able to take a turn without user interaction, meaning that the game can execute with no user interaction by using only computer players without human players. 
# A save game feature (and the corresponding loag game counterpart) must be available.