CS 486C

Capstone Experience

Spring 2013

Instructor: Dr. Doerry

Table of Contents

1 - Problem Statement2

2 - Process Overview4

3 - Requirements8

3.1 - Goals8

3.2 - Requirements Overview9

3.3 - Constraints10

4 - Solution Statement12

4.1 - Functional Specifications13

4.2 - Architectural Overview14

4.3 - Other Technologies20

5 - System Implementation21

5.1 - Site Overview21

5.2 - Attributes26

5.3 - User28

5.4 - User Notifications35

5.5 - Group37

5.6 - Forum45

5.7 - Analysis48

5.8 - Site Settings51

6 - Usability Testing52

7 - Future Work53

8 - Conclusion54

1 - Problem Statement

Groups are a fundamental concept in any large organization or social circle. Managing groups is a complex challenge that encompasses managing the group/subgroup hierarchy, analyzing group characteristics, and supporting intra-group and inter-group communication. While there are a number of software systems available for group management, many of these systems are designed for workflow management or casual social groups. Existing systems are unable to handle efficient creation, reorganization, and communication within complex, hierarchical group structures. There is a need for a hybrid system that combines social aspects and administrative group management. Any hybrid system should be able to:

  • Manage members by providing support to add and track members
  • Define groups manually and automatically using custom attributes to determine membership
  • Analyze members and groups with graphical and statistical breakdowns
  • Facilitate group communication via blogs, forums, and email

The lack of a suitable group management system is the primary motivation for the establishment of Group Wrangler.

GSEP and the Need for a Proper Group Management Tool

Group Wrangler was initially developed to support the Global Science and Engineering Program (GSEP) at Northern Arizona University (NAU). GSEP is a dual-degree curricular track that combines studies in any science or engineering discipline with studies in language and culture. The goal of GSEP is to internationalize the Science, Technology, and Math (STEM) degree programs at NAU. There are currently 13 science and engineering majors and 5 language choices for the program. The program is set up so that students can earn their dual-degree in 5 years. Students spend the fourth year of the program abroad studying and participating in an internship.

As Assistant Director of GSEP, our sponsor, Melissa Armstrong, manages a rapidly growing group of GSEP students that fall into multiple overlapping groups and subgroups, defined by academic status, language, major, and other characteristics. Currently, GSEP is using a variety of tools to manage students in the program, including Excel and word processing documents. This makes it very difficult to keep track of members within the organization. It is also inefficient because one person is responsible for entering all of the data for GSEP. GSEP was looking for one tool that would allow them to manage students in the program and facilitate communication among members. Specifically, GSEP needs one tool that will allow them to:

  • Manage 300-500 students
  • Define groups manually and automatically using attributes specific to GSEP
  • Analyze students and groups through charts and statistical breakdowns
  • Facilitate group communication for students to allow them to share their experiences

These criteria match up very well with the needs of a hybrid group management and communication system identified earlier. Addressing these key requirements will help to reduce the time spent on managing GSEP students. It will also allow students to be active participants in GSEP and help other students in the program.

More About GSEP

Analysis of Existing Products

We looked at a variety of existing products to determine if any of them would meet the needs of a hybrid group management system (Figure 1). We analyzed the products based on the criteria identified earlier for a proper hybrid system. The rating scale ranges from poor to excellent. A breakdown of some of the products is shown below.

Figure 1 - Existing Product Comparison

None of the products fully meet all of the criteria that we have identified. Google comes the closest in terms of meeting the criteria. Tools such as Google+ and Google Groups provide some very useful functionality in terms of facilitating functionality through forums blogs and emails. However, the Google products are lacking in some of the other areas because they do not provide great support for tracking members, defining groups automatically, or analyzing group statistics. Many of the other products suffer from similar shortcomings.

As described earlier, the main issue is that these systems are either focused on administrative control or social communication. Social tools such as Twitter, Facebook, and Google largely focus on self-organized groups that have users enter their own information. Tools for administrative control such as Church Teams, IBM Lotus Notes, and Microsoft Exchange are often centrally controlled and have a strong management focus. These tools are all very good at accomplishing specific tasks, but there is no tool that combines the full set of administrative needs with complete freedom of communication among members. After going through this process of analyzing other products, we decided that we would need to build a new hybrid system without relying on other existing products.

2 - Process Overview

