Future Artifacts

Development Methdology

The Adirontech team will use an Agile development methodology, with development sprints completing feature requirements taking the form of user stories. An Agile methodology is preferable for this system because it prevents certain elements from being blocked from completion due to reliance on other incomplete requirements. Our team will also benefit from asynchronous standups and sprint retrospectives, allowing us to keep tabs on our progress and regularly check-in with each other to be more aware of how we are progressing. Development progress will be kept track of using a Trello board, with user stories and features being delegated each sprint depending on the workload we are taking on at that time. Testing will be handled by Github’s automatic build tests, running a testing suite on new builds before they are accepted to be merged to ensure things remain working as expected.

Metrics

In addition to measuring our individual project-related efforts and team efforts, we also plan to utilize requirements volatility for our product metric, and code review completion time for our process metric. We believe that tracking requirements volatility will be beneficial due to the novelty of this project and the potential increase in scope. Additionally, we believe that tracking code review completion time will be beneficial due to the Agile framework in which our team will be operating. Given that we will work in two week sprints, it is important for us to manage code reviews and complete reviews as quickly as possible.

Domain Model

Domain model diagram

The domain model above captures important entities in the Adirondack Visitor Use Management system. First, hikers pre-register their intended hikes using the web app. Once the hiker is at the trail for their hike, the hiker will check in using the kiosk at the trailhead. The web app and trailhead kiosk will synchronize data so that hikers can view all of their updated information.

Another important entity in the domain model is the Adirondack Park ranger. The ranger is responsible for monitoring trails, as well as retrieving data from remote kiosks throughout the park. Remote kiosks are located at various trails throughout the park. Additionally, remote kiosks do not have access to WiFi, so the kiosk will ping hikers’ devices via bluetooth in order to count the number of visitors passing by the remote kiosk. Due to the lack of WiFi access, rangers need to retrieve data from the remote kiosks in order to upload the data to the Adirondack Visitor Use Management system.

Scope Statement

The Adirondack Visitor Use Management system will implement a three-part solution to the challenges of paper trail logs, with the goal of eventually replacing paper trail logs entirely. The first part of the solution, the trailhead kiosk, will allow hikers to check-in and check-out from hikes. The second part of the solution, the remote kiosk, will count the number of visitors that pass by using a Bluetooth pinging system. Lastly, the third part of the solution, the app, will allow hikers to pre-register their hikes, view important information about trails, and view parking availability. Additionally, the app will allow park rangers to view aggregated data regarding trail usage. The app is not intended to be used during a hike, but rather to assist hikers with planning their hike. In addition, the app is not intended to be used for emergency situations, due to the lack of reliable WiFi connection.

Project Goals

Given the scope of the project, our goals are as follows:

  1. Address the challenges of paper trail logs and promote sustainable growth by implementing a digital trail log system.
  2. Implement a system that can operate in situations with no wifi or power supply.
  3. Conduct in-person tests of the digital trail log system using the RIT trails.
  4. Implement a plan to transition from paper trail logs to digital trail logs with no data loss.
  5. Enable park rangers to effectively manage trail usage by providing accurate and timely information.

Milestone Chart

Milestone Completion Date
Complete designs for Web App 10/5/23
Begin implementation of Web App 10/10/23
Complete implementation of Web App 11/2/23
Begin implementation of Trailhead Kiosk 11/7/23
Complete implementation of Trailhead Kiosk 11/30/23
Begin implementation of Remote Kiosk 12/5/23
Complete implementation of Remote Kiosk 12/11/23
Begin user testing of entire system 1/23/24
Begin implementation of stretch goals 2/6/24
Complete implementation of stretch goals 4/23/24

Major Deliverables

In addition to action submissions, such as the midterm project review, short video, and final project presentation, our project will have several major deliverables. The first deliverable is the Web App, which we expect to complete by the beginning of November. The second deliverable is the Trailhead Kiosk, which we expect to complete by the beginning of December. The third and final deliverable is the Remote Kiosk, which we expect to complete by the end of December. Once these three deliverables are completed, we will implement any stretch goals and additional features that could improve the system.

Initial Requirements

Communication Plan

What Needs to Be Communicated Why Between Whom Best Communication Method Responsibility for Sending When/How Often
Agenda for sponsor meeting To set expectations prior to meeting and to act as a guide during the meeting Team, sponsor, and coach Email Heather Once a week, after our team meeting on Tuesday but before our Thursday meeting
Project status To give an overview of progress and show project success Team, sponsor, and coach Meetings (in-person/virtual) All team members Once a week at our Thursday meeting with our sponsor and coach
Project risks To inform stakeholders of risks and allow stakeholders to manage their risks related to the project Team, sponsor, and coach/td> Meetings (in-person/virtual) All team members Once per sprint, where each sprint is 2 weeks
Changes in requirements Changes in requirements will likely affect our development timeline and project scope Team, sponsor, and coach Meetings (in-person/virtual) Sponsor and all team members As needed, but likely once per sprint as development progress is evaluated
Changes in schedule/timeline Schedule changes will affect our development timeline Team, sponsor, and coach Meetings (in-person/virtual), email Heather As needed
Changes in team organization Changes in our team organization will impact our structure and individual roles Team, sponsor, and coach Meetings (in-person/virtual), email Heather As needed

Stakeholder Management Plan

ID Stakeholder Name Role Responsibilities Level of Interest (1-5) Level of Influence (1-5) Communication Frequency Communication Method
1 Craig McGowan Board Member, Project Sponsor Guiding project requirements, providing feedback on development 5 5 Weekly Email, meeting (in-person/virtual)
2 Ari Epstein Board Member, Project Sponsor Guiding project requirements, providing feedback on development 5 5 Weekly Email, meeting (in-person/virtual)
3 Mark Wilson Project Coach Providing feedback on development, providing guidance on development practices 5 5 Weekly Email, meeting (in-person/virtual)

Risk Management Plan

To manage and monitor short-term risks, our team will use the 4-ups, which are updated weekly. To manage long-term risks, we will utilize the following practices and processes:

  1. Risk Identification
    1. SWOT analysis
  2. Risk Analysis
    1. Risk exposure (RE) calculations
      1. RE = Impact * Probability
  3. Risk Prioritization
    1. Combine Risk RE, category, indicators, mitigation, contingencies, affected stakeholders, and resources for each risk. These will be aggregated in an excel spreadsheet.
  4. Risk Management Planning
    1. A risk management initial planning cycle will take place during a team meeting to examine initial, obvious long term risks.
  5. Risk Resolution
    1. We will decide actions to take towards each risk whether its avoidance, mitigation, knowledge/talent acquisition, or risk transfer
  6. Risk Monitoring
    1. A risk management review session will be conducted at the beginning of every iteration (sprint cycle).