Self-Assessment

Completing the Computer Science program at Southern New Hampshire University has been a meaningful experience that has shaped both my technical skills and my professional approach to solving real-world problems. Throughout the program, I have had the opportunity to apply computer science principles in ways that extend well beyond academic exercises, and my capstone project shown in this ePortfolio is the clearest example of that. I did not build the 84 Community Food Pantry Web Application for a grade, it was built to help my community food pantry be more effective to be able to feed more people. Every decision to enhance the application has practical use in mind.

While volunteering at the 84 Community Food Pantry, I observed firsthand the operational challenges the coordinators faced managing recipient registrations, food distributions, and volunteers using the manual processes. Before the system existed, eligibility determinations were performed by hand using printed guideline tables. Distribution registrations were tracked by hand using pen and paper, and communication was handled manually by sms texting. I developed the application based on direct observation of these processes and ongoing input from the volunteers who would use it. As the system was introduced into their operations, I gathered feedback on how it fit into their workflows and made improvements based on what was and was not working in practice. I also collected feedback from recipients of the food pantry on the ease of the registration process, which allowed for proper refinement to the recipient-facing components of the system. This experience reinforced that effective software development is not a solitary process, but it requires listening to the people who will use the system and designing solutions around their actual needs rather than assumptions about them.

Collaborating in a team environment and communicating with stakeholders were skills I developed throughout the program and applied daily in my professional role. In my current position, I lead a team of Systems Administrators and regularly partner with software developers to design and build systems that meet both technical and operational requirements. This cross-functional collaboration requires translating infrastructure and security constraints into terms that developers can act on and translating application requirements into infrastructure decisions that the systems team can implement reliably and maintain scalability. My capstone project reflected this same dynamic. Working with the pantry volunteers required translating operational needs into technical requirements and communicating design decisions in terms that were meaningful to a non-technical audience. For example, when I introduce the Role-Based Access Control system, I will need to explain to the volunteer team not just what had changed, but why the change matters and how the new structure will be shaped to their current area of responsibility. Courses such as CS 250 Software Development Lifecycle gave me frameworks for thinking about stakeholder communication and requirements gathering that I applied throughout this project. The ability to bridge the gap between technical implementation and practical operational impact is a skill I consider essential as a technology leader and a software developer.

My work in data structures and algorithms throughout the program prepared me to approach the eligibility determination engine with a clear understanding of what makes an algorithm reliable and maintainable. Courses such as CS 300: Analysis and Design and other computer science coursework taken at Edinboro University in my past, gave me a foundation for thinking about how reference data should be structured to support decision logic efficiently. The eligibility engine I developed for my capstone translates Federal Poverty Level guidelines into a deterministic classification process that separates reference data from procedural logic, stores threshold values in a normalized database table, and handles boundary conditions consistently. This design reflects an understanding of how the right data structure choice directly affects the long-term maintainability of a system. Leading a systems team has reinforced this understanding for me as decisions made at the architecture level have long-term consequences that are far more costly to correct after deployment than they are to get right from the beginning.

Software engineering and database design are areas where I have both academic preparation and significant professional experience. In my role as Senior Manager of Systems and Security Administration, while partnering with the software developers, I have seen firsthand how gaps between application design and infrastructure design create operational problems that are difficult to resolve after a system is in production. The SNHU Computer Science program enhanced my ability to apply formal software engineering principles to close that gap. The Role-Based Access Control enhancement required coordinated changes across both the database schema and the application authentication layer, which demanded the kind of disciplined, structured thinking that software engineering courses were reinforced. The database enhancements required writing production-safe deployment scripts that could be applied to a live system without data loss. This constraint pushed me to be more deliberate about order of operations and constraint enforcement than typical development work often requires. Applying iterative testing practices learned through CS 320: Software Test, Automation, and Quality Assurance, I verified the eligibility engine against a range of known household size and income combinations. I also tested boundary cases to confirm the algorithm produced the correct tier assignment. This is a discipline I now bring to every system my team supports.

Security has been a consistent theme across my program and is central to my professional role as a systems and security manager. Courses such as CS 305: Software Security, helped define the principles that I applied directly for this project. The original application contained an unauthenticated account creation page that posed a real security vulnerability. Addressing this through a database-driven Role-Based Access Control system, rather than just removing the file, reflects the security mindset the program helped me develop. In my professional role, I am responsible for anticipating and mitigating security risks across the systems my team manages, and I regularly work with software developers to ensure that security is considered at the design level rather than addressed as an afterthought. Designing systems that anticipate how they could be misused and building defenses into the architecture rather than layering them on afterward, is an approach I carry into both my academic and professional work.