Our capstone group, Team Lasso, is made up of three members. We initially had four members, but the fourth member was unable to continue into the development phase of the project. The main project roles for each member of the team are indicated below

  • Greg Andolshek - Design architect, back-end developer, documentation lead
  • Alex Koch - Graphics designer, frond-end developer
  • Michael McCormick - Team leader, back-end developer, client coordinator

Note that these roles were not exclusive, and we shared responsibilities while working on the project. All of us were involved in programming the code for the system and producing the documentation for the deliverables.

Our sponsor and mentor provided us with support throughout the development process. Our sponsor was very helpful in providing helpful feedback for any questions that we had about the organization or any specific requirements that the system should have. Our mentor has particular experience with user interface design, so his feedback was very helpful in terms of building a useful and intuitive layout for the site. Information about our sponsor and mentor and their titles are given below.

  • Melissa J. Armstrong – Assistant Director for the Global Science and Engineering Program
  • Dr. Eck Doerry – Associate Professor in the Computer Science Program at NAU

More About Team Lasso

Project Management Framework

Most of the project decisions were made in group meetings. We usually had meetings 2-3 times a week, and each meeting usually lasted between 1 and 2 hours. During these meetings, we reviewed the current status of work on the project and assigned people to work on future tasks. We made design and functionality decisions as a group. We used a voting scheme in case where we could not come to a unanimous decision. Some of the meetings were meant for meeting with our client and mentor to get their feedback on the work we had done. We also used email, text-messages, and phone conversations to communicate between team meetings.

We used a variety of tools to help us manage the tasks for this project. We used tools for both task management and configuration management. For task management we used the YouTrack system by JetBrains. This allowed us to prioritize issues and bugs and clearly communicate our progress to each other and to our mentor. For configuration management, we used Git and Bitbucket. Git allowed us to easily keep track of the different versions of the application. Bitbucket allowed us to store the code in a central location and easily get the latest code onto any machine.

Design Methodology

We used an agile development approach for this project because it was well-suited to the type of application we were developing. We did not have a solid idea of all of the requirements for the system before we began development. Specifically, we knew that we would need to make many revisions to the user interface. The agile approach allowed us to develop many prototypes for the system and rapidly incorporate user feedback. We were able to revise our requirements based on the feedback and incorporate the requirements into the next version of the system.

Deliverables

We developed several main documents while we were working on Group Wrangler. These documents helped us define the scope of our project and give us a clear idea of the product we were developing. Some of the main deliverables are listed below.

  • Team Inventory – a description of each team member in terms of experience and role on the project
  • Team Standards – a document that that describes the expectations of each team member in terms of the procedures for developing the applications and the steps for conflict resolution
  • Technology Feasibility – an exploration of the various technologies that could be used to build the application and a description of what technologies were ultimately chosen and why they were chosen
  • Requirements – a complete listing of the functional and non-functional requirements for the application, including environmental constraints
  • Final Report – the final document that includes a summary of the project overall and covers the details of the application as it has been built

In addition, we had presentations that we developed for design reviews that took place over the course of the year. We also had a poster and presentation for the Undergraduate Research Symposium at NAU.

List of Documents for Viewing

Timeline

The actual timeline (Figure 3) we ended up with for this project differs slightly from our initial plan (Figure 2) for the schedule we made when we first began working on the project. The original and actual timelines are shown below.

Figure 2 - Original Schedule Plan

Figure 3 - Actual Schedule

The timelines show the main project phases that we worked on over the course of the two semesters. The phases are broken up into time to work on the requirements, research technology, design the application, build a demo, work on the various versions of the project, and apply final testing and refinement.

Notice the differences between the original version of the project schedule and the final version. Our original project schedule was quite ambitious. We had even planned to include support for webinars in our original schedule. Also notice that we planned to build certain features in the system much earlier than we actually began working on them. This meant that we had less time to build the system, and less time for user testing as a result. We found three main reasons for the difference between the planned and actual schedule:

Expanding requirements scope

The nature of our project meant that it was difficult to narrow down all of the functional requirements for the system ahead of time. We had a solid concept of the main functional requirements based on the project description and meetings with our client and sponsor, but many of the details regarding the user interface were hard to establish before beginning development. We wanted to build a user interface that was intuitive and allowed users to quickly analyze the group hierarchy to find only the users and groups that they were interested in. We used an agile approach to address the changing requirements, but this made it difficult to stick to a solid schedule for the requirements.

Time for technology exploration

