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.
2014-04-24: Final Marks
2014-04-14: Increment 3 Marks
2014-04-03: Quiz 2 Marks
2014-03-11: Increment 1 and 2 Marks
2014-02-25: Quiz 1 Marks
2014-02-03:
Some sample quiz 1 questions for the short answer parts (each out of 5):
(a) Give an example of a class, and an example of a related association for that class, from your domain
model for increment 1 of the project. Define the class and the association. Explain why they belong to
the domain model.
(b) Describe a main scenario from increment 1 of the project. What is the goal of the scenario?
In what ways can the scenario go wrong?
(c) Explain the concept of a unit test. How can a unit testing framework like JUnit be used for testing subsystems and systems?
(d) Why is the requirements phase difficult? What can be done to reduce the problems that arise during the requirements phase?
2014-01-14: Given the drop in class numbers, Team 1 has been re-allocated across Teams 2 and 3 to give two teams of roughly 10 students. See Project Teams. Adjust roles accordingly.
2014-01-13: Labs in H-917 starting 14 January 2014.
2014-01-08: Project Teams Meet your team members as soon as possible, exchange contact information, and plan schedule. Do it tonight.
2014-01-08: The project information. for 2014 is the same as for 2013. The project is an iterative development of a spreadsheet utility.
2014-01-08: Labs begin in Week 2 of semester. Location will be announced.
Instructor: Dr Greg Butler, gregb@cs.concordia.ca
Office Hours - Dr Butler: Tuesdays 16:00-17:00 in EV.003.219; or by appointment.
Labs DI: Tuesdays 20:30-22:10 H-917 Lab Demonstrator Rupak Karmadhar (rupak.karmadhar@gmail.com)
The Course Outline for 2014 is the same as for 2013.
The software life cycle. IEEE and MIL standards for software documentation. Formal methods. Software architectures. Software design and prototyping. Interfacing and encapsulation. Use of libraries, frameworks, and CASE tools. Implementation and maintenance. Verification and validation.
This course is a 4-credit course with 3 contact hours (2.5 class hours) of lecture, and 2 hours of lab. Material is covered during lectures, 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.
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 4: 23:59 Monday 27 January 2014
Increment 2 Due Week 8: 23:59 Monday 3 March 2014
Increment 3 Due Week 11: 23:59 Wednesday 26 March 2014
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.
Tentative - subject to change.
Week 1 - 7 January 2014: Course Outline; Intro to Software Engineering.
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.
Reading: Pressman Chapters 1 Software and Software Engineering, 24 Project Management Concepts.
course outline,
slides
Landscape course outline slides.
Week 2 - 14 January 2014: Requirements.
Domain Model, use cases, scenarios, system operations and contracts.
Importance of domain model for data processing applications.
Reading: Pressman Chapters 5 Understanding Requirements,
6 Requirements Modeling: Scenarios, Information, and Analysis Classes.
slides
Optional Reading:
Twelve Requirements Basics for Project Success
Week 3 - 21 January 2014: Intro to Testing.
Introduction to testing: test plan, test suite, test case, test data.
Test infrastructure.
Reading: Pressman Chapters 17 Software Testing Strategies, 18 Testing Conventional Applications,
19 Testing OO Applications.
slides
Week 4 - 28 January 2014: Intro to Model-View-Control Architecture.
Typical Java application (the Model-View-Control architecture).
Reading: Pressman Chapters 9 Architectural Design, MVC (page XXX).
Java SE Application Design With MVC
Wikipedia MVC,
Wikipedia Swing Java UI classes
Article about Java UI classes amd MVC
slides
Week 5 - 4 February 2014: Principles of SE; Lifecycle Models.
Principles: Rigour and Formality,
Separation of Concerns,
Modularity,
Abstraction,
Anticipation of Change,
Generality,
Incrementality.
Waterfall model of lifecycle.
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.
Reading: Pressman Chapters 1 Software and Software Engineering,
2 Process Models, 3 Agile Development, 4 Principles that Guide Practice.
slides,
slides
Week 6 - 11 February 2014: Quiz 1; Design
Lecture on design starting 19:15.
Reading: Pressman Chapters 8 Design Concepts, 9 Architectural Design, 10 Component Level Design.
slides
17-21 February 2014: Mid-semester break
Week 7 - 25 February 2014: Design
Object-oriented development. Classes, objects, responsibilities, collaborations.
Design: responsibility-driven design; design patterns; use case realization; design rationale.
Reading: Pressman Chapters 8 Design Concepts, 9 Architectural Design, 10 Component Level Design.
slides
Week 8 - 4 March 2014: Architecture.
Components and connectors.
Layer, subsystem, module, package. Interface, protocol.
Layered architecture - layers, virtual machines.
Typical Java application (the Model-View-Control architecture).
Reading:
slides
Optional Reading:
Software Architecture: An Executive Overview SEI TR-003, 1996.
Week 9 - 11 March 2014: Validation and verification; Testing.
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.
Reading: Pressman Chapters 17 Software Testing Strategies, 18 Testing Conventional Applications,
19 Testing OO Applications. 15 Review Techniques.
slides
Week 10 - 18 March 2014: Design Patterns.
Design patterns.
Reading: Pressman Chapters 12 Pattern-Based Design.
slides
slides more on design patterns
Week 11 - 25 March 2014: Quiz 2.
Week 12 - 1 April 2014: Quality, Measurement, Metrics.
Reading: Pressman Chapters 14 Quality Concepts, 15 Review Techniques, 23 Product Metrics.
slides
Week 13 - 8 April 2014: Formal Methods.
Reading: Pressman Chapters 21 Formal Modeling and Verification.
slides