CHAPTER 4

Chapter 4

Methodology, Results, and Discussions

This chapter presents the testing and implementation results of CCARP, an innovative web and mobile application designed to connect homeowners with carpentry services. Its main objective is to walk through the step-by-step process of the capstone project, addressing identified gaps and validating the system's functionality. It outlines key development phases, beginning with requirements analysis, which uses data flow diagrams to illustrate how information moves within the system.

The chapter also discusses crucial elements such as system functionality, data management, user interface design, and technical requirements—all geared toward ensuring strong performance and fulfilling the platform's purpose. Security and legal compliance are carefully considered, with a checklist followed to ensure user data protection and adherence to relevant regulations.

Additionally, the user requirements section highlights the specific needs of both carpenters and homeowners, ensuring that CCARP offers a practical, efficient, and user-friendly experience.

The development process follows a well-structured methodology within a defined environment, enabling a systematic approach to building and refining the system. Continuous testing ensures the system’s reliability, while project scheduling, resource allocation, and risk management strategies help keep development on track and address potential challenges effectively and on time.

Requirements Analysis

Figure 4.1 Level 4 Data Flow Diagram (Explosion)

The Level 1 Data Flow Diagram (DFD) for inputting project details illustrates Process 4.1, which covers how construction-related information is entered into the system. This includes input fields for the lot area (with length, width, and total square meters), floor area (measured similarly), initial budget, and project timeline (start and end dates). Users can also select the type of house to be built from a predefined list—or manually enter the type if it’s not listed. Additional inputs include a carpenter limit, specifying how many carpenters can work on the project, an optional photo upload for reference, and a "More Details" text field for any extra project information. Once submitted, this data is forwarded to the carpenter dashboard, where the carpenter can view the plan (Process 4.2).

In Process 4.3, the carpenter evaluates the construction plan by rating its feasibility based on the following criteria:

Project scope and feasibility

Site and environmental considerations

Client readiness and commitment

Availability of workforce and resources

The evaluation score determines the outcome:

Score below 20: The plan is unacceptable and will trigger a recommendation for revision or rejection.

Score of 20: The plan is conditionally acceptable but requires significant revisions.

Score between 40 and 70: The plan is highly acceptable and can proceed.

The rating scale is as follows:

5 – Excellent (Meets all requirements)

4 – Good (Minor issues, manageable)

3 – Fair (Requires adjustments)

2 – Poor (Major concerns, needs discussion)

1 – Unacceptable (Not feasible)

After the evaluation, the results are saved to the Approved Plan Data Store. Process 4.4 handles the display of evaluation results, showing the scores and corresponding recommendations for each plan submitted by the client. This concludes the Level 1 DFD for this set of processes.

Figure 4.2 Level 1 Data Flow Diagram (Explosion)

The Level 1 Data Flow Diagram (DFD) for Evaluating Contracts outlines how contracts are processed within the system. It begins with Process 6.1, labeled "Entering Contract Details." In this step, the user inputs key contract information, including the type of job—either per day or on the job (pakyawan)—along with the duration in days. The duration is calculated automatically based on the start and end dates previously selected during Process 1: Creating Construction Plan.

Next, the user enters the price per day in Philippine currency, and the system automatically computes the labor cost by multiplying the daily rate by the number of days. Once submitted, most of the contract details will be shown in read-only mode (not editable), except for the type of work and per day rate, which can still be modified before submission.

After submission, the process moves to Process 6.2, which displays the contract details on the client's user interface. At this stage, the contract is marked as "pending" while awaiting the carpenter's approval.

Next, in Process 6.3, titled "Evaluating Contract," the client reviews the contract and selects one of two options: Accept or Reject.

If accepted, the contract is stored in the Approved Contracts table.

If rejected, the client is required to provide a rejection reason in a textbox that appears automatically.

Finally, Process 6.4, or "Displaying Contract Evaluation Result," shows the outcome of the evaluation in the carpenter’s user interface, reflecting whether the contract was accepted or rejected and including any comments if applicable.

This concludes the Level 1 DFD breakdown for the contract evaluation process.

Figure 4.3 Level 9 Data Flow Diagram (Explosion)

The Level 1 Data Flow Diagram (DFD) for Evaluating Project Turnover begins with Process 9.1, where the carpenter inputs key turnover details. These include the start date, end date, and the actual completion date—the day the project was finalized and submitted for turnover. The system also displays the completed tasks, pending tasks, total estimated days, and actual days spent. To confirm the turnover, the carpenter must check a box indicating that the project has been completed and delivered as agreed. A text field is provided where the carpenter must type their full name as a digital signature. Additionally, the carpenter may upload supporting documents, limited to photos and PDFs, and include turnover notes—a final comment or summary about the project.

