Project Plan rit online Learning Peer Evaluation Version 5 Prepared by: Team Green Apple

Download 0.56 Mb.
Size0.56 Mb.

Project Plan
RIT Online Learning Peer Evaluation

Version 1.5

Prepared by:

Team Green Apple

11 May 2006

Revision History



Reason For Changes


Amber Bahl


Template Creation


Amber Bahl


Project Overview


Amber Bahl


Management Structure


Amber Bahl


Planning and Control


Amber Bahl


Technical Process


Amber Bahl




Amber Bahl


Updated for Final Release


Table of Content

Table of Content 3

1. Project Overview 3

1.1. Project scope 4

1.2. Major software functions 4

1.2.1 Setup 5

1.2.2 Evaluation 5

1.2.3 Reporting 5

1.3. Deliverables 5

2. Management Structure 7

2.1. Project Lifecycle 7

2.2. Project Organization 7

2.2.1 External Interfaces 7

2.2.2 Internal Structure 7

2.2.3 Roles and Responsibility 8

2.2.4 Staffing 8

2.3. Risk Management 9

2.3.1 Top Risks List 9

2.3.2 Risk Mitigation Strategy: 9

3. Planning and Control 10

3.1. Estimation Method 10

3.2. Resource Identification 10

3.2.1 Staff 10

3.2.2 Time 10

3.2.3 Cost 10

3.3. Resource allocation 11

3.3.1 Work Breakdown Structure 11

3.3.2 Schedule 11

3.4. Tracking and control 11

3.4.1 Milestones 12

3.4.2 Reporting 13

3.4.3 Estimation Refinements 13

4. Technical Process 13

4.1. Methods, Tools and Techniques 13

4.2. Technology 14

4.2.1 Environment 14

4.2.2 Methods, Tools and Techniques 14

4.3. Project Artifacts 15

1.Project Overview

The RIT Online Learning department is in need of an online peer evaluation system that can enhance the collaborative learning experience. Currently, peer evaluation is supported by the use of online surveys provided by the RIT Clipboard system, which is difficult to setup and lacks good reporting functionalities. As a result, instead of using the tool as part of the early collaboration process where interventions can be apply part way into the project, it is often only used as a determinant of the project final grade. Our team will be responsible to deliver a standalone online evaluation system that will allow easy peer assessment and provide effective feedbacks without burdening faculty and students. The system will be built with future integration into myCourses or other online collaboration systems in mind. The product must be capable of providing multiple levels of access to these carrying sets of functionality.

The product will be a web-based application with functionality that can be determined by the access of user. Creating the product for internet use ensures multi-platform capability without a need for substantial overhead needed to convert the product to function for multiple specific platforms. Multiple levels of access are required in order to properly accommodate both administrative as well as client user functionality.
The administrative staff will have the highest level of access. They will be able to browse all available information and will also be responsible for assigning users a level of access.
The Scrum methodology will be followed by the development team to deliver this application. This project will be completed by a single development team in a span of 15 weeks. Like other Scrum teams this team will mainly consist of a Scrum Master, Product Owner and a group of developers. This project team will typically comprise of developers, QA, UI designers etc. This process model will help mitigate potential risks by providing multiple iterations of development and customer feedback. This process model will also provide backlogs to customer as well as management in order to assess progress.

1.1.Project scope

The online peer evaluation system can be broken down into three parts: Setup, Evaluation, and Reporting. For the setup, the system needs an easy way for faculty to create groups and add students into group. The setup functionalities will eventually be integrated to the group structure feature provided by the myCourses management system. For evaluation, it is ideal that the faculty can customize their own set of questions, but initially, a static sample of questions will be used. For reporting, the system needs to provide an effective, preferably graphical, representation of the evaluation results. Faculty needs to be able to easily identify the outliers, especially the problematic groups in the class or individuals within the groups. Different representations of the evaluation summaries will be implemented to allow faculty to efficiently assess results. Students will also receive evaluations from their peers, and they must be presented anonymously.

1.2.Major software functions

The online peer evaluation system will be divided into three parts:

1.2.1 Setup

The setup should provide an easy way for the faculty to create groups and add users into groups. The setup feature will eventually be integrated to the group structure feature provided by the myCourses management system.

