2 Project Plan

2.1 PROJECT MANAGEMENT/TRACKING PROCEDURES

Which of agile, waterfall or waterfall+agile project management style are you adopting. Justify it with
respect to the project goals.

Our group will utilize the waterfall project management model for this project. We chose the waterfall
model because we felt like it is better conducive to the structure of the class overall. Our first goal for the
semester is to complete a project plan that is of a high quality and can be easily used as a roadmap for
development of the project. We feel that we are better equipped to satisfy this goal if we focus entirely on
the project plan this semester, which constitutes the requirements phase of the waterfall method.
Additionally, another goal is to develop relevant skills for the project; our team believes that it is better to
develop skills during the requirements phase when we have more time than during an agile method with
two week sprints when we are actively trying to resolve issues. Finally, our last goal is to ensure our
project will not only function, but will also wholly satisfy the needs and desires of the client. In order to
achieve the needs and desires of the client, the requirements need to be correct. We feel like the dedicated
requirements phase of waterfall allows us to find the requirements better, which in turn will allow us to
achieve the needs and desires of the client.

What will your group use to track progress throughout the course of this and the next semester. This
could include Git, Github, Trello, Slack or any other tools helpful in project management.

During the first semester, we will utilize Discord and Google Docs to track progress. Since we are mainly
working in Google Drive for the project plan document and related tasks, it makes sense for us to also
track progress within the same software. To track progress during the development phase in the second
semester, our group will utilize Gitlab issues. Each issue will be assigned a number of effort points, which
will be utilized to ensure that all group members are assigned an equal amount of work. These issues will
then be placed into an issue board so that the issues can be easily visible and categorized. Finally, Gitlab
supports milestones as well; each issue will be tied to a larger milestone. Although Gitlab will be our
main source of tracking progress, Discord will be used as well for informal information on progress.

2.2 TASK DECOMPOSITION

In order to solve the problem at hand, it helps to decompose it into multiple tasks and subtasks and to
understand interdependence among tasks. This step might be useful even if you adopt agile methodology.
If you are agile, you can also provide a linear progression of completed requirements aligned with your
sprints for the entire project.

● Frontend
○ Create User Interface screen flow diagram
■ Design different components for each page
■ Articulate flow from one page to another
○ Create each individual UI component by picking high risk components first
 ■ Create UI for entering in transfer courses
■ Create UI for 4 year plan - highest risk
■ Create UI for login - lowest risk
■ Create UI for aggregate data screen
■ Create UI for viewing students that have accessed the site
○ Connect Frontend to Middleware
○ Verify UI design with Iowa State UI/UX domain experts
● Middleware
○ Integrate JSON parser for Workday API
○ Create methods to communicate with Workday API
○ Create methods to follow business logic rules to process data
○ Create REST API
● Backend
○ Set up Mocked Workday API
○ Database
■ Set up database
■ Integrate database with API

2.3 PROJECT PROPOSED MILESTONES, METRICS, AND EVALUATION CRITERIA

What are some key milestones in your proposed project? It may be helpful to develop these milestones for
each task and subtask from 2.2. How do you measure progress on a given task? These metrics, preferably
quantifiable, should be developed for each task. The milestones should be stated in terms of these metrics:
Machine learning algorithm XYZ will classify with 80% accuracy; the pattern recognition logic on FPGA
will recognize a pattern every 1 ms (at 1K patterns/sec throughput). ML accuracy target might go up to
90% from 80%.In an agile development process, these milestones can be refined with successive
iterations/sprints (perhaps a subset of your requirements applicable to those sprints).

● Frontend
○ Key milestone: Look for components that are in Bootstrap 5 which can be used for all
the functionality users will need to input their courses and output the four year plans in an
efficient UI/UX.
○ Key milestone: Be able to efficiently navigate forward and backward of the transfer
courses page in less than 5 seconds. Create screen flow diagrams that provide how each
page will interact with each other.
○ Key milestone: Connect frontend to the middleware using PHP and HTML
● Middleware
○ Key milestone: Creating methods that would communicate with the Workday API. REST
and JSON are frameworks that will be used to communicate with Workday.
○ Key milestone: Efficiently retrieving the four year plans and the coursework in less than
1 seconds regardless of the number of courses entered.
● Backend
○ Key milestone: Setting up a mocked Workday API on a server that would replicate REST
endpoint functionality and appropriate API responses in less than 1 seconds.
 ○ Key milestone: Setting up a database with mocked data filled from Workday that uses
MySQL.

2.4 PROJECT TIMELINE/SCHEDULE

● A realistic, well-planned schedule is an essential component of every well-planned project
● Most scheduling errors occur as the result of either not properly identifying all of the necessary
activities (tasks and/or subtasks) or not properly estimating the amount of effort required to
correctly complete the activity
● A detailed schedule is needed as a part of the plan:
○ Start with a Gantt chart showing the tasks (that you developed in 2.2) and associated
subtasks versus the proposed project calendar. The Gantt chart shall be referenced and
summarized in the text.
○ Annotate the Gantt chart with when each project deliverable will be delivered
● Project schedule/Gantt chart can be adapted to Agile or Waterfall development model. For agile, a
sprint schedule with specific technical milestones/requirements/targets will work.

The Gantt chart here is broken down into three major tasks: Frontend, Middleware, and Backend.
These major tasks each have their own subtasks - some of which belong to a group, like Diagramming,
UI, JSON Parsing, and Database. For this chart, we put the diagramming at the front because it is required
for the rest of the Frontend work to be completed. The Middleware and Backend tasks, even though they
could also be started in December, will wait until January to follow the structure of the course, where the
first semester is for documentation, while the second semester is for implementation. All tasks and
subtasks are to be completed by May.
The tasks that are in parallel can be completed this way because none inherently rely on the others
and we have enough group members to accomplish each of these simultaneously.