Once submitted, the turnover data is sent to the system and handled by Process 9.2, which displays the project turnover details on the client’s interface. After reviewing, Process 9.3 takes place, where the client rates the project turnover. This step uses the same project data provided in Process 9.1. The client is then presented with two options: "Approve Project" or "Request Revision." In either case, the client must provide comments or feedback for the carpenter.

If the project is approved, the data is stored in the Approved Turnover Projects table. Finally, Process 9.4, labeled "Displaying Result of Evaluation," presents the outcome of the client’s evaluation, including the feedback and decision made in Process 9.3.

This concludes the Level 1 DFD for Process 9: Evaluating Project Turnover.

Functional Requirements

Functionality

The system should offer key features that promote convenient and effective access to carpentry services for users. It must ensure the delivery of high-quality workmanship, support the efficient management of project plans, and establish a standardized process to maintain consistent work quality.

Example:

F1: The system allows users to create an account and log in using their email and password.

F2: The system allows clients to post their construction plans, opening job opportunities for carpenters.

F3: The system allows carpenters to approve posted plans to confirm project availability and understand the scope and limitations of the job.

F4: The system allows carpenters to generate contracts, helping avoid misunderstandings, prevent contract breaches, and ensure the safety of both parties.

F5: The system allows clients to evaluate the contract to determine if it aligns with their expectations and the carpenter’s qualifications.

F6: The system allows carpenters to post project updates, including progress, tasks, completed tasks, and attendance, for better project tracking.

F7: The system allows clients to view project updates, such as progress, tasks, completed tasks, and carpenter attendance, to monitor the project's development.

F8: The system allows clients to pay carpenters through various available modes of payment.

F9: The system allows carpenters to turn over completed projects, notifying the client that the project is ready for review.

F10: The system allows clients to review and evaluate the turned-over project, enabling them to request revisions if necessary.

Data

To ensure high-quality carpentry services, efficient project planning, and a standardized process for work quality, CCARP will securely store and manage essential data. This includes user profiles, project details, contract information, progress reports, and payment records. The system is designed to uphold data privacy, protect users from potential data breaches, and maintain secure and reliable transactions.

Below are the key data elements that CCARP will manage:

User Data

Contents: Full name, email, mobile number, address, date of birth, profile picture, username, and password.

Format: VARCHAR for text fields; DATETIME for date of birth; file paths for profile pictures.

Storage: Stored in the users table. Passwords are hashed using bcrypt.

Validation: Inputs are validated for format (e.g., proper phone number patterns) and uniqueness (e.g., no duplicate emails).

Privacy: Passwords and sensitive data are encrypted. Access is restricted by user roles using PHP's isset() method.D3: Order data (order ID, customer ID, order date, shipping address, billing address, order items, payment details) shall be recorded and stored in the database.

Plan Data

Contents: Plan ID, lot area, floor area, initial budget, house type, number of workers, photo reference, and additional details.

Format: VARCHAR for descriptions; DECIMAL for budget; DATE/TIME for start and end dates.

Storage: Stored in the plan table, linked to user_ID to identify the plan owner.

Validation: Start date cannot be the current date; end date must not be earlier than the start date.

Privacy: Plans are only accessible to the user who posted them, secured using isset() and the logged-in user_ID.

Contract Data

Contents: Contract ID, duration, type of work (per day or pakyawan), rate per day, and total labor cost.

Format: Dropdown for work type; DECIMAL for rate and cost.

Storage: Stored in the contract table and linked to user_ID, carpenter_ID, and plan_ID.

Validation: Only one contract is allowed per carpenter and plan to prevent duplication.

Privacy: Contracts are accessible only to the involved carpenter, secured using isset() based on carpenter_ID.

Report Data

Contents: Progress ID, task ID, completed task ID, attendance ID, time-in, and time-out.

Format: Dropdowns for status (e.g., Not Yet Started, Working, Done); VARCHAR for task and report descriptions; DATETIME for attendance logs.

Storage: Stored in the reports table, linked to contract_ID, task_ID, and completed_task_ID.

Validation: Tasks can only move to the completed list if marked "Done."

Privacy: Only carpenters can edit reports. Clients can view but cannot modify data. Access is controlled using isset() for both roles.

Payment Data

Contents: Payment ID, contract ID, user ID, carpenter ID, labor cost, duration, work type, payment method, and payment date.

Format: Dropdown for payment method (Cash on Hand, GCash, Credit Card); other fields are fixed and derived from the contract.

Storage: Stored in the payment table and linked to contract_ID, user_ID, and carpenter_ID.

Validation: Users must select a payment method to proceed.

