Instructor: Dr Greg Butler, gregb@cs.concordia.ca
Office Hours: Thursdays 1600-1700 in EV 3.219
TA: Shahida Chauhan chauhanshahida@gmail.com
TA: Dittimi Finide dittimi_finide@yahoo.com
Course Outline
Project Description for
Codenames game
Tutorials and Labs start in Week 2 on Wednesday January 16 and Thursday January 17, 2019.
Attend each week, and be prepared to show your work on the project.
You are expected to present your project submission the week before the submission date, to show that you are organized and documentation is done.
You are expected to present your final project submission during week 13, as part of the assessment.
Do!: Apply what you learn to develop software projects.
Think!: Think about what was easy, what was hard, and what seemed impossible.
Read!: Read other people's experiences and thoughts on how to make the hard things easier,
and how to do the impossible.
Read other people's code, too.
Experiment!: Try out new ideas, tools, and technologies for yourself.
2019-05-01: Final Marks
2019-04-30: Marks for Diary and Increments
2019-04-21: Marks for Increment 3
2019-04-11:
Marks for Quiz 2
You can see your exams 2pm-3pm Friday 12 April and 4pm-5pm Monday 15 April 2019 by sending me email saying at what time you will show up in my office.
2019-04-09: Marks for Increment 2
2019-04-04:
Iteration 3
Make sure you have unit tests for all your classes.
Make sure you submit a diary.
Make sure the diary is complete.
Make sure it is a pdf file.
2019-04-01:
Presentation
Bring your laptop! Check connectors in H-820 as most likely only VGA available.
The presentation should be about 10 minutes long. Summarize key features of your project. Highlight a few challenges encountered during the project. Present your lessons learned.
The demo should follow the presentation. It should be about 5 minutes long.
It should highlight 1 or 2 key aspects of the system.
Expect questions after the demo.
These are not part of the evaluation.
2019-04-01:
Test Document
For Iteration 3, follow the Latex template for the layout and contents of the document.
The Latex file tells you what to provide. However, the contents also depend on exactly
what test plan you developed to carry out the testing.
the scope of the sample Test Document is very large. They did significant testing.
You will most likely do much less. For whatever testing you did choose to include in your plan,
the sample document will show you what o describe.
2019-03-28:
To be clear on what you need to know about testing for Quix 2:
TDD; unit testing; unit testing in V-model;
verification, validation; correctness, robustness, reliability.
How did testing fit into Iteration 1 and 2 of the project.
2019-03-07: Marks for Quiz 1
2019-03-06: Marks for Increment 1
2019-01-27:
template for diary
link to example document for iteration 1 fixed.
2019-01-23:
For the project, you can use an MVC framework provided it follows the true, original MVC architecture
for desktop UIs, and not the (wrong) version for web interfaces.
It is however, very easy to develop an MVC architecture yourself. And a good learning experience.
2019-01-16: Labs PI, PJ, and PK take place in H-903.
2019-01-07: Watch here for announcemnts!
Software development process models (e.g. linear vs. iterative). Project management; roles, activities and deliverables for each software life cycle phase. Requirements management: analysis, elicitation, and scope. Architecture, design and the mapping of requirements to design and design to implementation. Traceability. Software quality assurance: verification, validation and the role of testing. Maintenance and evolution.
This course is a 4-credit course with 3 contact hours (2.5 class hours) of lecture, 1 hour of tutorial and 2 hours of lab. Material is covered during lectures, tutorials and labs. Through these three types of instruction you are taught the different perspectives of Software Engineering discipline : basic principles, formalisms, tools and team work. You will be learning a disciplined process of developing software and practicing it in a small project.
You should expect to average a total of 10 to 12 hours per week on this course. For individual weeks it will be much higher depending on your role in the project and the phase of the project. So plan your time accordingly.
Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edition, Prentice-Hall, 2005.
Roger S Pressman, Software Engineering: A Practitioner's Approach, 7th edition, McGraw-Hill
Another common software engineering textbook is:
Ian Sommerville,
Software Engineering, 7th edition, Addison-Wesley.
Students are required to complete a project in three parts (45%), submit an individual project diary (10%), and two quizzes (45%).
The project includes documenting requirements, design, and test plan and test results, as well as coding and testing. The project is a team project. Each part of the project requires a document as a deliverable (10%) and a source code deliverable (with unit tests) (5%).
Each student is required to keep a diary of their project activities and to submit their diary at each stage of the project. The diary is the basis for an individual project mark (10%).
Each quiz will be a closed book examination of at least one hour in duration. Each quiz is worth 22.5%.
Students must pass the quizzes in order to pass the course.
Your grade will depend on both your performance in the quizzes and your performance in the project. A poor performance in any single component may bring down your grade. There is no simple direct correlation between your total mark and the grade.
You should focus on the major phases of SE: requirements, design, coding, testing, maintenance. What is the main concern for each phase? What are the major problems? How are the problems addressed?
Know the terminology and use it correctly.
Know definitions, but know what the definition means, and why the concept is important and how it is applied/used.
Know the relationships/connections/dependencies between all the activities that go on in SE.
Know how to track progress of a SE project.
Know how to track quality of a SE project.
Know the Model-View-Control architecture, Observer design pattern.
Think about how the lecture material relates to your project work.
Quizzes typically have have three questions. Each question will have four parts, each requiring a short answer. Each part will have a mark out of 5, so each question has a mark out of 20.
Read each question carefully. Answer the question that is asked: do I want a definition, a description, a discussion, an example, etc. Write legibly. Write complete sentences.
Text that does not address the question that is asked, does not gain you any marks.
I mark your answers so that 3/5 is the mark for what I consider to be a good answer. A mark of 3/5 means that you know your stuff, and gave a good answer. A mark of 4/5 means that you understood the issues and used terminology accurately. A mark of 5/5 means that I could not ask for more in an answer.
On the raw mark scale per question, scoring 6-8 outof 20 is satisfactory while more than 12 out of 20 is very good to excellent.
A scaled mark is obtained by "bell curving" to an average of 65.0% and an sd of 13.5%.
As a guideline, a scaled mark of 65.0 would rank as a B (maybe low B+) as a grade; 50.0 would be C or below.
The emphasis of the project is on experiencing a complete software lifecycle rather than producing a gee-whiz final product. We want you to see how the phases and documents of the project relate to each other, to appreciate the point of trying to get it right the first time, but also having review mechanisms in place to catch mistakes (as they are bound to happen).
The system is built in three increments.
The project is done in a iterative fashion. Each iteration develops a working system. The first is a very basic system. The second has more features, but still basic in approach and scope. The third is close to a realistic system in scope, design, usability, and robustness.
Each increment will take three to four weeks. Each increment will have a document as a deliverable: a requiremenst document, a design document, and a test plan and report repectively for increment one, two, and three. Each increment will have source code as a deliverable including unit tests.
Increment 1 Due Week 5: 21:59 Sunday 10 February 2019
Increment 2 Due Week 9: 21:59 Sunday 17 March 2019
Increment 3 Due Week 12: 21:59 Sunday 7 April 2019
Project Demos
All teams should do a preliminary presentation of each Iteration in lab one week before the due date.
You do a formal presentation of the final submission in lab in week 13.
Marking Scheme
The document marking scheme is
The code and unit test marking scheme is as follows. Note that "code" includes the unit test code.
The diary is treated as a single submission consisting of three parts, one for each of the increments. The marking scheme is:
Late Penalty: There is a penalty of 10% of the assignment mark for each day that your assignment is late.
Iteration 1
The link for the electronic submission systems is here. Documents should be submitted as "project 1" and Source code as "programming_assignment 1", and your diary as "theory_assignment 1".
Use only the specified file formats for submission:
Submit a .tar.gz version of your source code (including JUnit tests).
Submit your document as a .pdf file.
Submit your diary as a .pdf file.
Remember that the Requirements Document must include all user stories.
Remember each student must submit a diary.
Each team assigns one student to submit source code and test code.
Each team assigns one student to submit the document.
More useful links:
Share latex Online latex editor
JUNIT tutorial
For use cases, scenarios, and domain modeling see the material on Requirements Engineering
that we will cover in class today.
Dr Sinnig slides on Requirements
Generic Interview Script
Use Case Writing Guidelines
SRS Template
UML Introduction
You must create you documents using Latex.
Here is some information:
Coming to Grips with Latex
Dr Grogono's Latex notes
Kile - an Integrated LaTeX Environment.
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.
Iteration 2
The link for the electronic submission systems is here. Documents should be submitted as "project 2" and Source code as "programming_assignment 2", and your diary as "theory_assignment 2".
Example of a design document. This is much more detailed and longer than you need to create.
Latex template for design document here.
In section 3 there is one subsection per subsystem.
Remove (comment out) the explanatory text in the template.
Required Elements:
(1) Detailed class diagram of all software classes (use UML package notation to indicate layers);
(2) Supporting Explanation which design principles / patterns have been implemented and why;
(3) For three (architecturally significant) user-goal level use cases, depict the main success scenario as a (design level) sequence diagram;
(4) Justification of your choice of use cases.
Use only the specified file formats for submission:
Submit a .tar.gz version of your source code (including JUnit tests).
Submit your document as a .pdf file.
Submit your diary as a .pdf file.
Iteration 3
Documents should be submitted as "Project 3" and Source code as "programming_assignment 3", and your diary as "theory_assignment 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.
Use only the specified file formats for submission:
Submit a .tar.gz version of your source code (including JUnit tests).
Submit your document as a .pdf file.
Submit your diary as a .pdf file.
Submissions
Note
Read these instructions carefully. Follow them exactly.
The link for the electronic submission systems is
here.
Documents should be submitted as "project 1" and Source code as "programming_assignment 1", and your diary as "theory_assignment 1".
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.
Diaries must be as pdf files and be readable.
Tentative - subject to change.
Week 1 - 10 January 2019: Course Outline; Intro to Software Engineering. Software Project Management. Software Processes
Software engineering: projects, phases, milestones, deliverables, people, tools, problems,
and some solutions.
Management, planning, scope, risks.
Major problems: requirements, architecture, change, complexity.
Putting it all together:
Aligning priorities on qualities,
Recognizing risks early,
Working system early,
Testing early.
Slides:
Course Outline Slides
Introduction to Software Engineering
Lifelong Learning of Software Development: For Your Information.
Major Issues in Software Engineering: For Your Information.
Teams, Conflicts, Meetings: For Your Information.
Reading: Pressman: Chapter 1 Software and Software Engineering; Chapter 2 Process Models; Chapter 3 Agile Development; Chapter 24 Project Management Concepts; Chapter 27 Project Scheduling.
Reading: Larman: Chapter 1 Object-Orinted Analysis and Design; Chapter 2 Iterative, Evolutionary and Agile.
Optional Reading: Sommerville: Chapter 1 Introduction; Chapter 4 Software Process; Chapter 5 Project Management.
Week 2 - 17 January 2019: Requirements.
Domain Model, use cases, scenarios, system operations and contracts.
Importance of domain model for data processing applications.
Slides:
Software processes
Dr Sinnig slides on Requirements
Generic Interview Script
Use Case Writing Guidelines
SRS Template
UML Introduction
Reading: Pressman: Chapter 5 Understanding Requirements; Chapter 6 Requirements Modeling: Scenarios, Information, and Analysis Classes; Chapter 7 Requirements Modeling: Flow, Behaviour, Pattern, and WebApps.
Reading: Larman: Chapter 5 Evolutionary Requiremnets; Chapter 6 Use Cases; Chapter 9 Domain Models; Chapter 10 System Sequence Diagrams.
Optional Reading: Sommerville: Chapter 6 Software Requirements; Chapter 7 Requirments Engineering Processes; Chapter 8 System Models.
Optional Reading:
Twelve Requirements Basics for Project Success
Week 3 - 24 January 2019: Test-Driven Development and Refactoring.
Introduction to testing: test plan, test suite, test case, test data.
Test infrastructure.
Reading: Larman Chapter 21 Test-driven development and Refactoring.
Reading: Pressman: Chapter 17 Software Testing Strategies; Chapter 31.4.7 Test-driven Development; Chapter 8.3.10 Refactoring.
Optional Reading: Sommerville: Chapter 17 Rapid Software Development; Chapter 21 Software Evolution.
Week 4 - 31 January 2019: Intro to UML and OO Fundamentals.
Review of OO, Java, and UML.
Slides:
TDD and Refactoring
Dr Sinnig slides on OO Fundamentals
UML Introduction
Reading: Larman: Chapter 14 On to Object Design; Chapter 15 UML Interaction Diagrams; Chapter 16 UML Class Diagrams.
Optional Reading:
Java SE Application Design With MVC
Article about Java UI classes amd MVC
Week 5 - 7 February 2019: Principles of SEs. Recap on Software Processes.
Principles: Rigour and Formality,
Separation of Concerns,
Modularity,
Abstraction,
Anticipation of Change,
Generality,
Incrementality.
Agile, iterative development; test-driven development; the V model.
Unified Process approaches to the problems.
Inception: major risks and use cases.
Elaboration: complete risk analysis, most use cases, architectural baseline, development plan.
Construction: incremental construction.
Transition: deployment to customer.
Slides:
Principles of SE
Unified Process
Reading: Pressman: Chapter 4 Principles that Guide Practice; Chapter 8.3 Design Concepts; Chapter 2 Process Models.
Reading: Larman: Chapter 2 Iterative, Evolutionary and Agile.
Optional Reading: Sommerville: Chapter 2 Socio-technical Systems; Chapter 4 Software Process; Chapter 25 Managing People.
Week 6 - 14 February 2019: Quiz 1; Design --- Architecture.
Lecture on design starting 19:15.
Components and connectors.
Layer, subsystem, module, package. Interface, protocol.
Layered architecture - layers, virtual machines.
Typical Java application (the Model-View-Control architecture).
Reading: Pressman Chapter 9 Architectural Design; Chapter 10 Component-Level Design.
Reading: Larman Chapter 13 Logical Architecture and UML Package Diagrams.
Optional Reading: Sommerville Chapter 11 Architectural Design; Chapter 12 Distributed Systems Architecture; Chapter 13 Application Architectures.
Optional Reading:
Software Architecture: An Executive Overview SEI TR-003, 1996.
Week 7 - 21 February 2019: Design - Detailed Design.
Object-oriented development. Classes, objects, responsibilities, collaborations.
Slides:
Design
Detailed Design
Software Architectures
Reading: Pressman Chapter 8 Design Concepts; Chapter 12 Pattern-Based Design..
Optional Reading: Sommerville Chapter 14 Object-oriented Design.
25 February to 1 March 2019: Mid-semester break
Week 8 - 7 March 2019: Design - GRASP and Responsibility-Driven Design.
Design: responsibility-driven design; use case realization; GRASP patterns for assignment of responsibility.
Slides:
Software Architectures
Responsibility-Driven Design
Reading: Larman Chapter 17 GRASP: Designing Objects with Responsibilities; Chapter 25 GRASP: More Objects with Responsibilities.
Week 9 - 14 March 2019: Design - Design Patterns.
GoF (Gang of Four) design patterns.
Slides:
Design Patterns
Reading: Pressman Chapter 12 Pattern-Based Design..
Reading: Larman Chapter 26 Applying GoF Design Patterns.
Week 10 - 21 March 2019: Software Testing - Introduction.
Validation, verification.
Introduction to testing: test plan, test suite, test case, test data.
Test infrastructure.
Introduction to testing: error, fault, failure; verification, validation;
correctness, robustness, reliability.
Approaches to creating test suites/test cases/test data.
Slides:
Testing - Introduction
Reading: Pressman Chapter 16 Software Quality Assurance; Chapter 15 Review Techniques; Chapter 17 Software Testing Strategies.
Optional Reading: Sommerville Chapter 22 Verification and Validation; Chapter 23 Software Testing; Chapter 27 Quality Management.
Week 11 - 28 March 2019: Quiz 2.
Week 12 - 4 April 2019: Structural Testing.
Slides:
Structural Testing
Reading: Pressman Chapter 17 Software Testing Strategies; Chapter 18 Testing Conventional Applications; Chapter 19 Testing Object-Oriented Applications.
Optional Reading: Sommerville Chapter 23 Software Testing.
Week 13 - 11 April 2019: Functional Testing.
Slides:
Functional Testing
Reading: Pressman Chapter 17 Software Testing Strategies; Chapter 18 Testing Conventional Applications; Chapter 19 Testing Object-Oriented Applications.
Optional Reading: Sommerville Chapter 23 Software Testing.