ASKSG

Project Plan

Version 2.0 (approved)
Prepared by Team Watchmen
3/8/13

Revision History

Contents

1. Overview

2. Goals and scope

In Scope

Out of scope:

3. Deliverables

4. Risk Management

5. Technical Process

Stage 1 Construction

6. Scheduling and Estimates

7. Measurement and Metrics

Measurements

Metrics

1. Overview

ASKSG seeks to give RIT Student Government (SG) a window into the topics affecting RIT students, show SG representatives what the student body is talking about, and help SG respond to student concerns quickly and effectively. To do this, ASKSG will automatically keep track of public conversations on social networks, analyze them for topics and sentiment, create reports and graphics for consumption by users, and allow users to respond to messages without leaving the application. Additionally, the interface will handle questions posed through private channels including email and SMS. The primary customer is the RIT Student Government, and the Director of Student Relations, Anthony Henning. The end-users will be the Director of Student Relations, SG Representatives, and the SG Advisors.

The system will run on a standard web application stack. Data will be stored in a MySQL database. The back-end will be written in Java, using Spring MVC and Hibernate, and will run on an Apache Tomcat server. The front-end will be written in HTML/CSS, and use JavaScript and jQuery. Spring is an enterprise grade application framework that has proven itself in the real world. Numerous features, ease of use, adaptability, and developer familiarity all influenced the decision to use the Spring application stack.

The project will be delivered in three stages. Stage 1, delivered in Week 6 of Winter Quarter (1/14/2013-1/20/2013), will contain a skeleton of the application, a public page for logging in and an introduction to the ASKSG project, basic user login and storage support, and support for direct communication. Stage 2, delivered in Week 4 of Spring Quarter (3/25/2013-3/31/2013), will improve the data model and provide support for: social network authentication, data aggregation from all supported social networks, publishing to social networks, and system administration. Finally, Stage 3, delivered in Week 8 of Spring Quarter (4/22/2013-4/28/2013), will add data exporting, analysis reports, social media analysis, and conversation detection.

Development will be done by Team Watchmen, with faculty advisor Ryan Schneider, and project champion Anthony Hennig.

2. Goals and scope

The goals for ASKSG are defined in terms of what’s in and out of scope. Everything that is in scope will be treated as a long-term goal for the project, and vise versa. We further refine the scope by enumerating all of the high-level features we expect to deliver (and omit) in the following sections.

In Scope

• Web application accessible through modern browsers (Firefox, Chrome)

• Website renders on mobile devices

• Social network support

• Reddit, Facebook, and Twitter
• Authentication with OAuth
• Social media scraping capabilities

• Analysis report generation (data export to Excel)
• Adherence to Americans with Disabilities Act for Accessibility

• Scalable font sizes
• Compatible with high contrast displays and magnification

• Public page for RIT student access
• Basic user login and data persistence

• Not using Shibboleth

• Support for direct communication between students and SG representatives

• SMS support via Twilio
• Email support

Out of scope:

• Replying to social message messages through ASKSG.
• Integration with the video relay service(s) is the only requirement that is out of scope. As such, it will not be included in the project schedule.
• Formal accessibility efforts beyond best effort design and practices are potentially out of scope or limited to stage 3.
• Mobile design beyond using a responsive HTML layout is out of scope.

3. Deliverables

The deliverables for the project will be partitioned between those for the Software Engineering Department and the RIT Student Government. For the Software Engineering Department, we are required to deliver:

1. Project website holding all work products and project artifacts maintained in the project account on the se.rit.edu web server.
2. Project plan, schedule and process methodology definition.
3. Tracking report for time/effort worked on the project, and at least two other product/process metrics appropriate to the project and development methodology.
4. Interim status and final project presentations.
5. Project poster and presentation at “SE Senior Project Day”.
6. Project technical report.

For the RIT Student Government, we are required to deliver:

1. Deployable system with minimal functionality (SMS and email conversation support).
2. Public presentation page.
3. End-user manuals (README files).
4. Requirements and software design specification documents.
5. Data package and backup delivered in physical medium (CD-ROM).

4. Risk Management

Several risks to the project have been identified for this project. For brevity, we identify them in the following table.

5. Technical Process

Based on the well-defined requirements provided upfront, we will be using the staged delivery process methodology. This will enable us to perform the same waterfall process activities upfront and deliver new versions of ASKSG to the stakeholders in smaller increments. A visual depiction of this process methodology is shown below in Figure 1.

Figure 1. A pictorial representation of the staged delivery process methodology

We will maintain the following internal artifacts throughout the course of the project (note that all artifacts are drawn from the waterfall process, since the staged delivery process is merely a slight variation of this methodology).

• Software Vision and Scope document
• Requirements Specification document
• Use Case Specification document
• Software Design Specification document
• Test Plan document
• Source code