Privacy: Payments are visible to both parties. Clients can access full details, while carpenters can view the payment method used. Access is protected using isset() in PHP.

Project Turnover Data

Contents: Actual completion date, client signature, turnover notes, supporting documents, confirmation status, client feedback, approved by, and turned over by.

Format: Checkbox for confirmation; VARCHAR for full name (as signature); file paths for documents (accepts only images and PDFs); dropdown for approval status; DATETIME for timestamps.

Storage: Stored in the project_turnover table. Linked via foreign keys to contract_ID, plan_ID, task_ID, completed_task_ID, user_ID (approved by), and carpenter_ID (turned over by).

Validation: All fields are required to ensure complete data integrity.

Privacy: Accessible to both clients and carpenters, but protected using PHP isset() to enforce role-based access.

User Interface

Figure 4.4 User Login Interface

UI1: The website shall feature a user-friendly and intuitive login interface with clear navigation and easy-to-use input fields, ensuring a seamless login experience for all users.

Figure 4.5 Creating Construction Plan Interface

UI2: The Create Construction Plan page shall allow users to input essential details including Lot Area, Floor Area, Initial Budget, Start Date, End Date, Type of House (via dropdown menu), Carpenter Limit, Reference Photo Upload, and a text area for additional specific project details.

Figure 4.6 Generating Contract Interface

UI3: The Contract Generator page shall clearly display all necessary contract information including the contractor and client names, project details, photo reference, responsibilities, daily rate calculated by duration, and a text field for the client’s digital signature.

Figure 4.7 Completing Project Interface

UI4: The View Progress page shall present the client's plan details along with the materials to be used and a real-time progress report for easy tracking of project development.

Figure 4.8 Paying Carpenter

UI5: The Pay Carpenter feature shall display the carpenter’s name, project duration, total labor cost, type of work (e.g., per day or pakyawan), selected payment method, payment date, and the sender's name to ensure transparent payment processing.

Figure 4.9 Compatible Devices for CCARP

The website shall be fully responsive and accessible across various devices, including desktops, laptops, tablets, and smartphones, ensuring a consistent user experience on all platforms.

Non-Functional Requirements

Technical Requirements

T1: Response Time

The system shall ensure a response time of 3 seconds or less for all operations, including login, logout, and particularly when inserting data into the designated databases.

T2: Peak Load Capacity

The system shall handle a peak load of at least 50,000 users concurrently without any performance degradation, lagging, or issues.

T3: Browser Compatibility

The system shall be fully compatible with major web browsers, including Google Chrome, Mozilla Firefox, Safari, and Microsoft Edge.

T4: Platform Compatibility:

The system shall be fully operational on both desktop and laptop devices, as well as mobile web browsers. Future updates may include dedicated iOS and Android app versions.

T5: Scalability

The platform shall be hosted on a scalable cloud infrastructure (e.g., AWS, Azure, or GCP), allowing seamless expansion to support increasing plan creations, transactions, and service providers.

T6: Data Throughput

The system shall be capable of processing a minimum of 30 transactions per second, ensuring smooth and uninterrupted payment processing and servicing.

T7: Integration with Third-Party APIs

The system shall integrate with payment gateways (e.g., Gcash, Maya, PayPal) for secure financial transactions, the Google Maps API for accurate location services, and SMS/Email notification APIs for sending contract confirmations and updates.

T8: Data Backup and Recovery

The system shall implement automatic daily backups for critical data (such as user profiles, services, and transactions) to ensure quick data recovery in case of system failure.

T9: Security Measures

The system shall use HTTPS encryption, implement secure password hashing with bcrypt, and enforce role-based access control (RBAC) to protect sensitive user data from unauthorized access.

T10: Resource Optimization

The platform shall be optimized to minimize CPU and memory usage, ensuring smooth operation even for users accessing the system via mobile devices.

T11: Localization

The system shall support local time zones and currency formats based on the user’s location. Consideration for multilingual support may be included in future updates.

Security Requirements

S1: Data Encryption

All sensitive user data, including personal details, reports, progress, and payment information, shall be encrypted both in transit (using TLS 1.3) and at rest (using AES-256) to prevent unauthorized access during transmission and while stored in the database.

S2: Strong Password

Users shall be required to create strong passwords that include a mix of uppercase and lowercase letters, numbers, and special characters. Passwords shall be securely hashed using bcrypt with a high work factor to provide robust security.

S3: Role-Based Access Control

The system shall implement role-based access control (RBAC) to ensure that users (clients, carpenters, and administrators) only have access to the functionalities and data relevant to their specific roles, minimizing the exposure of sensitive information.

S4: Intrusion Detection and Prevention

