Running Head: INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

InScope: Task and Project Management Board

Brittany Mazza, Chris Pina, and Ken Vader

California State University Monterey Bay

CST 499 Directed Group Capstone

Advised by Dr. Krzysztof Pietroszek

June 13, 2017

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

Executive Summary

Project management (PM) software and tools have become integral to the successful

planning and completion of projects in a number of disciplines. While the market is flooded with

options, most suffer from important deficiencies that the developers hope to address with this

project. The first of those deficiencies is over complicated software. Many project management

tools on the market offer too many options that are unnecessary for a significant number of users.

These complicated tools have a steep learning curve and are difficult to adopt. To make matters

worse many of the solutions available are designed for specific project management

methodologies. This can leave users who do not prescribe to those methodologies out of options.

Furthermore, the majority of solutions available are subscription based, which force

organizations to sign up for a web service and leaves them without the ability to host their own

software and control their data. These attributes make the current solutions unappealing to a

number of users.

The purpose of this project is to address these deficiencies by creating a simple, yet

effective tool that improves the workflow of project managers and their teams. The proposed

solution is InScope, an online project management tool that allows individual users and teams to

manage projects and tasks of any type. The primary goal for this project was to develop an

application that is simple and easy to learn. To achieve this goal InScope allows users to create

projects with a single click. Managing projects can be done from an easily accessible settings

page that allows project managers to effortlessly share their projects with other users. Tasks can

be created by completing a short form and are immediately shared with all members of a project.

The second goal for this project was to develop a flexible solution that would benefit project
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

manager regardless of their field. InScope does not conform to a specific project management

methodology. The application instead focuses on simplicity and usability, which allows the user

to integrate InScope into any workflow. The development team also strived to engage users and

make the application easy to adopt. To do so the InScope team set out to integrate elements of

gamification. By allowing project managers to assign point values to project tasks, users are

encouraged to utilize InScope and compete against other collaborators to a project. Finally, one

of the most important goals of this project was to allow organizations to easily host the

application on their private servers, eliminating the need to sign up for third-party web services.

To achieve this the development team has made the project publically available as open-source

under the popular MIT license. This will allow project managers and other developers with the

opportunity to customize the tool to meet their needs. Whether you are an individual working on

personal projects, a team that needs to collaborate, a member of the open-source community or a

company of any sizes, InScope provides an alternative to the overbuilt, closed-source software

available in the market.

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

Table of Contents

Introduction 4
Project Name and Description 4
Problem and Issue in Technology 4
Solution to the Problem 5
Project Goals and Objectives 5
Community and Stakeholders 7
Evidence that the Project is Needed 9

Feasibility Discussion 9

Design Requirements 12
Functional Decomposition of the Project 12
Selection of Design Criterion 13
Final Deliverables 14
Approach/Methodology 15
Legal Considerations 16
Ethical Considerations 18
Timeline/Budget 19

Usability Testing/Evaluation 22

Final Implementation 24

Conclusion 27
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

Introduction

Project Name and Description

This capstone project is called InScope and it is a dynamic, discipline agnostic task and

PM tool. It supports individuals and teams alike in their planning and execution of daily tasks

and long term projects. This open source, web-based solution adds game elements to incentivize

project participants. The discipline agnostic design allows any team to utilize InScope, regardless

of the type of project they are working on and project methodology they choose to use. The

flexible nature of InScope allows teams to not only see the road ahead but easily alter it when

needed.

Problem and Issue in Technology

It is often difficult to maintain a clear vision for the short and long term goals of a project

when in the midst of working on it. Teams commonly find themselves losing precious time

focusing on unimportant details while other pressing matters are being ignored. A well-run team

needs a focused vision and that includes knowing what needs to be done today, tomorrow, and in

the coming weeks. The teams ability to adapt to shifting priorities and keep their overall

roadmap in mind is a crucial component of completing their project on time, while still

maintaining a high quality. The project management solutions currently available have their

shortcomings, making the process more difficult than it needs to be.

Many of the PM suites available online require the user to adhere to a specific PM

methodology. Agile development, for example, is extraordinarily popular and most of the

available tools are specific to this workflow. A team that doesnt practice this workflow would

have to work around the functionality built for Agile development and force their workflow into
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

something that isnt built for it. This also leaves less flexibility for a team to change their

workflow and maintain a task history, as they would be required to switch PM platforms to meet

their new needs. There are tools that come with too many options and settings that cause

unnecessary confusion, while others are little more than task lists. Many of these options

additionally lock necessary features behind a subscription model and force teams to store their

project data on the servers of those that own the PM tools. These attributes make each tool rigid

and unappealing for many teams and their projects.

Solution to the Problem

Building a new tool that is agnostic to any kind development process methodology, open

sourcing the software for it, and giving users the freedom to have the management suite they

