 |
Note that the information presented here does not necessarily reflect the most up to date syllabus or course information. Rather this information is intended to provide a general overview of course content from previous offerings.
Chanchal Roy, Thorvaldson 280.4, croy@cs.usask.ca
Please email me if you have any questions or to arrange a time to meet. There are no office hours.
Principles and techniques for developing software combined with the practical experience of creating a mid-size software system as a member of a software development team. Includes: teamwork; projects, planning and process; users and requirements; use cases; modeling; quality; software architecture; testing; GUI design, design principles, patterns and implementation; ethics; professionalism. Topics include:
CMPT 214 and 250.
Note: As of September 2007, course prerequisites will be: CMPT 214 and 270.3
September 2007: CMPT 250.6 will be replaced by 270.3 and 280.3.
Students with credit for 250.6 do not need to take 270.3.
Lectures will cover the course at a conceptual level. Tutorials and other special sessions will provide additional information and help, as needed, especially at the technical level. Stay tuned for details during the course.
Lectures: Mon Wed & Fri 10:30 – 11:20, Thorv 205A
Tutorials: Tue 16:00 – 17:20, Thorv 205A
15% Midterm/Quizzes
45% Project (Final Project 20%; several project milestones and presentation 25%)
40% Final Exam
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, Craig Larman, Prentice Hall, 2005.
Code Complete, Second Edition, Steve McConnell, Microsoft Press, 2004.
The major workload in this course is a group project accomplished in self-selected teams of four people. Your team registers a company with the instructor with the goal of creating a software product for the course. It will be important to choose an appropriately scaled project that is neither too big or too small. Discussions during the lectures will help establish your project scope. The milestones and the final project submission are the responsibility of the entire group, but grades will be assigned individually based on project results and individual contributions. As a result, grades may vary between team members. A work plan outlining the tasks assigned to each team member will be a part of each milestone submission. Teamwork is also a part of the project, and a portion of your grade will be assigned based on how well your team works together. The milestones focus on key deliverables for that stage in the project, but in order to complete the project in a timely fashion it will be important to work on deliverables from later stages early in the term.
The primary goal of the term project is to provide you with experience in planning, designing and building a realistic software product of your choosing. You will apply the various principles and techniques that you are learning in class. A part of your job is to determine the requirements for your software product based on your discussions with potential users. You will also be able to ask for clarification or check your assumptions with the instructor or a teaching assistant. A secondary goal is to give you experience in working with a group, which is how nearly all of the worlds software is produced. You should recognize right away that group management is a complicated and important activity, and you should plan on spending some of your project time keeping other members of the group informed, assisting one another, and generally ensuring that the group works well together. It is important that you keep track of group and individual hours spent on the project. Resolve group conflicts early!
You must form a group of 4 or less and let me know within Sep 20. Send me email if you have any queries about project selection.
All milestones are due at 11:59 PM on a Sunday (unless otherwise specified). Milestones not handed in by that time will be given zero. The only exception is for illness or medical conditions with a doctor’s note. Since partial marks may be given for partial solutions, make available what you have completed at the due date! The final project will be due by 11:59 p.m., on the last day of classes, December 3 (Friday), with no exceptions. This is because examinations start shortly thereafter and students cannot still be working on projects during the exam period.
At each milestone, your team will electronically hand in your project portfolio. The entire web site portfolio is to be archived, compressed and handed in using the department’s E–Handin system/Moodle. Hand in the entire portfolio at each milestone. Also, make sure that you keep backup copies of all project materials - if something goes astray for any reason, it is your responsibility to reproduce what was lost!In case there is any difficulty just email me your submission.
A compressed archive to be handed in using the E-handin system can be created on Unix with the following commands:
tar cvf milestone1.tar YourCompanyName
gzip milestone1.tar
Alternatively you may create .zip files using any of the popular archive/compression tools.
Note: Please make sure that you use relative links on all of your web pages so that the marker will be able to navigate your site when installed in a different location! Also ensure you use proper permissions on all files and directories for access by your group and marker.
First midterm: On or before October 11
Second midterm: On or before November 3
Third midterm: On or before November 15
1.5% Milestone 1: Early Project Definition (September 26)
1.5% Milestone 2: Final Project definition (October 3)
2% Project proposal presentation (TBA)
8% Milestone 3: Requirements and preliminary design (group) (TBA)
8% Milestone 4: Detailed design of work units (individual) (TBA)
4% Project presentation (group) (Last week of lecture)
20% Final project (group and individual) (Dec 3)
| Week | Week Of | Topic | Subtopic |
|---|---|---|---|
| 1 | Sep 6 | Introduction | The course: goals, content, workload, and expectations The course project |
| 2 | Sept 13 | Software Process | The nature of software and software engineering Software failures Software process models |
| 3 | Sept 20 | Software Projects | A case study Software projects, teams & planning Problem definition and system scope Basic cost estimation |
| 4 | Sept 27 | Analysis | Requirements and use cases Business and domain modelling |
| 5 | Oct 4 | Design | Model based development Introduction to design patterns, design principles Mapping designs to implementation |
| 6 | Oct 11 | Design | Design principles and patterns |
| 7 | Oct 18 | Design | Advanced design patterns |
| 8 | Oct 25 | HCI | Usability engineering GUI development |
| 9 | Nov 1 | Testing | Quality assurance, Basic testing methods |
| 10 | Nov 8 | Software Architecture |
Software architecture introduction SA styles, SA evaluation, |
| 11 | Nov 15 | Maintenance | The importance of maintenance Refactoring and re-engineering |
| 12 | Nov 29 | Project Presentation | Student project presentations, Professionalism and Ethics |
You will have access to the Department computing facilities on the third floor of the Spinks addition. Systems
Your project must be developed in Java (unless otherwise you are allowed to do so in another language) and must run transparently when accessed through the Department’s standard computing environment. Your analysis and design artifacts (including diagrams, documentation, test suites, interface designs, etc.) must be similarly transparently accessible (use a format such as PNG, JPEG, GIF, HTML or PDF). Your team will be assigned a web site (with access to perl cgi and php environments) and your project artifacts should be easily accessible from your main page with a standard browser. Apart from these constraints, the actual technology choices you make to implement your project are up to your team. However, you should note that the Department has a variety of software platforms and tools available on the machines in the laboratory that could be used in the project. These include the Java Platform, java.sun.com, with Java, JavaDoc, the Java Development Kit and JavaSwing, as well as tools such as Eclipse, www.eclipse.org, an open source platform that includes many tools including UML drawing tools; Microsoft Visio, office.microsoft.com, a drawing editor useful for creating UML diagrams and other figures; Red Hat Cygwin, www.cygwin.com, a Unix environment developed by Red Hat for Windows to be used for running regression tests and constructing executables; SVN, a popular version control system to manage concurrent access to your source code; and gVim, www.vim.org, a text editor commonly used by software developers to edit programs based on the Unix editor vi. Java servlets are also available, but require some lead-time to set up.
Your project can be structured as a web site, and should include a description of the product, and links to each project artifact. There should also be a clear indication as to which team member created which project artifacts.
The website for your project should be rooted within your company directory. In your company directory create a home page.
/YourCompanyName/index.html
All your project artifacts should be linked directly or indirectly from your home page. Project artifacts include source code, diagrams, executables, technical memos, test cases, scripts, and so on. Use file formats that are viewable with a typical web browser. For example, use JPEG, GIF, PNG or PDF for your diagrams, and NOT the Microsoft Visio format.
Use separate directories to organize your project artifacts. For example, your source code, Java classes, Java documentation, data files and any other documentation for your implementation could be organized into separate directories within an implementation directory, for example:
/implementation/source/
/implementation/classes/
/implementation/javadoc/
/implementation/data/
/implementation/testsuites/
/implementation/documentation/
Once again, you will need to be careful to distinguish the files that are attributable to a group member. Minimally, ensure that the author of a program is noted in the comments of the program. You may wish to organize individual contributions in subdirectories by NSID, or (perhaps more ideally) provide a web page for each individual that links to their contributions.
Scripts should be provided to compile the source code, run the program, and run the tests. You may use separate scripts to compile each component, and it is recommended that you use a Makefile; however, ensure that there are three high level scripts for making, running, and testing your program. If you are using Java as your implementation language, you are encouraged to create a .jar file in addition to compiling the classes.
/implementation/makeAll
/implementation/run
/implementation/runtest
/implementation/yourproductname.jar
A README file should be provided to explain how to use make, run and test your program. The file should also explain the organization of your implementation directory.
/implementation/README