An intrusion detection and prevention system (IDPS) shall be deployed to monitor system activity for any signs of unauthorized access attempts, including brute-force attacks or malware, and take appropriate actions to mitigate such threats.

S5: Regular Security Audits and Penetration Testing

Periodic security audits and penetration testing shall be conducted at least quarterly to identify vulnerabilities, ensure the integrity of security measures, and apply necessary patches or updates to address potential risks.

S6: Secure Session Management

The system shall implement secure session management practices, including the use of encrypted cookies, automatic session timeouts, and measures to prevent session hijacking, ensuring that unauthorized users cannot access active sessions.

S7: Access Logging and Anomaly Detection

All user activities, such as login attempts, payment transactions, and service bookings, shall be logged for security auditing. Any anomalous behaviors or suspicious activities shall trigger real-time alerts for further investigation and mitigation.

S8: Protection Against Common Cyber Threats

The system shall have measures in place to defend against common web-based security threats, including SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and brute-force attacks, ensuring a secure environment for users and administrators.

S9: Secure Payment Transactions

All financial transactions shall be processed through trusted and secure payment gateways (e.g., GCash, Maya, PayPal) with end-to-end encryption to ensure transaction security and prevent fraud or unauthorized access.

S10: Data Backup and Disaster Recovery Plan

The system shall perform automatic encrypted backups on a regular basis to safeguard against data loss. A disaster recovery plan shall be in place to ensure service continuity in the event of system failures, cyber-attacks, or any other unforeseen incidents.

Legal Requirements

To ensure CCARP operates in full compliance with applicable legal and regulatory frameworks, the platform shall adhere to data privacy laws, consumer protection policies, and financial regulations. These measures are designed to:

L1: Compliance with Data Privacy Laws

CCARP shall comply with all relevant data privacy regulations, including the Data Privacy Act of 2012 (Philippines) and international standards such as GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act), ensuring the protection of user data through proper handling, storage, and consent management.

L2: Consumer Protection Compliance

The platform shall adhere to consumer protection laws, such as the Philippine Consumer Act (RA 7394), ensuring transparent pricing, clear service agreements, and fair treatment for users, as well as compliance with similar regulations in other jurisdictions where applicable.

L3: Intellectual Property Compliance

All content within CCARP, including branding, images, and software, shall adhere to copyright and trademark laws. Unauthorized use of third-party intellectual property shall be strictly prohibited to avoid legal infringements.

L4: Compliance with E-Commerce and Digital Service Regulations

As an online service provider, CCARP shall comply with relevant e-commerce and digital service regulations applicable to the countries in which it operates, ensuring secure transactions, accurate invoicing, and adherence to online business operation guidelines.

L5: Tax Compliance

CCARP shall ensure compliance with all applicable tax regulations, including VAT (Value Added Tax) where necessary, and maintain accurate documentation and reporting of revenue in accordance with local and international tax laws.

L6: Secure Payment and Financial Compliance

All financial transactions processed through CCARP shall adhere to anti-fraud regulations and financial security standards, including Anti-Money Laundering (AML) laws. The platform shall ensure the safe and legal processing of payments through verified and trusted payment gateways, such as GCash, Maya, and PayPal.

L7: Liability and Service Agreements

Users (including both clients and service providers) shall be required to agree to CCARP’s terms and conditions, which outline liability, dispute resolution procedures, and service warranties. These agreements will ensure clear expectations and legal protections for all parties involved.

User Requirements

To ensure that CCARP meets the needs and expectations of its users, it is crucial to prioritize usability, accessibility, and convenience for both homeowners and carpenters. Throughout the development process, gathering valuable feedback from users is essential to address their concerns and incorporate their suggestions, thereby continuously improving the system.

U1: Ease of Use

CCARP shall offer a user-friendly and intuitive interface, ensuring homeowners and carpenters can easily navigate the platform, post plans, and manage construction projects with minimal effort.

U2: Accessibility

The platform shall be fully accessible to all users, including those using mobile and desktop devices, and will comply with web accessibility standards to accommodate users with disabilities.

U3: Detailed Project Planning

Homeowners on CCARP shall be able to post detailed construction plans, including lot area, floor area, initial budget, house type, number of workers, reference photos, and additional project details to provide a comprehensive view of their project.

U4: Ratings and Feedback

CCARP shall feature a rating system to allow both homeowners and carpenters to rate each other, fostering a positive environment, building trust, and ensuring the continued delivery of high-quality services by both parties.

U5: Evaluation

Users shall have the right to evaluate various aspects of the system, including the plans they post, the contracts they sign, and the final results of the project, to ensure quality, integrity, and improvement within the platform.

