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
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.
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:
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.
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.
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:
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
Sprint 2 Spring Quarter
Sprint 3 Spring Quarter
Simple CRUD Operations
Create Questions Template
Data Access Layer
Integration with myCourses
For each release, the following deliverables will be available:
The Peer evaluation system demonstrating all functionality up to and including the current sprint.
An architecture supporting full functionality inclusive of the current sprint and additional functionality to be incorporated within subsequent sprints.
Source code required to build an executable product .
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.
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.
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
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.
Control the budget and resources allocated to the project.
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:
Project quality will be unacceptable due to vague ambiguous requirements
Project will take more time for the team to complete than the amount of time budgeted
Changing requirements will lead to extreme feature creep with each iteration
Project is not feasible with given conditions of schedule and resources.
2.3.2Risk Mitigation Strategy:
The more experienced team members will try and educate/ guild other team members with new technologies
The team members new to technologies will start with building small prototypes on their own to grasp new technology
Specific tasks will be assigned to specific members based of sill set
Help of domain experts will be taken to address integration with myCourses
Through many sprints the requirements will be revised many times to ensure that clarity is achieved.
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.
Throughout every sprint, each decision will be evaluated to make sure that it aligns with the overall goals of the project.
The team will undergo many team building events as deemed necessary by the team.
3.Planning and Control
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.
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.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)
The final product release is on third week of May, 2006.
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.
As mentioned above, team members are required to give a quick status of their weekly progress relative the expected sprint delivery.
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.
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.
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
.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
A general overview of the project with some of its key features.