Project Management PlanDistributed Development Monitoring/Mining

Tom Mooney, Ahmed Osman, Isaac Pendergrass, Shailesh ShimpiVersion 1.71/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 HistoryThis 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 is assembla. 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 PurposeCurrent 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 LimitationsThe 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 CycleSVN 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 DeliverablesThe 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 RolesEveryone 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 ResponsibilitiesSoftware 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.

Table 1: Roles and Responsibilities

2.3 ResourcesHuman Resources

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

Communication ResourcesThe 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 ManagementThe team will use SVN for source and documents management, which is already integrated into Redmine.

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

2.4 Risk Management OverviewAs 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.

Table 2: 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 ConstraintOur 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 WorkTo 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.

Negligible Marginal Critical Catastrophic

Certain Time Constraint

Likely Loss of Communication

Possible Loss of Personnel

Unlikely Loss of Work

Rare

Loss of PersonnelIn 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 CapabilitiesOur 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 documents2) Google+ Hangout – Video conferencing and collaborative document editing.3) Landline Communication

a. Member to Memberb. Conference Call – http://www.freeconferencecall.com

2.5 Process SummaryThe 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 OverviewOnce the initial project proposal is completed; the remaining following phases will be done iteratively in each of the sprints.

i Planning - 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.

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

iii Architecture & 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.

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

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

vi Evolution - 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)a. Bugsb. Featuresc. Tasks

2) Team Members IDs3) Latest news4) Time Spent

ActivitiesThe 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) Issues2) Changesets3) News4) Documents5) Files6) Wiki edits7) Messages8) Spent time

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

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

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

DocumentsThe documents screen provides a central location for all stakeholders to gain access to project documentation.

WikiThe wiki is used to store institutional information about the project that does not fit easily in any of the documentation scheduled for production.

RepositoryThe repository will be used to archive member work products and allow controlled collaborative work on the work product set.

These tools empower the control scheme adopted for this project. They also allow for the communication of relevant information to keep all stakeholders up-to-date on project progress.

2.8 Schedule - Tom Iteration Start Date Duration

(Weeks)End Date Activities Deliverables

0 1/31/2013 3 2/13/2013 Gather non-functional requirements and stories for iteration 1.

Finalize Project Plan

PPT for midterm presentation

SRS,Stories for iteration 1,Mid-term PPT

1 2/14/2013 2 2/27/2013 Iteration Planning

Development Retrospective

Build 1/prototype

2 2/28/13 3 3/18/13 Iteration Planning

Development Retrospective Prepare end of

term presentation

Stories for iteration 2,Build 2,End of term PPT

3 4/4/13 2 4/17/13 Iteration Planning

Development Retrospective

Build 3

4 4/18/13 2 5/1/13 Iteration Planning

Development Retrospective

Build 4

5 5/2/2013 2 5/16/2013 Iteration Planning

Development Retrospective

Build 5

6 5/16/13 2 5/29/13 Iteration Planning

Development Retrospective

Build 6

7 5/30/2013 2 6/10/13 Iteration Planning

Development Retrospective

Final build

2.9 References

Software product-line engineering: a family-based software development process By David M. Weiss, Chi Tau Robert Lai. Addison-Wesley, 1999

https://www.assembla.com/home http://www.wikipedia.org/

<<Process Comments:

This is a variation on a comment I made to one of Jonathan’s posts on agile.

While I have no real objection to the activities, roles, etc. contained in the team process, I am going to quibble with calling it “agile”. If the term “agile” has any meaning at all (other than being a recent euphemism for “good”) then an “agile process” has to possess aspects that are distinct from other kinds of processes. If “agile” is simple an iterative process with a faster cycle, then it is nothing distinct.

The question is, what, if anything differentiates agile processes? While the literature uses the term without ever fully defining it, I would suggest that there are some attributes that distinguish real agile processes from (for example) iterative processes with a fast cycle time. In particular:

1. Requirements are not understood and validated up front but are emergent over the course of development. They are addressed one or two at a time and validated through development.

2. Architectural design is not a distinct activity nor is design documentation produced. In fact the set of quality requirements that would normally drive architectural design are not all present for consideration when the design is initiated so they cannot be considered at once. Rather, the architecture emerges as the code is developed and is refactored as needed when new requirements emerge.

3. The code is the primary repository of all information about the development including detailed requirements and design decisions.

A real agile process would have all of these characteristics. What you have described is not an agile process, it its an iterative process in which you are deploying some specific techniques (e.g., time boxing) that are prevalent in agile processes (in fact, you are using IBM’s picture of an iterative process but labeling it “agile”). However, you are ignoring many others including daily stand-up meetings, customer on site, nightly build & test, etc. Certainly the “agile” aspects are not what drive the overall project plan and its products.

While the proposal advances the single sentence that “[the] software product will be the primary measure of success” this is not really true and, indeed, cannot be true of a Practicum project. The measure of success is necessarily the demonstration of mastery of a broad range of

activities and artifacts in the software process. These are where the team’s mastery of SE will largely be demonstrated, not the code. The fact that you are developing a requirements specification, architectural design, etc. confirms this. I would argue that these artifacts and related activities are inconsistent with any real agile process per the definition above.

I am harping on all this because I find that there is a lot of sloppy thinking around these topics in the SE community as a whole. “New” methods like agile are sold without anyone ever clearly stating what exactly the term means, what the underlying assumptions are, or what the limitations are. The result is that people end up applying the methods incorrectly or in situations where they are a poor fit. Figuring this out is left as an exercise for the reader.

I hope that is clear, I’ll get off my soapbox now.

Otherwise, the approach seems reasonable.

Stuart>>