need will solve the problems associated with the currently available PM tools. Through InScope,

teams and individuals are able to manage their tasks and projects in one place, where they have

control over their own data. The discipline-agnostic approach means that any project, not just

software projects, can be tracked and managed with ease. The ability to have multiple boards,

and even boards inside of tasks on other boards, allows the project to be managed at as

fine-grained a level as the project requires. Game elements help with overall engagement during

the life cycle of the project.

Project Goals and Objectives

There are a decent number of goals that need to be met in order to consider this project

complete. Contributors must gain familiarity with each step in the software development process,

become familiar with web application architecture and the tools that aid in its development, and

learn how to positively impact and assist one another when working within a team. Users of this
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

management tool, including the project managers and participants, also have defined goals. In

this system, an ordinary user is initially a participant but can become a project manager by

creating a board, which opens up new management features for them. They are able to fulfill

both participant and project manager roles through this system. The primary goal of this project

is to provide the participants with a feeling of accomplishment through their completion of tasks

managed in this application and when they promote themselves to project managers, they should

be able to easily and successfully manage their own projects.

A series of objectives aid in the progress toward making participants feel as if theyre

accomplishing their own goals while using this web application. Through their completion of

tasks, participants are able to attain new levels, which are assigned point values and rewards by

their project managers. To allow them to easily interact with each other and discuss their tasks

with appropriate parties, they are provided in-page, one-click comments in the task view. When

theyve completed a task, participants can indicate that they are done by selecting the appropriate

status of the task within a drop-down menu or through drag and drop functionality, depending on

the board view. As users become project managers, a wider set of objectives is gathered to allow

them to easily and successfully manage their projects. One of these objectives is to provide them

with a simple project overview page, allowing them to effortlessly review the overall status of

the project. This would include a quick view of the number of tasks completed and total tasks

assigned during a user-defined time range. We additionally want to allow project managers to set

rewards for the project participants. Project managers would have the capability of defining

achievement levels as well as assigning point values to each task. Completing tasks would allow

participants to earn task points that would ultimately allow them to reach certain achievement
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

levels. Project managers can also create new project boards, with a provided set of defaults,

within three clicks from their user page. Finally, the project manager can provide a set of

permissions to additional users to aid in the management of each project, further easing their PM

responsibilities.

As each user has their own goals for their projects, the InScope team does as well. To

work toward a familiarity with the software development process, the InScope team is expected

to have analyzed the project requirements within the first week, designed and architected the

project within the second week, and completed a minimum viable product (MVP) within the first

five weeks, including automated unit tests. While making progress toward being effective team

members that contribute positively toward the team, team objectives include weekly code

reviews, where one others code is reviewed prior to it being included in the project, and

providing status updates on a bi-weekly basis. Gaining an understanding of web application

architecture and the software tools to aid in its construction is the final goal for contributors to

the InScope project. The set of objectives that work toward it includes successfully implementing

a SQL database that is used on the project, working with Git and GitHub for the duration of the

project (where code reviews are performed), and successfully implementing the selected

language and framework for the application.

Community and Stakeholders

The primary stakeholders for this project include individuals working on personal

projects, the open-source community, and companies of varying sizes. Managing projects can be

very burdensome with a lot of overhead, which has resulted in many tools being developed to

assist project managers. These PM tools are frequently overbuilt, closed-source, and on
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

subscription models. Each of these factors can negatively impact our stakeholders, unfortunately

project managers may not realize the downsides of project management software until they have

committed valuable time and resources in adopting it at which point they may be dependent on

it.

Privacy and data security are a major concern for people relying on third-party

applications to house their data. Individuals, small companies, and large companies alike, will

have the option to host the web application within their own network, where they can limit

access to the public and house their own data, specifically project information, within on their

own machines. This method may be ideal when working as or with high profile companies and

sensitive data in general. Additionally, when bugs or problems arise, each stakeholder can raise

an issue or correct the problem publically since the project will be available as open-source. If

the stakeholder is not concerned about this, however, InScope still hosts a public-facing interface

where users can work on their project without the overhead of setting up their own machines. If

the stakeholders are not satisfied with the project, they will be able to request features or use the

codebase as a starting point to refine it into an application that meets their needs because it will

be open-sourced.

The lack of a subscription model and availability of the code base make this application

easily accessible to all of our stakeholders without limiting their use or the features available to

them. Once the application is running locally, a user (or set of users) will be able to completely

run the application offline and continue progress on their tasks.

Choosing task management software is an important decision for all of our stakeholders.

Once time and resource have been committed to adapting a particular product, switching to a
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

different application can be tedious and costly. Making the wrong choice can significantly

impact productivity and finances. Spending the time moving from their previous task

management software and later, after some use, finding that the new PM tool doesnt meet the

needs of the team can be detrimental to those working with the product. InScope boosts

