Week 8 Update

Progress on Rejection Feature for Graduate Applicants

An update on our progress regarding the implementation of the fallback option for the "Reject Applicants Anytime" feature.

Progress Summary

Backend Completion:

We have successfully implemented the backend functionality for rejecting graduate applicants. This includes:

• A new API endpoint that allows admins to reject applications at any time.
• Database updates
• Security policies ensuring only authorized admins can perform rejections.

Clarification on Scope:

We discussed and clarified the scope of the feature with the client, ensuring alignment on functionality and use cases. This will help avoid any miscommunication during deployment and testing phases.

Sprint Backlog

Here is the list of completed tasks from Week 8:

• Backend API endpoint for rejecting applications.
• Database schema migration
• Policy updates to restrict rejection functionality to admins.
• Initial testing of backend functionality using PHPUnit.

Next Steps

For Week 2, we will focus on:

• Finalizing the frontend UI for rejection functionality

Week 7 Update

Client Feedback & Clarifications:

This week began with a critical clarification of client priorities. After proposing a "save and resume" feature for student applicants, the client clarified that the core request was enabling post-deadline application modifications by admins (e.g., allowing edits to individual applications after the submission period closes). 

Revised Implementation Plan:

Following the clarification, the team pivoted to draft a solution focused on admin control enhancements:

Primary Goal:

• Granular Admin Control: Allow admins to modify individual applications post-deadline or reopen access for specific students.
• Technical Scope: Backend policy/routing adjustments, database schema updates, and frontend UI components for admin dashboards.
• Timeline: 4 weeks (development and testing).

Fallback Option:

• Simplified "rejection-only" functionality (if time constraints arise) to let admins reject applications anytime.

The client enthusiastically approved the proposed plan and emphasized the importance of regular updates.

Next Steps:

• Begin backend policy/routing implementation and database updates.
• Draft UI wireframes for admin modification interfaces.
• Monitor timelines closely to determine if fallback contingency is needed.
• Continue weekly progress syncs with the client.

Key Takeaways:

• Clear communication is essential to avoid misinterpretations of client needs.
• Flexibility in pivoting priorities ensures alignment with client goals.
• The team remains focused on balancing robust backend enhancements with intuitive admin/user experiences.

Looking ahead, Week 8 will focus on backend progress and UI prototyping. 

Product velocity chart remains unchanged:

Week 6 Update

Client Feedback & Priorities:

• Client is pleased with recent UI improvements
• However we anticipated that we are still expected to meet performance targets consistently.
• Team proposed focusing more on backend optimization to balance performance and UI stability. 
• Client agreed and reminded us of backlog requests made last semester and should follow up on that, especially:
• Admin feature enhancements.
• Student application progress saving ("save and resume" functionality).

Next Steps:

• Prioritize backend tasks to meet performance thresholds.
• Start scoping "save and resume" feature (critical for user experience).
• Review client’s backlog to align sprint goals with their long-term requests.

See simplified product velocity chart below:

Week 5 (Software Test)

Software testing for DeeDyL group

Link to software testing of DeeDyL: Software Testing 1 - March 6

Software Testing was done earlier today March 6, 2025. 

SE Admin Software demonstrator: John Domingo 
Evaluated by: ROTC group

Link to software testing of ROTC group:  Software testing on SE Admin group

Software evaluator: Raniel Castro
Software evaluated: DeeDyL 

 Week 5 Update

Progress this week has been slow due to exams and other steep increase in academic workloads. The client has finished the evaluation form and is attached below. The client has also mentioned that their team is currently on the move to also get their instance of the web application up and running and has asked to group to assist them accomplish the task when the time arrives. For the most part, the past week has mostly been more testing, bug discoveries, bug resolutions, and minor fixes.

Evaluation form signed by client