1.2.2 Evaluation

For evaluation purposes the faculty should be able to customize their own set of questions, but initially the development team will implement this feature by using a static set of questions. These questions will either be quantitative or qualitative depending on user requirements.

1.2.3 Reporting

For reporting purposes the system needs to provide a graphical representation of the collected data. The basic aim for this would be to easily identify outlier groups and individuals. Different representations of the evaluation summaries will be implemented to allow faculty to efficiently assess results like:

  • Pareto Chart

  • Pie Chart

  • Scatter Chart

Once the evaluations are filled by students the group members should be able to view all comments and concerns. All these evaluations must be presented anonymously.


Detailed list of features will be created after requirements gathering.

The figure below outlines the high-level releases for the Peer Evaluation System:

Sprint 1
Spring Quarter

(5rd week)

Sprint 2
Spring Quarter

(7th week)

Sprint 3
Spring Quarter

(9th week)

Simple CRUD Operations

  • Create Questions Template

  • Create Evaluations

  • LDAP Authentication

Data Access Layer

MyCourses Feed


And Reporting


Integration with myCourses

For each release, the following deliverables will be available:



Sprint Functionality

The Peer evaluation system demonstrating all functionality up to and including the current sprint.

Product Architecture

An architecture supporting full functionality inclusive of the current sprint and additional functionality to be incorporated within subsequent sprints.

Source Code

Source code required to build an executable product .

Product Backlog

A prioritized accounting of remaining functionality to be implemented within subsequent releases, which is indicative of remaining work to be completed and current project status.

2.Management Structure

2.1.Project Lifecycle

The functionality is prioritized at project inception and time-boxed releases are delivered, at which point additional functionality is incorporated to the code base. Upon each consecutive release, prior development activities may be revisited as necessary to address priority shift and requirements volatility.

2.2.Project Organization

2.2.1 External Interfaces

Figure 1.0, External Structure

2.2.2 Internal Structure

This project can be completed with a team of four people in a period of 15 weeks. The team will consist of software engineers capable of performing various tasks starting from requirements gathering, designing, database management, developing, testing to management. All the members will rotate between different roles to the final product delivered.

Figure 1.1, Internal Structure

2.2.3Roles and Responsibility



Scrum Master

Primary purpose is to mitigate project issues that may impede progress as they arise. Also, due to limited resources the Scrum Master will also be responsible for implementing the Peer evaluation system.

Product Owner

Control the budget and resources allocated to the project.

Project Team

Implement the goals and ideas of the project


The project will be completed with a team of four members in a period of 15 weeks.
The team will include the following members:

1 Scrum Master (Developer)

3 Developers

2.3.Risk Management

2.3.1 Top Risks List

  1. New Technologies

  2. myCourses Integration

  3. Project quality will be unacceptable due to vague ambiguous requirements

  4. Project will take more time for the team to complete than the amount of time budgeted

  5. Changing requirements will lead to extreme feature creep with each iteration

  6. Project is not feasible with given conditions of schedule and resources.





























2.3.2Risk Mitigation Strategy:

  1. The more experienced team members will try and educate/ guild other team members with new technologies

  2. The team members new to technologies will start with building small prototypes on their own to grasp new technology

  3. Specific tasks will be assigned to specific members based of sill set
  4. Help of domain experts will be taken to address integration with myCourses

  5. Through many sprints the requirements will be revised many times to ensure that clarity is achieved.

  6. By using past projects/experience as a way of estimating effective effort, a better approximation of the team's abilities can be made. This would allow for a more accurate range of justifiable schedule deadlines.

  7. Throughout every sprint, each decision will be evaluated to make sure that it aligns with the overall goals of the project.

  8. The team will undergo many team building events as deemed necessary by the team.

3.Planning and Control

3.1.Estimation Method

Schedule oriented practices will be used to deliver the final product in the span of 20 weeks. The customer will set the release date. The customer and the development team will then come up with an agree set of functionalities to be delivered on the release date. The customer prioritizes the list of features according to their needs and the development team will provide the estimates for implementing the features.

3.2.Resource Identification


The team size will be constant throughout the project.


Start Date: Nov 28th, 2005
End Date: May 19, 2006
The final released date is set to second week of April, 2006. Features are to be delivered iteratively every one to four weeks, depending on the complexity of the implementing feature.