Development and Testing

Development Methodology

Figure 4.10 Agile (Scrum) Methodology

The development of CCARP followed the Agile (Scrum) methodology, which provided flexibility, iterative development, and continuous user feedback. Agile was chosen due to the evolving nature of the project and the need to incorporate user-driven improvements throughout the development process. This approach enabled CCARP to adapt efficiently to user needs, ensuring that the platform could continuously improve while maintaining high performance and system reliability.

1. Requirements Gathering: Requirements were gathered iteratively, with a focus on key processes such as user registration, plan creation, contract generation, report management, attendance tracking, and payment integration. Regular feedback from homeowners and carpenters helped refine and enhance the platform's features.

2. Design: The system was designed with a modular and scalable architecture to ensure that CCARP could support future expansions. User interface designs were improved during each sprint to enhance usability, accessibility, and responsiveness across different devices.

3. Implementation: Development was conducted incrementally, with each sprint delivering a functional feature. Key modules, such as construction plan creation, contract management, evaluation, and progress reporting, were implemented iteratively. This allowed for continuous improvements throughout the development cycle.

4. Testing: Testing was conducted during every sprint to ensure each feature functioned as intended. The testing procedures included:

• Unit Testing: To validate individual components, such as plan creation and progress report generation.

• Integration Testing: To ensure seamless interaction between modules (e.g., plan creation, contract evaluation, and reporting).

• System Testing: To assess the overall functionality, performance, and security of CCARP.

• User Feedback Testing: Conducted during each sprint to identify usability issues and make improvements based on real-world usage.

1. Deployment: Deployment was carried out in stages after the successful completion of each sprint. Early releases allowed real users to test the platform, provide feedback, and ensure a smooth transition to the fully functional system.

2. Maintenance: CCARP underwent continuous maintenance and updates during and after development. Security enhancements, bug fixes, and feature updates were incorporated based on user feedback. Regular system monitoring ensured optimal performance and data security.

Development Environment

The development of CCARP utilized a variety of tools and technologies, ensuring a streamlined and efficient process.

1. Programming Languages

• HTML, CSS, React JS: Used for front-end development, responsible for the design, user interface (UI), and user experience (UX) of the system.

• PHP: Employed for server-side scripting and backend development. PHP is also used to fetch and manage data from the database.

• JavaScript: Utilized for creating interactive and dynamic UI functionalities, such as Sweet Alerts and alert messages

1. Development Tools:

• VS Code: Used for development and writing code manually.

• Trae: Assisted in development and writing code with the help of AI, enabling efficient code arrangement and bug detection. Trae also helps address errors that could hinder the development timeline.

• ChatGPT: Employed for ideation and guidance on implementing features and system functionality. It also helps with integrating features into the platform.

• XAMPP: Used for the local development environment, incorporating Apache for the web server, MySQL for database management, and PHP for backend and server-side processing.

• phpMyAdmin: Utilized for creating, updating, and deleting data within the database.

• GitHub: Used to store development progress and monitor the project's status. GitHub also enables version control and allows me to access and continue development across different devices.

1. Databases:

• MySQL: A robust and reliable relational database system used to manage and store platform data, including user profiles, plan data, contract information, report data, and transaction records.

1. Cloud Deployment:

• InfinityFree: A free cloud hosting platform used to deploy CCARP, making the platform accessible online for testing and demonstration purposes.

1. Operating Systems:

• Windows: The development and deployment processes were conducted on a Windows-based system, providing compatibility with the selected tools and technologies.

Testing Procedures

To ensure the quality and reliability of CCARP, the following testing activities were conducted:

1. Unit Testing: Individual components such as user registration, construction plan creation, and progress report generation were tested in isolation to validate their functionality.

2. Integration Testing: The interaction between different modules was tested, including linking the construction plan creation with plan evaluation and the contract module. Additionally, integration with the progress report was tested to ensure smooth data flow across the platform.

3. System Testing: The entire platform was tested to ensure all functionalities, from creating and evaluating construction plans to generating contracts and processing payments, worked seamlessly. This included end-to-end testing to validate the system's overall performance and stability.

4. User Acceptance Testing (UAT): Test users provided feedback to validate the usability, efficiency, and overall performance of the system. UAT focused on ensuring that the platform met the needs and expectations of end users.

5. Test Data: A combination of sample data and real-world scenarios was used to simulate various booking and transaction scenarios, ensuring that the platform could handle real-life usage.

6. Test Metrics: Key metrics such as defect density (number of defects per unit of code) and test pass rate (percentage of tests that passed) were tracked to measure system stability, performance, and reliability.

Implementation Plan

Project Schedule

