Distributed Development Monitoring/Mining

Project Management Plan

Distributed Development Monitoring/Mining

Tom Mooney, Ahmed Osman, Isaac Pendergrass, Shailesh Shimpi

Version 1.7

1/31/2013

This document describes the processes and tools to be used in planning, developing, monitoring and controlling the activities and assignments of the Distributed Development Monitoring/Mining team.

Revision History

Version / Description of Versions / Changes / Responsible Party / Date
1.0 / Initial version / Tom Mooney / 1/26/13
1.1 / Adding Schedule / Tom Mooney / 1/28/13
1.2 / Adding Deliverables, Roles and Resources sections / Ahmed Osman / 1/28/13
1.3 / Adding more sections / Shail Shimpi / 1/29/13
1.4 / Adding Risk Management Overview / Isaac Pendergrass / 1/30/13
1.5 / Adding Goals and Objectives, Control and Communication Plan sections / Isaac Pendergrass / 1/30/13
1.6 / Added Goals, Risks, References and updated Schedule / Shail Shimpi / 1/30/13
1.7 / Updated Terminology and Risks sections. Also added labeling for tables and adjusted figure numbering. Removed Names. / Isaac Pendergrass / 1/31/13

Approval Block

Version / Comments / Responsible Party / Date
1.0 / Initialized items are OK / Ahmed Osman / 1/26/13
1.5 / All sections are complete / Ahmed Osman / 1/30/13
1.6 / Document Reviewed / Shail Shimpi / 1/30/13
1.7 / Document Reviewed / Isaac Pendergrass / 1/31/13

Project Overview

1.1 Background and History

This project is for the OMSE software engineering final practicum. The main goal is for the team to show mastery of the concepts presented over the course of the OMSE program as well as developing a useful application that will contribute to furthering the state of the art of the field of software engineering. The original idea for the project came from the course syllabus for OMSE 555 as detailed below:

With the growth of distributed development has come a variety of environments supporting distributed team collaboration. These environments typically provide a suite of (more or less) integrated applications for communication (messaging, chat, voice), project management (milestones, tickets), collaborative work (wiki), version management (SVN, Git), and so. One such tool that we have used for a number of student projects isassembla. Assembla provides free support for open-source projects. Another is the Redmine suite that we are currently using.

The use of such collaboration tools provides a rich database of developer interactions and artifacts. During a project this data is updated in real time as the developers communicate and create artifacts using the communication tools provided by the site (i.e., chats, files, messages, etc. are saved). After the project, the data provides a record of both what transpired, and the results.

This suggests that it may be possible to instrument a collaboration tool like assembla to monitor progress and compare it to the results of past projects. Thus, for example, one might be able to detect that a project is getting into trouble based on communication metrics or schedule changes. A project in this area would explore tools and metrics for tracking and analyzing distributed developments using such environments.

1.2 Purpose

Current collaboration tools such as Assembla and Redmine provide a number of capabilities for assisting distributed teams in communication, collaboration, and project management. Some examples of these capabilities are:

●Source control repository hosting.

●Communication and collaboration tools such as wikis, news feeds, and messaging systems.

●Task and issue tracking.

●Shared document hosting.

●Project management tools such as activity reports and key metric gathering and tracking.

It is this last feature, the project management tools that this project will be working to enhance and augment.

Current collaboration software allows for gathering and reporting on a plethora of metrics. Where these tools come up short are on methods for analyzing those metrics and automatically alerting stakeholders to signs of trouble based on historical project performance. The purpose of the Distributed Development Monitoring/Mining tool will be to augment current collaboration tools in order to address this shortcoming. It will do this by collecting and modeling historical project data to predict, in real time, the health of an in-progress project and to alert the project stakeholders when signs of trouble are detected.

1.3 Scope and Limitations

The project scope is defined based on time and resource constraints as well as the complexity of obtaining and analyzing enough data to produce statistically significant results. The final software produced by this project will serve only as a proof of concept. It will deal with a small amount of data and focus on a few key metrics to demonstrate the possibility of creating such a tool on a larger scale. Statistically significant results will not be produced and therefore the accuracy of predictions made about project health will not be reliable.

The project will:

●Identify a key project metric related to project success.

●Develop the necessary infrastructure for obtaining data from the Assembla collaboration tool related to the selected metric.

●Develop methods for analyzing the data.

●Develop mechanisms for delivering alerts to users.

1.4 Goals and Objectives

The project will be considered a success if the following goals and objectives are met:

1)The goal is to develop an application framework based on family based software development process. Thus, this framework can work with other open source collaboration tools as well.

2)Prototype application is developed that can retrieve key metric data from Assembla.

