Project Overview - Portland State University · Web viewOpen source project management and...

Software Project Management Plan (SPMP) Distributed Development Monitoring/Mining

Version 2.12/4/2013

Tom MooneyAhmed OsmanShailesh Shimpi

Isaac Pendergrass

Advisor: Dr. Stuart Faulk

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.

Table of Contents

Project Overview............................................................................................................................3

Background and History.............................................................................................................3

Purpose......................................................................................................................................3

Scope and Limitations................................................................................................................4

Goals and Objectives.................................................................................................................4

Stakeholders..............................................................................................................................4

Documents and References......................................................................................................5

Terminology...............................................................................................................................5

Approach.......................................................................................................................................6

Deliverables...............................................................................................................................6

Responsibilities and Roles.........................................................................................................6

Resources..................................................................................................................................7

Risk Management Overview......................................................................................................7

Process Summary......................................................................................................................9

Life Cycle Overview.................................................................................................................11

Control and Communication Plan............................................................................................12

Schedule..................................................................................................................................14

Revision History...........................................................................................................................15

Approval Block.........................................................................................................................16

Project Overview

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.

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.

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.

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.

Goals and Objectives The project will be considered a success if the following goals and objectives are met.

Development of an application framework capable of retrieving and processing key metric data from Assembla and identifying patterns that may be used to predict the likelihood of success or failure of a project at any stage in its development.

Publication of documentation intended to be used by future teams to extend the framework and/or application. This documentation will provide the following:

Existing characteristics, interfaces and modules of the framework/application. Utilization instructions for the interfaces and module. Guidance on future scope and research.

The project is completed, documented and deployed no later than June 10, 2013.

Stakeholders Stuart Faulk. Tom Mooney Ahmed Osman

Isaac Pendergrass Shail Shimpi

Documents and References

OMSE 555/556 Course Syllabus Project Proposal https://www.assembla.com/home http://www.wikipedia.org/

Terminology

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.

http://www.wikipedia.org/

https://www.assembla.com/home

Approach

DeliverablesThe following deliverables will be provided for the project:

Software Project Management Plan (SPMP). Software Test Plan (STP). Concept of Operation and Software Requirements Specification (SRS). Software Architecture Documentation (SAD). Presentations, Prototype & Demo(s) Source Code. Software tutorial (installation and configuration instructions). Software User Documentation.

Responsibilities and RolesEach member will have a primary role and a secondary role depending on the project need.The following table defines the roles and responsibilities.

Role ResponsibilitiesSoftware Developer Responsible for developing the code and use unit testing to

ensure the quality and product of the final application (product)

Software Architect/Designer

The Designer is an individual or small group of people assigned to the project that possess the necessary skills to define architecture and high-level design.

Software Requirement Engineer

Responsible for requirements elicitation and creation of 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 ensuring the development team follows the values and practices of the process.Protects the team by making sure they do not overcommit themselves as 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

Project Role Assignments

Software Project Manager Isaac PendergrassAhmed Osman

Software Requirement Engineer Shail ShimpiIsaac Pendergrass

Software Architect/Designer Tom MooneyShail Shimpi

Software Developers Entire Team

Software QA/Test Engineer Ahmed OsmanTom Mooney

Product Owner Dr. Stuart Faulk

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 tool 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.

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:

The potential to deliver the product in a non-deployable state due to the constrained schedule.

The potential of losing communication with team members. The potential of losing significant portions of work due to system failures both within

and outside of sphere of control. 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 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.

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.

Negligible Marginal Critical Catastrophic

Certain Time Constraint

Likely Loss of Communication

Possible Loss of Personnel

Unlikely Loss of Work

Rare

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 PersonnelIn an effort to mitigate the risk of staff migration, the project team intends to assign primary and secondary responsibility for each of the roles (as described in Table 1 above). This will mitigate the risk of any unforeseen change, such as an unplanned absence of a team member due to family or work issue, and will ensure that the team is not creating silos of knowledge. Another benefit of the iterative development methodology allows adjusting 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 reason these methods fail. Alternatives have been appointed to ensure that our communications link remains intact. 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

