![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Senior Design Project Topic Summary: Created On: 3-Aug-2005 14:44 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Senior Design Project
Instructor: Chuck Wallace Computer Science Email: [email]wallace@mtu.edu[/email] School: Michigan Technological University Houghton, MI USA Course description In this course, you will work with other students to create a real software product for real clients. In doing so, you will get experience in a wide variety of activities: Determining the objectives of your software development project, and developing a plan to accomplish them; Identifying the risks to your project, and taking steps to avoid or mitigate them; Communicating with the stakeholders in your software, to learn from them and to keep them aware of your progress; Documenting your product clearly and precisely, for the benefit of your users and future developers; Designing and verifying your software. Prerequisites Intro to Software Engineering Software Quality Assurance Course activities What you do in this course will be largely up to you and your team members. Every software project is unique, and part of the challenge for you is to determine the steps to take. However, there are certain things that every team will do. Kickstarting the process In the first class meeting, there will be a discussion of potential projects. I will have certain project ideas in mind; you are certainly welcome to present yours as well. Teams and projects will be determined by the second meeting. It is certainly my desire to assign each student to his "dream project", but this is not always possible. Each team will then define the project objectives and a preliminary timeline for attaining the objectives. The timeline will include both intermediate and final deliverables: actual products, such as reports or executable code, to be shared with your client. The first version of the timeline is due by the third meeting. Needless to say, the timeline will likely change over the course of the semester. Risk management Each project will follow the Spiral Model of software development. This process model structures software development as a series of cycles, each consisting of the following phases: Determine objectives (e.g. functionality, usability), alternative means of implementation (e.g. design A vs. design B vs. "off-the-shelf"; questionnaires vs. direct interviews for usability testing), constraints on application of alternatives (e.g. time, software compatibility, availability of users). Evaluate alternatives; identify and resolve risks. The unresolved risks at any point in the project are what drive the steps in later points. For instance, the risk of client uncertainty about the status of the project may drive the implementation of a prototype. Develop and verify next-level product. For a given cycle, this may include "coding" and "testing", in their most straightforward senses; on the other hand, it may involve something less programming-oriented (e.g. a written mock-up of a user interface, which is then validated by presenting it to the client). Plan next phases. Planning terminates with a review-and-commitment step, involving all the relevant stakeholders: this may be just the software development team, or it may extend to clients or end users. Journals Each team member will maintain a journal, in which he will record his individual activity each day. The journal will serve as a record of information pertinent to the project (e.g. information from client conversations, explanation of why design decisions were taken, problems with planning meetings). Journals do not need to be in perfect literary form, but they should be stored in electronic format and written in a way that is understandable to outside readers, like your team members and me. Weekly meetings Every week, each team will report in oral and written form on its progress. Ideally, these reports can draw from the information in team members' journals. In the weekly group meeting, the "spotlight" team for the given week will present its report to the entire class; the other teams will simply present their reports to me. Each report will include the following: discussion of the previous week's risks; explanation of work on avoiding or mitigating the risks, along with justification of the steps taken; presentation of the updated risk document; presentation of changes to the timeline. Every team member is expected to participate orally in every report. During meetings when your team is not in the spotlight, you are heartily encouraged to ask questions during the presentation. This will make things more interesting for you and will help your fellow students. Grading There are two ways to grade team projects. In the individual approach, each student receives a grade reflecting the quality of his work within his project, as reported in his journal. In the collective approach, all members of a team receive the same grade, based on the overall quality of the project work. I am happy to use either approach. Anyone who wishes to be graded individually must let me know, well before the end of the semester; students who do not request individual grading will be graded collectively. Grading will be based on the quality of the following: software project planning documentation (risk documents and timeline) deliverable materials journals meeting attendance and participation |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.