The three enhancements in this ePortfolio are not independent exercises but rather represent three layers of the same real-world system. Enhancement One addresses the security and access control architecture of the administration portal. Enhancement Two addresses the algorithmic logic that automates eligibility determination for recipients. Enhancement Three addresses the database schema that supports both of those enhancements, ensuring that the underlying data structures are normalized, integrity-enforced, and safe to deploy in a production environment. Together, they demonstrate an ability to design and improve a complete software system from the application layer through the data layer, with security and maintainability considered at every level. This portfolio reflects not only the knowledge gained throughout my time in the Computer Science program at SNHU, but also how that knowledge has been applied to deliver a solution that provides meaningful value to my community. Completing this program has strengthened my technical expertise and leadership capabilities, allowing me to lead more effectively and contribute at a higher level within my organization.

Code Review

Before any enhancements were made, I conducted a structured code review of my selected artifact. The review walks through existing functionality, identifies areas for improvement in structure, logic, efficiency, security, and documentation, and outlines the planned enhancements mapped to the five course outcomes.

Watch my code review video!

Artifact Overview

The artifact used across all three enhancement categories in this ePortfolio is the 84 Community Food Pantry Web Application, a full-stack web application developed to support the operations of a local community food pantry. The application manages recipient contact information, registration tasks, distribution scheduling and tracking, and administrative functions used by volunteers during food distribution events. The system was originally developed as a production solution for the pantry and was cloned and purged for use in this capstone project so enhancements could be implemented without affecting the live environment. These improvements will be integrated into the production system upon completion of this course.

Enhancement One — Software Design and Engineering

The artifact I selected for the Software Design and Engineering category is my 84 Community Food Pantry Web Application, a full-stack web application I developed to support the operations of my local community food pantry. The application manages recipient contact information, recipient registration tasks, distribution tracking, and administrative functions used by the volunteers during food distribution events. The system was originally developed as a solution for the pantry; I cloned and purged the production system for use in my capstone project so enhancements could be implemented without affecting the live system. These enhancements will be integrated into the live system upon my completion of this course.

I selected this artifact for my ePortfolio because it demonstrates several important software engineering principles including secure system design, database-driven application architecture, and maintainable authentication logic. The system is actively used in a real community environment, which requires the software to be reliable, secure, and adaptable as operational needs change. This made this artifact a strong example of applied software design.

The enhancement implemented for this milestone was the development of a Role-Based Access Control system, or RBAC, for the administration portal. Based on the original design of the application, all administrative functions were handled by a small group of volunteers. Because of this, an unauthenticated page was created which would accept a username and password, hash the password and insert the username and hashed password into the database. This method, although acceptable for initial setup and first admin creation, if not addressed, poses a significant security vulnerability if it were discovered. To address this, I redesigned the authorization structure so that administrative permissions are defined in the database and enforced by the application logic. This required creating a new roles table, modifying the admin users table to include a role reference, and updating the authentication module to dynamically evaluate user permissions when pages are visited.

Implementing Role Based Access Control significantly improved the system architecture. This improvement separates user identity from permission definitions, which follows standard software engineering practices for secure system design (Ferraiolo et al., 2001). This approach allows additional roles to be introduced in the future without rewriting application logic, improving both maintainability and scalability. I also added safeguards in the administrative user management interface to prevent administrators from accidentally disabling their own accounts or modifying their own privilege level.

Through this enhancement process, I demonstrated skills aligned with several program outcomes, particularly the ability to design and implement computing solutions using established software engineering practices. The redesign required the modification of both the database schema and the application authentication flow, while maintaining compatibility with the remaining application pages. I also considered security implications during development, ensuring that restricted pages could not be accessed through direct URL entry by unauthorized users.

While working on this enhancement, I was reminded of the importance of designing systems that anticipate unforeseen or altered requirements. Although the original version functions correctly for its intended purpose, choosing to not structure the system for role management has inadvertently caused the implementation to be more difficult and left a significant security vulnerability. By introducing a normalized role structure and database-driven permission checks, the system is now more robust and easier to maintain. This experience strengthened my understanding of how thoughtful software architecture decisions can improve both security and long-term scalability of real-world applications.