productivity in the long run by providing game-like incentives to complete tasks for participants

and the stakeholders will be pleased with the result. The success of this project and the outcomes

of the teams working with the application will offset the resources spent and productivity lost

from switching PM tools, leading to increases in revenue and productivity.

Evidence that the Project is Needed

Companies, large and small, have private data or data for their clients that are not meant

to be shared with the public. Using software that runs on a server outside of their control, or in

the cloud, and not behind their own network can leave companies vulnerable to a data breach if

hackers are able to breach the software that they use. For this reason it is vital that this project is

available to install and run within the users own network.

Many small groups and companies dont follow a traditional software development

workflow or need to manage a project that isnt software development-specific. The majority of

tools available for use cater toward an Agile or Waterfall workflow that doesnt work for many

teams. Providing users an option thats more flexible with lower overhead than the currently

available options is incredibly important to the InScope team.

Feasibility Discussion

PM software has become crucial to the success of project managers in software

development and a number of other fields. Research has shown that the use of PM software is on
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

10

the rise and its increased use will only continue. According to Bounds (1998), in a survey of IIE

Solutions, 20% of readers responded that they use PM software (cited in Grevins, Lawrence &

Nallan, 2000). It is almost certain that the figure has grown exponentially over the past decade as

the use of technology in the workplace has grown. This increase in the demand for PM software

is crucial for the success of InScope. The InScope team will ensure that users are satisfied with

their experience. Research in the field of PM and the use of software has shown that when users

are satisfied with the software they will be more likely to use it to increase their individual

productivity and consequently increasing the efficiency of the project (Grevins et all., 2000).

User satisfaction is a top priority when developing any type of PM software, including the

InScope application itself.

One method for increasing satisfaction with PM software is to increase the engagement

of its users through gamification. As Zichermann (2013) explains, Gamification is the

application of design concepts and techniques, loyalty programs and behavioral economics in a

business environment (cited in Briers, 2013). Gamification can be very effective in modifying

or reinforcing certain behaviors. By turning the desired behavior change into a game, people

become engaged and encouraged to adopt new habits (Gartner, 2012). This gamification is what

separates InScope from its competitors. The gamification of PM and task management has been

done before. The best example is Red Critter (www.redcrittertracker.com), which uses badges

and rewards for completing certain tasks to promote productivity. Red critter allows users to

manage multiple projects and users. The weakness of Red Critter comes in its strict adherence to

the Agile development model. The flexibility of the proposed application is what will set it apart.

Red Critter includes many great features, but those features may become cumbersome for some
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

11

users. According to the survey of IIE Solutions readers discussed previously, most users report

using only the simplest features of their PM software (Grevins et al., 2000). InScope focuses on

simplicity by not forcing users to follow a particular PM methodology. InScope also distances

itself from the competition through its simplified and flexible approach and gamification.

With so many competitors in the project management software market there are bound to

be some similarities between our project and existing solutions. However, the goal of the

InScope team is to differentiate our project from any other offering available by closely

analyzing every feature and making certain that our implementation of said feature is unique and

an overall improvement to what has been done in the past. For example, the use of some type of

board to gather every element of a project is a tried and prove technique that has been used by

teams in every field. The task management tool Trello (trello.com) makes perfect use of boards

to define a project. However, the use of boards by Trello remains rigid. Boards can be used only

to define projects. The goal of InScope is to allow users to embed boards within smaller tasks.

This will provide users with yet another way to stay organized. Users will be able to place boards

within a task that is already assigned to a parent board, making the use of boards more powerful

than what is currently available in other PM tools. InScope will also provide task list

functionality comparable to Toodledo (www.toodledo.com). However our goal is to allow users

to pull a sorted task list from every board the user is a member of. This will provide users with a

powerful eagle eye view of their entire task list. InScope will also gamify task completion in a

similar fashion as Red Critter. However, the InScope team hopes to build even more flexibility

for project managers by allowing them to select the rewards for each achievement level, as well

as defining how much each task is worth towards that achievement level. With these
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

12

improvement we hope that InScope builds on the solutions that came before it to become a

universal PM solution.

Design Requirements

Functional Decomposition of the Project

There are two major roles a user can play when using InScope. Their primary role is as a

participant in a project. This is the default role that every user is assigned when they are assigned

to a project or create their own project. Creating their own project within the application enables

additional administration features that are otherwise not seen. Through this process, the users

gain access to their second role as a project administrator. The InScope application must

implement specific functionality to support both of these roles and the additional feature of

administrator-defined levels for project participants to achieve through their completion of tasks.

As a project participant, a user or set of users will follow a task through its creation and

changes in status until the task is complete. The user assigned to a task will generally handle

updating the task status during their time working on the task. InScope handles this by storing

the available task statuses for a project in the database. The application is not concerned about

