Difference between revisions of "DPS911"
m (→Course Outcomes) |
|||
| Line 18: | Line 18: | ||
* create appropriate technical and introductory documentation for a software product | * create appropriate technical and introductory documentation for a software product | ||
* devise and implement a QA and testing strategy in order to insure the quality of the software being produced | * devise and implement a QA and testing strategy in order to insure the quality of the software being produced | ||
| − | * apply the concepts, techniques and principles acquired in previous programming and open source courses to the programming of | + | * apply the concepts, techniques and principles acquired in previous programming and open source courses to the programming of an open source project |
* work within a community open source context, which means leveraging globally distributed tools and communication practices in order to include feedback in the development process | * work within a community open source context, which means leveraging globally distributed tools and communication practices in order to include feedback in the development process | ||
* participate in regular group meetings to review progress on the project | * participate in regular group meetings to review progress on the project | ||
Revision as of 13:54, 11 January 2018
Contents
Open Source Project
Subject Description
This course builds on the skills and knowledge developed in DPS909 by having the student take a partially developed open source project to completion. The student must have an open source project in progress, along with a faculty mentor and coordinator approval, in order to enroll. Through first-hand experience the student will learn what is necessary to take a working program and polish, refactor, and improve it on the way to making 1.0 product release.
Course Outcomes
Upon successful completion of this subject students should be able to:
- work on a real world software project
- complete an existing alpha stage project and release a piece of production quality software
- solve implementation problems by working with existing open source technical documentation and existing code
- work in a self-directed manner to plan and complete a major open source programming project
- create and post project planning and implementation information using on-line communication tools, for example: blogs, wikis
- develop and release software on a regular schedule
- use feedback gathered from school and community members to improve software
- create appropriate technical and introductory documentation for a software product
- devise and implement a QA and testing strategy in order to insure the quality of the software being produced
- apply the concepts, techniques and principles acquired in previous programming and open source courses to the programming of an open source project
- work within a community open source context, which means leveraging globally distributed tools and communication practices in order to include feedback in the development process
- participate in regular group meetings to review progress on the project
- create and give project demos, showing how the software works and where it is going in future releases
Major Project
This is a project course, and the student’s mark will come from work done on a real open source project. The goal of this project is to get students to move beyond "learning" and "hacking" on a piece of open source software, and to focus on creating something of excellent quality. Furthermore, students will be expected to create something of value within the community. As was the case in DPS909, given the nature of the project, students will be expected to work using an open and transparent methodology, one which enables and encourages collaboration with the open source community.
Details
- Each student must have an existing open source project, preferably something in the 0.3 range. Students who don't have a project, or who have a project of questionable value and potential, must work with their professor to find a suitable alternative quickly.
- Each student will create, or continue working on an existing project wiki page. All project documentation, releases, and other deliverables should go in this wiki page--nothing is to be handed-in by hand, and all marking will be done out of the wiki page.
- Students are expected to be self-directed and highly motivated. It is the responsibility of the student to make sure that projects move forward, and that external dependencies are resolved quickly (e.g., problems getting info from someone on-line).
- Given that the course will be run without formal classes, it is expected that all students will be active on IRC, the course wiki, and in any other appropriate on-line resources.
- Students will blog at least once per week. On your blog you should discuss the current iteration of your work, your thinking for future releases, and any interesting anecdotes or information about interactions with other people in the community.
- Update your personal page on the wiki with permanent information, such as a list of your contributions to various projects.
Intellectual Property
Given that this course is focused on open source development, all student work must be licensed using an appropriate open source license--probably the one used by the project of which your work is a part.
Grading
Detailed grading information will be discussed later in the term.
- 70% 7 bi-weekly releases marked at 10% each. Assuming a project at version 0.3, this represents releases 0.4 through 1.0
- Each release requires you to update your Project Wiki page, write a Blog post, and make your release/code available on the web or in bugzilla.
- 15% 3 project demos marked at 5% each. Demos will be done for your professor, but will also be marked as on-line artifacts; that is, you will be expected to do something that can be shown on-line (screencasts/screenshots, diagrams, blog posts, etc.)
- 15% final project presentation