2.5 RISKS AND RISK MANAGEMENT/MITIGATION

Consider for each task what risks exist (certain performance target may not be met; certain tool may not
work as expected) and assign an educated guess of probability for that risk. For any risk factor with a
probability exceeding 0.5, develop a risk mitigation plan. Can you eliminate that task and add another task
or set of tasks that might cost more? Can you buy something off-the-shelf from the market to achieve that
functionality? Can you try an alternative tool, technology, algorithm, or board? Agile project can associate
risks and risk mitigation with each sprint.

Task Risks & Probability (In Mitigation

parenthesis)

Create User Interface Screen None None

Flow Diagram

Create each individual UI 1. Components don’t integrate 1. Use PHP for all components
component by picking high risk well and make a cohesive to ensure component
components first experience (0.2) integration
2. Some components can’t be 2. Relax performance
as user friendly due to 1 constraints to make sure UI
second round trip time is user friendly
performance constraints
(0.5)

Connect Frontend to 1. Frontend and middleware 1. Use a well known process

Middleware cannot communicate (0.1) communication method like
2. Cannot enforce REST to help make
communication speed is communication between
faster than a 1 second round processes easy
trip time desired threshold 2. Research other process
(0.3) communication methods and
change to a more performant
one

Verify UI design with Iowa State 1. ISU rejects the UI design 1. We will have the UI design
UI/UX domain experts (0.2) approved incrementally to
have less time reworking
components

Create JSON parser for 1. Workday updates their API 1. Monitor changes to
Workday API queries causing our JSON parser to Workday’s API and have our
no longer work (0.1) Workday our mocked API is
up to date

Create methods to communicate 1. Workday updates their API 1. Monitor changes to

with Workday API causing our mocked one to Workday’s API and have our
be out of date (0.1) Workday domain expert
2. Iowa State IT verify our mocked API is up
misunderstands Workday to date
API functionality (0.2) 2. We will have regular
meetings with our domain
expert from ISU IT to fix
any misunderstandings
quickly
 Create methods to follow 1. The rules of what courses 1. Design extensible and
business logic rules to process are required and what modular code to make any
data courses transfer may change changes easy or find a
(0.9) solution where Workday can
handle this for us

Create REST API for 1. REST API cannot handle 1. Research other process
middleware less than a 1 second round communication methods and
trip time(0.3) change to a more performant
one

Set up Mocked Workday API 1. Workday updates their API, 1. Monitor changes to
causing our mocked one to Workday’s API and have our
be out of date (0.1) Workday domain expert
verify our mocked API is up
to date

Database 1. Workday updates their API 1. Monitor changes to

causing our mocked Workday’s API and have our
database of information to Workday domain expert
be out of date(0.1) verify our database is up to
date

2.6 PERSONNEL EFFORT REQUIREMENTS

Include a detailed estimate in the form of a table accompanied by a textual reference and explanation.
This estimate shall be done on a task-by-task basis and should be the projected effort in total number of
person-hours required to perform the task.

Task Man
Hours

Create User Interface Screen 50 Usability is one of the major requirements for this project
Flow Diagram so it is important to get the design right. We will need to
verify the design with the team often to ensure a user
friendly experience.

Create each individual UI 160 4-year plan: 80, transfer courses: 50, login: 30. Creating
component by picking high risk the UI components will take the most amount of time
components first while hooking them up to data providers should be fairly
simple.

Final Connection of Frontend to 30 We will do basic integration early in the project and
Middleware finish the full integration later on. The full integration of
the middleware to the frontend will require more time
and effort.
 Verify UI design with Iowa State 20 This effort estimation assumes 2 meetings and accounts
UI/UX domain experts for any rework from feedback we receive.

Integrate JSON parser for 30 This expected number could go down as we explore the
Workday API queries different libraries available for us to use.

Create methods to communicate 30 The bulk of this task will be understanding what data we
with Workday API can get from Workday and adapting it to the frontend’s
needs.

Create methods to follow 80 The expected effort for this task depends a lot on what we
business logic rules to process learn from IT concerning what can be pulled from a
data workday database and what rules we have to create
ourselves, i.e. 4 year plan.

Create REST API 30 This is a small task for the frontend to communicate with
our middleware. We do not expect to cause many
problems and therefore should not require a large amount
of effort.

Set up Mocked Workday API 80 This is based on our current understanding of what
Workday is and what information it will provide.

Create Database 80 We are assuming we will have to keep records on student

information, their 4 year plans and so on. When we get a
better idea from IT about all the data that workday will
hold, it will reduce how much work we have to put into
the database. At the least, we will still need a database for
any mocked workday data we will want to use while
building the program.

Integrate Database and API 40 The effort put into this task will go hand in hand with
how much effort is put into the database. The larger and
more complex our database is, the more work to integrate
it with our mocked workday API.

Integrate Middleware and API 30 This task is split into 2 phases. We will do a basic
integration early to get the two aspects linked which will
only take about 5-10 man hours. Towards the end of the
project, the full integration will require more effort as we
will have more functionality to link together and likely
more issues to solve.

2.7 OTHER RESOURCE REQUIREMENTS

Identify the other resources aside from financial (such as parts and materials) required to complete the
project.
We will utilize a virtual machine for the purposes of hosting our web application. The virtual machine will
be capable of not only hosting the frontend of the web application but can also host the middleware. Our
virtual machine has already been set up by ETG and runs Windows 10. Otherwise, our group will not
require any additional resources for this project.