CS 499: Computer Science Capstone
Professional Self-Assessment
This ePortfolio represents the end of my computer science program, but it is more useful to me as a record of how my engineering judgment developed. I began the program with working knowledge of software testing and a strong concern for reliability. Through the program, I learned to connect that concern to architecture, algorithms, databases, secure coding, and communication. The three enhanced artifacts are not separate class assignments placed next to each other. Together, they show one repeatable process: examine a working system, identify a bounded weakness, select an appropriate improvement, test the expected and restricted paths, and use evidence to explain the result.
The portfolio follows that process through three stages. The Travlr Getaways enhancement focuses on architecture and design by adding role-based access control to a full-stack application. The ABCU Advising Assistance Program focuses on algorithmic efficiency by replacing an ordinary binary search tree with a self-balancing AVL tree and explicit smart-pointer ownership. The Grazioso Salvare dashboard focuses on database security and integrity by moving configuration out of source, authenticating staff access, enforcing a MongoDB schema, allocating record numbers atomically, and measuring an index with explain output. This progression mirrors a full software lifecycle: establish a trustworthy permission boundary, choose and measure an efficient internal structure, and protect persistent data at the storage boundary.
My professional experience at Karl Storz Endoskope shaped how I approached every enhancement. I test software for medical equipment used in surgical procedures, where a missed defect can become a patient-safety issue. I have had opportunities to work on software quality, automation, Agile processes, requirements, and collaborating with software engineers in a regulated medical device environment. Coursework outside the three selected artifacts also shaped my approach. In CS 320, I wrote unit tests targeting 80-90% code coverage and learned to treat testing as part of the design rather than a step added at the end. CS 305 also pushed me to think about software in layers and consider security across the system.
Collaboration and Stakeholder Support - Outcome One
The first program outcome is about using strategies that help diverse audiences make decisions. At Karl Storz, much of my work involves translating technical details into requirements, test evidence, instructions, or explanations that other people can act on. Working with software engineers, quality standards, Agile processes, and requirements in a regulated environment has shown me that collaboration depends on making both the risk and the result understandable. In my Module One plan and later journal reflections, I connected the same idea to explaining technical work for people who did not take the original courses and organizing the final portfolio so visitors can understand each project before opening the source. I do not treat one artifact alone as complete evidence of every part of collaboration. The evidence is cumulative across professional experience, coursework, the code review, narratives, and the final ePortfolio.
Travlr provides the most direct audience example. The application serves customers or standard users and administrative staff, and those groups should not receive the same controls. The code review and narrative explain why the interface, server rules, and test evidence distinguish those responsibilities. The server returns 401 when identity is not established, 403 when an authenticated user lacks permission, and a successful response when the administrator role is allowed. These observable results make the permission decision understandable to developers and reviewers.
The other two artifacts also support decision making for different audiences. The advising program preserves the familiar load, list, and search workflow while changing the internal tree, so an academic-advising user gains predictable performance without having to learn a new interface. The rescue-dog dashboard translates shelter rules into named filters and presents results through a table, outcome chart, and map. In each case, I used technical changes to support the people who depend on the system rather than treating implementation as an end by itself.
Professional Communication - Outcome Two
The second outcome requires professional communication in oral, written, and visual forms. The recorded code review is the oral component. It introduces the original functionality, shows the relevant code, distinguishes strengths from limitations, and connects each planned enhancement to course outcomes. I organized it for an audience that did not take the original courses, which forced me to explain concepts such as authentication versus authorization, tree height, and database indexing without assuming the audience already knew the implementation.
The three narratives and this self-assessment are the written component. I use the same evidence-driven structure throughout: context, decision, implementation, result, trade-off, and reflection. The ePortfolio is the visual component. A portfolio can explain the problem a project addressed, show the finished result, and guide a visitor toward the source code and supporting evidence. Navigation and download links let a reviewer move from the professional self-assessment to the code review, submitted narratives, and original and enhanced artifacts.
This structure follows the approach I described in my Module Five journal. A repository can hold the complete work, while GitHub Pages and lightweight Markdown give employers, coworkers, and other visitors a clear introduction before they explore the source in detail. Each portfolio page therefore begins with the problem and result, then provides links to the submitted narrative, original and enhanced code, and supporting evidence. The level of detail changes, but the underlying facts remain consistent.
Data Structures, Algorithms, and Trade-Offs - Outcome Three
The third outcome is most visible in the ABCU enhancement. Earlier in CS 300, I compared vectors, hash tables, and binary search trees for an advising application. In the capstone, I returned to the selected tree and examined a limitation that was easy to overlook when using a small classroom dataset: an ordinary binary search tree has no protection against an unfavorable insertion order. Sorted input can make its height approach the number of records, which changes search and insertion from the expected logarithmic behavior to linear behavior.
I replaced that structure with an AVL tree that records height and applies left, right, left-right, or right-left rotations after insertion. I also replaced owning raw pointers with std::unique_ptr so ownership is explicit and cleanup is automatic. Automated tests cover all four rotation cases, tree invariants, missing courses, duplicate keys, empty input, sorted input, and in-order output. The original user-facing behavior remains the same, which made direct regression testing possible.
The benchmark demonstrates both the benefit and the cost. With 10,000 records inserted in sorted order, the ordinary tree reached a height of 10,000 while the AVL tree remained at 14. The median successful-search total dropped from 306,753.1 microseconds to 1,929.4 microseconds in that worst-case scenario. On randomized input, however, the ordinary tree built faster at 10,000 records: 3,307.2 microseconds compared with 5,143.5 microseconds for the AVL tree. That result matters because it prevents an exaggerated conclusion. AVL balancing provides a predictable worst-case bound, but height bookkeeping and rotations are not free. The correct choice depends on the workload and the value of predictable performance.
Software Engineering and Database Practice - Outcome Four
The fourth outcome asks for well-founded tools and techniques that produce value. Each enhancement uses established tools and practices to solve a specific design problem without adding unnecessary complexity. In Travlr, the enhancement uses a constrained role field, a trusted claim in a signed token, reusable Express authorization middleware, Angular route and interface controls, and direct API tests. The server remains the security boundary because a client-side control can be bypassed. The test matrix covers an authorized administrator, an authenticated regular user, missing authentication, invalid or expired authentication, and protection against a public registration request that tries to self-assign an administrator role.
The database enhancement applies the same discipline at a different layer. MongoDB and dashboard settings are loaded from environment variables, staff authentication protects access, and the collection uses JSON Schema validation so invalid data is rejected even when a write bypasses the Python class. An atomic counter plus a unique index prevents concurrent inserts from assigning the same record number. The dashboard uses named columns and safe empty-state behavior instead of depending on fragile numeric positions or assuming that data always exists. The final test suite produced 30 passing tests, including real MongoDB integration checks and concurrent counter allocation.
The compound sex-and-age index was measured instead of merely added. On a 1,000-document representative dataset, the original query performed a collection scan and examined all 1,000 documents to return 97. After the index was added, MongoDB used the named index and examined 97 keys and 97 documents to return the same 97 records. I also documented the remaining limitation: the case-insensitive, unanchored breed regular expression is still evaluated after the index narrows the sex and age range. This is a useful result because it improves the common predicates without claiming that one index solves every part of the query.
Security Mindset - Outcome Five
The fifth outcome ties the portfolio together. My security approach is to identify where trust is established, constrain what crosses that boundary, and test how the system behaves when an assumption is false. Travlr separates authentication from authorization and follows least privilege. A valid token establishes identity, but it does not automatically grant administrative permission. Public registration always creates the restricted role, and the API enforces authorization even if a user bypasses the Angular interface.
The Grazioso enhancement applies defense in depth. Credentials and connection details are no longer embedded in enhanced source code. Authentication protects the dashboard, application validation gives clear feedback, MongoDB validation protects the stored collection, and empty update or delete selectors are rejected to prevent accidental broad operations. The AVL enhancement contributes to security in a different way: explicit smart-pointer ownership reduces memory-management risks that can result from manual deletion and unclear ownership.
Negative testing is an important part of this mindset. I tested missing and invalid tokens, insufficient roles, attempted role escalation, absent configuration, rejected database documents, empty datasets, missing courses, duplicate keys, and invariant violations. These cases anticipate failure and misuse instead of assuming that only the successful path matters. I also kept the limitations visible: Basic Authentication requires HTTPS outside local testing, the breed regular expression remains a residual filter, and AVL balancing adds implementation and insertion overhead. Security and reliability improve when limitations are documented honestly rather than hidden behind a passing demonstration.
Professional Growth and Direction
Completing the program has changed how I evaluate software. I still begin with whether the system works, but I now ask additional questions: Who is allowed to perform the action? What happens with adversarial or malformed input? Does the data structure have a predictable boundary? Can the database enforce its own integrity? What evidence would another engineer need to reproduce the result? Those questions are visible across all three artifacts and reflect the kind of engineer I want to become.
My next goal is to move into broader software engineering responsibilities, especially in medical technology or another regulated environment where secure design, testing, and documentation have practical consequences. I also want to continue developing in cloud systems, DevSecOps practices, and collaborative delivery methods. This portfolio does not claim experience in every part of computer science, and areas such as mobile and embedded development remain outside its scope. It does show that I can learn an unfamiliar layer, make a focused improvement, explain the trade-offs, and support my conclusions with working evidence.
The most important result of the capstone is therefore not one framework, language, or database feature. It is the process I can carry into future work: preserve what is already correct, make the smallest change that addresses the real risk, test both allowed and denied behavior, measure the result, and communicate it clearly enough that other people can make an informed decision.
Portfolio Contents
- Code Review
- Enhancement One: Software Design and Engineering
- Enhancement Two: Algorithms and Data Structures
- Enhancement Three: Databases