the meaning behind these statuses so there is little overhead involved in this process. However,

handling the features accessible by a project administrator requires more work.

The primary role of the project administrator is to set permissions for users on the project

and manage the levels defined by them. Figure 1 illustrates the level creation and design that is

completed by a project administrator to prepare for project participants to work toward through

their completion of tasks.

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

13

Figure 1. Project administrator level creation process.

Supporting user-defined levels creates additional overhead for the developers because the

feature touches many portions of the application. Creating levels and assigning point values

works through the projects settings, levels, and tasks. Calculating user levels for the project

requires the application to track a users accumulated points through tasks theyve worked on.

This touches user profiles and tasks and challenges the compartmentalization of the application

itself.

Selection of Design Criterion

InScope is a web application that requires its users to access it through a web browser.

While a back-end server is not necessary due to the use of Googles Firebase API, a server is still

required to run the front-end Angular 2 application. The costs associated with running the

front-end are minimal due to the small size of the codebase and a minimal number of initial

users. The application does not require a large or powerful server during this initial phase.

Amazons cloud servers will allow us to initially run the service free of charge.
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

14

Users accessing the application will have no cost requirements, as InScope is a free

service. Users can additionally access the codebase and run it on their own servers if they desire,

eliminating any cost for all users and the InScope team.

Final Deliverables

The completion of this project produced two deliverables. The first is a functioning web

application deployed to a publicly available hosting service. The publicly deployed application

will allow a user to connect to the application and log in using a Google email address. Once a

user is logged in, they will have the ability to create and edit projects, create and edit tasks,

manage project users, and manage project point values. A user will be able to participate in

multiple projects and be a project manager on some projects, but not others. As part of user task

editing, they will also be able to set point values on individual tasks. The project manager of a

project will be able to assign tasks to other users working on the project. The point values are

used by the project manager to set intervals (levels) for the team to work towards. The levels

are designed to aid in user engagement. The deployed web application will keep persistent data

through a Firebase database, providing users with an alternative to existing project management

tools.

The second deliverable is the documentation and source code for this project. The team

has allowed for the project to be open source and publicly available on Github. Along with the

source code, Github will host the documentation for the web application. The documentation

describes the process required for configuring and running a private instance of the web

application. The open source nature of this project will also allow for others to alter or enhance

features that are present in the teams initial release. The documentation will assist a user in
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

15

configuring the project on their own server or hosting service, including build information. The

documentation will also cover the configuration of a Firebase project through the Firebase

console.

Approach/Methodology

The project management methodology that was used on this project was a blend of

sequential and Agile methodologies. The team performed requirements gathering prior to and

during the first week, where they determined the minimum requirements needed for this project.

During the first week, the team also discussed how to divide the labor of this project to ensure

that all components of the project had a member taking ownership (see Appendix A for details).

This phase included researching similar project management suites, finding what features users

liked and used most often, and what features users typically do not use. During this phase, the

team also set out an early priority list for feature implementation.

Once the team had the information gained from the requirements phase, they were able to

determine the appropriate technology stack for this project. Based on the need for flexibility,

scalability, and the tight time frame involved, the team ultimately chose to go with an existing

framework rather than build something entirely from scratch. The chosen technology stack was

also chosen to fit in with the overall development approach of this project.

During active development, the team employed an iterative, Agile-like development

approach. Features were implemented on a priority that was determined during weekly team

meetings. Each team member would pick up the next item in the priority queue to implement,

ensuring that the team was always working towards the weekly and overall goals. Code review
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

16

and testing were completed alongside development, to ensure new features were not breaking

existing features.

The overall project milestones were initially set up during the requirements gathering and

architecting phases. As the project proceeded, these milestones were adjusted as needed to keep

the project moving towards the end goal. The feature implementation milestones were the ones

that required the most adjustment, with any missed milestones being pushed into the next week.

The ability to adjust to changing milestones was critical to the success of the project, as not all

milestones were completed as planned.

Legal Considerations

The InScope team had to address two important legal considerations during the

development of this project. The first revolved around the issue of copyrights. With a number of

task management software products already available, concerns regarding infringement of

intellectual property arise. After researching and testing other tools, the team will unavoidably be

influenced by what others have already created. Copying another companys product and

releasing it to the public can be detrimental to their business and could infringe on their

intellectual property if any unique features are covered by software patents. To lessen copyright

concerns the InScope team simplified the features of the application. InScope offers basic

features that are not likely to infringe any intellectual rights. Furthermore, the InScope team built

the application using open sourced tools that allow the team to work freely without worry of

copyright infringement. For example, the InScope application was built primarily using the

Angular2 framework, which is offered by Google with an MIT license. The MIT license allows

developers to use the provided software without restriction, including without limitation the
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

17

rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the

