Project Plan

Project Plan

Authors	Key
Ryan Gurnick	rg
Joseph Goh	jg
Samuel Lundquist	sl
Mason Sayyadi	ms
Owen McEvoy	om

Revision History

Date	Author	Description
02/13/2020	rg	Initial document creation, team organization, design making considerations
02/13/2020	ms	Adding milestones
02/14/2020	jg	Updated overall formatting
02/14/2020	rg	Moving changes over from google drive
02/20/2020	rg	Adding development tools section
02/20/2020	sl	Grammar check and clarity revision
02/20/2020	rg	Final revisions before initial documents due
02/24/2020	rg	Updating Build Plan
02/27/2020	rg	Adding additional tools
03/07/2020	jg	all mentions of regTools changed to Registration Tools

Team Organization

Our team will work together to complete each section of the project, as opposed to assigning any section of the project to one person. This means that no single person will be solely responsible for any particular part of the project. For smaller tasks, we will work as individuals to accomplish task completion in a streamlined manner. For larger tasks, we will have two groups of two people working on two tasks that can be worked on simultaneously and the last person in our group will do oversight to ensure that the components come together in the correct manner. The person with oversight of the project will switch at various different points during the project development to ensure that every team member understands the full breath of the application.

Each member of the team will be responsible for updating documentation for the portions of the application that they work on as well as updating the time log for each task. Tasks will be divided up in a first come first serve way, where all tasks will be posted on a github wiki page and then each team member will be able to assign themselves to the tasks. When no team member is assigned the person doing oversight will assign a team member to the task. Upon completion of a task, the overseer will review the other member's work and finalize it.

Design Making Considerations

There is no single decision maker within our group. We all work together to determine what needs to be developed based on the plan, requirements, and design specification. All decisions regarding design are intended to be worked on as a group to ensure that the integration is seamless. We will settle any disputes by a simple majority vote, however it is unlikely that this will occur.

When discussing the project design/implementation, we will attempt to make decisions based on the following criteria:

(Most decisions will start out in the non-technical realm and then end up needing some additional technical considerations to be made. Thus this is meant to be a two part process, starting in the non-technical realm with documentation, discussion, and the specific outlined considerations. Then moving to the technical realm and including the additional considerations.)

Non Technical Decisions:

• How many resources (people, staff hours, equipment, etc;) will be consumed by a modification?

• Will the outcome of the decision benefit the end user?

• What are the risks and rewards of implementing the decision?

• Will making this decision impact any of the previous decisions made?

• How does this help reinforce the software requirements specifications?

• What changes will be needed within the software design specification?

• Can this decision be implemented while remaining within the constraints of the project?

• How will this decision affect the requirements of the project?

Technical Decisions:

• Can a standalone prototype be developed within the given time?

• Will the standalone prototype produce significant benefits to the user?

• What change to functionality will be mandated by the decision?

• What are the risks and rewards to the user?

• What is the impact on future maintenance or development?

• Does this impact how components are linked together or interact?

• Where in the software will this functionality be added and how will that impact that component and it's linked elements?

Communication Procedures

We as a team have consolidated our communication process to the following:

1. First, we expect most ideas to start with a conversation.

• If the conversation happens in person, we will take notes and continue the conversation online with Discord if needed.
• Online conversation that doesn't originate in discord should be copied into or noted in Discord for logistics. Group members involved will be mentioned using '@' which will trigger a Discord notification. Discord notifications will be sent to their personal computer and Phone immediately in a manner similar to a text message.

2. If necessary, the conversation will continue and become formalized via the Github wiki by generating a task within the tasks list.

• We monitor the task(s) and their progress officially via Github wiki or through discord communications.
• All formal decisions will be noted via Github and Discord to ensure consistency among team members and to divide work in an equitable way.

3. Team members will be assigned to specific task(s) if necessary and will record official progress on the task tracker within Github wiki.

• The Github task tracker page will change states and have tags denoting what state it is currently in.
• Things like work in progress, testing, waiting, completed.

4. When completed and integrated as intended the task will be marked as closed in github.