We had a few main criteria in mind when we were choosing which technologies we wanted to use to develop the application. We were looking for technologies that would allow us to quickly develop prototype versions of the application so that we could rapidly incorporate feedback from testing. Additionally, we wanted to use technologies that had solid documentation and support for software engineering principles. We wanted future developers to be able to pick up our code and be able to easily adjust it to fit the needs of their organization.

We spent a substantial amount of time researching the various frameworks we could have used to develop the application. We looked at frameworks in a variety of languages, including PHP, Ruby, Java, JavaScript, and Python. Our team built several demos in these various languages in order to see which technology would work best for our application. We built our first substantial demo application using Google Web Toolkit. We chose not to use Google Web Toolkit because we found it quite difficult to build basic features, and we were unsatisfied with the level of community support and documentation. We ultimately decided to use Ruby on Rails as our framework at the beginning of the second semester. We did lose some time choosing which technology to use for the application, but it paid off in the end. The initial investment of time spent choosing the proper technologies helped us to build a better application.

Fewer team members during development

When we first made our initial project schedule, we had planned on developing the application with the original four team members. However, we found out near the end of the first semester that the fourth team member would be unable to continue on into the second semester. This meant that we had to adjust the schedule based on the amount of work we believed we could accomplish with the remaining three team members. Each remaining team member also had to pick up the team roles of the fourth team member. It took us some time to figure out the new team dynamic.

Given the difficulties we encountered during working on the project, we are quite happy with the final version of the application. We were able to adjust to the challenges and adjust the schedule so that we could still build a proper product. Through the development process, we learned valuable lessons about how to handle changing requirements and team dynamics.

3 - Requirements

In the initial requirements acquisition phase, we met with our sponsor, Melissa Armstrong, to establish some of the key features of the Group Wrangler system. We then met with our mentor to refine our initial list of requirements. Our goal was to establish the needed core functionality of the system. We then constructed our initial requirements document, which we submitted to our sponsor and mentor for comments. Our peers and the faculty also provided us with helpful feedback when we presented our work in the form of design reviews. We had further meetings with our mentor and sponsor to further refine the scope of our requirements.

3.1 - Goals

The main goal of the application is to provide a system that combines administrative grouping control with intra-group freedom in terms of communication. The application is meant to provide one tool that meets a variety of grouping needs. While the application was initially designed with GSEP in mind, the application can actually be used for a variety of organizations. The system addresses the four main grouping challenges listed below.

Manage members

The system should allow for adding, tracking, and deleting members. In particular, GSEP is interested in allowing users to enter and track their own profile information. The burden of maintaining data is then taken off of the administrator. Additionally, GSEP wanted to support individual member profiles.

Define groups manually and automatically

The system should allow administrators to set up custom attributes that can be used to determine group membership automatically. GSEP is specifically interested in attributes such as major, language, year abroad, etc. The system should also allow administrators to manually invite users to groups. Regular users should also be allowed to join certain public groups.

Analyze members and groups

The system should allow administrators to analyze members and groups through graphical and statistical breakdowns. This will allow administrators to get quick feedback on the people that are in certain groups and decide when it might be a good idea to create a new group.

Facilitate group communication

The system should include several tools for communication such as blogs, forums, and email support. GSEP wants to use these communication tools to support students abroad and allow them to share their experiences.

Additionally, the system should be easy to use, maintain, and extend. The idea is that any organization should be able to install Group Wrangler and tailor it to fit certain needs.

3.2 - Requirements Overview

We broke our main functional requirements down based on the capabilities of certain users. Our main classes of users include generic users and administrators. People without a user account are also able to view certain parts of the site, but they do not have any other abilities. Below is a short breakdown of what the main user types can do in the system.

Generic User

Once a generic user logs into the system with his or her password, he or she can perform any of the following actions:

Communicate

A user can communicate with other members of the organization via a variety of tools. The user can post to the forums to ask questions of other members. Each user has a blog where he or she can share experiences.

View groups

Each user can view information about groups he or she is in as well as other groups in the organization. A user can view particular information about any group he or she has permission to see. This information includes group announcements, a list of the group members, and rules for membership in the group. A user can subscribe to a particular group to get information about that group in the form of notifications. A user also has the ability to manually join any public groups.

Manage account

A user can manage his or her account information. Each user can fill out his or her own values for the custom attributes set up by the administrator. These attribute values can then be used to automatically place users into groups based on the rules for the groups. A user also has access to general settings such as email address, password, and profile image. Additionally, a user has privacy settings that can be used to determine who should be able to view the user’s information.