The following structured timeline was followed using a Gantt chart to efficiently track milestones:

Week 1: Requirements gathering and creating system diagrams.

Week 2: UI/UX design development and prototyping.

Week 3: Development of user authentication and profile setup module.

Week 4: Development of construction plan creation, progress tracking, and payment process modules.

Week 5: Minor revisions based on user feedback and changes requested.

Week 6: Creation of an evaluation tool to assess how the objectives of the study are met through CCARP.

Week 7: Deployment of the system and User Acceptance Testing (UAT).

Week 8: Data gathering for final analysis and reporting.

Week 9: Manuscript preparation and format adjustments for final submission.

Allocate resources: Assign tasks to team members (if applicable).

• Estimate time and effort: Determine the estimated time and effort required for each task.

• Track progress: Regularly monitor progress against the schedule and make adjustments as needed.

Resource Allocation

1. Human Resources:

• Project Manager: Oversees the project's progress, manages timelines, and ensures quality.

• Developer: Responsible for backend and frontend development, integration, and coding.

• Tester: Ensures the system meets the required standards and performs functionality, integration, and user acceptance tests.

• UI/UX Designer: Designs the user interface and experience, ensuring the system is intuitive and user-friendly.

1. Hardware Resources:

• Laptop with Intel i3 processor or higher (or equivalent) for development and testing.

• Local server setup using XAMPP for development and database management.

• Stable Internet Connection for online deployment, remote collaboration, and testing.

1. Software Resources:

• VSCode: Integrated development environment (IDE) for writing code.

• Trae: AI-based development tool for assistance in coding and debugging.

• Filezilla: For uploading files to the online server during deployment.

• XAMPP: Used for local server development and testing environment.

• Compatible Browsers: For cross-platform testing (Google Chrome, Mozilla Firefox, Safari, Microsoft Edge).

1. Financial Resources

• Cloud Hosting (InfinityFree): Free hosting service for deploying CCARP online.

• Contingency Fund: Estimated at PHP 2,000 for any unforeseen expenses, additional software, or cloud services required during the project.

Risk Management

1. Risk Identification

Information Asset	Threats	Vulnerabilities	Impact	Risk Level
Customer Data	Data Theft	If access controls are weak, unauthorized people or attackers might get into customer databases.	Identity theft, financial loss for customers, and damage to the business reputation	High
Payment Information	Payment System Breach	If customer data isn't encrypted when stored, there's a higher chance that someone could intercept and access the data without permission.	Financial losses, regulatory fines, and reputational damage.	High
Operational Data	Equipment Tampering	If payment processing systems are vulnerable, they can be used by unauthorized individuals for accessing or making fraudulent transactions.	Equipment malfunctions, potential safety hazards, and operational disruptions.	Low

1. Risk Mitigation:

- Technical Risks:

Solution: Conduct thorough testing (unit, integration, system, and user acceptance testing) to identify and resolve bugs early in the development cycle.

Implement encryption (TLS 1.3 for transit and AES-256 for storage) and adhere to security best practices (e.g., secure password hashing, role-based access control) to protect data and prevent breaches.

• Financial Risks:

Solution: Allocate contingency funds (PHP 2,000) to cover unexpected expenses such as additional tools, hosting fees, or unanticipated costs during deployment or after launch.

• Operational Risks:

Solution: Establish service level agreements (SLAs) with providers to define acceptable response times for technical support, hosting services, or any third-party APIs, ensuring swift resolution of operational issues.

• Compliance Risks:

Solution: Regularly perform audits to ensure ongoing adherence to relevant regulatory frameworks (such as Data Privacy Act, GDPR, etc.). Implement a monitoring system to track compliance and quickly address any issues that arise.

1. Risk Monitoring:

• Regular Risk Reviews:

Solution: Hold bi-weekly meetings to assess the current risks, discuss new potential risks, and evaluate the effectiveness of mitigation strategies. This ensures that the project is staying on track and that any emerging risks are promptly addressed.

• User Feedback:

Solution: Continuously collect user feedback (from homeowners, carpenters, and other stakeholders) through surveys, direct communication, and usage analytics. This allows the team to identify potential issues early, address concerns, and incorporate improvements based on real-world usage.

• Performance Monitoring:

Solution: Implement automated tracking for system performance, including response times, transaction throughput, and error rates. Monitoring tools (e.g., New Relic, Google Analytics, etc.) will allow the team to quickly identify performance bottlenecks or any issues impacting the user experience.

Communication Plan

Communication Channels

Meetings:

• Virtual and In-Person: Regular meetings are conducted both virtually and in-person to facilitate team discussions, resolve issues, and ensure alignment on project goals and deliverables.

Email