In summary, Discord will act as a tool for our group to keep track of conversations that takes place asynchronously. Discord will act as an extension of in person interactions allowing them to take place from great distances by providing text and voice communication. Then the information that gets refined from those conversations via discord and in person interactions is formalized in the Github task tracker page and progress is tracked from there.

Milestones

• Successfully scraped/parsed data (PROJECTED :: ~ 02/19/2020)
• Have tables populated with the class/major data that will be needed for the project.(PROJECTED :: ~ 02/22/2020)
• Created UI (Tkinter) (PROJECTED :: ~ 02/24/2020)
• Working Prototype 1 (PROJECTED :: ~ 02/28/2020)
• Completed basic backend functionality (PROJECTED :: ~ 03/04/2020)
• Debugged all major error test cases (PROJECTED :: ~ 03/08/2020)
• Completed all documentation (PROJECTED :: ~ 03/08/2020)

Project Tracking

Build Plan

 

Task	Date Assigned	Date Completed	Time Spent	Completed By
First Group Meeting	2/12/20	2/13/20	4 Hours	All Staff
Initial Documents	2/13/20	2/14/20	20+ staff hours	All Staff
SRS	2/13/20	2/20/20	10+ staff hours	om, ms, jg
SDS	2/13/20	2/20/20	10+ staff hours	rg, om, ms, sl
Project Plan	2/13/20	2/20/20	4 hours	rg, sl
Web Scraping	2/14/20	N/A	10 staff hours	N/A
Interviews	2/20/20	N/A	N/A	N/A
Graphics Models	2/20/20	N/A	N/A	N/A
- Long Term Planning	N/A	N/A	N/A	N/A
- Class Management	N/A	N/A	N/A	N/A
-Notifications (Interface)	N/A	N/A	N/A	N/A
Revisions of Technical Documents (SRS/SDS/Project Plan)	2/24/20	N/A	N/A	N/A
Data Processing	2/25/20
- Store raw data to the data store	2/25/20	N/A	N/A	N/A
- Process raw data into usable information	2/25/20	N/A	N/A	N/A
- Finalize Unified Model	N/A	N/A	N/A	N/A
- Notifications Events	N/A	N/A	N/A	N/A
More will be added below as the development and design processes more.

Rationale

We have agreed as a group to use Incremental Development to build this application, which will include building a variety of prototypes that we will end up molding into the final codebase. We are attempting to build an application that the University of Oregon could decide to implement for all students. We plan to have various components of this application that are going to be developed in tandem, which adds some extra complexity. We are aiming to ensure that we reduce complexity as much as possible by designing each module to handle their specific task and not much else. This means that we will be working to produce weak coupling with other modules and strong cohesion within modules. We want to ensure that this application is as modular as possible and would be compatible with a server environment if desired.

With this specific project we have two main goals that are motivating us to succeed. The first, is our desire to make this application something that the University of Oregon could introduce to all of the students enrolled. Secondly, we are attempting to build this application in such a way that it can be expanded/extended with ease to aid in the largest part of the application development cycle, maintenance.

Risk Strategies

In the development process, there are various risks that could hinder us from being able to fully complete the application. First, we anticipate that building a desktop application rather than a website or cloud based application will cause the user some additional issues. In dealing with this risk we plan to build a system that can have the functionality to work with a remote server and constantly communicate over the internet, however that will not be showcased in this project. Secondly, there is the risk that we will underestimate the amount of time that a specific task will take. For this reason, we have set strict deadlines with plenty of time included for troubleshooting and debugging. In addition, we structured the development of this application such that for larger modules, there will be multiple team members working on them at any given time. This is done with the intent to “cross-train” our team members, so that all of us are more than comfortable with working on any component of this application.

Dealing with various risks we will attempt to be very flexible in our implementation as well as software architecture so that if we need to change direction it can be done with ease.

Tool Utilization

Our team will work with a standardized set of tools to aid us in the development of this application. We will attempt to judge any new tools we use to determine if it overlaps with any set of functionality that is already provided by the current toolset. Below is the list of tools to date that we are using:

• Discord
• Google Drive
• Google Colab
• Github
• Typora
• Pycharm
• TablePlus