Screenshots

Admin Dashboard — Before & After

The original dashboard provided no access controls. All navigation options were available to any authenticated user. The enhanced dashboard conditionally shows the User Manager navigation item only to users assigned the Global Admin role.

Original
No User Manager link visible

Enhanced
User Manager link visible for Global Admin role

User Manager

The User Manager, only accessible to the Global Admin role, displays all administrative accounts with their assigned role, status, and last login. Role badges visually distinguish Global Admin from Pantry Admin accounts, and the currently logged-in user is identified with a "You" badge to support the safeguard preventing self-modification.

Add Admin User

New administrator accounts require a username, password, and role assignment at creation. Roles are populated dynamically from the database, ensuring that any roles added in the future automatically appear in this interface without code changes.

Edit Admin User

The edit interface allows a Global Admin to change another user's role, reset their password, or deactivate their account. Safeguards in the application logic prevent an administrator from modifying their own role or deactivating their own account from this screen.

Artifact Files

File	Description
_auth.cfm (Enhanced)	Authentication guard with role loading and page-level access control
index.cfm (Enhanced)	Admin dashboard with conditional User Manager navigation for Global Admin
users.cfm (Enhanced)	User management module — restricted to Global Admin role
_auth.cfm (Original)	Original authentication guard before RBAC implementation
index.cfm (Original)	Original admin dashboard before RBAC implementation

Enhancement Two — Algorithms and Data Structures

The artifact I selected for the Algorithms and Data Structures category is the income eligibility determination engine developed for the 84 Community Food Pantry web application. This component evaluates a household's reported income and household size against Federal Poverty Level guidelines and assigns an eligibility tier used to determine qualification for participation in pantry distributions. The original version of the application was designed primarily to track recipients and distributions, and eligibility determinations were performed manually by reviewing printed guideline tables received by the regional Food Bank, for us it's the Greater Pittsburgh Community Food Bank. The enhanced artifact introduces an automated decision-making component that improves consistency, efficiency, and accuracy when determining eligibility. The eligibility engine was implemented as a modular component using structured decision logic and database-driven threshold values to ensure that eligibility determinations are applied uniformly across all recipients.

I selected this artifact for inclusion in my ePortfolio because it demonstrates practical application of algorithmic thinking and structured data evaluation in a real-world environment. The eligibility engine transforms regulatory guidance into a deterministic classification process that evaluates numeric inputs and produces consistent results. This enhancement highlights my ability to translate policy requirements into a logical algorithm that uses defined data structures to guide decision-making. The component also demonstrates how structured lookup tables can be used to drive classification logic rather than relying on hard-coded values, allowing the system to adapt easily as poverty guideline thresholds change annually. By storing guideline thresholds and eligibility tiers in the database, the algorithm separates reference data from procedural logic, improving maintainability and scalability.

The enhanced artifact applies a step-by-step algorithm that accepts household size and annual income as input, retrieves the corresponding Federal Poverty Level threshold from the database, calculates the household's percentage of the poverty level, and assigns an eligibility tier based on defined ranges. This deterministic approach ensures that identical inputs always produce the same output, which is critical when implementing systems that must follow regulatory guidelines. The algorithm relies on structured data relationships and conditional evaluation logic to determine eligibility classification. The modular design of the eligibility_engine.cfm file also allows the logic to be reused across multiple application workflows, including initial registration and periodic income updates. This demonstrates how separating algorithmic logic into reusable components improves maintainability and reduces redundancy within the application.

Through this enhancement, I demonstrated skills aligned with course outcomes related to algorithm design, structured problem solving, and implementation of computing solutions that address real-world needs. Designing the eligibility determination process required careful consideration of how to structure reference data efficiently, how to minimize repeated calculations, and how to ensure the logic remained adaptable as guidelines evolve. The use of database-driven thresholds provides flexibility and prevents the need for code changes when regulatory values are updated. This design decision reflects an understanding of how appropriate data structures can improve both efficiency and long-term sustainability of a system.