Process SummaryThe project team will be adopting a process that is, at a high level, a combination of modified waterfall and iterative software development model. This process promotes stable planning, requirements, architecture and design phases, and evolutionary development and delivery.

The project team will be utilizing the following characteristics of the iterative model: Completion of planning, requirements, architecture, and design phases, including related

documentation, prior to the start of the implementation phase. Development phase will be iterative with incremental product deliveries. Cross-functional and self-organizing team composition. Utilization of virtual methods for distributed team communication. Implementing continuous integration.

http://www.freeconferencecall.com/

Fig 1: Overview of DMM’s iterative & incremental development process model

Once project planning, requirements analysis, architecture and design phases, and documentation are complete, the team intends to adopt iterative and incremental development methodology. The product backlog is an ordered list of "requirements" that is maintained for a product, while the sprint backlog is the list of work the development team must address during the next sprint. The team will adopt small sprints that will have a duration of two weeks. Every 4 weeks the team will implement the major sprint. The working incremental product will be released at the end of each major sprint. The team expects and will accommodate some minor planning, requirements and design changes during the iterative development methodology.

Fig 2: DMM’s Sprint Adoption for Implementation/Development Phase

Life Cycle OverviewThe DMM project will go through the following phases and software development life cycle.

PlanningThe objective of this activity is to develop a project plan, decompose the work into tasks, look at the resources, assign the resources for each of the tasks, verify that milestones/deliveries are met and adjust the plan & resources based on the project’s needs.

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

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

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

TestingIntegration and Quality testing will be carried out in this phase.

EvolutionThis 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.

Deployment & User DocumentationOnce the product is ready, it will be deployed into the production environment. Prior to deployment, the team will produce/update the user’s manual.

The project team has defined the following major project phases, phase deliverables, and the schedule.

Phase I: Project Plan Requirements Specification Architecture & Design Software tooling researched Project metrics formalized

Phase II: Development, testing, and integration iterations.

Fig 3: DMM Project’s Phases

Control and Communication PlanThis project will be controlled using the Redmine project management. 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:

Issue tracking stats (open vs. total) Bugs Features Tasks

Team Members IDs Latest news 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:

Issues Change sets News Documents Files Wiki edits

Messages 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.

ForumsThe forums provide an avenue for in depth discussion of any or all project issues that may arise. Any member can raise or respond to an issue, and all team members have visibility of the posted discussions.

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. Communication updates will also come in the form of weekly verbal status reports. These updates are to ensure the project team is on track for meeting its near-term goals. In addition to the reports, four presentations will be given, marking the midterm and final points of each term.

Schedule Iteration Start Date Duration

(Weeks)End Date Activities Deliverables

0 1/31/2013 3 2/13/2013 Produce SRS and Concept of Operations.

Finalize Project Plan

PPT for midterm presentation

SRS, Concept of OperationsMid-term PPT

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

Development Retrospective

Build 1/prototype


Development Retrospective Prepare end of

term presentation

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



Build 3



Build 4



Build 5



Build 6



Final build

Revision HistoryVersion 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.


1.8 Updated the overall document per Dr. Stuart’s suggestions. Software process model is changed. New diagram added.

Shail Shimpi 2/1/13

1.9 Added TOC, Updated the entire document to get a unified look and feel. Moved Revision section to end of document. Updated Goals and Objectives, Roles and Responsibilities, Risk Management Overview, Process Summary, Lifecycle Overview, Control and Communication Plan sections.


2.0 Removed “Agile” from definitions. Moved references at the end to the already existing references section. Added a few comments for discussion

Tom Mooney 2/3/13

2.1 Removed comments, Updated iterative & incremental development process model diagram, reformatted table and figure labels.


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

1.8 Document Reviewed Shail, Ahmed 2/1/13

2.0 Document Reviewed Tom Money 2/3/13

2.1 Document Reviewed Isaac Pendergrass 2/4/13

Project Overview - Portland State University · Web viewOpen source project management and...

Documents

Transcript of Project Overview - Portland State University · Web viewOpen source project management and...