• Formal Communication: Email is used for official updates, submission of reports, and sharing formal documentation to ensure traceability and accountability.

Project Management Software

• Trello/Asana: These platforms are utilized to monitor project progress, assign tasks, track deadlines, and manage team workflows efficiently.

Instant Messaging

• Quick Communication: Platforms like Gmail Chat and Facebook Messenger are used for quick clarifications, informal coordination, and immediate updates.

Documentation Repositories

• Google Drive and GitHub: Google Drive is used to store non-code documentation, including meeting notes and design files. GitHub serves as a version-controlled repository for source code and development collaboration.

Communication Protocols

• Clear Guidelines: Defined protocols are established to standardize communication frequency, response times, escalation paths, and documentation standards, ensuring timely and effective collaboration among team members.

Capstone Project Deployment Results

The deployment of the CCARP system was carried out from April 3, 2025 to May 3, 2025, involving three homeowners and three carpenters from various areas in Toril, Davao City. During this period, we closely monitored user interaction with the platform—particularly how progress reports were created, submitted, and evaluated in real-world conditions.

Despite encountering several challenges that initially made the deployment seem difficult, the process was ultimately successful. Observing the system in use outside of a controlled testing environment provided valuable insights into both the strengths of the platform and the areas needing improvement. This real-world deployment served as a crucial learning experience, significantly contributing to the refinement and future enhancement of CCARP.

General Objective: Increase the accessibility of carpentry jobs in local markets by at least 30%

	DIS	INN	INS	INT B	OPT
Discomfort	0.708	-0.312	0.406	-0.498	-0.166
Discomfort2	0.794	-0.484	0.601	-0.619	-0.371
Discomfort3	0.742	-0.307	0.528	-0.57	-0.349
Discomfort4	709	-0.45	0.473	-0.528	-0.31
Discomfort5	0.838	-0.374	0.654	-0.652	-0.325
Innovativeness	-0.327	0.805	-0.364	0.461	0.37
Innovativeness2	-0.44	0.791	-0.433	0.494	0.375
Innovativeness3	-0.488	0.836	-0.462	0.571	0.492
Innovativeness5	-0.369	0.8	-0.355	0.452	0.456
Insecurity	0.494	-0.454	0.712	-0.59	-0.294
Insecurity2	0.588	-0.378	0.745	-0.596	-0.353
Insecurity3	0.569	-0.386	0.78	-0.62	-0.372
Insecurity4	0.536	-0.438	0.785	-0.611	-0.406
Insecurity5	0.525	-0.321	0.813	-0.596	-0.256
Insecurity6	0.586	-0.368	0.814	-0.645	-0.369
Intention to use 1	-0.604	0.516	-0.605	0.866	0.463
Intention to use 2	-0.702	0.545	-0.745	0.913	0.476
Intention to use 3	-0.721	0.59	-0.748	0.905	0.481
Optimism	-0.337	0.415	-0.401	0.478	0.797
Optimism2	-0.327	0.409	-0.311	0.411	0.817
Optimism3	-0.329	0.397	-0.342	0.397	0.752
Optimism4	-0.255	0.348	-0.261	0.325	0.768
Optimism5	-0.347	0.501	-0.408	0.461	0.835

Table 4.1 Table Statistics

Figure 4.11 Admin dashboard Viewstatistic page

A related study by Jayabalan, N., Mohd Makhbul, Z., and Lim Dao Siang, J. M. (2019) utilized a similar methodology by conducting a survey to assess the accessibility of carpentry jobs in the local market and to analyze the perceptions and adoption of e-recruitment technologies. Their study applied Partial Least Squares Structural Equation Modeling (PLS-SEM), as referenced in Table 4.1 of their work.

In the current study, Figure 4.11 presents the criteria adapted from Jayabalan et al.’s framework: Discomfort (DIS), Innovativeness (INN), Insecurity (INS), Optimism (OPT), and Intention to Use (INTB). One participant, Carpenter Angelito Engcoy, completed the survey and achieved an accessibility score of 73.3%, meeting the project’s target. His overall rating averaged 4 out of 5.

The system successfully met its objective of increasing accessibility to carpentry jobs in the local market by 30%, based on survey responses. This outcome highlights the users' perceptions and experiences when interacting with the platform. These findings are in alignment with the study of Jayabalan et al. (2019), which also used the dimensions DIS, INN, INS, OPT, and INTB to evaluate technology adoption and accessibility in a similar context.

Specific Objective 1: Enhance the efficiency of project plans by at least 20%