3)The application displays the ability to process the data and identify patterns of success and failure.

4)The application has the ability to produce a model that may be applied to current projects to alert users of possible issues.

5)The project is completed by the end of June 2013.

In addition to the above-mentioned goals and objectives, the team should also hit all projected milestones and deliverable dates.

1.5 Stakeholders

●Stuart Falk

●Tom Mooney

●Ahmed Osman

●Isaac Pendergrass

●Shail Shimpi

1.6 Documents and References

●OMSE 555/556 Course Syllabus

●Project Proposal

1.7 Terminology

Agile / Software process model that is based on iterative and incremental development.
API / Application Programming Interface
Assembla / Open source project management and distributed team collaboration software.
Collaborate / Web based software that provides users with video and audio conferencing as well as collaborative document editing facilities.
IDE / Integrated Development Environment
Redmine / Open source, web based project management and bug tracking tool.
REST / Representational State Transfer. Distributed software architecture.
SDLC / Software Development Life Cycle
SVN / Apache Subversion (often abbreviated SVN, after the command name svn) is a software versioning and revision control system distributed under an open source license.

Approach

2.1 Deliverables

The following deliverables will be provided for the project:

• Software Project Management Plan (SPMP).
• Software Test Plan (STP).
• Software Requirements Specification (SRS).
• Software Architecture Document (SAD).
• Source Code.
• Software tutorial (installation and configuration instructions).
• Software User Documentation.

2.2 Responsibilities and Roles

Everyone in the team will have different roles and responsibilities during the project. Each member will have a primary role and a secondary role depending on the project need.

The following table will describe the role and the responsibilities of each role.

Role / Responsibilities
Software Developer / The Development team is a group of individuals assigned to the project that collectively possess the necessary skills to implement and test the application or system
Software Architect/Designer / The Designer is an individual or small group of people assigned to the project that possess the necessary skills to define an architecture and high-level design.
Software Requirement Engineer / Responsible for requirements elicitation and create the SRS document.
Discuss the requirement changes during the project period.
Software QA/Test Engineer / Responsible for integration and acceptance testing.
Ensure the overall quality of the products and the artifacts.
Software Project Manager / Responsible for making sure the development team follows the values and practices of the process.
Protects the team by making sure they do not overcommit themselves to what they can achieve during development period.
Facilitates the daily activities and is responsible for removing any obstacles that are brought up by the team during the meetings
Product Owner / The Product Owner in conjunction with customers defines the features of the product and prioritizes which features will be included in each release.

Table1: Roles and Responsibilities

2.3 Resources

Human Resources

The team consists of four members and the tasks will be distributed to them depending on their roles.

Communication Resources

The team will use Redmine as a collaboration toll for communication and for recording activities.

It will be used for assigning tasks and bug against the product to the team members.

Team will be using also emails for communication for small conversations

Configuration Management

The team will use SVN for source and documents management, which is already integrated into Redmine.

Development Tools

The team will use c# for code development and will use REST API to access Assembla Database.

2.4 Risk Management Overview

As with any software development project, there are risks associated with this undertaking. Due to the fact that we are operating as a distributed team, those risks are amplified, especially in areas where communication is essential. The most likely risks for this project have been identified. They are as follows:

1)The potential to deliver the product in an unusable state due to the constrained schedule.

2)The potential of losing communication with team members.

3)The potential of losing significant portions of work due to system failures both within and outside of sphere of control.

4)The possibility of losing a team member.

These potential threats have been categorized as to their inevitability and impact in the risk assessment matrix below.

Negligible / Marginal / Critical / Catastrophic
Certain / Time Constraint
Likely / Loss of Communication
Possible / Loss of Personnel
Unlikely / Loss of Work
Rare

Table2: Risk Assessment Matrix

Our methods of dealing with these potential issues are mitigatory in nature. The purpose is to limit the damage caused by the occurrence of any of these events to a level that does not prevent the team from moving forward and delivering on the requirements. Listed below are the means that we have developed to cope with the discovered risks.

Time Constraint

Our main weapon in mitigating the time constraint risk is using an Agile/Iterative development methodology. This will allow us to adequately define chunks of functionality that can be delivered in the time allowed. The addition of each chunk will represent a readily deployable application for use and evaluation. It is also proper to view the mitigating efforts taken for the remaining risks as contributing to the goal of meeting the time constraint satisfactorily.

Loss of Work

To ensure that the impact from loss of work is optimally mollified, the following actions will be taken.

1)The team will make use of the centralized SVN repository included in the Redmine project space. Each member will check in all changes to work products and relevant items.