Software (Open Source Initiative, n.d.). As Max Sills, an attorney in Google's Open Source

Office, wrote Google wants developers to be confident that they can use, fork, modify, and

extend Angular without worry (Sills, 2016). By carefully selecting tools and features the

InScope team has managed to mitigate copyright concerns.

The second crucial legal consideration had to do with the distribution of the InScope

application. One of the most important goals of this project was for the development team to

release the software as an open source project. This would make the project widely available,

which could have ramifications for the InScope team. For example, the developers could be held

responsible if a user loses important data as a result of a bug in the program. According to

Plotkin (2012), when it comes to meeting minimum standards of quality and security From a

legal perspective, responsibility would almost always fall with the company rather than its

programmers (p. 98). Since the software is being released to the public directly by the

programmers and not a company, the development team must establish minimum standards of

quality and security. To do this, we will limit the possibility of defects with a rigorous testing

process and diminish liability for user error by providing proper documentation. Furthermore,

officially releasing the software as open source requires that the development team select a

license. The InScope software will be released using the MIT license, which includes important

protections for the developers. The MIT license includes the following critical clause, The

software is provided as is, without warranty of any kind, express or implied In no event shall

the authors or copyright holders be liable for any claim, damages or other liability (Open Source
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

18

Initiative, n.d.). While the license does not remove the legal and moral obligations to produce

defect free software, it does provide some protection, which is important for this project.

Ethical Considerations

Implementation of this project also raises important ethical questions that must be

considered before making the application widely available. Specifically, issues of security and

the impact of the product on the world need to be addressed. One of the key features of the

proposed software is the ability to retrieve saved tasks by logging into the system with a

username and password. An important ethical issue to consider is safeguarding the data that the

software has been entrusted with. In order to produce a successful program, developers must

manage permissions correctly at all stages of development. Permissions will allow users to

collaborate while protecting the stored data of each user. Furthermore, as Plotkin (2012) argues,

the success of usernames and passwords depend on the difficulty of cracking the software that

denies access to those who do not provide a legitimate username and password (p. 30).

Mitigating this ethical concern will require choosing the appropriate technology to encrypt user

passwords, proper implementation of that technology, and ensuring users are only able to see

what they have been given permission to. In order to tackle this concern, the InScope team made

the decision to leverage available tools for authentication. InScope uses Firebase, a product from

Google, to handle all user authentication. Because InScope uses the Firebase API, users have the

option to login into the system using their Google credentials. By leveraging this tool in the

development of this project, the InScope team and software are no longer responsible for storing

user passwords. This mitigates some of the security concerns.

We must also consider the impact of the proposed product on the world. It could be
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

19

argued, for example, that digital task management will help reduce paper waste and therefore

have a positive impact on the environment. However, as Carli (2010) argues, there is growing

recognition that digital media technology uses significant amounts of energy from coal-fired

power plants making a significant contribution to global warming. An application like the one

proposed may have a negative impact on the environment in the long term. Applications that

work on older products could extend the life of electronic devices and decelerate the dangerous

production of e-waste, so the development team for this project should ensure backward

compatibility. The InScope application is web based, which extends compatibility. The user does

not need a specific operating system or specific architecture to use the application. Developing

an application compatible with a variety of devices would additionally help underprivileged

communities that may not have access to the latest devices. It is the ethical responsibility of

software developers to make serious attempts to allow all users to benefit from the use of their

products and supporting backward compatibility would help. For those with limited internet

access, moving simple activities that used to happen on paper onto the internet may have

negative effects when theyre expected to collaborate with people online to get their work done.

Each new application that requires internet access is potentially an additional barrier. Providing

offline access, which would allow users to continue working offline and sync when the internet

is available, may lessen that burden.

Timeline/Budget

Some early milestones were met successfully. However, as the project proceeded into

weeks 2 through 4, the team fell behind schedule. This was largely due to miscalculation of the

amount of time needed to familiarize the team with the chosen technology stack. Choosing
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

20

Angular 2 came with a higher learning curve than was anticipated, but once learned, allowed for

the quicker implementation of features. There was also a change in back-end technology that

resulted in lost time. The team moved away from a PostgreSQL database and instead chose to

utilize the Firebase API that provided an out of the box database. Again, this incurred a cost for

the time needed to learn the framework. However, it removed the need for the team to host the

database or deal with the overhead of securing information, as that is made much simpler with

Firebase.

Beginning in week 4, the team was able to make up the lost time, as the chosen

technology made building the application significantly easier. The team made the foundation of

the project robust and modular, to help speed the implementation of features. This resulted in

most of the heavy lifting completed during the earliest stages, and the subsequent features

building off of the underlying framework built by the team. See Table 1 for more details

regarding the expected milestone completions each week and how the schedule changed each

week.

Table 1

InScope Application Development Timeline and Weekly Status for 2017