The Software Vision and Scope document will be a deliverable of the Software Concept phase. The Requirements Specification and Use Case Specification documents will be a deliverable of the requirements development phase. And finally, the Software Design Specification and Test Plan documents will be a deliverable of the architecture design phase. The Use Case Specification and Test Plan documents are expected to evolve as the final detailed design, construction, and release stages in the process lifecycle are completed.

To track our progress and maintain these artifacts, we will use the following tools:

• Google Drive for all process-oriented and design-related artifacts
• GitHub for source code management, issue tracker, and configuration documentation

At a high level, our project lifecycle can be partitioned into four separate stages: (1) concept, requirements, and design, (2) stage 1 construction, (3) stage 2 construction, and (4) stage 3 construction. In the first stage we will elicit the full set of requirements from the primary stakeholder and use them to design a software solution for ASKSG. All of the major internal artifacts will be developed during this stage and continually evolved throughout the course of the project as requirements churn and the development schedule inevitably changes. The goals of the remaining three stages can be itemized as follows:

Stage 1 Construction

• Application skeleton
• Public page for RIT student access
• Basic user login and data persistence
• Support for direct communication between students and SG representatives

Stage 2 Construction

• Mature data model for social media integration and data mining
• Social network authentication (using OAuth)
• Data aggregation from all supported social networks
• Social network publishing capabilities
• System administration

Stage 3 Construction

• Data exporting
• Analysis report generation
• Social media data analysis
• Conversation detection through data mining

6. Scheduling and Estimates

Based on our technical process, we have partitioned the work for this project into six major sections: project vision, requirements gather, architecture specification and design, stage 1, stage 2, and stage 3. From these we have devised a project schedule and set of milestones to drive the project forward, and also designate the resources required to complete each milestone. In order to track our progress towards these milestones, weekly time sheets will be filled in and active tasks will be recorded on the appropriate spreadsheets. In the event that the project schedule needs to change, we will discuss the severity of the change as a group and then vote on the estimated schedule slippage. Then, these results will be relayed to the project sponsor and stakeholder.

Work Breakdown Structure

• ASKSG

• Project vision

• Project plan
• Vision and scope document
• Weighted feature list

• Requirements gathering

• Requirements Specification document
• Use Case Specification document
• UI mockups and storyboards

• Architecture specification and design

• Software Design Specification document
• Test Plan document

• Stage 1

• Application skeleton
• Public page for RIT student access
• Basic user login and data persistence
• Support for direct communication between students and SG representatives

• Stage 2

• Mature data model for social media integration and data mining
• Social network authentication (using OAuth)
• Data aggregation from all supported social networks
• System administration

• Stage 3

• Data exporting
• Analysis report generation
• Social media data analysis
• Conversation detection through data mining

Estimation techniques

To determine our schedule we needed to have some estimate about the size of the system and effort required to implement it. To do this, we assigned complexity levels to each major feature based on our experience in implementing similar functionality in other software systems. From here we computed an aggregate number of points represented by the project. From this function point total we computed the physical size of the software (in terms of LOC) using the rough estimate that one function point is equal to approximately 300 Lines of Code (LOC). This LOC estimate was again based on our prior implementation experience. Then, using the COCOMO model, we determine the required effort needed by the developers to develop this product. Each step in this estimation process is outlined below.

With this function point total we use the estimate of 300 LOC for every function point, and calculate the total LOC as follows.

For an organic software project, the COCOMO model parameters are  and However, given our team’s abilities, we felt it best to adjust these parameters such that  and  and we calculated the total amount of effort as follows.

[man-months]

Given the time frame for this project, this estimate makes the project infeasible. However, COCOMO is an estimation model intended to provide a rough guideline for developer schedules. There are a number of variables that can skew estimate numbers from incorrectly enumerating features and their complexities to the Lines of Code to function point number we chose (300). Additionally, this project involves fewer people with a far shorter schedule than the average project COCOMO is generally applied to. A four person project developed outside of corporate overhead involves less communication channels and formalities normally associated with development. While the model suggests that our scope is ambitious, given our experience with similar applications, delivering a product with requested functionality is feasible.

Project schedule

7. Measurement and Metrics

Throughout the course of this project we will be collecting a variety of process and development measurements in order to quantitatively evaluate the team’s progress on the ASKSG project. For brevity, we list these measurements and the corresponding metrics that will be derived below.

Measurements

• Percentage of requirements that change every week
• Scheduler overage (differences between actual and estimated task completion dates)
• Number of individual hours spent on specific tasks every week, categorized based on the type of activity (e.g. requirements, design, implementation, test, etc)
• Feature value for each completed activity (assigned by a team vote)
• Total number of defects in the code base

Metrics

• Progress metrics

• Schedule slippage
• Earned feature completion value (based on difficulty and priority of item completion)

• Defect metrics

• Defect density
• Bug fix velocity

• Effort metrics

• Categorized time spent on activities per week

• Activity metrics

• Requirements volatility