Tasks	Start time	End time	Start time	End time
Masonry of shafts	March 20 7:00	March 20 11:00	March 20 12:42	March 20 15:12
Preparation of concrete floor pours and pouring	March 21 7:00	March 21 11:00	March 21 7:31	March 21 11:04
Waterproofing	March 22 7:00	March 22 11:00	March 22 8:01	March 22 12:05
Tiling	March 23 7:00	March 23 11:00	March 8:07	March 15:55
Joints	March 27 7:00	March 27 11:00	March 26 9:31	March 27 14:38
Suspended ceiling	April 03 7:00	April 03 11:00	April 03 7:32	April 03 12:13
Caulking of suspended ceiling	April 04 7:00	April 04 11:00	April 04 7:24	April 04 10:09
Painting of suspended ceiling	April 05 7:00	April 05 11:00	April 05 7:29	April 05 9:56
Shaft drywall	March 21 7:00	March 21 11:00	March 21 7:31	March 21 13:11
Kitchen furnishing	March 22 13:30	March 23 8:00	March 22 9:50	March 23 13:06

Task	Difference in start time	Difference in end time
	<2h	2-4 h	>4 h	<2h	2-4 h	>4h
Masonry of shafts	1	1		1	1
Preparation of concrete floor pours and pouring	4	1		4	1
Waterproofing	3	2	1	3	3
Tiling	3	1	1	2	2	1
Joints		2	2	2	1	1
Suspended ceiling	4	1	1	1	1	4
Caulking of suspended ceiling	1	2	1		1	3
Painting of suspended ceiling	1		2			3
Furnishing	2		1			3
Finishing	1	1				2
Kitchen furnishing	3	1	1	2	2	1
Total	23	12	10	15	12	18

Table 4.2 Time differences in starting time and end time in task

Figure 4.12 Progress and Attendance

A related study by Zhou, Y. and Luo, H. (2021) focused on the real-time tracking of task progress on construction sites. As presented in Table 4.2, the study recorded both the start and end times of tasks, and calculated the time difference to assess task duration. These durations were then compared across different tables to analyze time efficiency.

In Table 4.12, a comparison is made between the traditional system and CCARP. For example, under the traditional method, the masonry of shafts task began on March 20 at 7:00 AM and ended at 11:00 AM, taking 4 hours to complete. In contrast, a similar task labeled “mag pintura” within CCARP started at 7:30 AM and finished at 9:30 AM, lasting only 2 hours.

This comparison demonstrates that CCARP successfully enhanced the efficiency rate of project plans by at least 20%. The results also include an efficiency analysis showing the percentage of time saved. The status indicator confirms that the target was achieved, validating CCARP’s effectiveness in improving task time management and overall workflow efficiency.

Specific Objective 2: Strengthen the implementation of standardized procedures for monitoring work quality at least 25%

S/N Performance Objectives	Alpha	Remarks
1. Construction of door and window frames	0.87	Good
2. Frame construction of wall paneling, wall cladding, and partitioning	0.86	Good
3. Construction of pre-fabricated structure (wooden stair, handrails, and balusters)	0.88	Good
4. Construction of wooden scaffold	0.87	Good
5. Construction of wooden ladder	0.87	Good
6. Construction of roof, ceiling frames, and covering	0.88	Good
7. Construction of pre-cast lintel formwork	0.87	Good
8. Construction of the flat segmental arch	0.87	Good
9. Construction and finishing of a table, chair, and stool	0.86	Good
	0.87	Good

Table 4.3 Evaluation Ratings

Figure 4.13 Evaluation Rating Details

A related study by Connecteam (2024, April 16) and Eze, T. I., & Okorie, U. (2022) provided a Construction Quality Control Checklist consisting of 10 criteria. The primary objective of this checklist was to assess the impact of transitioning from paper-based to digital quality control systems on workflow efficiency, accountability, and data utilization in construction projects. As shown in Table 4.13, the study also evaluated the quality measurement process using the Cronbach’s Alpha method, aiming to identify key performance objectives and competencies in carpentry and joinery practical skills. Furthermore, it involved the development of an assessment tool—the Instrument for Assessing Carpentry and Joinery Students’ Practical Skills (IACJSPS)—which was statistically validated for reliability and suitability in educational settings, including capstone projects.

In the case of CCARP, a participating homeowner completed the quality survey and scored 44 out of 50, indicating a positive evaluation. Using the Cronbach’s Alpha method, the instrument recorded a reliability coefficient of 0.85, which is considered highly acceptable, thereby confirming the consistency and dependability of the tool in assessing project outcomes.

This evidence supports that CCARP successfully achieved its goal of strengthening standardized procedures for monitoring construction work quality by at least 25%, aligning with the findings of Eze and Okorie (2022). The results demonstrate a significant improvement in the quality of work facilitated by the system’s digital approach.