Docstoc

phases

Document Sample
phases Powered By Docstoc
					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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:31
posted:11/3/2011
language:English
pages:3