VIEWS: 31 PAGES: 3 POSTED ON: 11/3/2011
CTP 210 Term Project Course Description Specification, analysis, design, implementation, documentation and presentation of a medium-sized software system using by small teams under close supervision of a faculty advisor for each team. Teams will develop a software system, utilizing tools and techniques that they already know from previous courses and new ones that they will independently choose and learn during project development. Project Phases and Deadlines 1. Planning and Analysis (10%) Project planning and analysis is central to conducting a methodological software development effort. The students are required to develop documents on what they are to produce and how to manage the production effort. IEEE standards are taken as a baseline but are reduced to comply with the size of the projects. The deliverables and/or action items under this phase and some useful documents for each are listed below. Project Plan (PP) (%2.5): The project plan does give a short problem description list of activities, with individual responsibilities, dependencies, deadlines and the plan B (risk mitigation) in a compact document. The project plan has to prepared early in the project and updated if necessary. (guide) (reduced project plan template) (IEEE PMP standard). Analysis Report (AR) (%7.5): The analysis report systematically defines in detail the requirements of the software modules to be produced, from different perpectives. (guide) (reduced SRS template with UML and/or DFD) (IEEE SRS standard) 2. Design (15%) A systems design is essential to develop software in a coordinated fashion. Unless design entities are previously specified with their interfaces and behavioral models, integrating individual software components is very hard if not impossible. Design Report (DR) (10%): The design report decomposes the proposed solution into independent design entities (modules or components) with assigned names, goals and functionalities. Each design entity will be documented appropriate to its characteristics. Use of tables, figures, standards compliant UML and ER diagrams are necessary to communicate not only data models but also relationships and flow of events. (guide) (reduced SDD template with UML and ER diagrams) (IEEE SDD standard) Design Presentation (DP) (5%): The design presentation will summarize the problem statement, and the proposed solution to department faculty and guests from industry. The tools and techniques to be used will also be discussed. The presentation should also feture standards compliant UML and ER diagrams, and if possible a working prototype of the proposed system. (guide) (sample DPs from previous semester / not necessarily perfects) 3. Implementation (40%) The implementation phase of the project is the one with the longest duration. Therefore most efforts are spent during this time. In order to facilitate an almost linear distribution of efforts over weeks and a fair workload distribution among team members, many small milestones should be defined and many seperate deliverables will be required. Prototype Presentation (PP) (5%) : During the middle of the implementation phase, every team will have to demonstrate a running prototype of the system. The prototype should solidly demonstrate progress since the design presentation. (sample PPs from previous semester – not necessarily perfect) Final Presentation (IP) (5%): At the end of the semester every team will demonstrate the application to department faculty and guests from industry. This presentation should also include a checklist based requirements validation. Even though presentation grading is not on the quality of software deliverables but on the quality of the presentation, software deliverables are a pre-requisite for the presentation. A presentation with no actual software deliverable will be graded zero. (guide) (sample IP) Implementation Report (IR) (10%) : The implemantation report should assist users who will actually make use of the software. The user documentation should define the need and scope of the system and demonstrate use of all features of the system. To ensure consistency within user documentation, an ISO standard is used. The standard does not dictate how the documentation should be structures, all it does is to enable documentation developers to use a common set of formatting and similart criteria. (guide) (user manual template) (ISO user manual standard) Coding Quality (CQ) (15%) : The coding quality, that can either be manually observed or evaluted using software engineering tools and techniques show how good a software is structured with respect to aspects such as understandability and maintainability. Very small effort such as using a common coding style and commenting complicated algorithms can contribute vastly towards overall quality. (coding style guide) (testing guide) (list of tools for improving coding quality) (list of tools for documentation) Individual Performance (InP) (5%): Even though teams collaborate, some team members are over-performers, or some do stay behind even when hey contribute alot. There may be also similar reasons for under-performance These are based on behavioral preferences and can not be judged easily by looking at code deliverables. The supervisor is responsible for observing and improving the performance of individual team members, possibly through off the record performance improvement plans and action items. At the end of the semester, each team member is individually evaluated for personal attitude towards the project and personal performance improvement. 4. Weekly Progress (30%) Team members are required to report in to their supervisor at least once every week on a pre-scheduled basis. These scheduled meeting are integral to keeping the pace of the project and to early detect problems. At the end of each week, the supervisor evaluates the results and weekly progress of the team on individual basis. Contribution to some smaller project activities such as establishing a project group web site, using Moodle or email lists to notify others on updates will also be evaluated on this basis. Weekly Progress Reports (WPR) (30%): There will be a number of weekly progress reports prepared by the supervisor. The average of the individual scores for each team member will be used for the overall grading of that person at the end of the semester. (guide for attending meetings) 5. Attendance (5%) The weekly lectures aim at delivering both theory and practical insight into problems related to software project management. Thus attending to and participating in the weekly lectures is crucial. An important note on individual grading: Although the projects are assigned to teams, grading is done individually. In the past, there were letter grade differences in members of the same team, mostly due to individual performance observed in weekly meetings. This semester the individuality of grades is made more visible to the student. 40% of the total grading (weekly progress, individual performance, attendance) is directly individual and 15% of the grading (three presentations) is partially individual. Practically a team with very good project result could have a number of A's and a number of F's based on contribution to project objectives and team work.