Weeks Focus Milestones Weekly Status
1. April 25 - Project Setup Wireframe application On Schedule for week
May 2 / Design Design database 1.
Phase Create initial Github repository
Finalize technology stack
Create initial project with a
simple Hello World page
Create documentation
Create unit test suite

2. May 3 - Implement Implement user login Partially on schedule.

May 9 User Login Implement user login features Task states and CRUD
Features, (encrypting and storing routes not complete.
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

21

Admin passwords) Views not

Permission Implement task CRUD routes implemented.
Controls, and (create, read, update, and
Tasks CRUD destroy)
Define preset task states (To
Do, In Progress, etc.)
Implement list view project
board with tasks
Implement admin controls
Board management
User group that has
permissions

3. May 10 Achieve Implement admin-defined level Change to Firebase

- May 16 Working creation functionality (level during this week. Time
Minimum CRUD) spent learning Firebase
Viable Implement assigning points API.
Product definition for tasks (for admin)
(MVP) Implement functionality that
assigns user the defined amount
of points for a task
Implement level functionality
for individual participants
(calculate points)
Implement boards hierarchy
(placing a board within a task
on another board)
Deploy the application as a live
website

4. May 17 Additional Implement feature allowing Login, project view,

- May 23 Feature admin to define task states on and task view are
Development board implemented. Routes
Implement saved project board for those sections are
definition, allow admin to implemented.
create commonly used board
structures quickly
Implement kanban board view

5. May 24 Additional Implement drag-and-drop Remaining CRUD

- May 30 Feature functionality on kanban board routes implemented.
Development view Work on user profiles
Implement user profiles and task editing
(picture upload, about section, underway.
external links, etc.)
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

22

Complete any incomplete tasks

from previous weeks

6. May 31 Finalize Implement feature freeze

- June 6 Project & Manually test (QA) the
Prepare for application
Presentations Fix any remaining bugs that
come out of testing
Add any missing
documentation
Add any missing unit tests
Deploy final version to the
website

Usability Testing/Evaluation

While the initial plan for testing this web application involved a heavy focus on test

driven development, the actual testing methodology did not follow this commonly used structure.

The framework chosen for the project was Angular 2. This framework comes with a unit testing

framework built into it. When new pieces were generated for the application, it would also create

the initial file to fill in the associated tests. Unfortunately, the team was not initially able to get

the tests to run properly and struggled to meet some major initial deadlines set upon us. This

combination caused the team to forgo automated tests and focus on manual testing to complete

the application.

As each feature in the application was being assembled, the team member that was

implementing the feature was expected to test it manually prior to their code being added to the

overall code base. This testing included the expected use cases, as well as the unexpected. This

includes placing unexpected values in forms, like a string of characters where a number is

expected and selecting the unrelated buttons at odd times. Once the feature was stable, the
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

23

implementing member of the team would commit their changes to the larger code base. To

ensure that their feature was complete and tested well, they would inform the team of their

update and each team member would additionally test it using a similar testing process.

Several issues were found using this process. A primary issue that surfaced was displayed

in the console during log out while on various pages. When a user had interacted with a page,

like editing a task, and had requested to log out of the website, many errors would be displayed

in the console. This was alarming. Upon some research, the team discovered that there was an

issue with how data was being retrieved and released. Without the team testing unexpected use

cases, it may not have been discovered. This would have likely interfered with the product as a

whole at a later time. While many of the problems found during testing were placed on the

original implementor to fix, the others required the whole teams contributions to resolve. The

issue while logging out was one of those cases.

When the whole team was needed to solve and resolve an issue, there was a frequent

discussion in the shared chat group and teamwork to divide the areas that needed work. Issues,

like the logging out problem, needed resolution across several pages and testing on all of them to

ensure the application was stable. Each team member communicated the area that they were

working on and when it was resolved, the areas they were testing to cover the entire project.

With additional time, automated tests would have likely been implemented but manual

testing by the team proved to be adequate and reliable for this particular project. Automated tests

may still be added in the future. For this rapid implementation, however, they were difficult to

maintain, as the application underwent heavy changes quickly. Maintaining the automated tests

was unrealistic. The application underwent several large refactorings during its development
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

24

after the Angular 2 framework became more familiar to the team. Each of these would have

required nearly all of the tests to be rewritten, which couldnt be afforded by the team. Manual

testing also provided the opportunity for each of the team members to become familiar with the

feature implemented by one another and see how a new user many interact with the application.

This allowed the team to see areas for improvement in terms of usability. Because of these

reasons, the team is satisfied with the solutions used to test the application and believes it was the

correct choice for this particular project.

In addition to testing the application within the team, usability issues were identified

through a simple survey that was administered through SurveyMonkey (see Appendix B for the

administered questionnaire). Several participants provided quick feedback after using the

