25 KiB
SOFTWARE DEVELOPMENT AND IMPLEMENTATION AGREEMENT
Parties: (Term: 3-5 Years, To be finalized based on Support/Maintenance period post-delivery)
This Software Development and Implementation Agreement (the "Agreement") is entered into effective as of [Date - e.g., August 5, 2024] (the "Effective Date"), by and between:
Cell Tech, a Partnership organized and existing under the laws of the Republic of the Philippines, with its principal place of business at Funda Dalipe, San Jose, Antique (hereinafter referred to as "Developer").
AND
Western Institute of Technology, a Partnership organized and existing under the laws of the Republic of the Philippines, with its principal place of business at Lapaz, Iloilo City (hereinafter referred to as "Client").
(Developer and Client may be referred to individually as a "Party" and collectively as the "Parties").
Recitals:
A. Client requires the design, development, implementation, testing, and delivery of a custom Learner Management System (hereinafter referred to as the "System" or "LMS") as further specified herein, to meet its operational and educational requirements.
B. Developer represents that it possesses the necessary expertise, personnel, skills, and resources to develop and deliver the System in accordance with the specifications, timelines, and conditions outlined in this Agreement.
C. Client desires to engage Developer to perform such software development and implementation services ("Services"), and Developer desires to provide such Services to Client, subject to the terms and conditions set forth in this Agreement.
Agreement:
NOW, THEREFORE, in consideration of the mutual covenants, promises, and agreements contained herein, and other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, the Parties hereto agree as follows:
ARTICLE 1: DEFINITIONS
(Optional: Add definitions for key terms used throughout the agreement if needed for clarity, e.g., "Acceptance Criteria," "Deliverables," "Sprint," "Intellectual Property," etc.)
ARTICLE 2: SCOPE OF SERVICES
2.1 General Scope: Developer shall perform the Services necessary to design, develop, test, and implement the System as described in this Agreement and its Exhibits. The System is intended to function as a Learner Management System providing functionalities for learners, instructors, and administrators.
2.2 Development Methodology: Developer shall utilize an Agile (Iterative and Incremental) Software Development Life Cycle (SDLC) methodology for the performance of the Services.
a. Process: The project will be broken down into smaller, manageable cycles ("Sprints," typically 2-4 weeks). Each Sprint will generally include planning, design, development, testing, and stakeholder review, aiming to produce a potentially shippable increment of the System.
b. Rationale: This methodology is selected to provide adaptability to evolving requirements, facilitate early and frequent feedback from Client, foster collaboration and transparency, manage risks effectively, and maintain focus on user needs.
c. Project Management: Developer shall employ project management practices consistent with the Agile methodology, including but not limited to backlog grooming, sprint planning, daily stand-ups (as appropriate), sprint reviews, and retrospectives. Regular communication and progress reporting shall be provided to Client. (). Project tracking will utilize [].
2.3 Key System Features and Characteristics: The System developed under this Agreement shall aim to possess the following features and characteristics:
a. Technology Stack:
i. Frontend: [Specify frontend tech: e.g., Vite Vanilla, React/Vue, etc.]
ii. Backend: Rust utilizing the Actix framework.
iii. Database: MariaDB.
iv. Deployment Environment: Containerized using Docker and orchestrated via Docker Compose.
b. Performance & Scalability: The architecture is designed for efficient performance and to accommodate future growth in user base and data volume.
c. Security: Development practices will incorporate security considerations, including secure authentication mechanisms (e.g., PAKE SRP planned for initial implementation), data validation, and adherence to standard secure coding practices. ().
d. User Interface (UI) and User Experience (UX): The System shall feature an intuitive, responsive user interface adaptable to various screen sizes (desktop, tablet, mobile) and designed according to the principles outlined in Section 3.1 and Exhibit A. Adherence to accessibility guidelines (e.g., WCAG) will be pursued where practicable. ().
e. Modularity: The System architecture promotes modularity to facilitate future enhancements and integrations.
2.4 Video Demonstration: As part of the development process or deliverables, Developer shall provide Client with a video demonstration showcasing core System functionalities, user roles (learner, instructor, administrator), and key workflows, substantially covering the items listed below:
a. Platform Navigation and Layout.
b. Key User Journeys (Learner Course Interaction, Instructor Course Management, Administrator User/Course Management).
c. Core Feature Highlights (Dashboard, Profiles, Course Interaction, Admin Interfaces).
d. Interface Responsiveness.
2.5 Excluded Services: ().
ARTICLE 3: SYSTEM SPECIFICATIONS AND ARCHITECTURE
3.1 User Interface (UI) Layout and Flow: The general layout principles and high-level component relationships for the System's user interface are conceptually depicted in Exhibit A (User Interface Flow Diagram), incorporated herein by reference. Key layout components include a persistent Header, a contextual Sidebar (where applicable), a Main Content Area, and a Footer. Specific screen designs and detailed UI specifications will be developed and refined during the Sprints, subject to Client review and feedback.
3.2 Backend Architecture: The high-level backend architecture, illustrating the interaction between the Actix framework, database (MariaDB), and other core components within the planned containerized environment, is conceptually depicted in Exhibit B (Backend Architecture Diagram), incorporated herein by reference. ().
3.3 Technical Specifications: ().
ARTICLE 4: PROJECT TIMELINE AND DELIVERABLES
4.1 Estimated Timeline: The estimated timeline for the completion of the Services is approximately [Calculate total weeks from Gantt, e.g., 35 weeks], commencing from the Effective Date or an otherwise agreed-upon project start date. A detailed breakdown of phases, estimated task durations, and dependencies is illustrated in the Gantt chart provided as Exhibit C (Project Timeline Gantt Chart), incorporated herein by reference.
4.2 Acknowledgement of Estimates: Client acknowledges that the timeline provided in Exhibit C is an estimate based on the initial Scope of Services and the Agile methodology. Timelines may be adjusted based on the evolution of requirements, Client feedback, unforeseen complexities, or mutually agreed-upon changes processed via the Change Management procedure (Article 6).
4.3 Key Deliverables: Major deliverables under this Agreement include:
a. Access to incremental System builds for review at the end of relevant Sprints.
b. The final, deployed System software meeting the Acceptance Criteria (Article 5).
c. The Video Demonstration (as per Section 2.4).
d. System Documentation, including user guides for administrators, instructors, and learners, and technical documentation sufficient for ongoing maintenance and operation. ().
e. Source Code for the developed System. ().
f. Training materials and sessions as specified in Section 4.4.
4.4 Training and Handover: Upon successful deployment, Developer shall provide:
a. Training for Client's designated administrators and instructors. ().
b. Onboarding materials (e.g., documentation, potentially videos) for learners.
c. A formal handover process concluding the development phase.
ARTICLE 5: TESTING AND ACCEPTANCE
5.1 Testing: Developer shall perform internal testing throughout the development process, including unit, integration, and functional testing, appropriate to the Agile methodology.
5.2 User Acceptance Testing (UAT): Client shall be responsible for conducting UAT upon notification from Developer that specific features, modules, or the System as a whole are ready for review. Client shall perform UAT in accordance with agreed-upon test plans or criteria. ().
5.3 Acceptance Criteria: The System shall be deemed accepted by Client upon the earlier of: (a) Client providing written notice of acceptance; or (b) Client using the System in a live production environment for purposes other than UAT; or (c) the expiration of the final UAT period without Client providing written notice of material non-conformities preventing acceptance. ().
5.4 Defect Resolution: Developer shall use commercially reasonable efforts to correct any material defects or non-conformities to the agreed specifications identified during UAT and reported by Client in accordance with the agreed process.
ARTICLE 6: CHANGE MANAGEMENT
6.1 Change Request Process: Recognizing the iterative nature of the Agile methodology, changes to the Scope of Services, requirements, or specifications may arise. All requests for changes ("Change Requests") must be submitted in writing.
6.2 Impact Assessment: Developer shall assess the impact of each Change Request on the project scope, timeline, and cost. Developer will provide Client with a written analysis of the impact and any associated cost adjustments or schedule modifications.
6.3 Approval: No Change Request shall be implemented by Developer unless and until both Parties have mutually agreed upon the change, its impact, and any associated adjustments in writing (e.g., via a formal Change Order document).
ARTICLE 7: PROJECT CONSIDERATIONS AND RISK MITIGATION
7.1 Potential Scope Evolution: Client acknowledges that the flexibility of the Agile process requires diligent scope management by both Parties to control project timelines and costs. The Change Management process (Article 6) is the agreed mechanism for managing scope adjustments.
7.2 Initial Setup and Data Migration:
a. Client is responsible for necessary preparations for System implementation, including user account provisioning (unless otherwise agreed) and ensuring readiness of any required infrastructure not provided by Developer.
b. If data migration from existing systems is required and included in the Scope of Services (), Client shall cooperate fully with Developer, providing data in the required format and participating in validation. Developer and Client will collaboratively develop a specific Data Migration Plan. The complexity of data migration may impact the project timeline and effort.
c. Developer shall provide reasonable onboarding support, training (as per Section 4.4), and documentation to facilitate a smooth transition.
ARTICLE 8: FEES AND PAYMENT SCHEDULE
()
8.1 Fees: Detail the total project cost or the billing rate (e.g., Time & Materials with a cap, Fixed Fee). Specify currency.
8.2 Payment Schedule: Outline milestones or dates for invoicing and payment terms (e.g., Net 30 days). Include details for initial deposit, milestone payments, final payment.
8.3 Expenses: Specify how expenses (e.g., travel, third-party licenses) will be handled – included in fees or reimbursed separately. Require pre-approval for significant expenses.
8.4 Taxes: State which party is responsible for applicable taxes.
ARTICLE 9: INTELLECTUAL PROPERTY RIGHTS
()
9.1 Ownership of Deliverables: Typically, upon full payment, ownership of the custom code developed specifically for the Client (the System) transfers to the Client. Clearly define this.
9.2 Developer's Pre-Existing IP: State that Developer retains ownership of its pre-existing tools, libraries, frameworks, know-how, and code used in the project but grants Client a license to use them as integrated into the System. Define the scope of this license (e.g., perpetual, non-exclusive, royalty-free).
9.3 Third-Party Materials: Address ownership and licensing of any third-party components (e.g., open-source libraries) used. Client typically receives these under their respective licenses.
ARTICLE 10: CONFIDENTIALITY
()
10.1 Definition of Confidential Information: Define what constitutes confidential information for both Parties.
10.2 Obligations: State the receiving Party's obligation to protect the disclosing Party's confidential information, using a reasonable degree of care.
10.3 Exclusions: List standard exclusions (e.g., publicly known information, independently developed, required by law).
10.4 Duration: Specify the duration of the confidentiality obligations (e.g., a number of years after agreement termination).
ARTICLE 11: WARRANTIES AND DISCLAIMERS
()
11.1 Developer Warranties:
a. Performance Warranty: Developer typically warrants that the System will perform substantially in accordance with the agreed specifications for a limited period (e.g., 90 days) after Acceptance ("Warranty Period"). Detail the remedy (e.g., Developer will correct defects).
b. Authority: Warrant that Developer has the right and authority to enter into this Agreement.
c. Non-Infringement: Warrant that, to Developer's knowledge, the custom-developed portions of the System do not infringe on third-party IP rights. (Often subject to limitations).
11.2 Disclaimers: EXCEPT FOR THE EXPRESS WARRANTIES STATED HEREIN, DEVELOPER DISCLAIMS ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. State that the System is provided "AS IS" after the Warranty Period.
ARTICLE 12: LIMITATION OF LIABILITY
()
12.1 Exclusion of Certain Damages: NEITHER PARTY SHALL BE LIABLE TO THE OTHER FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES (INCLUDING LOST PROFITS) ARISING OUT OF OR RELATING TO THIS AGREEMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
12.2 Cap on Direct Damages: EACH PARTY'S TOTAL CUMULATIVE LIABILITY FOR DIRECT DAMAGES ARISING OUT OF OR RELATING TO THIS AGREEMENT SHALL BE LIMITED TO THE TOTAL FEES PAID OR PAYABLE BY CLIENT TO DEVELOPER UNDER THIS AGREEMENT. (This amount is often heavily negotiated).
12.3 Exceptions: Specify exceptions to limitations (e.g., breach of confidentiality, indemnification obligations, infringement).
ARTICLE 13: TERM AND TERMINATION
()
13.1 Term: The Agreement commences on the Effective Date and continues until the Services are completed and final payment is made, unless terminated earlier as provided herein.
13.2 Termination for Cause: Either Party may terminate if the other Party materially breaches the Agreement and fails to cure within a specified period (e.g., 30 days) after written notice.
13.3 Termination for Convenience: (Optional) Allow either Party (or just Client) to terminate without cause upon written notice (e.g., 30 or 60 days). Specify consequences (e.g., payment for work performed).
13.4 Effect of Termination: Detail obligations upon termination (e.g., return of confidential information, final payments for work done, delivery of work-in-progress).
ARTICLE 14: MISCELLANEOUS
14.1 Governing Law: Specify the jurisdiction whose laws will govern the Agreement (e.g., "State of [Your Jurisdiction], without regard to its conflict of laws principles").
14.2 Dispute Resolution: Outline the process for resolving disputes (e.g., negotiation, mediation, arbitration, litigation) and specify the venue/location.
14.3 Notices: Define how formal notices must be sent between the Parties (e.g., certified mail, email with confirmation).
14.4 Entire Agreement: State that this Agreement (including Exhibits) constitutes the entire understanding between the Parties and supersedes all prior discussions or agreements.
14.5 Amendments: Specify that any changes must be in writing and signed by both Parties.
14.6 Assignment: State whether either Party can assign its rights or obligations under the Agreement (usually requires consent).
14.7 Severability: If any part of the Agreement is found invalid, the rest remains in effect.
14.8 Force Majeure: Address delays caused by events beyond reasonable control.
14.9 Relationship of Parties: State that Developer is an independent contractor, not an employee or partner of Client.
ARTICLE 15: EXHIBITS
The following Exhibits are attached hereto and incorporated by reference into this Agreement:
- Exhibit A: User Interface Flow Diagram
- Exhibit B: Backend Architecture Diagram
- Exhibit C: Project Timeline Gantt Chart
- ()
IN WITNESS WHEREOF, the Parties hereto have caused this Software Development and Implementation Agreement to be executed by their duly authorized representatives as of the Effective Date.
[CLIENT COMPANY: Western Institute of Technology]
Name: Mark Glen C. Guides
Date: 08/04/2025
[CELL TECH] (Developer)
Name: Jose DanielG. Percy
Name: Rekcel M. Endencia
Date: 08/04/2025
EXHIBIT A: User Interface Flow Diagram
---
config:
theme: neo-dark
---
flowchart LR
subgraph Layouts["Layouts"]
Centered["🎯 Centered Layout (Login, Register)"]
ThreeCol["🏛️ Three-Column Layout (Admin Dash)"]
SplitCol["| Sidebar | Content | (Split Column Layout)"]
end
Header["🧭 Header (Logo, Menu, User Profile Dropdown)"]
Sidebar["📚 Sidebar (Optional, Collapsible)"]
MainContent["🖥️ Main Content Area (Hosts Widgets/Pages)"]
Footer["📎 Footer (Links, Copyright)"]
Modal["P M Modal Container"]
LoginPage["🔑 Login Page"]
LoginWidget["🧩 Login Widget (SRP)"]
RegisterButtonWidget["🧩 Button Widget -> Register"]
RegisterPage["✍️ Register Page"]
RegisterInfoWidget["🧩 Register Info Widget"]
LoginButtonWidget["🧩 Button Widget -> Login"]
DashboardPage["📊 Dashboard Page"]
VariousWidgets["🧩 Various Dashboard Widgets"]
ProfilePage["👤 Profile Page"]
ProfileInfoWidget["🧩 Profile Info Widget (Pic, Name, ID, DOB)"]
PostFeedWidget["🧩 Post Feed Widget"]
AdminPage["⚙️ Admin Dashboard"]
StudentsWidget["🧩 Students Widget"]
TeachersWidget["🧩 Teachers Widget"]
ManageStudentsPage["📋 Manage Students Page"]
StudentTableWidget["🧩 Student Table Widget"]
LoginPage --> Centered
RegisterPage --> Centered
DashboardPage --> SplitCol
ProfilePage --> SplitCol
AdminPage --> ThreeCol
ManageStudentsPage --> SplitCol
LoginPage --> LoginWidget
LoginPage --> RegisterButtonWidget
RegisterPage --> RegisterInfoWidget
RegisterPage --> LoginButtonWidget
DashboardPage --> VariousWidgets
ProfilePage --> ProfileInfoWidget
ProfilePage --> PostFeedWidget
AdminPage --> StudentsWidget
AdminPage --> TeachersWidget
ManageStudentsPage --> StudentTableWidget
Header --> Sidebar
Sidebar --> MainContent
MainContent --> Footer
UserProfile["User Profile"] --> Modal
Modal --> AccountSettingsWidget["🧩 Account Settings Widget"]
MenuLinks["Menu Links"] --> Modal
Modal --> UnderConstructionWidget["🧩 'Under Construction' Widget (e.g., Classrooms)"]
End of Exhibit A
EXHIBIT B: Backend Architecture Diagram
flowchart TD
subgraph A["🌐 Client (Browser)"]
direction LR
Frontend["Vite App"]
end
subgraph B["🐳 Docker Environment"]
direction TB
subgraph C["🚦 Actix Backend Container (lms-backend)"]
direction TB
ActixServer["🚀 Actix HTTP Server"] --> Middleware["🛡️ Middleware (CORS, Log, Auth*)"]
Middleware --> Router["🗺️ Router (handlers.rs)"]
Router --> Handlers["⚙️ Route Handlers"]
Handlers -- Uses --> DBPool["💾 DB Pool (SQLx)"]
Handlers -- Uses --> Models["📝 Data Models (models.rs)"]
Handlers -- Uses --> Errors["❗ Error Handling (errors.rs)"]
Handlers -- Uses --> AppState["🧠 App State (Temp SRP/Session*)"]
Handlers -- Calls --> DBModule["🗃️ DB Logic (db.rs)"]
DBModule -- Uses --> DBPool
DBModule -- Uses --> Models
end
subgraph D["🗄️ MariaDB Container (db)"]
MariaDB["MariaDB Server"] -- Stores --> LMSData["LMS Database (lms_db)"]
end
C -- Connects via Network --> D
end
A --> B
End of Exhibit B
EXHIBIT C: Project Timeline Gantt Chart
gantt
title LMS Development Timeframe (Estimated)
dateFormat YYYY-MM-DD
axisFormat %Y-%m-%d
todayMarker stroke-width:3px,stroke:#E67E22,stroke-opacity:0.8
%% Define Sections based on Phases
section Phase 1: Planning & Design (Approx. 5 Weeks)
Requirements Gathering & Analysis :req, 2024-01-15, 10d
System Architecture Design :design, after req, 10d
UI/UX Wireframing & Prototyping :wireframe, after design, 10d
Tech Stack Finalization & Setup :setup, after design, 5d
Phase 1 Review & Approval :p1review, after wireframe, 5d
section Phase 2: Core Development (Approx. 18 Weeks)
Database Schema Implementation :dbdev, after setup, 15d
Backend Core & Auth Dev (Rust) :backend, after setup, 50d
Frontend Foundational Setup :frontend_setup, after setup, 15d
API Development & Integration :api, after backend, 30d
Frontend UI Development :frontend_ui, after frontend_setup, 40d
Widget System Implementation :frontend_widget, after frontend_setup, 20d
Module Development (Iterative) :modules, after api, 60d
Initial Dev Testing & Integration :devtest, after modules, 15d
section Phase 3: Testing & Deployment (Approx. 8 Weeks)
Comprehensive QA Testing :qatest, after devtest, 20d
User Acceptance Testing (UAT) :uat, after qatest, 10d
Feedback Implementation & Bug Fixing :fixes, after uat, 10d
Deployment Preparation :deployprep, after fixes, 5d
Production Deployment & Go-Live :deploy, after deployprep, 5d
section Phase 4: Post-Launch (Approx. 4 Weeks)
System Monitoring & Stabilization :monitor, after deploy, 10d
Admin & Instructor Training :admintrain, after deploy, 10d
Learner Onboarding Materials :learnertrain, after admintrain, 10d
Final Documentation & Handover :handover, after admintrain, 10d
%% Milestones (Aligned with phase ends where logical)
milestone Phase 1 Complete : 2025-02-16
milestone Core Backend Complete : 2025-04-19
milestone Core Frontend Complete : 2025-05-31
milestone Development Complete : 2025-07-26
milestone Testing Complete : 2025-08-23
milestone Project Go-Live : 2025-08-30
milestone Project Handover : 2025-09-27
Note: Dates are estimates and subject to refinement based on detailed sprint planning and potential scope adjustments defined via the Change Management process (Article 6). End of Exhibit C