Tutorials and Labs start in Week 2 on Thursday January 14, 2016.
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 project submission the week after the submission date, 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.
2016-04-17: Final Marks
2016-04-09: Iteration 3 Marks
2016-04-05: Quiz 2 Marks and Iteration 2 Marks
2016-03-17: Tutorial Questions
Week 10: Testing
What is a unit test?
Define the following terms: error, fault, failure.
What is the difference between a test case and test data?
What are the things that we must describe for a test case?
What is the relationship between requirements (use case, scenario) and test cases?
Discuss "Testing can show the presence of bugs but never their absence."
What are the similarities and differences between functional testing and structural testing?
Explain how you can use unit testing and facades to implement integration testing?
What is regression testing? Why do we perform regression testing?
Explain the difference between system testing and acceptance testing.
Why do we call testing "dynamic verification"?
Explain the difference between verification and validation.
Using the V model for the waterfall lifecycle, explain the connection between the development steps
(requirements, architectural design, detailed design, coding), the steps to create test cases, and
the testing steps (unit testing, integration testing, system testing).
Be clear on when the steps are performed during the lifecycle.
What is debugging? What steps are involved? How do these steps relate to cohesion and coupling?
Define the terms: correctness, reliability, roubustness.
Explain how those terms (correctness, reliability, roubustness) differ from each other?
When you say "My program works!", which term are you referring to: correctness, reliability, roubustness?
Week 12: Structural Testing
What is a control flow graph?
Give two examples of programs and their control flow graphs.
Why is it a directed graph? What does that even mean?
What is coverage? How does coverage depend on a set of test cases? Is more coverage better than less coverage? Why?
Define the following coverage criteria: statement coverage, branch coverage.
Give an example of a program P and a set of test cases T, where T has statement coverage of P but not branch coverage.
Give an example of a program P and a set of test cases T, where T has branch coverage of P but not statement coverage.
What is a path in the control flow graph?
Give an example.
Give an example of a program P and a set of test cases T, where T has (simple) path coverage of P.
What is multi-condition coverage? And why should we care about multi-condition coverage?
Week 13: Functional Testing
What is a function mathematically speaking?
Why is functional testing called black-box testing?
What information do we use to develop functional test cases?
What is boundary value testing?
In boundary value testing, which values do we select in order to perform robustness testing?
What is equivalence partitioning?
What does it "partition"?
What is used for the basis of deciding "equivalence" or not?
Select a method m of a class C in you project where it makes sense to use boundary value testing,
and describe the range of values used by the method and the boundary (or boundaries).
Discuss how you would create test cases for the method using boundary value testing.
Repeat the previous question, this time illustrating an application of equivalence class testing.
2016-03-10: Quiz 1 Marks
2016-03-10: Tutorial Questions
Week 7: Design
Describe the goal of the Design Phase of the software lifecycle?
What documents are produced during the Design Phase?
What do the documents contain? Which UML diagrms do they use? Who reads the documents, and for what purposes do they read the document?
What do we mean by fitness of purpose of a design?
Explain the terms: modularity, (class) interface, cohesion, coupling.
Explain information hiding.
Explain the concept of design for change.
What is issue-driven design? How does it relate to design rationale?
How do they both relate to the design cycle and the major design decisions?
What is a construction plan?
Can you have a construction plan before you have a design?
Is OO development seamless?
Why, or why not?
What is the representation gap?
Following Jacobson's terminology, which kind of objects represent things in the domain model?
Week 7: Software Architecture
Why is software architecture a major issue for software engineering?
What is a software architecture? What does it describe? How is it used? By whom? And for what purpose?
Why are class interfaces so important in software architecture?
How do we perform quality control of a software architecture?
Describe the layered architecture. What are the principles behind a layered architecture?
How does a typical client-server architecture relate to the layered architecture?
How does a typical client-server architecture relate to the domain model in requirements?
Describe the Model-View-Controller architecture.
What are the principles behind the MVC architecture?
How is the Observer design pattern used in MVC?
What is the relationship between a typical client-server architecture and the MVC?
Week 8: Responsibility Driven Design
What is a responsibility?
Give a definition of responsibility.
What are the three kinds of responsibility?
How are responsibilities used in use case realization?
What is the relationship between design for change and the GRASP pattern Protected Variations?
What is the relationship between Jacobson's control object and the GRASP pattern Controller?
What are their relationship to the Controller of MVC?
Week 9: Design Patterns
What is a design pattern?
Why do we give them names?
Describe the following design patterns: Observer, Iterator, Composite, Proxy, Facade, Strategy.
Give an example of the use of each pattern using words and code segments.
2016-03-03: Do preliminary presentation of your system and document for Iteration 2 for Iteration 2 in lab tonight!
2016-03-02: Iteration 1 Marks
2016-01-28: Tutorial Questions
Week 3: Major Issues in SE
Why are these problem areas for SE: requirments, architecture, change, complexity?
What can go wrong in a software project due to requirments, architecture, change, complexity?
What is the impact or consequences of these things going wrong?
How do we try to prevent these things going wrong? Or lessen their impact?
Week 4: Test-driven development
What is a unit test?
What information do we need to write a unit test?
That is, what SE work must be done before we are in a position to start writing unit tests for a class?
What is test-driven development?
What are the advantages of writing the unit tests for a class C before writing the code for a class C?
What are the advantages of writing a test suite for the requirements before writing the code.
Explain how a test suite can be used as a substitute for uses cases
when coming to agreement with a customer as to what the system should deliver in terms of functionality.
How does test-driven development avoid redundant work in design and coding?
What is refactoring?
How does refactoring support test-driven development?
Why does the software need to be well-structured and well-organized?
Isn't it enough that the code works?
Week 4: Software process
What is a software process?
What does it process?
Who or what perform the steps in the process?
What information is needed during the software process?
What is a stakeholder?
Give some examples of stakeholders.
What concerns do the different stakeholders have?
Explain the differences between linear and iterative software processes?
How do the waterfall model and the spiral model act as baselines for comparing different approaches to software development?
Explain the following terms:
phase, activity, iteration, release, deliverable, milestone.
Suppose that you are doing a small project using code and fix approach.
How do you measure your progress towards completion?
That is, how can you determine a completion date to tell to the customer?
Suppose that you are doing a small project using test-driven development approach.
How do you measure your progress towards completion?
That is, how can you determine a completion date to tell to the customer?
What is agile software development?
What are the advantages and disadvantages of agile software development?
Week 5: Unified Process
What is a risk?
How doe we manage risks?
How is the unified process risk-driven?
Why does the unified process emphasize risks?
Why is the unified process architecture-centric?
How is the unified process use case driven?
Describe the phases and disciplines of the unified process.
What is visual modeling?
Why do UML and unified process emphasize visual modeling?
Why do we need models in software development?
Week 5: Principles
Why and how do people play such a major role in software development?
Explain the terms:
model, abstraction, generality, modularity, incrementality, separation of concerns, rigour, formality.
Describe at least 10 examples of separation of concerns that arise during software development.
What is the most common use of formality in software development?
For everything you have learned so far, how does it relate to the major problem areas for SE: requirments, architecture, change, complexity?
2016-01-21
There is only one tutorial and lab, now given by Samia Hilal. Go to H-537.
Do not worry about your actual registration fro tutorials and labs.
Due to students dropping the course, Team Y is to be disbanded. See Project Teams and Other Project Information.
2016-01-16
Please correct your registrations for tutorials and labs to be consistent with your teams:
Tut PA and lab PI: Teams U, T, S
Tut PB and lab PJ: Teams Z, Y, W, V
by the DNE date January 19, 2016.
2016-01-11: TAs are
Mostafa Erfani (mostafa.erfani@gmail.com)
Samia Hilal (samia.hilal@videotron.ca)
2016-01-11: Tutorial Questions
Week 1 SE and Software Process
What is a process? Give some examples of process for domains other than IT and engineering.
Why should a process be systematic, measurable in terms of cost, time, and resources, and documented?
What are the key differences between a small software development assignment, and a software engineering project?
As a developer on a SE project, who would you need to communicate with? Be as inclusive as possible.
Why is it recommended to follow the question - listen - paraphrase - report back - get confirmation process
when communicating?
How are risks handled in the Unified Process?
What are the common risks to a software project?
How do you mitigate risks?
Week 2 Requirements
Why do use cases focus on business goals and the business task of an actor?
Draw a UML class diagram to explain the relationships between actor, goal, use case, and scenarios?
Add main scenario, alternative scenarios, exceptional scenarios, recovery and failure scenarios to your UML class diagram
to explain the relationships between actor, goal, use case, and scenarios?
What is a stakeholder? List some examples of stakeholders.
What is a functional requirement?
What is a non-functional requirement?
Why does a requrement have to be testable?
2016-01-07:
Course Outline
Project Description.
Project Teams and Other Project Information.
Instructor: Dr Greg Butler, gregb@cs.concordia.ca
Office Hours - Dr Butler: Thursdays 16:00-17:00 in EV.003.219; or by appointment.
Tutors:
Mostafa Erfani for PA and PI
Samia Hilal for PB aand PJ
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.
Roger S Pressman, Software Engineering: A Practitioner's Approach, 7th edition, McGraw-Hill
Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edition, Prentice-Hall, 2005.
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: 23:59 Wednesday 3 February 2016
Increment 2 Due Week 9: 23:59 Wednesday 9 March 2016
Increment 3 Due Week 12: 23:59 Wednesday 30 March 2016
Project Demos
All teams should do a preliminary presentation of each Iteration in lab on the Thursday before the due date.
You do a formal presentation of the Iteration in lab on the Thursday after the due date..
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
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.
Submit a .tar.gz version of your source code (including JUnit tests).
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.
Submit a .tar.gz version of your source code (including JUnit tests).
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 - 7 January 2016: 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 - 14 January 2016: 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 - 21 January 2016: 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 - 28 January 2016: 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 - 4 February 2016: 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 - 11 February 2016: 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 - 18 February 2016: 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.
22-26 February 2016: Mid-semester break
Week 8 - 3 March 2016: 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 - 10 March 2016: 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 - 17 March 2016: 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 - 24 March 2016: Quiz 2.
25-28 March 2016: Easter - University closed.
Week 12 - 31 March 2016: 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 - 7 April 2016: 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.