application. The questions were primarily based on ease of use of the application and the

participants responded with answers that ranged from very easy to very difficult. This

allowed the team to target and improve usability in particular areas in the application.

Final Implementation

The final implementation of InScope consisted of a front end using Angular 2, a back

end using Firebase, and middleware utilizing AngularFire 2. The team also took advantage of

some other existing frameworks, such as Dragula and Twitter Bootstrap, to aid in the completion

of this project. The selection of the final technology stack came about after considerable testing

with other options. The technology stack that was chosen works well together and provided the

team with all of the features they needed to successfully complete the project. The specifics of

each piece of the technology stack are discussed below.

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

25

Angular 2 was chosen as a front end framework, due to the ease of configuring single

page applications. The single page application gives the user the feeling that they do not need to

wait for pages to load. The way Angular 2 accomplishes this is with its modular design. The web

page is effectively broken down into components that will provide different parts of the page.

These components can load data asynchronously, which gives the user the experience of having

parts of the page updated in real time without page loads. The team also utilized Angular 2 to

create services for user authentication and database communication. The services created by the

team simplified actions across all components, by making the same set of methods and access to

data seamless regardless of which component was being worked on.

After quite a bit of testing and deliberation, the team settled on using Firebase for the

back end database. The project was already utilizing Firebase for authentication and token

creation, so adding in the Firebase database features made a lot of sense. Firebase is a NoSQL

database, with everything stored in JSON formatted strings (figure 2). Examples of the JSON

objects are available in Appendix C. This made the data structure simple for a human to read.

However, it required that the data be kept in as flat of a tree as possible. Due to some query

limitations of Firebase, having nested data structures in the tree made access to those nested

structures unnecessarily complex. The result of those limitations was not only a flattened data

structure, but it also necessitated repeated data values in different parts of the tree. Integrating

Firebases authentication and database features also alleviated some of the overhead of managing

authentication tokens when accessing the database.

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

26

Figure 2. The flat, NoSQL Firebase database

While utilizing middleware was not strictly required for this project, the team chose to

take advantage of AngularFire 2 and its collection of libraries. AngularFire 2 simplified the

database communication for Angular. AngularFire allowed the team to keep references to data

points in the database as observable objects. These objects are then used to pull data from the

database. Since they are references and not primitive data, they are always current to what is

stored in the database. AngularFire 2 objects also made it simple to store data in Firebase,

typically with only a couple of lines of code.

Brittany made great use of the Dragula library to implement the drag and drop

functionality in the kanban board. Without Dragula, the team would not have had time to

implement drag and drop from scratch, so leveraging it here made that functionality possible.

The team also utilized the ever popular Twitter Bootstrap library to give the site a cohesive,

responsive feel.
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

27

The site is currently deployed on Firebase hosting