During my work on enhancing this artifact, my primary challenge was understanding and interpreting into code how the algorithm should evaluate household size when an exact guideline match was not available. The Federal Poverty Level guidelines are published with defined income thresholds based on specific household sizes. However, real-world data does not always align perfectly with predefined values, requiring thoughtful handling of boundary conditions. I needed to determine whether the algorithm should require an exact match to a stored household size value or dynamically evaluate the closest applicable guideline range. This required careful consideration of how the lookup logic should behave when handling households larger than the maximum defined guideline value. I implemented logic that ensures the algorithm consistently applies the correct threshold by selecting the appropriate guideline entry and applying a structured comparison method. This experience reinforced the importance of clearly defining algorithm boundaries and ensuring predictable behavior when processing real-world data that may not always align perfectly with structured datasets.

This enhancement strengthened my understanding of how algorithms and data structures support reliable decision-making in software systems. By implementing a structured eligibility determination process, I was able to demonstrate how computer science principles can be applied to improve operational efficiency while ensuring compliance with established guidelines. The resulting component provides a repeatable, transparent, and scalable method of determining eligibility that improves both administrative efficiency and data consistency within the food pantry system.

Screenshots

People List — Before & After

The original People list displayed only name, phone, status, and actions. The enhanced version adds a Tier column showing each recipient's calculated eligibility tier directly in the list, giving volunteers immediate visibility into eligibility status without opening individual records.

Original
No eligibility tier displayed

Enhanced
Eligibility tier badge displayed for each recipient

Add Person — Eligibility Engine Integration

The Add Person form was updated to collect household size and annual gross income at the time of registration. When the record is saved, the eligibility engine runs automatically and assigns the appropriate tier before the record is committed, ensuring every new recipient enters the system with a calculated eligibility result.

Before Save
Household size and income entered — Save triggers the engine

After Save
Recipient added with eligibility tier automatically assigned

Edit Person — Eligibility Results

The Edit Person view surfaces the full eligibility determination result inline, displaying the assigned tier, FPL percentage, FPL threshold amount, and the timestamp of the last calculation. Saving any change to household size or income reruns the engine and updates the result automatically.

Artifact Files

File	Description
eligibility_engine.cfm (Enhanced)	Modular eligibility determination engine using database-driven FPL thresholds
people.cfm (Enhanced)	Recipient management module updated to integrate automated eligibility determination
people.cfm (Original)	Original recipient management module before eligibility engine integration

Enhancement Three — Databases

The artifact I selected for the Databases category is the database schema supporting the 84 Community Food Pantry web application. The application manages recipient records, food distribution scheduling and tracking, registration workflows, and administrative functions used by pantry volunteers. The database schema used for this system was originally created by me in February, 2026, alongside the application itself.

I selected this artifact because it gave me the opportunity to demonstrate real database design skills in a context where the decisions I made would have a direct, meaningful impact on a system that is actively used in my community. The changes made to this schema are being made in a test environment for this course; however, they are being deployed to the production system when this course is complete. That responsibility shaped how I thought about every design decision, from constraint definitions to the structure of audit records.

The two SQL scripts submitted for this milestone, RBAC_Deployment.sql and Eligibility_Engine_Deployment.sql, represent two distinct but complementary database enhancements. The RBAC script introduces a role-based security structure by creating a tbl_Roles table and linking it to the existing tbl_AdminUsers table through a foreign key relationship. This design separates role definitions from user records, enforces reference integrity at the database level, and allows the system to support additional roles in the future without requiring additional changes to the schema (Ferraiolo et al., 2001). The script was written to be safe for deployment into an existing live system; existing user records were updated with appropriate role assignments before the NOT NULL constraint was enforced on the RoleID column, which prevented data integrity violations during migration.

The Eligibility Engine script addresses the database layer of the income eligibility determination system developed in Milestone Three. It extends the tbl_People table with eligibility-related columns, creates a tbl_FPL_Guidelines table seeded with 2026 Federal Poverty Level data published by the Department of Health and Human Services (Office of the Assistant Secretary for Planning and Evaluation, 2023), and creates a tbl_EligibilityAudit table that records a history of every eligibility calculation performed for each recipient. The FPL guidelines table includes a unique constraint on the combination of year and household size, which prevents duplicate guideline records from being inserted during repeated deployments. The audit table is linked to tbl_People through a foreign key, ensuring that audit records can only reference valid recipient records.

