Professional Documents
Culture Documents
Inscopecapstonefinalreport
Inscopecapstonefinalreport
Inscopecapstonefinalreport
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
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
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.
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
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
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
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
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
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
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
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
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
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
Feasibility Discussion
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
One method for increasing satisfaction with PM software is to increase the engagement
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
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
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,
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
13
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.
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.
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
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
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
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
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
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
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
21
22
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
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
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
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
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
26
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,
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
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
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
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
30
References
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
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
https://opensource.org/licenses/MIT
Plotkin, R. (2012). Computers, Internet, and Society. Computer Ethics. New York: Facts on File.
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 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
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
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
"currentLevel" : 1,
"currentPoints" : 17,
"leaderboard" : {
"HQtOp8U7bXePRhm1gnFjvhfOdh92" : 17
},
"members" : {
"HQtOp8U7bXePRhm1gnFjvhfOdh92" : true,
"hiL7htAx3EQTe02tygxCoE4w3qS2" : true,
"vlALPd2dR3S3rrdI3cJPflPjU863" : true
},
"owner" : "HQtOp8U7bXePRhm1gnFjvhfOdh92",
"ownerEmail" : "bmazza@csumb.edu",
"pointInterval" : 20,
"timestamp" : 1497216477827,
{
INSCOPE: TASK AND PROJECT MANAGEMENT BOARD
35
"assignedTo" : "kvader@csumb.edu",
"owner" : "cpinanorman@csumb.edu",
"projectId" : "-KmTjfZnZ8CVeMUeR_-N",
"taskPointValue" : "15",
"taskStatus" : "Delegated",
"timestamp" : 1497312081686,