(https://inscope-tracker-1f500.firebaseapp.com). There are other options for hosting, including

getting a registered domain name, that the team may pursue in the future. As it exists now, it is a

fully functional site that is ready to meet the needs of users. For those users looking to run the

app on their own server, or looking to change or add functionality, the source code can be found

on GitHub (https://github.com/InScopeTracker).

Conclusion

InScope was designed to be an application for a regular user, group, or small company

with several projects. Unlike many of the applications available today, it focused on providing a

simple project management system that wasnt tied to workflow-specific methodologies, like

Agile development. Project management systems that cater to these methodologies tend to be

bloated and require significant overhead. There are many teams that dont require the additional

features, likely finding it burdensome to maintain. Additionally, these systems may require paid

subscriptions without access to the code base or the servers theyre running on. InScope is open

source and anyone can acquire it, customize it, and serve it on their own system, within their own

network. This access can be desireable for companies or individual users that want to ensure the

safety of the data that theyre storing by hiding their project management software behind their

own network.

Building InScope on one of the latest JavaScript frameworks, Angular 2, and with a well

known and supported back end database, Firebase, provided some great out of the box

functionality, like user authentication. While the learning curve was steep for the team in the

beginning, it became pretty simple once the team was familiar. The component structure of
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

28

Angular 2 allowed the team to manipulate the project easily and quickly to better fit the usability

of the application. Utilizing the authentication services and database provided by Firebase for

storing all project related information made it easier for the team to get the project running

quickly and reliably.

Many choices had to be made during the implementation of InScope. Some planned

features and technologies had to be removed from the overall plan, but the frequent

communication between the team members allowed priorities to be readjusted and decisions to

be made quickly. The largest lesson learned was the importance of regular communication,

scheduled and unscheduled, and making decisions quickly. A tight deadline means that the

project has to continue moving forward, which is why the quick decisions were so important for

this project. InScope had planned meetings every Sunday night at 9 PM for the duration of the

project. Many of the issues for the week and plans for the following week were discussed at

these meetings. However, the unscheduled communication was also vital to the success of the

project.

The initial decisions regarding the technology stack were done with high consideration of

the relevancy of the technologies themselves. The team wanted to use a popular front end

JavaScript framework, Angular 2, to extend their knowledge base, as none were already familiar

with it. Many discussions were had to successfully design and implement the InScope product.

While the team knew major things that were going to be implemented, details, like point tracking

and leaderboards, were not completely detailed during the initial design. As the implementation

begun on this feature, the team discussed the details of it.

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

29

The team successfully implemented many of the planned pieces of the application and

additional features. However, theres still remaining features that the team would like to build

into the application. Interaction with tasks through comments, attached documents, and GitHub

integration is the next step for the application. Additionally, the team would like to provide

additional login options, nest tasks within a task and offer optional methodology-specific

features, like Gantt charts and velocity measurement. The future of this product is filled with

opportunity and the team looks forward to seeing how it grows.

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

30

References

Briers, B. (2013). The gamification of project management. Retrieved from

https://www.pmi.org/learning/library/gamification-project-management-5949

Carli, D. (2010). Going Paperless: Not as Green as You May Think. Retrieved from

https://www.greenbiz.com/blog/2010/04/14/going-paperless-not-green-and-tree-friendly-

you-think

Grevins, J., Sanders, L. G., & Suresh, N. C. (2000). The role of project management software in

project management process and project success. Retrieved from

http://www.pmi.org/learning/library/role-pm-software-process-success-1075

Gartner. (2012). Gartner Says by 2014, 80 Percent of Current Gamified Applications Will Fail to

Meet Business Objectives Primarily Due to Poor Design [Press Release]. Retrieved from

http://www.gartner.com/newsroom/id/2251015

Open Source Initiative (n.d.). The MIT License. Retrieved from

https://opensource.org/licenses/MIT

Plotkin, R. (2012). Computers, Internet, and Society. Computer Ethics. New York: Facts on File.

Retrieved from http://go.galegroup.com.library2.csumb.edu:2048/ps/i.do?p=GVRL&

sw=w&u=csumb_main&v=2.1&it=aboutBook&id=GALE|9781438137483

Sills, M. (2016, January 11). Angular 2: an MIT Open Source Licensed Framework. [Web Blog].

Retrieved from

http://angularjs.blogspot.com/2016/01/angular-2-mit-open-source-licensed.html
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

31

Appendix A

This project was successfully completed due to major contributions from each team

member. Each member participated in every phase of the project from requirements gathering

through deployment. The bulk of the decision making was done as a group effort, and any major

changes to the project were discussed by the entire group. To facilitate decision making and

increase ownership across all phases of the project, each team member acted as a point person

for specific areas of the project.

For general software design and architecture issues, Brittany Mazza guided the decision

making process. This included seeking out various technologies that we could utilize to fit our

projects needs and proposing different options for front end and back end frameworks. Brittany

also led the way in setting up our development environment with a proper linting file.

Chris Pina lead the User Interface design tasks. General application layout, color scheme,

and font choice were all a part of this. Chris provided the team with wireframes in the early

stages of development that proved invaluable as we planned the workflow of the application.

Chris was also instrumental in setting up the main Firebase service module that was used by

many of the modules in this application.

The backend and database design was lead by Ken Vader. This included the initial design

and testing of the Firebase database, as well as configuring user authentication for the

application. Ken also managed the deployment of the application to the Firebase hosting service.
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

32

Appendix B

InScope User Feedback Survey

INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

33
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

34

Appendix C

An example of the project and task JSON objects stored in Firebase, the NoSQL database

used in this project, are below.

"currentLevel" : 1,

"currentPoints" : 17,

"leaderboard" : {

"HQtOp8U7bXePRhm1gnFjvhfOdh92" : 17

},

"members" : {

"HQtOp8U7bXePRhm1gnFjvhfOdh92" : true,

"hiL7htAx3EQTe02tygxCoE4w3qS2" : true,

"vlALPd2dR3S3rrdI3cJPflPjU863" : true

},

"owner" : "HQtOp8U7bXePRhm1gnFjvhfOdh92",

"ownerEmail" : "bmazza@csumb.edu",

"pointInterval" : 20,

"statuses" : [ "To-Do", "Delegated", "Doing" ],

"timestamp" : 1497216477827,

"title" : "Pet Project"

{
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD

35

"assignedTo" : "kvader@csumb.edu",

"description" : "Create slides for final video presentation. ",

"owner" : "cpinanorman@csumb.edu",

"projectId" : "-KmTjfZnZ8CVeMUeR_-N",

"projectTitle" : "Final Video Presentation",

"taskPointValue" : "15",

"taskStatus" : "Delegated",

"timestamp" : 1497312081686,

"title" : "Create presentation PowerPoint"