3.3.Resource allocation

3.3.1Work Breakdown Structure

Detailed Work Breakdown Structure will be created after requirements gathering.

Figure 1.2 shows the product based Work Breakdown Structure.

Figure 1.2, Work Breakdown Structure (Product Based)


For detailed schedule refer to the Senior Project Plan.mpp.

3.4.Tracking and control

The Scrum Master/Development Team oversees all the Scrum meetings and tracks the development status. The development team identifies the initial backlog at the start of the sprint, and periodically tracks the progress made by the development team. Progress tracking is done during the Scrum meetings, where team members are required to state their development progress relative to the sprint backlog.
To improve the process of identifying the number tasks to complete for a particular sprint and the length of the sprints, metrics that address the questions of “how many tasks should be associated for each sprint?” and “how long should a sprint last for” will be utilize. The selected metrics should assist the Scrum Master/Development Team in writing up sprint backlogs.
The following metrics will be implemented in the development of the product:

  • Number of tasks completed for a particular sprit (Work effort distributed for each sprint)

  • Number of open bugs

  • Total numbers of hours

  • Total number of bugs

    • Per feature

    • Per task

    • Bug type
      • UI

      • Feature

      • Feedback

  • Sprint backlogs

  • Product backlogs

3.4.1 Milestones

Major Milestones

The final product release is on third week of May, 2006.

Minor Milestones

These milestones are the iterative and incremental feature delivery at the end of each sprint. This allows customers to see the progress made compare to the overall project. This also allows customers to give feedbacks on the developed features, which can then lead to changes or additional features to be implemented in the next sprint.

3.4.2 Reporting

Weekly Report

As mentioned above, team members are required to give a quick status of their weekly progress relative the expected sprint delivery.

Sprint Report

The Scrum Master/Development Team is responsible for creating and delivering sprint information (sprint backlog) to the project team and the stakeholders. At the end of the sprint, the project team meets with the stakeholders where they will see the developed functionalities. Base on this delivery, features to be addressed in next sprint is re-defined. From the meeting and the backlog, the stakeholders can visualize the development progress of project.

3.4.3 Estimation Refinements

After each sprint, any of the pre-defined features can be changed. Depending on customers’ inputs, features can be added, removed, or re-prioritized. Estimates are also refined or redefined based on these changes. Obstacles and problems encountered in the previous sprints are taken into account when refining the new estimates.

4.Technical Process

4.1.Methods, Tools and Techniques

Scrum Methodology: The whole project will be delivered in chunks depending on the requirements prioritization. Development team will get a specific amount of time to implement each chunk of functionality.

Revision Control: CVS will be used to track changes to all documents, source code, and any other relevant files.

Daily Builds: Source code will be build every night to avoid integration issues.


4.2.1 Environment

The web-client shall be accessible via http request forwarded through any of the supported browsers listed below:

  • Mozilla Firefox 1.07 or higher

  • Microsoft Internet Explorer 6.0 or higher

  • Netscape Navigator 7.0 or higher

4.2.2 Methods, Tools and Techniques

Software Tools:

  • .NET 2003 Framework

  • Microsoft Project will be used to track overall progress.

  • Microsoft Office 2003

  • MS-SQL Server 2000

  • IIS Web Server 6.0

  • Trac (Integrated SCM and Project Management)

  • Subversion Tracking System

4.3.Project Artifacts

Document Name


Project Outline

A general overview of the project with some of its key features.

Project Plan

A document containing the following subsections:

  • Project Scope

  • Management Structure

  • Planning and Control

  • Technical Process

  • Supporting Plans


A formal requirements document containing User Stories, Use case realizations etc.

Project Schedule (Sprint Schedule)

The breakdown of how long each iteration will take.

Source Code

Source code required to build an executable product and incorporate the solution with deployment tools on the client- and server-side platforms.

User Manual/ Setup Documents

Formal setup documents and User manual will be provided to help users in setup and maintenance of the product.

(User Manual will be optional and will only be provided if time permits)

Design / Feature Documents

Design and Feature documents will be provided for maintenance purposes.

Share with your friends:

The database is protected by copyright © 2019
send message

    Main page