2)Each team member will set the Auto-Save/Auto-Recover feature of their Integrated Development Environment (IDE) to save at a maximum interval of five minutes.

3)The SVN repository will be mirrored to a remote server so that in the unlikely event of a Redmine outage, the team may still continue development.

Loss of Personnel

In effort to reduce the damage that would be caused by an unplanned absence of a team member due to work or family issues, the project is run in a manner that distributes the weight of all roles evenly among the team. This ensures that we are not creating silos of knowledge that could render the team vulnerable in the event of a departure. A secondary benefit of our development methodology also allows us to adjust at predefined intervals to ensure that all points are being covered.

Loss of Communication Capabilities

Our communication scheme generally consists of two meetings per week via the Collaborate Team Meeting Room and message transmissions via email. If for some, as of yet unknown, reason these method fail. Alternatives have been appointed to ensure that our communications link remains strong. These alternatives are:

1)Skype – Used for meetings that do not involve collaborative editing of documents

2)Google+ Hangout – Video conferencing and collaborative document editing.

3)Landline Communication

1. Member to Member
2. Conference Call –

2.5 Process Summary

The project team will be adopting Agile software development process model. This model promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

Project team will be utilizing the following main characteristics of Agile model;

○Iterative and incremental development

○Team composition will be cross functional and self-organizing.

○Distributed team that will utilize virtual communicating methods

○Close customer interactions

○Software product will be the primary measure of success and

○Implementing continuous integration

Fig 1: Overview of DMM Agile development process

The project team will use Scrum sprints for iterative development. The product backlog is an ordered list of "requirements" that is maintained for a product while sprint backlog is the list of work the development team must address during the next sprint. The team will adopt small sprint that will have the duration of a week and every 4 weeks (month); the team will implement the major sprint. The working incremental product will be released at the end of each major sprint.

Fig 2:DMM Sprint Planning

2.6 Life Cycle Overview

Once the initial project proposal is completed; the remaining following phases will be done iteratively in each of the sprints.

iPlanning - The objective of this activity is to look at the product backlog, select the priority requirements to work on, decompose the work into tasks, look at the resources and then develop a plan for the sprint.

iiRequirements Analysis - In this, the requirements will be further analyzed and the features and functions (those need to be built) will be defined.

iiiArchitecture & Design - Based on the work to be done and features those need to be developed; the product architecture will be adjusted and components design will be done.

ivImplementation (Development) - In this activity, the development of these features and functions will be implemented.

vTesting - Integration and Quality testing will be carried out in this phase.

viEvolution - This phase consist of understanding what went right and what went wrong in the sprint. Right activities will be strengthened and incorrect activities will be modified for better results in the next sprint.

Fig 3: Systems Development Life Cycle (SDLC) in each iteration

Finally, once the product is ready; it will be deployed into the production environment.

Even though the team will be adopting Agile development model; based on OMSE 555 & 556 class schedule; the project team has defined the following major project milestone, their deliverables and the schedule:-

○During milestone 1 duration; the project team plans to conduct and complete the following activities; project plan, software research on the tooling, communication metic, requirements specification document, and architecture & design.

○Milestone 2 duration will be mainly used to develop the product and

○Milestone 3 will be mainly used for testing and deployment.

Besides providing weekly status reports to the stakeholders; the team will do total presentations to the class; two each (midterm & final) in OMSE 555 and 556. These presentations will be a comprehensive report of the project’s progress.

Fig 4: DMM Project’s Milestones

2.7 Control and Communication Plan

This project will be controlled using the Redmine project management suite provided by Portland State University. Included in this application are a number of tools to assist with tracking the progress and problems associated with the current project. Members/Stakeholders are allowed to enter issues against the project and monitor the progress. The pertinent sections of this application are described below.

Overview (Dashboard)

The overview screen serves as the project dashboard, giving just enough information to get a feel for the overall health of the project. It includes statistics on the following:

1)Issue tracking stats (open vs. total)

1. Bugs
2. Features
3. Tasks

2)Team Members IDs

3)Latest news

4)Time Spent

Activities

The activity screen gives a more in-depth view of the activity that has occurred across the entire project. In addition to the activities performed, the responsible team member and time of occurrence are displayed. The page is user configurable and allows the selection of any combination of the following:

1)Issues

2)Changesets

3)News

4)Documents

5)Files

6)Wiki edits

7)Messages

8)Spent time

Gantt Chart

The Gantt chart is used to show individual project task scheduling and their impact on the project schedule as a whole.

Calendar

The Calendar is used to show specific project milestones as well as group meetings and other events that are important to the stakeholders.

News

The new screen is used to broadcast pertinent project information to all stakeholders. (Announcements, etc.)