Both scripts were written and commented with production safety in mind. Deployment considerations were included to ensure duplication of the schema changes happen safely without loss of data. This approach reflects an understanding that database changes in a live system carry risk, and that a well-written deployment script is as important as the schema itself.

Through this enhancement, I made meaningful progress toward several of the program's course outcomes. The design and implementation of the FPL guidelines table and its relationship to the eligibility engine demonstrates my ability to design computing solutions using appropriate data structures and algorithmic principles. Storing threshold values in a normalized, database-driven table rather than hard-coding them in application logic is a deliberate architectural decision that improves maintainability and ensures the system can adapt to annual guideline changes without code modifications. The role-based security schema demonstrates a security mindset applied at the data layer, enforcing access control definitions in the database rather than relying solely on application logic to manage permissions. Both enhancements together show an ability to use well-founded database design techniques to implement solutions that deliver real operational value.

The course outcomes I planned to address were the ability to demonstrate database design skills, security-conscious schema architecture, and the use of data structures to support algorithmic decision-making. I believe both scripts satisfy these outcomes.

Reflecting on the process of building these enhancements, the most valuable learning came from working through the practical constraints of modifying a live schema safely. I have worked with databases professionally for many years, but this project pushed me to be more deliberate and disciplined in how I documented my intentions and structured my deployment approach. Writing scripts that can be run safely against an existing system, accounting for existing data, enforcing integrity without breaking production, required me to think carefully about order of operations in a way that typical development work sometimes misses.

The eligibility audit table prompted some interesting design thinking. I had to decide whether to track every recalculation or only changes, and whether to store the FPL threshold value at the time of calculation or rely on the guidelines table for historical reference. I chose to store the FPL amount and percent directly into the audit record so that a historical calculation would always reflect the guideline values that were in effect at that time, even if the guidelines table is updated in a future year. That decision felt insignificant at the time; reflecting on that decision shows an understanding of how audit data needs to be treated differently than transactional data.

Overall, this enhancement reinforced that good database design is as much about anticipating how data will be used and maintained over time as it is about getting the structure right for the current requirement. I came away from this milestone with a clearer appreciation for the discipline that thoughtful schema design demands.

Screenshots

Database Relationship Diagram — Before & After

The diagrams below show the database schema before and after the enhancements implemented across both milestones. The original schema contains no role structure linked to administrative users, and tbl_People contains only basic recipient contact fields with no eligibility-related columns. The enhanced schema reflects both the RBAC and eligibility engine additions in full.

Original
No role structure, no eligibility columns on tbl_People, no audit table

Enhanced
tbl_Roles linked to tbl_AdminUsers, tbl_People expanded, tbl_EligibilityAudit added

Deployment Flow Diagrams

The diagrams below illustrate the ordered sequence of operations executed by each deployment script. Both scripts were written with production safety in mind, ensuring that schema changes could be applied to a live system without data loss or integrity violations.

The RBAC deployment flow (left) shows the deliberate order of operations, creating the roles table first, adding the RoleID column to tbl_AdminUsers, updating existing user records with appropriate role assignments, and only then enforcing the foreign key constraint. This sequence was critical to prevent data integrity violations against existing records during migration.

The eligibility engine deployment flow (right) shows the creation of the FPL guidelines and eligibility tiers reference tables, followed by the audit table, before foreign key constraints are applied, ensuring all referenced tables exist before relationships are enforced.

Artifact Files

File	Description
Schema Export — Original	Baseline database schema export prior to any enhancements
Schema Export — Enhanced	Full database schema export reflecting all enhancements applied across milestones
RBAC_Deployment.sql	Deployment script creating the roles table and linking it to the admin users table
Eligibility_Engine_Deployment.sql	Deployment script adding FPL guidelines, eligibility audit table, and recipient eligibility columns

References

Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R., & Chandramouli, R. (2001). Proposed NIST standard for role-based access control. ACM Transactions on Information and System Security, 4(3), 224–274. https://doi.org/10.1145/501978.501980

Office of the Assistant Secretary for Planning and Evaluation. (2023, January 19). Poverty guidelines. ASPE; U.S. Department of Health and Human Services. https://aspe.hhs.gov/topics/poverty-economic-mobility/poverty-guidelines

Video Icon Pictures PNG Transparent Background, Free Download #8044 - FreeIconsPNG. (2016). Freeiconspng.com. https://www.freeiconspng.com/img/8044