Paciolan

Configuration Management

Team Members

Matthew Olitoquit | Austin Tang | Riana Zuchlewski | Ada Lo | Cong Han

Development Process

Overview of Our Process

Getting to Know the Project

The first step for our team was to meet with our sponsors, understand what their company does, what they stand for, and learn more information about the project.

Create Slices Based on Project Requirements

Based on our sponsor's requirements, we created slices and developed user stories to plan our workflow. This was inspired by the Kanban method to implement Agile into our project.

Learn the Framework

The frameworks we have utilized in our project are React and AWS. Both were new to us individually, but are now part of our skillset as a team!

Get to Work !

After initial preparations, we started this project by developing the skills needed to execute our sponsor's vision for our project.

As a team, we worked in parallel with the support of our sponsors to become better programmers in Javascript and HTML.

How Did We Work With Our Sponsors ?

To start, we had longer meetings to get to know the team of sponsors that our project group will be working with closely for the next two quarters. We discussed the details of our project and the expectations between our team and theirs.
The next major step was an inception meeting with our sponsors to create slices and tasks that curated our workflow for the next few months. This inception meeting was our first step into implementing strategies commonly found in software engineering careers.
After getting more in-depth about our project, our sponsors hosted a few training sessions with coding exercises that would teach us how to utilize the frameworks required for this Capstone.
During the first quarter, we had daily stand-up meetings ranging from 15 minutes to one hour. As we started to understand how to work as a team, communicate with each other and coordinate our deliverables, we transitioned to two stand-up meetings per week. Each team member would report their progress and receive feedback from our sponsors. We also took advantage of this time to resolve any outstanding issues that were discovered in our respective subteams, which allowed the whole team to get on the same page.

How Did We Resolve Conflicts & Make Decisions?

We would first discuss issues internally and think of different approaches for a solution that the majority of the group would agree with.
During our stand-up meetings, we would mention the issue to our sponsor, and provide our different solutions.
Ultimately, the decision is made based on the sponsor's suggestions and approval.

How Were Design and Implement Decisions Made?

We were provided with a completed user interface design, but we are also encouraged to discuss with the UI/UX designer on how to improve the design.
Implementation decisions are discussed during standup meetings with our sponsor.

Challenges

Knowledge Deficiencies:

While the group had a general understanding of coding fundamentals and languages, the project required a more thorough understanding of the languages and frameworks. The team did not have a strong coding background, but all of us had at least some experience.

Solution:

We scheduled training sessions with our sponsors and and took the initiative to continue learning the frameworks on our own time.

Lack of Experience:

Majority of our group has not practiced with agile software development in the courses they've taken recently.

Solution:

We split into pairs to work on tasks and we would schedule coding sessions to help each other.

Lack of Proper Code Reviews:

Significant changes to the code architecture had to be made due to cascading problems not being discovered in earlier code reviews with our sponsor.

Solution:

Code reviews moving forward would be more detailed and involved with our sponsors. We would inform our sponsor about our implementation strategy to understand their approach.

Documentation

Miro Board & Figma

Project Trello Broad

Documentation That We Created for This Project Include:

Miro Board: The byproduct of our initial inception meeting. We used this tool to visualize and create smaller tasks based on project requirements. We then categorized the tasks by "size" and whether it was backend or frontend work.
Figma: Documents provided by our sponsors for the design and interactions of the webpage. We are using this as reference as we work on our project from the ground-up.
Trello Board: The tasks from the Miro board are converted into "cards" with descriptions on the Trello board. Utilizing "user-stories" as our product management technique, they are used to assign tasks and keep track of our working progress.
Requirements Document: We have documented the tasks and requirements from the inception meeting into a formal document and separated them between functional and non-functional requirements. This is a living document that is routinely monitored thorughout our project's lifespan, with changes being made when the need arises.
Sprint Reports: We have created bi-weekly reports of our progress to reflect on everyone's contributions and challenges that were encountered within those two weeks. Burn-down charts are included to visualize our progress, which also displays how much we are deviating away from our initial expectations.

Evaluation

For our backend architecture, unit testing was done through JEST. This was another aspect of JavaScript that our team had to spend training time on. As we moved onto Slice 2, we noticed that JEST was inefficient in testing our design since our code architecture was mostly for the frontend of the configuration tool. To comply with the demands of the project schedule, we focused on general functionality testing. This includes verifying if the correct components are being rendered, interaction with those components are operational, and if our branches were compatible with each other prior to merging within our code repository.

Working within our sub-teams, we found design and implementation discrepancies as we were building our code. Simple fixes were either remedied by personal online research or coding sessions with our sponsor, a software developer for Paciolan. There have been instances where our code architecture needed an extreme overhaul to meet the requirements of functions found in later slices.

If our code disabled any functionality of the configuration tool, we created a new user story to make time later in the project schedule for repairs. This allowed us to continue progressing through the project to respect the internal deadlines of our user stories.

Final Product

Configuration Tool

We have implemented an online configuration tool with a simple user interface that allows Paciolan and their clients to make configuration on the clients' websites. This configuration tool will improve the efficiency of Paciolan's workflow and decrease the amount of time it takes to get changes into production.

For design, our final result is a two-page configuration management tool that consists of a Client List, with each client having their own configuration page.
While currently in a developmental state, our tool connects with Paciolan's frameworks using Amazon Web Services to share and receive data from their API.

As shown below, each interface has their own functions that were designed by Paciolan's design team, but coded and developed by our team from scratch!

Aside from the GitLab repository, there are no other deliverables that we need to provide to our client. Since our code is still in-development, Paciolan's software team will be continuing the configuration management tool using their official Client Data information. The GitLab repository will contain other documentation that is required, such as the README.md that will guide the software team to initialize the project.

Video of The Configuration Management Tool

Brief overview of our capstone project
Covers the problem it solved
Screen GIFs of some notable features

Client List Page

Dynamically Search for client
Navigate to selected client's configuration page
Sort the client table by ascending or descending order alphabetically.

Client Configuration Page

Edit and save configurations of the selected client's MyAccount 2.0 page.
Change the branding of a client's page using Hex Codes
View the client's account to confirm changes were implemented.
Toggling cards with switches would disable the component on the Client's account page.
Tool contains pop-up modal components for additional inputs and error prevention to keep a clean, simple interface.

Page updated

Report abuse