From 31ecf0d02289d10834c594de380712614ee5ac20 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 01:45:49 +0800 Subject: [PATCH 01/15] docs: Delete docs/CONTRACT.md --- docs/CONTRACT.md | 58 ------------------------------------------------ 1 file changed, 58 deletions(-) delete mode 100644 docs/CONTRACT.md diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md deleted file mode 100644 index a922c6e..0000000 --- a/docs/CONTRACT.md +++ /dev/null @@ -1,58 +0,0 @@ -# Contract Proposal: Learner Management System (LMS) - -## **Short Version** - -**1. SDLC (Software Development Life Cycle) Used:** - -We will employ an **Agile methodology**, specifically an iterative and incremental approach. This allows for flexibility and adaptation throughout the project lifecycle, ensuring the LMS evolves to meet your needs effectively. Agile is chosen for its responsiveness to change, emphasis on collaboration, and delivery of working software in short cycles. - -**2. Advantages:** - -* **Modern Technology Stack:** Utilizes cutting-edge technologies for performance, scalability, and maintainability. -* **User-Centric Design:** Intuitive and responsive interface ensuring ease of use for all users (learners, instructors, administrators). -* **Modular and Scalable Architecture:** Designed for future expansion and integration of new features and modules. -* **Robust Project Management:** Experienced team employing Agile practices for timely delivery and effective communication. - -**3. Disadvantages:** - -* **Evolving Requirements:** Agile's flexibility can sometimes lead to scope creep if not managed effectively. We will mitigate this with clear communication and prioritized feature implementation. -* **Initial Setup Complexity:** Setting up a comprehensive LMS requires initial effort in data migration and system configuration. We will provide thorough onboarding and support to ease this transition. - -**4. Video Explanation:** - -A concise video will demonstrate the LMS in action. Key points include: - -* System Overview: High-level tour of the platform and its modules. -* User Roles: Demonstration of learner, instructor, and administrator interfaces. -* Core Workflows: Showcase of essential features like course enrollment, content delivery, and progress tracking. - -**5. Wireframe:** - -The LMS features a clean and structured wireframe: - -* **Header:** Top navigation with logo, user profile, and main menu links. -* **Sidebar:** Contextual navigation within modules for quick access to features and settings. -* **Main Content Area:** Dynamic space for dashboards, course content, user lists, and interactive elements. -* **Footer:** Essential links, copyright information, and support contact details. - -**6. Timeframe (Gantt Chart):** - -```mermaid -gantt - title LMS Development Timeframe - dateFormat YYYY-MM-DD - section Planning & Design - Requirements Gathering :a1, 2024-01-15, 1w - System Design :a2, after a1, 2w - UI/UX Wireframing :a3, after a2, 2w - section Development - Frontend Development :b1, after a3, 8w - Backend Development :b2, after a3, 10w - Database Design & Setup :b3, after a2, 3w - API Integration :b4, after b2, 6w - section Testing & Deployment - System Testing :c1, after b4, 4w - User Acceptance Testing :c2, after c1, 2w - Deployment & Go-Live :c3, after c2, 2w - Training & Handover :c4, after c3, 2w -``` -- 2.47.2 From 2b059d089a39070a80e877cd9a935a36fe2e2e8b Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 05:33:52 +0800 Subject: [PATCH 02/15] Update docs/CONTRACT.md --- docs/CONTRACT.md | 348 +++++++++++++++++++++++++++++++++++++++++++ docs/DETAILED_VER.md | 167 --------------------- 2 files changed, 348 insertions(+), 167 deletions(-) create mode 100644 docs/CONTRACT.md delete mode 100644 docs/DETAILED_VER.md diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md new file mode 100644 index 0000000..5113ab7 --- /dev/null +++ b/docs/CONTRACT.md @@ -0,0 +1,348 @@ +# Contract Proposal: Learner Management System (LMS) + +**INTERNAL NOTES FOR THOSE WRITING THE CONTRACT:** + +Check the source code in order to see the following: + +* ``: Marks a section primarily for the development team's reference. +* ``: Indicates specific information the team needs to fill in or verify before finalizing for a client. +* Regular text without markers is intended for the final client-facing proposal. + +## **Executive Summary** + + + +**1. Development Approach (SDLC):** + +We will utilize an **Agile (Iterative and Incremental)** methodology. This approach ensures flexibility, allowing the LMS to adapt to evolving needs through regular feedback loops and the delivery of working software components in short cycles (sprints). This minimizes risk and maximizes alignment with your requirements. + +**2. Key Advantages:** + +* **Modern & Performant:** Built with a cutting-edge stack ([Specify frontend tech: e.g., Vite Vanilla, React], Rust/Actix backend, MariaDB) for speed, scalability, and long-term maintainability. +* **User-Focused Design:** An intuitive, responsive interface ensures ease of use for learners, instructors, and administrators across all devices. +* **Modular & Scalable:** The architecture is designed for future growth, allowing seamless integration of new features and modules as your needs expand. +* **Collaborative & Transparent:** Our Agile process emphasizes clear communication and regular updates, ensuring you are involved and informed throughout development. + +**3. Potential Considerations & Mitigation:** + +* **Evolving Scope:** Agile's flexibility requires careful scope management. We mitigate this through prioritized backlogs and a clear change request process. +* **Initial Setup:** LMS implementation involves initial setup and potential data migration. We provide dedicated onboarding support, training, and documentation to ensure a smooth transition. + +**4. Video Demonstration:** + +A concise video demonstration will showcase the LMS's core functionalities, user roles (learner, instructor, admin), and key workflows like course interaction and progress tracking. + +**5. System Overview:** + +The LMS features a user-friendly interface with a standard layout (top navigation, optional sidebar, main content area) and a robust backend architecture ensuring efficient data management and processing. *(Detailed diagrams follow in the full version).* + +**6. Estimated Timeframe:** + +The project is estimated to take approximately **[Calculate total weeks from Gantt, e.g., 35 weeks]**, broken down into phases: Planning & Design (5 weeks), Development (18 weeks), Testing & Deployment (8 weeks), and Training & Handover (4 weeks). *(A detailed Gantt chart is provided in the full version).* + +--- + +## **Full Proposal Document** + +### Contract Proposal: Learner Management System (LMS) Development and Implementation + + + +#### 1. SDLC (Software Development Life Cycle) Used: Agile - Iterative and Incremental Methodology + +For the development of the Learner Management System (LMS), we will employ an **Agile Software Development Life Cycle (SDLC)** methodology, specifically focusing on an **iterative and incremental** approach. + +* **Methodology Description:** Agile development breaks down the project into smaller, manageable cycles called iterations or sprints (typically 2-4 weeks). Each iteration includes planning, design, development, testing, and stakeholder review, culminating in a potentially shippable increment of the software. This process repeats, with each increment building upon the previous ones, allowing the LMS to evolve based on feedback and real-world usage. + +* **Why Agile for this LMS?** + * **Adaptability:** The educational landscape and user needs can change. Agile allows us to incorporate feedback and adjust priorities effectively throughout the project without derailing progress. + * **Early Value & Feedback:** You will see working parts of the LMS early and often. This provides tangible progress and crucial opportunities to provide feedback, ensuring the final product truly meets your needs. + * **Collaboration & Transparency:** Agile fosters close collaboration between our team and your stakeholders through regular meetings (e.g., sprint reviews, planning sessions) and clear communication channels. + * **Risk Management:** Addressing challenges in small iterations allows for early identification and mitigation of risks, preventing them from escalating into major roadblocks. + * **User-Centricity:** Continuous feedback loops ensure the development remains focused on delivering the best possible experience for learners, instructors, and administrators. + +Our commitment to Agile principles ensures a collaborative, flexible, and results-oriented development process tailored to delivering a high-quality LMS. + +#### 2. Advantages: Key Benefits of the Proposed Learner Management System + + + +This LMS project is meticulously designed to provide substantial advantages through its technology, design, and the project management approach employed. + +* **Technological Advantages:** + * **Modern Technology Stack:** The LMS leverages a robust and contemporary technology stack: + * **Frontend:** [Specify frontend tech: e.g., Vite Vanilla for rapid prototyping and performance, potentially transitioning to React/Vue for larger-scale features if needed] + * **Backend:** Rust with the Actix framework, chosen for its exceptional performance, memory safety, and concurrency capabilities, ensuring a highly responsive and scalable backend. + * **Database:** MariaDB, a reliable and performant open-source relational database, well-suited for structured LMS data. + * **Deployment:** Containerized using Docker and orchestrated with Docker Compose for consistent environments and easier deployment/scaling. + * **Performance & Scalability:** The chosen technologies are optimized for speed and efficiency, capable of handling a growing number of users and concurrent activity without performance degradation. + * **Security Focused:** Security is integrated from the start, employing secure authentication (PAKE SRP), data validation, appropriate data handling practices, and readiness for standard security protocols (HTTPS). + * **API-Ready Architecture:** The backend is designed with API principles in mind, facilitating potential future integrations with other institutional systems or third-party educational tools. + +* **Design Advantages:** + * **Intuitive User Experience (UX):** Prioritizing ease of use, the interface will feature clear navigation, logical workflows, and a clean layout, minimizing the learning curve for all user types. + * **Responsive & Accessible UI:** The user interface will adapt seamlessly to various screen sizes (desktops, tablets, mobiles) and will adhere to accessibility best practices (WCAG guidelines where applicable) to ensure usability for everyone. + * **Visually Engaging:** A modern aesthetic will be applied to create a professional and engaging learning environment. + * **Modular Layout:** The frontend utilizes a widget-based system and distinct layout modules (centered, three-column, split-column), promoting code reusability and simplifying future enhancements or modifications. + +* **Project Management Advantages:** + * **Experienced Team:** Our team comprises skilled developers proficient in Rust, modern frontend frameworks, database management, and experienced project managers adept at Agile methodologies. + * **Transparent Process:** We ensure transparency through regular progress updates, sprint demonstrations, access to project tracking tools (), and open communication channels. + * **Quality Assurance:** Rigorous testing is embedded in our process, including automated tests (unit, integration where feasible) and manual testing (functional, usability, UAT) to deliver a stable and reliable platform. + * **On-Time Delivery Focus:** Our Agile planning and execution aim for predictable delivery of milestones outlined in the project timeframe. + +#### 3. Disadvantages: Potential Limitations and Mitigation Strategies + + + +Transparency is key to a successful partnership. While we are confident in delivering an exceptional LMS, we acknowledge potential challenges and have proactive mitigation strategies in place. + +* **Potential for Scope Creep (Agile Flexibility):** + * **Challenge:** The iterative nature of Agile can sometimes lead to requests for additional features ("scope creep") that were not initially planned, potentially impacting timelines or budget. + * **Mitigation:** + * **Clear Initial Scope:** We begin with a thorough requirements gathering phase to establish a clear baseline scope documented in a product backlog. + * **Prioritization:** Features in the backlog are prioritized based on value and effort, ensuring focus remains on core objectives. + * **Structured Change Management:** A formal process will be used for any new feature requests. Each request will be evaluated for its impact on scope, timeline, and budget, requiring stakeholder approval before being added to the backlog. + * **Sprint Goal Focus:** Each sprint will have a clear goal, helping the team stay focused on delivering the agreed-upon functionality for that iteration. + +* **Complexity of Initial Setup and Data Migration:** + * **Challenge:** Implementing any new system, particularly one replacing an existing platform, involves initial configuration, user setup, and potentially migrating data, which can be complex. + * **Mitigation:** + * **Dedicated Support:** We will provide dedicated support during the onboarding phase to assist with system configuration and user setup. + * **Data Migration Planning:** If data migration is required, we will collaborate with you to develop a detailed migration plan, including data mapping, validation, and testing, to ensure accuracy and minimize disruption. + * **Comprehensive Training:** Role-specific training materials (documentation, videos, potentially live sessions) will be provided for administrators, instructors, and learners. + * **Phased Rollout Option:** We can discuss a phased rollout strategy (e.g., by department, by feature set) if desired, to allow for gradual adoption and focused support. + * **Ongoing Documentation:** Clear and accessible documentation will be maintained for ongoing reference. + +#### 4. Video Explanation: Demonstrating the LMS Functionality + + + +To provide a tangible preview of the LMS, we will produce a short video walkthrough. This video will cover: + +* **Platform Navigation:** A guided tour of the main dashboard, navigation elements (top bar, sidebar where applicable), and overall layout. +* **Key User Journeys:** + * **Learner:** How a learner finds and enrolls in a course, accesses learning materials (lessons, resources), submits assignments, checks grades, and views their progress. + * **Instructor:** How an instructor manages their courses, uploads content, creates assignments/quizzes, grades submissions, communicates with learners, and monitors class progress. + * **Administrator:** How an administrator manages users (students, teachers), oversees courses, configures system settings, and accesses basic reporting. +* **Core Feature Highlights:** Demonstrations of key modules like the dashboard widgets, profile management, course interaction pages, and admin management interfaces. +* **Responsiveness:** Briefly showcasing how the interface adapts to different screen sizes. + +This video aims to give stakeholders a clear visual understanding of the system's look, feel, and core capabilities before full deployment. + +#### 5. System Architecture & User Interface Overview + + + +##### 5.1. User Interface (UI) Wireframe & Layout + + + +The LMS user interface is designed for clarity, consistency, and ease of navigation. The core layout principles are: + +* **Header (Top Navigation Bar):** Consistently visible at the top, providing access to main menu pages (e.g., Dashboard, Classrooms, Admin), user profile information (picture, name), and account actions (Profile, Settings, Logout) via a dropdown. +* **Sidebar (Contextual Navigation):** Appears in specific layouts (like the Split Column Layout). It provides quick access to subsections or features relevant to the current module (e.g., course navigation, admin sub-menus). It supports a collapsed icon-only mode for maximizing content space. +* **Main Content Area:** The primary workspace where module-specific content, widgets, forms, tables, and learning materials are displayed dynamically based on user interaction. Layouts include Centered (for Login/Register), Three-Column (for Admin Dashboard), and Split Column (for pages requiring a sidebar). +* **Footer:** Contains essential links (e.g., support, privacy policy), copyright information. + +The following diagram illustrates a high-level flow and component relationship within the user interface: + +```mermaid +flowchart TD + %% Layout Types (Vertical) + subgraph Layouts["Layouts"] + Centered["🎯 Centered Layout (Login, Register)"] + ThreeCol["πŸ›οΈ Three-Column Layout (Admin Dash)"] + SplitCol["| Sidebar | Content | (Split Column Layout)"] + end + + %% Core Components + 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"] + + %% Page Examples & Widget Hosting + 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"] + + %% Layout usage relationships (vertical chaining) + LoginPage --> Centered + RegisterPage --> Centered + DashboardPage --> SplitCol + ProfilePage --> SplitCol + AdminPage --> ThreeCol + ManageStudentsPage --> SplitCol + + %% Containment relationships + LoginPage --> LoginWidget + LoginPage --> RegisterButtonWidget + + RegisterPage --> RegisterInfoWidget + RegisterPage --> LoginButtonWidget + + DashboardPage --> VariousWidgets + + ProfilePage --> ProfileInfoWidget + ProfilePage --> PostFeedWidget + + AdminPage --> StudentsWidget + AdminPage --> TeachersWidget + + ManageStudentsPage --> StudentTableWidget + + %% Core Component Relationships (chained vertically) + Header --> Sidebar + Sidebar --> MainContent + MainContent --> Footer + + %% Modal Triggering (vertical flow) + UserProfile["User Profile"] --> Modal + Modal --> AccountSettingsWidget["🧩 Account Settings Widget"] + MenuLinks["Menu Links"] --> Modal + Modal --> UnderConstructionWidget["🧩 'Under Construction' Widget (e.g., Classrooms)"] + +``` + +*Diagram: High-level UI Component Relationships and Layout Usage.* + +##### 5.2. Backend Architecture (Internal Reference) + + + + + + +The backend is built using Rust and the Actix web framework, interacting with a MariaDB database via SQLx. It's designed to be modular and performant. + +**Code Structure:** + +The project follows a standard Rust structure with modules for configuration (`config.rs`), database interactions (`db.rs`), request handling (`handlers.rs`), data models (`models.rs`), and error handling (`errors.rs`). The `main.rs` file initializes the application, database pool, middleware, and routes. + +**Request Flow:** + +1. **Request Received:** Actix server receives an HTTP request. +2. **Middleware:** Passes through Logging, CORS, and (future) Auth middleware. +3. **Routing:** Matched to a handler function in `handlers.rs`. +4. **Handler Execution:** Logic is executed, potentially using injected DB pool, AppState (for temporary SRP/session data - **Note: Requires replacement for production**), and deserialized request data. +5. **DB Interaction:** Handler calls functions in `db.rs` which use SQLx to query MariaDB. +6. **Response/Error:** Handler returns a JSON response (using models from `models.rs`) or an `AppError` which is converted to a standard JSON error response. + +**Component Diagram:** + + +```mermaid +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 LR + 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 + + %% Notes + +``` + + + +*Diagram: Backend Component Interaction and Deployment Structure.* + +#### 6. Timeframe (Gantt Chart): Project Schedule and Milestones + + + +The following Gantt chart provides an estimated schedule for the LMS project, outlining key phases, tasks, dependencies, and durations. This timeline is based on our Agile methodology and assumes standard workweeks. Actual sprint-level timelines will be refined during project execution. + +```mermaid +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 : 2024-02-16 + milestone Core Backend Complete : 2024-04-19 + milestone Core Frontend Complete : 2024-05-31 + milestone Development Complete : 2024-07-26 + milestone Testing Complete : 2024-08-23 + milestone Project Go-Live : 2024-08-30 + milestone Project Handover : 2024-09-27 +``` + +*Note: Dates are estimates and subject to refinement based on detailed sprint planning and potential scope adjustments.* \ No newline at end of file diff --git a/docs/DETAILED_VER.md b/docs/DETAILED_VER.md deleted file mode 100644 index 1476a37..0000000 --- a/docs/DETAILED_VER.md +++ /dev/null @@ -1,167 +0,0 @@ -# Contract Proposal: Learner Management System (LMS) - -## **Full-Length Version** - -### Contract Proposal: Learner Management System (LMS) Development and Implementation - -#### 1. SDLC (Software Development Life Cycle) Used: Agile - Iterative and Incremental Methodology - -For the development of the Learner Management System (LMS), we propose utilizing an **Agile Software Development Life Cycle (SDLC)** methodology, specifically an **iterative and incremental approach**. - -* **Description of Agile Methodology:** Agile methodologies prioritize flexibility, collaboration, and rapid iteration. In an iterative and incremental model, the project is broken down into smaller, manageable iterations (sprints). Each iteration involves planning, design, development, testing, and review. At the end of each iteration, a working increment of the software is delivered. These increments are progressively built upon to create the final LMS. - -* **Rationale for Choosing Agile:** - * **Adaptability to Changing Requirements:** The education sector is dynamic, and requirements for an LMS can evolve. Agile is inherently flexible, allowing for adjustments and incorporation of new features or modifications throughout the development process without causing significant disruptions. - * **Early and Continuous Delivery:** Agile ensures that functional components of the LMS are delivered early and frequently. This provides stakeholders with tangible progress and opportunities for early feedback, leading to a more refined and user-centric final product. - * **Enhanced Collaboration and Communication:** Agile emphasizes close collaboration between the development team, stakeholders, and end-users. Regular meetings, feedback sessions, and transparent communication channels ensure alignment and shared understanding throughout the project. - * **Risk Mitigation:** By breaking down the project into smaller iterations, risks are identified and addressed early in the development cycle. This proactive approach reduces the likelihood of major issues arising later in the project. - * **Focus on User Needs:** Agile's iterative nature and emphasis on feedback ensure that the LMS is developed with a strong focus on meeting the actual needs of learners, instructors, and administrators. - -#### 2. Advantages: Key Benefits of the Learner Management System - -This LMS project is designed to deliver significant advantages across technology, design, and project management domains, resulting in a robust and effective learning platform. - -* **Technological Advantages:** - * **Modern Technology Stack:** The LMS will be built using a contemporary technology stack, including [Specify technologies like: React/Vue.js/Angular for frontend, Node.js/Python/Java for backend, modern databases, etc.]. This ensures high performance, scalability to accommodate growing user bases, and ease of maintenance and future updates. - * **Secure and Reliable Platform:** Security is paramount. The LMS will incorporate robust security measures, including secure authentication protocols, data encryption, and regular security audits to protect user data and ensure system integrity. - * **API-Driven Architecture:** The LMS will be designed with a well-defined API (Application Programming Interface). This allows for seamless integration with other educational tools, third-party platforms, and future system expansions, enhancing interoperability and flexibility. - * **Responsive and Accessible Design:** The platform will be fully responsive, ensuring optimal user experience across various devices (desktops, tablets, and smartphones). Accessibility standards will be adhered to, making the LMS usable by individuals with diverse needs. - -* **Design Advantages:** - * **User-Centric Interface (UI) and User Experience (UX):** The LMS will feature an intuitive and user-friendly interface designed based on UX best practices. Navigation will be straightforward, and workflows will be streamlined, ensuring ease of use for learners, instructors, and administrators, regardless of their technical proficiency. - * **Visually Appealing and Engaging Design:** A modern and aesthetically pleasing design will enhance user engagement and create a positive learning environment. The visual design will be consistent with current web design trends and tailored to be professional and education-focused. - * **Customizable and Brandable:** The LMS will be designed to be easily customizable and brandable. Themes, logos, and color schemes can be adapted to align with the institution's branding, providing a cohesive and professional online presence. - * **Modular and Flexible Layout:** The LMS will employ a modular design approach, allowing for easy addition, removal, or modification of features and modules. This ensures the platform can evolve alongside changing educational needs and technological advancements. - -* **Project Management Advantages:** - * **Experienced and Dedicated Team:** A team of experienced software developers, designers, and project managers will be assigned to this project. Their expertise in LMS development and Agile methodologies ensures efficient and high-quality project execution. - * **Transparent Communication and Reporting:** We are committed to maintaining transparent and consistent communication throughout the project lifecycle. Regular progress reports, sprint reviews, and stakeholder meetings will keep you informed and involved. - * **Timely Delivery and Adherence to Schedule:** Agile project management, combined with meticulous planning and resource allocation, will ensure that the LMS is delivered on time and within the agreed-upon timeframe. - * **Quality Assurance and Testing:** Rigorous testing protocols will be implemented throughout the development process, including unit testing, integration testing, system testing, and user acceptance testing. This comprehensive approach guarantees a stable, reliable, and high-quality LMS. - -#### 3. Disadvantages: Potential Limitations and Mitigation Strategies - -While this LMS project offers numerous advantages, it is important to acknowledge potential disadvantages and outline strategies to mitigate them. - -* **Potential for Scope Creep (Agile Flexibility):** - * **Disadvantage:** Agile's inherent flexibility, while beneficial, can sometimes lead to scope creep if not managed effectively. As requirements are iteratively refined, there's a risk of adding features beyond the initial project scope, potentially impacting timelines and budgets. - * **Mitigation:** We will implement robust scope management practices. This includes: - * **Clear Initial Requirements Definition:** Thorough requirements gathering and documentation at the project outset. - * **Prioritized Backlog Management:** Utilizing a prioritized product backlog, ensuring that only essential and high-value features are included in each iteration. - * **Change Management Process:** Establishing a formal change request process for evaluating and managing any proposed changes to the scope, ensuring impacts on timeline and budget are clearly understood and agreed upon. - * **Regular Sprint Reviews:** Conducting sprint reviews with stakeholders at the end of each iteration to ensure alignment and manage expectations regarding scope and progress. - -* **Complexity of Initial Setup and Data Migration:** - * **Disadvantage:** Implementing a comprehensive LMS, especially if migrating from a legacy system or setting up from scratch, can be complex. Data migration, system configuration, and user onboarding require initial effort and coordination. - * **Mitigation:** We will provide comprehensive support to ease the setup and transition process: - * **Dedicated Onboarding Team:** Assigning a dedicated onboarding team to assist with data migration, system configuration, and initial user setup. - * **Detailed Migration Plan:** Developing a detailed data migration plan to ensure a smooth and accurate transfer of existing data to the new LMS. - * **Comprehensive Training Programs:** Providing comprehensive training programs for administrators, instructors, and learners to ensure they can effectively utilize the LMS features from day one. - * **Phased Rollout Approach:** Considering a phased rollout approach, where the LMS is implemented module by module or department by department, to minimize disruption and allow for gradual adoption. - * **Ongoing Support and Documentation:** Providing ongoing technical support and comprehensive documentation (user manuals, FAQs, video tutorials) to assist users post-launch and ensure continued smooth operation. - -#### 4. Video Explanation: Demonstrating the LMS Functionality - -To provide a clear understanding of the LMS and its capabilities, we will create a concise and informative video explanation. This video will be a valuable tool for stakeholders to visualize the system in action and understand its core functionalities. - -* **Key Points to be Covered in the Video:** - * **System Overview and Navigation:** - * A high-level tour of the LMS platform, showcasing its overall structure and layout. - * Demonstration of the main navigation menu and how users can access different modules and features. - * Highlighting the responsive design and accessibility of the platform across devices. - * **User Role Demonstrations:** - * **Learner Perspective:** Showcasing the learner dashboard, course catalog, course enrollment process, accessing course content (modules, lessons, assignments), interaction with learning materials, progress tracking, and communication features. - * **Instructor Perspective:** Demonstrating the instructor dashboard, course creation and management tools, content uploading and organization, assignment creation and grading, communication with learners, progress monitoring, and reporting functionalities. - * **Administrator Perspective:** Highlighting the administrator dashboard, user management (adding, editing, managing user roles), system settings and configurations, reporting and analytics overview, and platform customization options. - * **Core LMS Workflows and Features:** - * **Course Enrollment and Management:** Illustrating the process of learners enrolling in courses and instructors managing their courses. - * **Content Delivery and Learning Resources:** Showcasing various content formats supported (videos, documents, interactive modules, etc.) and how they are presented to learners. - * **Assessment and Grading:** Demonstration of assignment submission, automated and manual grading processes, quiz functionalities, and gradebook management. - * **Communication and Collaboration Tools:** Highlighting features such as forums, messaging systems, announcements, and live session integration for enhanced interaction and communication within the learning environment. - * **Progress Tracking and Reporting:** Overview of progress tracking features for learners and reporting functionalities for instructors and administrators to monitor learning outcomes and system usage. - -#### 5. Wireframe: User Interface Layout and Navigation Structure - -The LMS wireframe is designed to be clean, intuitive, and user-focused, providing a structured and efficient learning environment. - -* **Overall Layout Structure:** - * **Header (Top Navigation Bar):** Located at the top of every page, providing consistent global navigation. - * **Logo Area:** Institution's logo (left side). - * **Main Menu Links:** Links to primary LMS modules (e.g., Dashboard, Courses, Users, Calendar, Reports, Admin Panel) - positioned centrally or right side. - * **User Profile/Account Section:** User avatar or initials, full name, dropdown menu for profile settings, notifications, and logout (rightmost side). - * **Sidebar (Left Navigation Panel):** Contextual navigation relevant to the currently active module. - * Appears on most pages except for login/registration and full-screen content views. - * Provides quick access to sub-sections and features within the current module (e.g., within "Courses": My Courses, Course Catalog, Archived Courses; within "Admin": User Management, System Settings, Reporting). - * May be collapsible to provide more screen real estate for content when needed. - * **Main Content Area (Central Pane):** The primary display area for dynamic content, varying based on the module and page selected. - * Displays dashboards, course listings, individual course pages, user profiles, forms, tables, interactive learning elements, etc. - * Designed to be responsive and adapt to different screen sizes. - * **Footer (Bottom Bar):** Located at the bottom of every page, containing less frequently used but essential information. - * Copyright information, terms of service, privacy policy links. - * Support contact information or links to help documentation. - * Language selection or accessibility options (if applicable). - -* **Navigation and Major Components:** - * **Dashboard:** Personalized landing page after login. - * **Widgets/Cards:** Displaying key information at a glance: "My Courses," "Upcoming Assignments," "Recent Announcements," "Progress Overview," "Calendar Events." - * Customizable layout to allow users to prioritize information. - * **Course Catalog/Course Listing:** Page to browse available courses. - * **Search and Filter Options:** Keywords, categories, instructors, course level, etc. - * **Course Cards/Tiles:** Displaying course name, brief description, instructor, enrollment status, and thumbnail image. - * **Course Detail Page:** In-depth information about a selected course: full description, syllabus, learning objectives, instructor bio, enrollment button. - * **Individual Course Pages:** The learning environment for each enrolled course. - * **Course Navigation Menu (within sidebar or top tabs):** Modules/Lessons, Assignments, Quizzes, Discussions, Grades, Participants. - * **Content Display Area:** Presenting lesson content, videos, documents, interactive activities. - * **Progress Bar:** Visual representation of course completion. - * **User Profiles:** Pages to view and manage user information. - * **Learner Profile:** Personal details, enrolled courses, grades, progress reports. - * **Instructor Profile:** Personal details, courses taught, student feedback. - * **Admin Profile:** Administrative settings access, system reports. - * **Admin Panel:** Module accessible only to administrators. - * **User Management:** Adding, editing, deleting users, managing user roles and permissions. - * **Course Management:** Creating, editing, managing courses, categories, instructors. - * **System Settings:** Platform configurations, branding customization, security settings. - * **Reporting and Analytics:** Access to system usage reports, learner performance data, course analytics. - * **Communication Tools:** - * **Announcements:** System-wide or course-specific announcements displayed prominently. - * **Forums/Discussion Boards:** Areas for asynchronous discussions within courses or across the platform. - * **Messaging System:** Private messaging between users (learners, instructors, admins). - * **Integration with Live Session Tools:** Links or embedded interfaces for video conferencing or virtual classroom platforms. - -#### 6. Timeframe (Gantt Chart): Project Schedule and Milestones - -The project timeframe is structured using a Gantt chart to provide a clear visual representation of project phases, tasks, dependencies, and timelines. This schedule is based on an Agile iterative development approach, with key milestones identified for each phase. - -```mermaid -gantt - title LMS Development Timeframe - dateFormat YYYY-MM-DD - axisFormat %Y-%m-%d - todayMarker stroke-width:5px,stroke:#0f0,stroke-opacity:0.5 - section Phase 1: Planning & Design (5 Weeks) - Requirements Gathering :req, 2024-01-15, 14d - System Design :design, after req, 14d - UI/UX Wireframing & Prototyping :wireframe, after design, 14d - Design Review & Approval :designreview, after wireframe, 7d - section Phase 2: Development (18 Weeks) - Frontend Development :frontend, after designreview, 56d - Backend Development & API :backend, after designreview, 70d - Database Design & Setup :database, after designreview, 21d - API Integration & Testing :api, after backend, 42d - Internal Testing (Dev Team) :devtest, after api, 21d - section Phase 3: Testing & Deployment (8 Weeks) - System Testing (QA Team) :systest, after devtest, 28d - User Acceptance Testing (UAT) :uat, after systest, 14d - UAT Feedback & Fixes :uatfix, after uat, 14d - Deployment & Go-Live :deploy, after uatfix, 14d - section Phase 4: Training & Handover (4 Weeks) - Admin & Instructor Training :admintrain, after deploy, 14d - Learner Onboarding & Training :learnertrain, after deploy, 14d - Documentation & Handover :handover, after learnertrain, 14d - - %% Milestones (Example, adjust dates based on actual timeline) - milestone Phase 1 Complete : 2024-02-19 - milestone Phase 2 Complete : 2024-06-24 - milestone Phase 3 Complete : 2024-08-19 - milestone Project Go-Live : 2024-08-19 -``` -- 2.47.2 From 8178806075d185b619d5167aae771cf066927fa6 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 11:26:03 +0800 Subject: [PATCH 03/15] Update graphs --- docs/CONTRACT.md | 34 ++++++---------------------------- 1 file changed, 6 insertions(+), 28 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 5113ab7..c035311 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -148,75 +148,56 @@ The LMS user interface is designed for clarity, consistency, and ease of navigat The following diagram illustrates a high-level flow and component relationship within the user interface: ```mermaid -flowchart TD - %% Layout Types (Vertical) +--- +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 - - %% Core Components 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"] - - %% Page Examples & Widget Hosting 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"] - - %% Layout usage relationships (vertical chaining) LoginPage --> Centered RegisterPage --> Centered DashboardPage --> SplitCol ProfilePage --> SplitCol AdminPage --> ThreeCol ManageStudentsPage --> SplitCol - - %% Containment relationships LoginPage --> LoginWidget LoginPage --> RegisterButtonWidget - RegisterPage --> RegisterInfoWidget RegisterPage --> LoginButtonWidget - DashboardPage --> VariousWidgets - ProfilePage --> ProfileInfoWidget ProfilePage --> PostFeedWidget - AdminPage --> StudentsWidget AdminPage --> TeachersWidget - ManageStudentsPage --> StudentTableWidget - - %% Core Component Relationships (chained vertically) Header --> Sidebar Sidebar --> MainContent MainContent --> Footer - - %% Modal Triggering (vertical flow) UserProfile["User Profile"] --> Modal Modal --> AccountSettingsWidget["🧩 Account Settings Widget"] MenuLinks["Menu Links"] --> Modal @@ -261,7 +242,7 @@ flowchart TD subgraph B["🐳 Docker Environment"] direction TB subgraph C["🚦 Actix Backend Container (lms-backend)"] - direction LR + direction TB ActixServer["πŸš€ Actix HTTP Server"] --> Middleware["πŸ›‘οΈ Middleware (CORS, Log, Auth*)"] Middleware --> Router["πŸ—ΊοΈ Router (handlers.rs)"] Router --> Handlers["βš™οΈ Route Handlers"] @@ -280,9 +261,6 @@ flowchart TD end A --> B - - %% Notes - ``` `: Marks a section primarily for the development team's reference. -* ``: Indicates specific information the team needs to fill in or verify before finalizing for a client. -* Regular text without markers is intended for the final client-facing proposal. +**[Your Company Name]**, a [Your Company's Legal Structure, e.g., Limited Liability Company] organized and existing under the laws of [Your Jurisdiction, e.g., the State of Delaware], with its principal place of business at [Your Company Address] (hereinafter referred to as the "**Developer**"), -## **Executive Summary** +AND - +**[Client Company Name]**, a [Client Company's Legal Structure, e.g., Corporation] organized and existing under the laws of [Client's Jurisdiction], with its principal place of business at [Client Company Address] (hereinafter referred to as the "**Client**"). -**1. Development Approach (SDLC):** +(Developer and Client may be referred to individually as a "**Party**" and collectively as the "**Parties**"). -We will utilize an **Agile (Iterative and Incremental)** methodology. This approach ensures flexibility, allowing the LMS to adapt to evolving needs through regular feedback loops and the delivery of working software components in short cycles (sprints). This minimizes risk and maximizes alignment with your requirements. +**Recitals:** -**2. Key Advantages:** +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. -* **Modern & Performant:** Built with a cutting-edge stack ([Specify frontend tech: e.g., Vite Vanilla, React], Rust/Actix backend, MariaDB) for speed, scalability, and long-term maintainability. -* **User-Focused Design:** An intuitive, responsive interface ensures ease of use for learners, instructors, and administrators across all devices. -* **Modular & Scalable:** The architecture is designed for future growth, allowing seamless integration of new features and modules as your needs expand. -* **Collaborative & Transparent:** Our Agile process emphasizes clear communication and regular updates, ensuring you are involved and informed throughout development. +**Agreement:** -**3. Potential Considerations & Mitigation:** +**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: -* **Evolving Scope:** Agile's flexibility requires careful scope management. We mitigate this through prioritized backlogs and a clear change request process. -* **Initial Setup:** LMS implementation involves initial setup and potential data migration. We provide dedicated onboarding support, training, and documentation to ensure a smooth transition. +## ARTICLE 1: DEFINITIONS -**4. Video Demonstration:** +*(Optional: Add definitions for key terms used throughout the agreement if needed for clarity, e.g., "Acceptance Criteria," "Deliverables," "Sprint," "Intellectual Property," etc.)* -A concise video demonstration will showcase the LMS's core functionalities, user roles (learner, instructor, admin), and key workflows like course interaction and progress tracking. +## ARTICLE 2: SCOPE OF SERVICES -**5. System Overview:** +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:** *()*. -The LMS features a user-friendly interface with a standard layout (top navigation, optional sidebar, main content area) and a robust backend architecture ensuring efficient data management and processing. *(Detailed diagrams follow in the full version).* +## ARTICLE 3: SYSTEM SPECIFICATIONS AND ARCHITECTURE -**6. Estimated Timeframe:** +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:** *()*. -The project is estimated to take approximately **[Calculate total weeks from Gantt, e.g., 35 weeks]**, broken down into phases: Planning & Design (5 weeks), Development (18 weeks), Testing & Deployment (8 weeks), and Training & Handover (4 weeks). *(A detailed Gantt chart is provided in the full version).* +## 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 NAME]** + +By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Name: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Title: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ + +**[YOUR COMPANY NAME]** (Developer) + +By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Name: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Title: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ --- -## **Full Proposal Document** - -### Contract Proposal: Learner Management System (LMS) Development and Implementation - - - -#### 1. SDLC (Software Development Life Cycle) Used: Agile - Iterative and Incremental Methodology - -For the development of the Learner Management System (LMS), we will employ an **Agile Software Development Life Cycle (SDLC)** methodology, specifically focusing on an **iterative and incremental** approach. - -* **Methodology Description:** Agile development breaks down the project into smaller, manageable cycles called iterations or sprints (typically 2-4 weeks). Each iteration includes planning, design, development, testing, and stakeholder review, culminating in a potentially shippable increment of the software. This process repeats, with each increment building upon the previous ones, allowing the LMS to evolve based on feedback and real-world usage. - -* **Why Agile for this LMS?** - * **Adaptability:** The educational landscape and user needs can change. Agile allows us to incorporate feedback and adjust priorities effectively throughout the project without derailing progress. - * **Early Value & Feedback:** You will see working parts of the LMS early and often. This provides tangible progress and crucial opportunities to provide feedback, ensuring the final product truly meets your needs. - * **Collaboration & Transparency:** Agile fosters close collaboration between our team and your stakeholders through regular meetings (e.g., sprint reviews, planning sessions) and clear communication channels. - * **Risk Management:** Addressing challenges in small iterations allows for early identification and mitigation of risks, preventing them from escalating into major roadblocks. - * **User-Centricity:** Continuous feedback loops ensure the development remains focused on delivering the best possible experience for learners, instructors, and administrators. - -Our commitment to Agile principles ensures a collaborative, flexible, and results-oriented development process tailored to delivering a high-quality LMS. - -#### 2. Advantages: Key Benefits of the Proposed Learner Management System - - - -This LMS project is meticulously designed to provide substantial advantages through its technology, design, and the project management approach employed. - -* **Technological Advantages:** - * **Modern Technology Stack:** The LMS leverages a robust and contemporary technology stack: - * **Frontend:** [Specify frontend tech: e.g., Vite Vanilla for rapid prototyping and performance, potentially transitioning to React/Vue for larger-scale features if needed] - * **Backend:** Rust with the Actix framework, chosen for its exceptional performance, memory safety, and concurrency capabilities, ensuring a highly responsive and scalable backend. - * **Database:** MariaDB, a reliable and performant open-source relational database, well-suited for structured LMS data. - * **Deployment:** Containerized using Docker and orchestrated with Docker Compose for consistent environments and easier deployment/scaling. - * **Performance & Scalability:** The chosen technologies are optimized for speed and efficiency, capable of handling a growing number of users and concurrent activity without performance degradation. - * **Security Focused:** Security is integrated from the start, employing secure authentication (PAKE SRP), data validation, appropriate data handling practices, and readiness for standard security protocols (HTTPS). - * **API-Ready Architecture:** The backend is designed with API principles in mind, facilitating potential future integrations with other institutional systems or third-party educational tools. - -* **Design Advantages:** - * **Intuitive User Experience (UX):** Prioritizing ease of use, the interface will feature clear navigation, logical workflows, and a clean layout, minimizing the learning curve for all user types. - * **Responsive & Accessible UI:** The user interface will adapt seamlessly to various screen sizes (desktops, tablets, mobiles) and will adhere to accessibility best practices (WCAG guidelines where applicable) to ensure usability for everyone. - * **Visually Engaging:** A modern aesthetic will be applied to create a professional and engaging learning environment. - * **Modular Layout:** The frontend utilizes a widget-based system and distinct layout modules (centered, three-column, split-column), promoting code reusability and simplifying future enhancements or modifications. - -* **Project Management Advantages:** - * **Experienced Team:** Our team comprises skilled developers proficient in Rust, modern frontend frameworks, database management, and experienced project managers adept at Agile methodologies. - * **Transparent Process:** We ensure transparency through regular progress updates, sprint demonstrations, access to project tracking tools (), and open communication channels. - * **Quality Assurance:** Rigorous testing is embedded in our process, including automated tests (unit, integration where feasible) and manual testing (functional, usability, UAT) to deliver a stable and reliable platform. - * **On-Time Delivery Focus:** Our Agile planning and execution aim for predictable delivery of milestones outlined in the project timeframe. - -#### 3. Disadvantages: Potential Limitations and Mitigation Strategies - - - -Transparency is key to a successful partnership. While we are confident in delivering an exceptional LMS, we acknowledge potential challenges and have proactive mitigation strategies in place. - -* **Potential for Scope Creep (Agile Flexibility):** - * **Challenge:** The iterative nature of Agile can sometimes lead to requests for additional features ("scope creep") that were not initially planned, potentially impacting timelines or budget. - * **Mitigation:** - * **Clear Initial Scope:** We begin with a thorough requirements gathering phase to establish a clear baseline scope documented in a product backlog. - * **Prioritization:** Features in the backlog are prioritized based on value and effort, ensuring focus remains on core objectives. - * **Structured Change Management:** A formal process will be used for any new feature requests. Each request will be evaluated for its impact on scope, timeline, and budget, requiring stakeholder approval before being added to the backlog. - * **Sprint Goal Focus:** Each sprint will have a clear goal, helping the team stay focused on delivering the agreed-upon functionality for that iteration. - -* **Complexity of Initial Setup and Data Migration:** - * **Challenge:** Implementing any new system, particularly one replacing an existing platform, involves initial configuration, user setup, and potentially migrating data, which can be complex. - * **Mitigation:** - * **Dedicated Support:** We will provide dedicated support during the onboarding phase to assist with system configuration and user setup. - * **Data Migration Planning:** If data migration is required, we will collaborate with you to develop a detailed migration plan, including data mapping, validation, and testing, to ensure accuracy and minimize disruption. - * **Comprehensive Training:** Role-specific training materials (documentation, videos, potentially live sessions) will be provided for administrators, instructors, and learners. - * **Phased Rollout Option:** We can discuss a phased rollout strategy (e.g., by department, by feature set) if desired, to allow for gradual adoption and focused support. - * **Ongoing Documentation:** Clear and accessible documentation will be maintained for ongoing reference. - -#### 4. Video Explanation: Demonstrating the LMS Functionality - - - -To provide a tangible preview of the LMS, we will produce a short video walkthrough. This video will cover: - -* **Platform Navigation:** A guided tour of the main dashboard, navigation elements (top bar, sidebar where applicable), and overall layout. -* **Key User Journeys:** - * **Learner:** How a learner finds and enrolls in a course, accesses learning materials (lessons, resources), submits assignments, checks grades, and views their progress. - * **Instructor:** How an instructor manages their courses, uploads content, creates assignments/quizzes, grades submissions, communicates with learners, and monitors class progress. - * **Administrator:** How an administrator manages users (students, teachers), oversees courses, configures system settings, and accesses basic reporting. -* **Core Feature Highlights:** Demonstrations of key modules like the dashboard widgets, profile management, course interaction pages, and admin management interfaces. -* **Responsiveness:** Briefly showcasing how the interface adapts to different screen sizes. - -This video aims to give stakeholders a clear visual understanding of the system's look, feel, and core capabilities before full deployment. - -#### 5. System Architecture & User Interface Overview - - - -##### 5.1. User Interface (UI) Wireframe & Layout - - - -The LMS user interface is designed for clarity, consistency, and ease of navigation. The core layout principles are: - -* **Header (Top Navigation Bar):** Consistently visible at the top, providing access to main menu pages (e.g., Dashboard, Classrooms, Admin), user profile information (picture, name), and account actions (Profile, Settings, Logout) via a dropdown. -* **Sidebar (Contextual Navigation):** Appears in specific layouts (like the Split Column Layout). It provides quick access to subsections or features relevant to the current module (e.g., course navigation, admin sub-menus). It supports a collapsed icon-only mode for maximizing content space. -* **Main Content Area:** The primary workspace where module-specific content, widgets, forms, tables, and learning materials are displayed dynamically based on user interaction. Layouts include Centered (for Login/Register), Three-Column (for Admin Dashboard), and Split Column (for pages requiring a sidebar). -* **Footer:** Contains essential links (e.g., support, privacy policy), copyright information. - -The following diagram illustrates a high-level flow and component relationship within the user interface: +### EXHIBIT A: User Interface Flow Diagram ```mermaid --- @@ -205,33 +239,12 @@ flowchart LR ``` -*Diagram: High-level UI Component Relationships and Layout Usage.* +*End of Exhibit A* -##### 5.2. Backend Architecture (Internal Reference) +--- - - - - +### EXHIBIT B: Backend Architecture Diagram -The backend is built using Rust and the Actix web framework, interacting with a MariaDB database via SQLx. It's designed to be modular and performant. - -**Code Structure:** - -The project follows a standard Rust structure with modules for configuration (`config.rs`), database interactions (`db.rs`), request handling (`handlers.rs`), data models (`models.rs`), and error handling (`errors.rs`). The `main.rs` file initializes the application, database pool, middleware, and routes. - -**Request Flow:** - -1. **Request Received:** Actix server receives an HTTP request. -2. **Middleware:** Passes through Logging, CORS, and (future) Auth middleware. -3. **Routing:** Matched to a handler function in `handlers.rs`. -4. **Handler Execution:** Logic is executed, potentially using injected DB pool, AppState (for temporary SRP/session data - **Note: Requires replacement for production**), and deserialized request data. -5. **DB Interaction:** Handler calls functions in `db.rs` which use SQLx to query MariaDB. -6. **Response/Error:** Handler returns a JSON response (using models from `models.rs`) or an `AppError` which is converted to a standard JSON error response. - -**Component Diagram:** - - ```mermaid flowchart TD subgraph A["🌐 Client (Browser)"] @@ -262,19 +275,16 @@ flowchart TD A --> B ``` - -*Diagram: Backend Component Interaction and Deployment Structure.* +*End of Exhibit B* -#### 6. Timeframe (Gantt Chart): Project Schedule and Milestones +--- - - -The following Gantt chart provides an estimated schedule for the LMS project, outlining key phases, tasks, dependencies, and durations. This timeline is based on our Agile methodology and assumes standard workweeks. Actual sprint-level timelines will be refined during project execution. +### EXHIBIT C: Project Timeline Gantt Chart ```mermaid gantt @@ -323,4 +333,5 @@ gantt milestone Project Handover : 2024-09-27 ``` -*Note: Dates are estimates and subject to refinement based on detailed sprint planning and potential scope adjustments.* \ No newline at end of file +*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* -- 2.47.2 From 2a8d75294f2a272e74c60977b71be66fdcd645e8 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 12:06:20 +0800 Subject: [PATCH 05/15] Fix formatting --- docs/CONTRACT.md | 136 ++++++++++++++++++++++++++++++++++++----------- 1 file changed, 105 insertions(+), 31 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 3d2fddc..6ff5658 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -29,127 +29,201 @@ C. Client desires to engage Developer to perform such software development and ## 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 []. + +> 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. + +> 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. + +> 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. + + > 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. + + > 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. + + > 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)*. + + > 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 -- 2.47.2 From 64f30aa363e8812567f459369fa95120a3d32297 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 12:07:22 +0800 Subject: [PATCH 06/15] Fix Recitals --- docs/CONTRACT.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 6ff5658..c230ca1 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -15,7 +15,9 @@ AND **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:** -- 2.47.2 From f816d3eef4fa1b78bd2b8779a13e603b2c67f7d6 Mon Sep 17 00:00:00 2001 From: rekcelph Date: Tue, 8 Apr 2025 15:02:51 +0800 Subject: [PATCH 07/15] UPDATED CONTRACT --- docs/CONTRACT.md | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index c230ca1..9131b2b 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -239,19 +239,18 @@ The following Exhibits are attached hereto and incorporated by reference into th **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 NAME]** +**[CLIENT COMPANY: Western Institute of Technology]** -By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ -Name: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ -Title: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ -Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Name: Mark Glen C. Guides +Date: 08/04/2025 -**[YOUR COMPANY NAME]** (Developer) +**[CELL TECH]** (Developer) -By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ -Name: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ -Title: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ -Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Name: Jose DanielG. Percy + +Name: Rekcel M. Endencia + +Date: 08/04/2025 --- @@ -400,13 +399,13 @@ gantt Final Documentation & Handover :handover, after admintrain, 10d %% Milestones (Aligned with phase ends where logical) - milestone Phase 1 Complete : 2024-02-16 - milestone Core Backend Complete : 2024-04-19 - milestone Core Frontend Complete : 2024-05-31 - milestone Development Complete : 2024-07-26 - milestone Testing Complete : 2024-08-23 - milestone Project Go-Live : 2024-08-30 - milestone Project Handover : 2024-09-27 + 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).* -- 2.47.2 From 6ffdbeadb5496e8052e737b465c91cd26d8ae177 Mon Sep 17 00:00:00 2001 From: rekcelph Date: Tue, 8 Apr 2025 18:48:42 +0800 Subject: [PATCH 08/15] Updated CONTRACT --- docs/CONTRACT.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 9131b2b..4a5aae8 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -4,11 +4,11 @@ This Software Development and Implementation Agreement (the "**Agreement**") is entered into effective as of **[Date - e.g., January 1, 2024]** (the "**Effective Date**"), by and between: -**[Your Company Name]**, a [Your Company's Legal Structure, e.g., Limited Liability Company] organized and existing under the laws of [Your Jurisdiction, e.g., the State of Delaware], with its principal place of business at [Your Company Address] (hereinafter referred to as the "**Developer**"), +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. AND -**[Client Company Name]**, a [Client Company's Legal Structure, e.g., Corporation] organized and existing under the laws of [Client's Jurisdiction], with its principal place of business at [Client Company Address] (hereinafter referred to as the "**Client**"). +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. (Developer and Client may be referred to individually as a "**Party**" and collectively as the "**Parties**"). -- 2.47.2 From 28435c2f3bd8939a15b062e400106da3aeac21df Mon Sep 17 00:00:00 2001 From: rekcelph Date: Tue, 8 Apr 2025 19:08:34 +0800 Subject: [PATCH 09/15] Updated nigga --- docs/CONTRACT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 4a5aae8..18c1b67 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -1,7 +1,7 @@ # **SOFTWARE DEVELOPMENT AND IMPLEMENTATION AGREEMENT** **Parties:** - +(3-5 Year Term) This Software Development and Implementation Agreement (the "**Agreement**") is entered into effective as of **[Date - e.g., January 1, 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. -- 2.47.2 From 673f8bb24f2e9cc4484a5af2e552a2f6ffa9ff8e Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 22:59:35 +0800 Subject: [PATCH 10/15] Updated Parties/Recitals/Agreement --- docs/CONTRACT.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 18c1b67..88e2f55 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -1,14 +1,15 @@ # **SOFTWARE DEVELOPMENT AND IMPLEMENTATION AGREEMENT** **Parties:** -(3-5 Year Term) -This Software Development and Implementation Agreement (the "**Agreement**") is entered into effective as of **[Date - e.g., January 1, 2024]** (the "**Effective Date**"), by and between: +(Term: 3-5 Years, To be finalized based on Support/Maintenance period post-delivery) -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. +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. +**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**"). -- 2.47.2 From 5505adc040bef3423f744a972dec2d6714c237eb Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 23:02:41 +0800 Subject: [PATCH 11/15] Update ARTICLE 2 to be more pacific --- docs/CONTRACT.md | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 88e2f55..2228b0d 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -31,37 +31,37 @@ C. Client desires to engage Developer to perform such software development and ## 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.1 **General Scope:** Developer shall perform the Services necessary to design, develop, test, implement, and deliver the System as described in this Agreement and its Exhibits. The System is intended to function as a comprehensive Learner Management System providing functionalities for learners, instructors, and administrators of Western Institute of Technology. 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. +> a. **Process:** The project will be broken down into Sprints. Each Sprint will generally include planning, design, development, testing, and stakeholder review, aiming to produce a potentially shippable increment of the System. Sprint duration will be mutually agreed upon, typically **[e.g., two (2)]** weeks. > > 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 []. +> c. **Project Management:** Developer shall employ project management practices consistent with the Agile methodology. Developer shall provide Client with **[e.g., weekly progress summaries via email and bi-weekly Sprint review meetings]**. Project tracking and backlog management will utilize **[Specify Tool, e.g., Trello, Jira, Asana, GitHub Projects - requires agreement]**, to which Client representatives will be granted appropriate access. 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.] +> > i. Frontend: Vite utilizing Vanilla TypeScript and Bootstrap v5.3. > > > > ii. Backend: Rust utilizing the Actix framework. > > -> > iii. Database: MariaDB. +> > iii. Database: MariaDB (version 10 or later compatible version). > > > > 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. +> b. **Performance & Scalability:** The architecture is designed for efficient performance under expected load conditions (to be reasonably defined) and to accommodate future growth in user base and data volume anticipated by the Client over the Agreement term. > -> 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. *()*. +> c. **Security:** Development practices will incorporate security considerations, including secure authentication mechanisms (specifically, the **OPAQUE** PAKE protocol), secure session management, input validation, protection against common web vulnerabilities (e.g., Cross-Site Scripting, SQL Injection), and adherence to standard secure coding practices. The Parties shall mutually agree upon any specific additional security standards or penetration testing requirements, if necessary. > -> 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. *()*. +> 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 Web Content Accessibility Guidelines (WCAG) **[Specify required level, e.g., 2.1 Level AA]** will be pursued where reasonably practicable within the scope and budget. > -> e. **Modularity:** The System architecture promotes modularity to facilitate future enhancements and integrations. +> e. **Modularity:** The System architecture, including the frontend widget system and backend service structure, promotes modularity to facilitate future enhancements, maintenance, and potential 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: +2.4 **Video Demonstration:** As part of the Deliverables, Developer shall provide Client with a video demonstration (e.g., screen recording with narration) showcasing core System functionalities, user roles (learner, instructor, administrator), and key workflows, substantially covering the items listed below: > a. Platform Navigation and Layout. > @@ -69,9 +69,18 @@ C. Client desires to engage Developer to perform such software development and > > c. Core Feature Highlights (Dashboard, Profiles, Course Interaction, Admin Interfaces). > ->d. Interface Responsiveness. +> d. Interface Responsiveness. -2.5 **Excluded Services:** *()*. +2.5 **Excluded Services:** Unless otherwise explicitly agreed upon in a written Change Order (Article 6), the Services under this Agreement **do not** include: +> a. Ongoing hosting services, server maintenance, or domain name registration/renewal fees beyond the initial deployment and stabilization period defined in Phase 4 of Exhibit C. +> +> b. Creation or curation of educational content (course materials, quizzes, etc.) to be loaded into the LMS. +> +> c. Extensive data migration services from legacy systems beyond [Define scope, e.g., "basic assistance with data mapping and import validation for user data provided in a pre-agreed format" or "data migration services as detailed in a separate Statement of Work"]. Client is responsible for data extraction and cleansing from source systems unless otherwise agreed. +> +> d. Procurement or management of hardware infrastructure required by Client outside the scope of the development and deployment process. +> +> e. Licenses for any third-party software required by Client for its own operations that may interact with the LMS, unless such software is directly embedded by Developer as part of the System Deliverable and its licensing terms are passed through. ## ARTICLE 3: SYSTEM SPECIFICATIONS AND ARCHITECTURE -- 2.47.2 From 1445ec83db66de85e4b5f30c4cbf12f7f2734932 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 23:03:48 +0800 Subject: [PATCH 12/15] Updated ARTICLE 3 & 4 to be more pacific --- docs/CONTRACT.md | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 2228b0d..0a28a95 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -84,39 +84,42 @@ C. Client desires to engage Developer to perform such software development and ## 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.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 during Sprint Reviews. -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.2 **Backend Architecture:** The high-level backend architecture, illustrating the interaction between the Actix framework, MariaDB database, OPAQUE authentication flow, 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:** *()*. +3.3 **Technical Specifications:** Detailed technical specifications, including specific API endpoint definitions, data model schemas, and performance guidelines, may be documented collaboratively by the Parties during the project lifecycle, potentially in a shared repository or document store ([Specify if needed, e.g., "maintained in the project's shared Confluence space"]), and referenced herein upon mutual agreement. Initial database schema is based on requirements outlined during project initiation. ## 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.1 **Estimated Timeline:** The estimated timeline for the completion of the Services is approximately **Thirty-Five (35) weeks**, commencing from the 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.2 **Acknowledgement of Estimates:** Client acknowledges that the timeline provided in Exhibit C is an estimate based on the initial Scope of Services, assumptions about requirements stability, and the Agile methodology. Timelines may be adjusted based on the outcomes of Sprints, the complexity of features prioritized, Client feedback responsiveness, unforeseen technical challenges, or mutually agreed-upon Change Requests processed via the Change Management procedure (Article 6). Developer shall promptly communicate any anticipated significant deviations from the estimated timeline. 4.3 **Key Deliverables:** Major deliverables under this Agreement include: - > a. Access to incremental System builds for review at the end of relevant Sprints. + > a. Access to functional System increments for review and feedback at the conclusion of relevant Sprints (typically via a staging environment). > - > b. The final, deployed System software meeting the Acceptance Criteria (Article 5). + > b. The final, deployed System software meeting the Acceptance Criteria (Article 5), delivered to the agreed production environment. > > 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. *()*. + > d. System Documentation, comprising: + > > i. User Manuals: Guides for administrators, instructors, and learners covering core functionalities. + > > + > > ii. Technical Documentation: Including deployment instructions, system architecture overview, API endpoint documentation (e.g., generated OpenAPI spec), and database schema description, sufficient to enable technically skilled personnel to operate, maintain, and potentially extend the System. The specific level of detail shall be **[e.g., "standard industry practice for systems of similar complexity" or specify further detail if required]**. > - > e. Source Code for the developed System. *()*. + > e. Source Code for the custom-developed portions of the System delivered under this Agreement, provided via **[Specify method, e.g., access to a Git repository, digital media transfer]**. Source code escrow requirements, if any, must be separately agreed upon in writing. > - > f. Training materials and sessions as specified in Section 4.4. + > f. Training materials and delivery of training sessions as specified in Section 4.4. -4.4 **Training and Handover:** Upon successful deployment, Developer shall provide: +4.4 **Training and Handover:** Upon successful deployment (Go-Live milestone in Exhibit C), Developer shall provide: - > a. Training for Client's designated administrators and instructors. *()*. + > a. Training for Client's designated administrators and instructors, covering system administration, course management, user management, and key instructional features. This training shall consist of **[Specify format, duration, number of sessions, e.g., "up to two (2) remote training sessions, each lasting approximately three (3) hours, for a maximum of ten (10) Client attendees per session"]**. > - > b. Onboarding materials (e.g., documentation, potentially videos) for learners. + > b. Onboarding materials suitable for learners, such as a concise user guide document and potentially referencing the Video Demonstration. > - > c. A formal handover process concluding the development phase. + > c. A formal handover meeting and documentation transfer concluding the development and deployment phases outlined in Exhibit C. ## ARTICLE 5: TESTING AND ACCEPTANCE -- 2.47.2 From 00a7e8c488c472f9d6f87d15967abb75f4416832 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 23:05:20 +0800 Subject: [PATCH 13/15] Updated ARTICLE 5-10 to be more pacific --- docs/CONTRACT.md | 59 ++++++++++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 27 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 0a28a95..bb07aa2 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -123,67 +123,72 @@ C. Client desires to engage Developer to perform such software development and ## 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.1 **Testing:** Developer shall perform internal testing throughout the development process, appropriate to the Agile methodology. This includes developer testing (e.g., unit tests where applicable), integration testing of components, and functional testing against requirements defined for each Sprint. -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.2 **User Acceptance Testing (UAT):** Client shall be responsible for conducting UAT. Developer shall notify Client when specific features, modules, or System increments are ready for UAT (typically at the end of Sprints or designated UAT phases as shown in Exhibit C). Client shall perform UAT in accordance with mutually agreed-upon test plans or use cases based on the Acceptance Criteria. Client shall have **[Specify duration, e.g., ten (10) business days]** from such notification to conduct UAT for the provided increment and report any identified material defects or non-conformities ("**Defects**") to Developer in writing via the agreed project tracking tool ([Tool name from 2.2.c]). Failure to report Defects within the specified period may be deemed acceptance of that increment for the purpose of proceeding with development, without prejudice to addressing Defects identified later within the Warranty Period. -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.3 **Acceptance Criteria:** The System (or relevant increment) shall be deemed formally accepted by Client upon the earliest occurrence of: + > (a) Client providing Developer with written notice of acceptance; or + > + > (b) Client using the delivered System or increment in a live production environment for its intended operational purposes (excluding UAT activities); or + > + > (c) The expiration of the final UAT period for the complete System (as per the timeline in Exhibit C) without Client providing written notice of material Defects that prevent acceptance according to the agreed Acceptance Criteria. + > + > Acceptance Criteria shall primarily be based on the functional requirements defined in the project backlog and specifications developed during the Sprints, demonstrating that the System operates substantially as intended. -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. +5.4 **Defect Resolution:** Developer shall use commercially reasonable efforts to correct any material Defects identified during UAT and properly reported by Client within the agreed timeframe. Defect prioritization and resolution timelines will be managed as part of the Agile backlog grooming and sprint planning process. Resolution of minor defects or cosmetic issues may be deferred to subsequent Sprints or the Warranty Period by mutual agreement. ## 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.1 **Change Request Process:** Both Parties acknowledge that requirements may evolve. Any proposed change to the agreed-upon Scope of Services, features, specifications, or Deliverables after the initial baseline established during planning ("**Change Request**") must be submitted in writing by either Party to the other Party's designated project contact. -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.2 **Impact Assessment:** Upon receipt of a Change Request, Developer shall promptly assess its potential impact on the project scope, technical feasibility, estimated timeline, resource allocation, and overall project cost. Developer will provide Client with a written impact analysis, including any proposed adjustments to fees or schedule, within **[e.g., five (5) business days]**, or a longer period if mutually agreed for complex requests. -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). +6.3 **Approval:** Developer shall not proceed with implementing any Change Request until both Parties have formally agreed in writing (e.g., through a signed Change Order document referencing this Agreement) to the Change Request itself, its assessed impact, and any associated adjustments to the Agreement's terms, including fees and timeline. Approved Change Orders shall become part of this Agreement. ## 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.1 **Potential Scope Evolution:** Client acknowledges that the flexibility inherent in the Agile process necessitates active participation and decisive feedback from Client representatives to manage scope effectively. Both Parties agree to utilize the Change Management process (Article 6) diligently to ensure that scope adjustments are intentional, documented, and their impacts understood and agreed upon, thereby mitigating risks to project timelines and budget. 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. + > a. Client Responsibilities: Client is responsible for providing necessary access to its infrastructure (if applicable), timely feedback, subject matter expertise, and ensuring user readiness for the System implementation. Client shall designate key personnel to participate in project meetings, reviews, and UAT. > - > 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. + > b. Data Migration: **[Select ONE option based on agreement, requires confirmation]:** + > * **Option 1 (Migration Not Included/Basic Assistance):** Data migration from Client's existing systems is not included in the scope of Services under the base Fees. Developer may provide reasonable assistance with defining data formats or validating imported data, subject to separate agreement or Change Order if significant effort is required. Client is primarily responsible for extracting, cleansing, formatting, and importing its data. + > * **Option 2 (Migration Included - Define Scope):** Data migration services for [Specify data types, e.g., user profiles, basic course structures] from [Specify source system(s)] are included in the Scope of Services. A detailed Data Migration Plan outlining responsibilities, formats, timelines, and validation procedures shall be developed collaboratively by the Parties early in the project. Client remains responsible for the accuracy and completeness of source data provided. Complexities discovered during migration may necessitate a Change Request. > - > c. Developer shall provide reasonable onboarding support, training (as per Section 4.4), and documentation to facilitate a smooth transition. + > c. Support and Training: Developer commits to providing the onboarding support, training, and documentation outlined in Articles 2, 4, and associated Exhibits to mitigate challenges associated with system transition and user adoption. ## ARTICLE 8: FEES AND PAYMENT SCHEDULE -*()* +**8.1 Fees and Payment Terms:** **The total fees, billing rates (if applicable), invoicing procedures, and payment schedule for the Services rendered under this Agreement shall be detailed in a separate Payment Schedule document (designated as Exhibit D), which shall be mutually agreed upon by the Parties in writing and incorporated herein by reference upon execution.** Exhibit D shall specify currency (Philippine Peso - PHP, unless otherwise agreed), payment milestones or frequency, and payment terms (e.g., Net 30 days from invoice date). -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 **Expenses:** Unless otherwise specified in Exhibit D, Developer shall bear its own general overhead costs. Any direct, out-of-pocket expenses reasonably incurred by Developer specifically for the project (e.g., pre-approved travel, specific third-party software licenses necessary for the deliverable) shall be reimbursable by Client only if pre-approved by Client in writing. Invoices for approved expenses shall include supporting documentation. -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. +8.3 **Taxes:** Each Party shall be responsible for its own taxes imposed by relevant authorities. Fees specified in Exhibit D are exclusive of any applicable Value Added Tax (VAT) or other sales taxes, which, if applicable, shall be added to Developer's invoices and paid by Client. ## ARTICLE 9: INTELLECTUAL PROPERTY RIGHTS -*()* +9.1 **Ownership of Custom Developed System:** Subject to Client's full payment of all fees due under this Agreement and Developer's reservation of rights in Pre-Existing IP (Section 9.2), Developer hereby assigns to Client all right, title, and interest in and to the custom Source Code and associated Deliverables specifically created by Developer for Client under this Agreement (the "**Custom Developed IP**"). -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 Intellectual Property:** Developer shall retain all right, title, and interest in and to any software, code, libraries, tools, methodologies, know-how, or other intellectual property owned or licensed by Developer prior to the Effective Date or developed independently of this Agreement ("**Developer Pre-Existing IP**"), even if incorporated into the System or used in performing the Services. -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 **License to Developer Pre-Existing IP:** To the extent Developer Pre-Existing IP is incorporated into the System Deliverables, Developer hereby grants Client a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license to use, reproduce, modify, and create derivative works of such Developer Pre-Existing IP solely as necessary for Client to use, operate, maintain, and enhance the System for its internal educational and administrative purposes. This license is non-transferable except to a successor of Client's entire business related to the System. -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. +9.4 **Third-Party Materials:** Any third-party software or materials, including open-source software components, incorporated into the System shall be subject to the terms and conditions of their respective licenses. Developer shall identify any significant third-party components and their licenses to Client upon request or as part of the documentation Deliverable. Client's use of the System is subject to compliance with such third-party licenses. ## ARTICLE 10: CONFIDENTIALITY -*()* +10.1 **Definition:** "**Confidential Information**" means any non-public information disclosed by one Party ("**Disclosing Party**") to the other Party ("**Receiving Party**") under this Agreement, whether orally or in writing, that is designated as confidential or that reasonably should be understood to be confidential given the nature of the information and the circumstances of disclosure. This includes, but is not limited to, business plans, financial information, customer lists, personnel information, technical data, trade secrets, know-how, source code (for Developer's pre-existing IP), and the terms of this Agreement. -10.1 **Definition of Confidential Information:** Define what constitutes confidential information for both Parties. +10.2 **Obligations:** The Receiving Party agrees to: (a) use the Confidential Information solely for the purpose of performing its obligations or exercising its rights under this Agreement; (b) not disclose the Confidential Information to any third party without the prior written consent of the Disclosing Party, except to its employees, contractors, or legal/financial advisors who have a need to know and are bound by confidentiality obligations at least as restrictive as those herein; and (c) protect the Confidential Information from unauthorized use or disclosure using at least the same degree of care that it uses to protect its own confidential information of like importance, but not less than a reasonable degree of care. -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:** The obligations under this Article shall not apply to information that the Receiving Party can demonstrate: (a) was already lawfully known to the Receiving Party at the time of disclosure, free of any obligation of confidentiality; (b) is or becomes publicly known through no wrongful act of the Receiving Party; (c) is rightfully received from a third party without restriction and without breach of this Agreement; or (d) was independently developed by the Receiving Party without reference to or use of the Disclosing Party's Confidential Information. -10.3 **Exclusions:** List standard exclusions (e.g., publicly known information, independently developed, required by law). +10.4 **Required Disclosure:** If the Receiving Party is compelled by law, regulation, or court order to disclose any Confidential Information, it shall provide the Disclosing Party with prompt prior written notice (to the extent legally permissible) to allow the Disclosing Party an opportunity to seek a protective order or other appropriate remedy. -10.4 **Duration:** Specify the duration of the confidentiality obligations (e.g., a number of years after agreement termination). +10.5 **Duration:** The confidentiality obligations set forth herein shall survive the termination or expiration of this Agreement for a period of **[e.g., five (5)]** years. Obligations related to trade secrets shall survive indefinitely as long as they remain trade secrets under applicable law. ## ARTICLE 11: WARRANTIES AND DISCLAIMERS -- 2.47.2 From a5e8ff49d10f791a609d1eaf18fda8178bc18ba3 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 23:07:23 +0800 Subject: [PATCH 14/15] Update ARTICLE 11-15 to be more PACIFIC --- docs/CONTRACT.md | 90 +++++++++++++++++++++++++++--------------------- 1 file changed, 51 insertions(+), 39 deletions(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index bb07aa2..17c4b6e 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -192,83 +192,95 @@ C. Client desires to engage Developer to perform such software development and ## 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). +11.1 **Developer Warranties:** Developer warrants to Client that: + > a. **Performance Warranty:** For a period of **[Specify duration, e.g., ninety (90) days]** following the date of final Acceptance of the complete System by Client ("**Warranty Period**"), the System will perform substantially in accordance with the material functional specifications agreed upon by the Parties under this Agreement when operated in the intended environment. Client's sole and exclusive remedy, and Developer's entire liability, for breach of this warranty shall be for Developer to use commercially reasonable efforts to correct or provide a workaround for any reproducible, material non-conformity reported by Client in writing during the Warranty Period. This warranty does not cover defects arising from misuse, modification by Client or third parties not authorized by Developer, accidents, or failure to operate the System in accordance with documentation or specified requirements. > - > b. **Authority:** Warrant that Developer has the right and authority to enter into this Agreement. + > b. **Authority:** Developer has the full right, power, and authority to enter into this Agreement and perform its obligations hereunder. > - > 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)*. + > c. **Service Performance:** The Services will be performed in a professional and workmanlike manner, consistent with generally accepted industry standards. + > + > d. **Non-Infringement:** To Developer's knowledge, the Custom Developed IP delivered under this Agreement does not infringe upon any valid patent, copyright, or trade secret of any third party existing under the laws of the Republic of the Philippines as of the Effective Date. Developer makes no warranty regarding infringement related to Developer Pre-Existing IP or any third-party materials. -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. +11.2 **Disclaimers:** **EXCEPT FOR THE EXPRESS WARRANTIES SET FORTH IN SECTION 11.1, THE SYSTEM, SERVICES, AND DELIVERABLES ARE PROVIDED "AS IS." DEVELOPER HEREBY DISCLAIMS ALL OTHER WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT WITH RESPECT TO THE SYSTEM AS A WHOLE OR ANY THIRD-PARTY COMPONENTS. DEVELOPER DOES NOT WARRANT THAT THE SYSTEM WILL BE ERROR-FREE, UNINTERRUPTED, OR MEET ALL OF CLIENT'S REQUIREMENTS.** ## ARTICLE 12: LIMITATION OF LIABILITY -*()* +12.1 **Exclusion of Indirect Damages:** **IN NO EVENT SHALL EITHER PARTY BE LIABLE TO THE OTHER PARTY OR ANY THIRD PARTY FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES (INCLUDING, BUT NOT LIMITED TO, LOST PROFITS, LOST REVENUE, LOST DATA, LOSS OF GOODWILL, OR BUSINESS INTERRUPTION) ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT OR THE USE OR PERFORMANCE OF THE SYSTEM OR SERVICES, REGARDLESS OF THE THEORY OF LIABILITY (CONTRACT, TORT, OR OTHERWISE), EVEN IF SUCH PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.** -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:** **EXCEPT FOR LIABILITY ARISING FROM A PARTY'S BREACH OF ITS CONFIDENTIALITY OBLIGATIONS (ARTICLE 10), INDEMNIFICATION OBLIGATIONS (IF ANY - NOT CURRENTLY INCLUDED, CONSIDER ADDING), OR INFRINGEMENT OF THE OTHER PARTY'S INTELLECTUAL PROPERTY RIGHTS, EACH PARTY'S TOTAL AGGREGATE LIABILITY TO THE OTHER PARTY FOR ALL CLAIMS FOR DIRECT DAMAGES ARISING OUT OF OR RELATING TO THIS AGREEMENT, WHETHER IN CONTRACT, TORT, OR OTHERWISE, SHALL NOT EXCEED THE TOTAL AMOUNT OF FEES ACTUALLY PAID BY CLIENT TO DEVELOPER UNDER THIS AGREEMENT DURING THE TWELVE (12) MONTH PERIOD PRECEDING THE EVENT GIVING RISE TO THE CLAIM.** *(Note: This cap is often heavily negotiated. Alternatives include a fixed amount or excluding certain types of direct 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). +12.3 **Basis of Bargain:** The Parties acknowledge that the limitations of liability and disclaimers of warranties set forth in this Agreement reflect the agreed-upon allocation of risk between the Parties and form an essential basis of the bargain, without which Developer would not have entered into this Agreement on the terms provided. ## ARTICLE 13: TERM AND TERMINATION -*()* +13.1 **Term:** This Agreement shall commence on the Effective Date and shall continue until all Services are completed, the System is Accepted, final payment has been made, and the Warranty Period has expired, unless terminated earlier pursuant to the terms of this Article 13. The initial intended development and deployment term is estimated in Exhibit C. The overall Agreement duration might extend based on mutually agreed support terms beyond the initial delivery (as suggested by the "3-5 Year Term" note, which requires separate definition, likely in a Support Agreement). -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 this Agreement upon written notice if the other Party materially breaches any provision of this Agreement and fails to cure such breach within **[Specify cure period, e.g., thirty (30) calendar days]** after receiving written notice specifying the breach in reasonable detail. Material breaches include, but are not limited to, failure to make timely payments (by Client) or failure to meet key milestones or Deliverable requirements after reasonable opportunity to cure (by Developer). -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:** **[Choose ONE option or delete if not applicable]:** + * **Option A (Client Only):** Client may terminate this Agreement without cause at any time upon **[Specify notice period, e.g., thirty (30) days']** prior written notice to Developer. + * **Option B (Mutual):** Either Party may terminate this Agreement without cause at any time upon **[Specify notice period, e.g., sixty (60) days']** prior written notice to the other Party. + * **Option C (No Convenience Termination):** (No clause added). -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). +13.4 **Effect of Termination:** Upon termination or expiration of this Agreement for any reason: + > a. Developer shall cease performing Services and shall promptly deliver to Client all completed Deliverables and work-in-progress, including Source Code for Custom Developed IP up to the date of termination. + > + > b. Client shall pay Developer for all Services performed and accepted Deliverables provided up to the effective date of termination, plus any pre-approved, non-cancelable expenses incurred. If termination is by Client for convenience (if Option A or B is chosen), Client shall also pay **[Specify additional amount, e.g., "a termination fee equivalent to X% of the remaining estimated project fees" or "for the work completed during the notice period"]**. + > + > c. Each Party shall promptly return or, at the Disclosing Party's request, destroy all Confidential Information of the other Party in its possession or control. + > + > d. Any provisions of this Agreement that by their nature should survive termination (including, but not limited to, Articles 9, 10, 11.2, 12, 14, and payment obligations accrued prior to termination) shall survive. ## 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.1 **Governing Law:** This Agreement and any disputes arising out of or relating to it shall be governed by and construed in accordance with the laws of the **Republic of the Philippines**, 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.2 **Dispute Resolution:** The Parties agree to attempt to resolve any dispute, controversy, or claim arising out of or relating to this Agreement amicably through good faith negotiation between authorized representatives. If negotiation fails within **[e.g., thirty (30) days]**, the Parties agree **[Choose ONE: e.g., "to submit the dispute to mediation under the rules of [Specify Mediation Body in the Philippines] before resorting to litigation" OR "that the exclusive venue for any legal action shall be the competent courts of [Specify City, e.g., Iloilo City], Philippines"]**. -14.3 **Notices:** Define how formal notices must be sent between the Parties (e.g., certified mail, email with confirmation). +14.3 **Notices:** All notices, requests, demands, and other communications required or permitted under this Agreement shall be in writing and shall be deemed effectively given: (a) upon personal delivery; (b) upon transmission by electronic mail to the addresses specified below (provided confirmation of receipt is obtained); or (c) three (3) business days after deposit with a reputable overnight courier or registered mail, postage prepaid, addressed to the Parties at their respective addresses first set forth above, or to such other address as a Party may designate by notice. + > **To Developer:** Attn: [Name/Title], Email: [Email Address] + > **To Client:** Attn: [Name/Title], Email: [Email Address] -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.4 **Entire Agreement:** This Agreement, including all Exhibits attached hereto (which are incorporated herein by reference), constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior or contemporaneous proposals, understandings, representations, warranties, covenants, and agreements, whether written or oral, relating thereto. -14.5 **Amendments:** Specify that any changes must be in writing and signed by both Parties. +14.5 **Amendments:** No amendment, modification, or waiver of any provision of this Agreement shall be effective unless in writing and signed by duly authorized representatives of both Parties. -14.6 **Assignment:** State whether either Party can assign its rights or obligations under the Agreement (usually requires consent). +14.6 **Assignment:** Neither Party may assign or transfer this Agreement or any of its rights or obligations hereunder, without the prior written consent of the other Party, which consent shall not be unreasonably withheld or delayed. Notwithstanding the foregoing, either Party may assign this Agreement without consent in connection with a merger, acquisition, or sale of all or substantially all of its assets related to this Agreement, provided the assignee agrees in writing to be bound by the terms hereof. -14.7 **Severability:** If any part of the Agreement is found invalid, the rest remains in effect. +14.7 **Severability:** If any provision of this Agreement is held by a court of competent jurisdiction to be invalid, illegal, or unenforceable, the validity, legality, and enforceability of the remaining provisions shall not in any way be affected or impaired thereby, and such provision shall be deemed modified to the minimum extent necessary to make it valid, legal, and enforceable. -14.8 **Force Majeure:** Address delays caused by events beyond reasonable control. +14.8 **Force Majeure:** Neither Party shall be liable for any failure or delay in performing its obligations hereunder (except for payment obligations) if such failure or delay is caused by circumstances beyond its reasonable control, including but not limited to acts of God, war, terrorism, strikes, labor disputes, pandemics, epidemics, government orders, fire, flood, earthquake, or internet service provider failures ("**Force Majeure Event**"). The affected Party shall provide prompt notice to the other Party and shall use reasonable efforts to resume performance as soon as practicable. If a Force Majeure Event continues for more than **[e.g., sixty (60) days]**, the non-affected Party may terminate this Agreement upon written notice. -14.9 **Relationship of Parties:** State that Developer is an independent contractor, not an employee or partner of Client. +14.9 **Relationship of Parties:** Developer is an independent contractor, and nothing in this Agreement shall be construed as creating an employment, partnership, joint venture, or agency relationship between Developer and Client. Neither Party has the authority to bind the other Party in any respect. ## 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 -* *()* +* **Exhibit A:** User Interface Flow Diagram +* **Exhibit B:** Backend Architecture Diagram +* **Exhibit C:** Project Timeline Gantt Chart +* **Exhibit D:** Payment Schedule *(To be mutually agreed upon and attached)* **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]** +**[CLIENT: Western Institute of Technology]** -Name: Mark Glen C. Guides -Date: 08/04/2025 +By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Name: Mark Glen C. Guides +Title: [Client Representative Title] +Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ -**[CELL TECH]** (Developer) +**[DEVELOPER: Cell Tech]** -Name: Jose DanielG. Percy +By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +Name: Jose Daniel G. Percy +Title: [Partner / Authorized Representative] +Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ +By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Name: Rekcel M. Endencia - -Date: 08/04/2025 +Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ --- -- 2.47.2 From 160a92eceb9998172c801a5cb290fb5f424236f2 Mon Sep 17 00:00:00 2001 From: aki Date: Tue, 8 Apr 2025 23:07:51 +0800 Subject: [PATCH 15/15] Add ARTICLE 1: DEFINITIONS --- docs/CONTRACT.md | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/docs/CONTRACT.md b/docs/CONTRACT.md index 17c4b6e..72bad51 100644 --- a/docs/CONTRACT.md +++ b/docs/CONTRACT.md @@ -27,7 +27,31 @@ C. Client desires to engage Developer to perform such software development and ## 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.)* +For the purposes of this Agreement, the following terms shall have the meanings ascribed to them below: + +1.1 **"Acceptance Criteria"** means the specific, measurable criteria defined in this Agreement or mutually agreed upon test plans, which the System must meet to be formally accepted by the Client. + +1.2 **"Agile"** refers to the iterative and incremental software development methodology described in Section 2.2. + +1.3 **"Confidential Information"** has the meaning set forth in Article 10. + +1.4 **"Deliverables"** means the specific items, including software code, documentation, reports, and training materials, that Developer is obligated to provide to Client under this Agreement, as further detailed in Section 4.3. + +1.5 **"Intellectual Property"** means any and all patents, copyrights, trademarks, trade secrets, database rights, design rights, and other proprietary rights, whether registered or unregistered. + +1.6 **"LMS"** or **"System"** means the custom Learner Management System software to be developed and implemented by Developer for Client pursuant to this Agreement. + +1.7 **"OPAQUE"** refers to the Oblivious Pseudo-Random Function (OPRF) based Asymmetric Password-Authenticated Key Exchange protocol intended for user authentication within the System. + +1.8 **"PAKE"** means Password-Authenticated Key Exchange, a class of cryptographic protocols allowing two parties to establish a shared cryptographic key based on a user's password without transmitting the password itself. OPAQUE is a type of PAKE protocol. + +1.9 **"Services"** means the software design, development, implementation, testing, training, documentation, and delivery services related to the System to be performed by Developer under this Agreement. + +1.10 **"Sprint"** means a time-boxed iteration (typically 2-4 weeks) within the Agile development process during which a defined amount of work is completed and made ready for review. + +1.11 **"Source Code"** means the human-readable programming language instructions used to create the System software. + +1.12 **"UAT"** means User Acceptance Testing, the process by which Client validates that the System meets the agreed-upon requirements and Acceptance Criteria. ## ARTICLE 2: SCOPE OF SERVICES -- 2.47.2