General Information
| Course number | IT490 |
|---|---|
| Course title | Systems Integration |
| Section | 451 |
| Semester | Fall 2026 |
| Modality | online asynchronous |
| Credits | 3 |
| Delivery | Online Newark |
Instructor
| Name | Matt Toegel |
|---|---|
| matthew.toegel@njit.edu | |
| Discord | MattToegel |
| GitHub | MattToegel |
Section Details
| Section | Meeting | Location |
|---|---|---|
| 451 | Canvas / Discord | Online |
Office Hours
| Time | Location |
|---|---|
| Monday and Tuesday, 10:00-11:20 AM | CKB main-floor public area (not the ground floor) |
Supplementary early-evening availability may be provided through Discord, but it is not a scheduled office-hour block. General availability is also provided through email or Canvas Inbox. Discord is the preferred place for project coordination questions because many IT490 issues involve team workflow, server state, deployment, and troubleshooting context.
Course Catalog
Prerequisites: CS 113 or CS 115, IS 331 or CS 331, and IT 340.
The course introduces the major design, implementation, and distributed deployment issues related to:
- System integration
- Network Operating Systems (NOS)
- Cross-platform database integration
- E-commerce and e-business applications
- Cross-server and multi-location e-session migration
- Related communication security topics
Course Format
This is an online asynchronous course. All course activity can be completed online; there are no required face-to-face or scheduled synchronous sessions. Follow the weekly schedule posted in Canvas.
Canvas is used for course materials, deadlines, and official course links. Discord supports course communication and project coordination. The Learn Courses Platform may be used for project evidence gathering, structured worksheet output, or course-specific workflow support when directed.
Students should monitor Canvas, Discord, and NJIT email for updates. For questions requiring a timely response, use Discord, email, or Canvas Inbox rather than Canvas Comments; Canvas Comments are appropriate for information that can be reviewed during grading.
Objective
This course consolidates and applies knowledge from earlier IT and CS courses. It emphasizes real-world, project-based learning in a team environment.
Students will work in teams to develop a full-stack application and supporting deployment architecture covering:
- System, network, and database administration
- Software engineering
- Full-stack development
- Project and deployment strategies
- Team coordination and documentation
Learning Outcomes
By the end of the course, students should be able to:
- Plan and document a team-based systems integration project with clear scope, responsibilities, and milestone evidence
- Use GitHub branches, issues, pull requests, project boards, and review comments to coordinate team work
- Design a full-stack system that integrates frontend, backend, database, messaging, logging, and deployment components
- Simulate a multi-server cluster with development, QA, production, and failover or load-balancing concerns where required
- Apply system, network, and database administration concepts to Linux server environments
- Integrate third-party data, APIs, ETL-style workflows, or service interfaces into an approved project design
- Configure, monitor, troubleshoot, and document public deployment environments
- Maintain evidence of server health, deployment behavior, team decisions, project changes, and operational risk
- Explain change management, disaster recovery, rollback, and security decisions for a distributed application
- Present individual contributions and connect those contributions to the larger team system
Grading Breakdown
| Category | Weight |
|---|---|
| Assignments | 10% |
| Quizzes | 10% |
| Project Proposal | 5% |
| Milestones | 20% |
| Midterm | 15% |
| Midterm Milestone | 15% |
| Final Project Deliverables (Final Project and Project Showcase) | 20% |
| End of Semester Change Log | 5% |
All points will be converted to a final percentage and letter grade at the end of the semester. Canvas will have the category weights applied. The published percentage ranges are a fixed absolute grading scale; the course does not use an official curve.
Extra Credit
Extra-credit tasks may be offered through homework, quizzes, or surveys. Any extra-credit points apply only to the corresponding grading category.
The typical target for substantive feedback is one to two weeks, preferably sooner.
Grading Scale
| Grade | Percentage Range |
|---|---|
| A | 89.5% to 100% |
| B+ | 84.5% to below 89.5% |
| B | 79.5% to below 84.5% |
| C+ | 74.5% to below 79.5% |
| C | 69.5% to below 74.5% |
| D+ | 64.5% to below 69.5% |
| D | 59.5% to below 64.5% |
| F | Below 59.5% |
Materials And Technologies
This course uses online resources instead of a required textbook. Canvas is the official source for assignments, assessments, grades, announcements, and required or recommended resources. The Learn Courses Platform may be used for project evidence gathering or course workflow support when directed.
Students will use:
- Discord, Canvas Inbox, or email for course communication
- Git for Windows, Git for macOS, or Git for Linux
- GitHub for version control and assignment evidence
- GitHub Education, recommended but not required
- Respondus LockDown Browser for exams
- A device meeting the YWCC minimum specifications, with administrative access to install required software
- A functional, charged device and charger for each in-person class meeting and assessment
- (Recommended) A notebook
- One instructor-provided shared GitHub repository per team for course materials and group work
- A public project host such as AWS, GCE, Azure, DigitalOcean, or another approved hosting environment
- Exposing local virtual machines via ZeroTier/Tailscale is also fine, but teams should discuss an uptime schedule
- Ubuntu 24.04+ where a Linux server environment is needed
- VirtualBox, VMware, cloud VMs, or similar environments when they support the approved team architecture
- Docker and container-based substitutes are not permitted for required course infrastructure. The course assesses each team's ability to manually configure and document Linux environments, services, networking, and recovery procedures.
Architecture-dependent technologies include:
- A database system appropriate to the approved project design
- Messaging, logging, API, ETL, or service integration tools appropriate to the approved project design
Project evidence includes:
- Logs, screenshots, diagrams, meeting notes, server notes, and written documentation as project evidence
Team Workflow Expectations
This course simulates a professional team environment. The instructor provides one shared GitHub repository and one dedicated Discord communication channel for each team. A general class Discord channel is also provided for course-wide communication. Students contribute to their team repository throughout the semester. Teams coordinate project work in the repository using:
- Branches for all task work
- Issues for tasks, bugs, documentation, deployment work, and team process work
- Pull requests to merge work into the main team branch
- Peer review before merging pull requests; review is required for a pull request to receive grading credit
- Project boards or equivalent tracking to show team progress
Each team member may be the point of contact for one or more VMs or services and must document their health, updates, purpose, and connections. Technical domains remain shared: students must understand and demonstrate the parts of the system their work touches, work across domains, and assist teammates when needed.
The project may grow from an initial set of development VMs into development, QA, production, and replicated production or failover environments depending on the milestone.
Submission Criteria
Project Proposal
Each team must use a Google Doc for initial planning and throughout the pre-approval phase. The document must be shared with the instructor. After approval, the approved project proposal must be posted as a Markdown file in the team's GitHub repository. A missing or unapproved proposal may result in a zero for the project and related milestones.
The proposal should identify:
- Project objective: what the system is trying to accomplish and who it is for
- Core user workflows: what users can do in the application and what value they get from it
- External API data: which external API or APIs will be used, what data will be pulled in, and how that data supports the project objective
- Stored data model: what project-specific data the team will store in its own database
- User data associations: how stored records connect to a logged-in user, team, role, profile, or other user-owned entity
- CRUD operations and features: what users can create, read, update, and delete, and which screens or API endpoints are needed for those actions
- User interaction with data: how users search, filter, select, compare, modify, or act on the stored and external data
- Team members and expected responsibilities
- Major services: frontend, backend, database, message queue, API gateway, workers, logging, or other required components
The team must allocate every proposed feature to one of these goal categories:
- MVP Goals: the features required for a functional midterm version of the project
- Final Goals: the additional features the team commits to completing for the final project
- Stretch Goals: optional features attempted only after the MVP Goals and Final Goals are on track
Milestones
Each milestone is a working showcase checkpoint. By the stated Canvas due time, each group must submit a recording. For Module 3's Milestone 1, the recording must show the functional logging-system proof of concept across the role-based VMs; application code is not required at that checkpoint. For later milestones, the recording must show the functioning live application. In every recording, the group must demonstrate the relevant feature or infrastructure behavior, explain what changed, point to supporting GitHub, deployment, server, log, diagram, or documentation evidence, and identify what remains for the project MVP or final Project Showcase.
Project Showcase
Each group must submit its final project and recorded Project Showcase virtually by 11:59 PM on Sunday, December 13, 2026, the university's official last day of classes. The recording must show the functioning live application. Each group member must present their role and contributions in the recording. Contributions will be verified through GitHub activity, project artifacts, documentation, communication evidence, and the final Project Showcase.
Change Log
The end-of-semester change log must include:
- GitHub repository and relevant branch names
- Pull requests or commit references associated with each team member
- Server and deployment documentation
- Team communication evidence such as Discord messages, meeting minutes, and group chats
- Architecture, service, or VM responsibility changes
- Significant changes and why they were made
- Known limitations or unresolved issues
Project Guidelines
All projects must follow the required architecture and team workflow, simulate a multi-server or distributed system, and implement basic networking and security features to receive credit.
Option A: Software As A Service
Use third-party data to build a functional online service, such as sports statistics, server status, business data, public datasets, or another approved source. The project should do more than display a static utility. It should integrate data into a usable service with team-owned backend behavior, persistence, and deployment documentation.
Option B: Mobile Or Web Game
Design a server-backed game with user tracking, state management, and a frontend for web or mobile use. External API data should be used where applicable, and at least one external data source is expected unless the instructor approves another integration plan.
Course Topics
- Software as a Service
- Project management
- ETL: Extract, Transform, Load
- Messaging layers
- Server-side development
- Change management
- Disaster recovery
- GitHub workflows
- Scripting
- Deployment documentation
- Team troubleshooting and operational evidence
- Multi-server environments and service responsibility
Illustrative Schedule
The schedule is a guideline and may change based on class pace, project needs, team troubleshooting needs, and deployment issues. Some modules may span more than one week. The outline identifies the planned due module for each milestone; Canvas provides the exact due date and time.
| Module | Topics |
|---|---|
| Module 1 |
|
| Module 2 |
|
| Module 3 |
|
| Module 4 |
|
| Module 5 |
|
| Module 6 |
|
| Module 7 |
|
| Module 8 |
|
| Module 9 |
|
| Module 10 |
|
| Module 11 |
|
Schedule Notes
Systems-integration work is cumulative, so early architecture and workflow decisions affect later milestones. Security, operational risk, and best practices will be discussed throughout the semester when they apply to project work.
Assignments
Assignment evidence follows the Project Evidence Expectations checklist. Assignments are generally graded out of 10 points unless otherwise noted.
Quizzes
Weekly online quizzes may be used to check current module understanding. Quizzes are completed in Canvas by the assigned due date.
Unless otherwise noted:
- Quizzes are closed notes and closed resources
- Quizzes are individual work
- Quizzes are graded out of 10 points
- Quizzes have time limits and attempt limits
- Quizzes require a passphrase
Exams
The midterm is completed independently during the shared Week 8 assessment period. The recorded midterm showcase is due in Week 9 by the stated Canvas due time.
The midterm will cover the first portion of the course and the integration concepts, project workflows, and operational practices introduced before the exam. It is generally graded out of 100 points. The Final Project Deliverables, including the Project Showcase, remain the final assessment.
Course Workflow Expectations
Students should expect to submit evidence that demonstrates both behavior and process:
- Team GitHub repository link
- Branch, issue, pull request, commit, or project board evidence when requested
- Runtime evidence from the environment or location specified by the assignment
- Screenshots or command outputs when requested
- Server, database, log, or monitoring evidence when requested
- Architecture diagrams or written documentation when requested
- Team communication, meeting, or decision evidence when requested
- VM or service responsibility notes when requested
- Explanation of what changed and why
- AI collaboration disclosure when used
Policies
Team Work And Ownership
This course simulates a professional team environment. Group work must clearly distinguish ownership of tasks. Students are expected to contribute meaningfully, communicate clearly, and document their work.
Students should not rely on one teammate to understand or produce the entire system. Each member must be able to explain their own contributions and how those contributions connect to the larger project.
To receive proper credit, each team member must have documented and approved work properly recorded on GitHub for their tasks.
Team members should not overwrite another team member's work. If such a situation happens, there must be a documented and agreed-upon reason from the team to show it was intentional and why.
GitHub And Project Evidence
Each team will use the GitHub repository provided by the instructor. Individual forks may be used when appropriate, but final team work must be pushed to the original team repository unless the instructor approves another workflow.
Common branch prefixes include:
feature/for new feature workbugfix/for bug fixeschore/for documentation, refactoring, maintenance, or other non-feature work
Pull requests must be reviewed by at least one teammate before merging. If a pull request is not approved, the team should document why and what needs to change.
Issues should be granular enough that ownership is clear. Issues should include a useful title, description, acceptance criteria, assignee, and links to related pull requests when applicable.
Project Structure And Required Artifacts
Assignments and project deliverables must follow the required repository structure, artifact names, documentation expectations, and submission instructions unless the assignment explicitly allows another approach.
Teams should keep project documentation, meeting notes, decision logs, architecture diagrams, server notes, and milestone evidence in the team repository, typically in a docs/ or team/ area unless another structure is approved.
Submissions that replace the expected project evidence with unrelated generated code, unsupported frameworks, or undocumented architectures may receive no credit because they cannot be fairly evaluated against the course objectives.
Academic Integrity
Academic Integrity is the cornerstone of higher education and is central to the ideals of this course and the university. Cheating is strictly prohibited and devalues the degree that you are working on. As a member of the NJIT community, it is your responsibility to protect your educational investment by knowing and following the academic code of integrity policy at NJIT Academic Integrity Code.
The instructor has a professional responsibility to report academic misconduct to the Office of the Dean of Students. A code violation may result in disciplinary action, including a failing grade, suspension, or dismissal. Questions about the Academic Integrity Code may be directed to dos@njit.edu.
The work done is expected to be your own, and group work must clearly distinguish ownership of tasks. Use of snippets or material from others should be kept to a minimum, and the source must be credited where applicable.
AI Usage Policy
Artificial intelligence (AI) tools may be used as learning and troubleshooting aids when they help you understand course concepts, diagnose a problem, or improve work you created. AI use must not replace your own analysis, implementation, decisions, or explanation.
You may use AI to:
- Ask for explanations of concepts, syntax, terminology, or error messages
- Ask for debugging strategies, test ideas, or ways to interpret output
- Review code, writing, diagrams, or designs that you created
- Generate small practice examples that you independently adapt and can explain
- Brainstorm approaches before making and documenting your own choices
You may not use AI to:
- Submit complete or substantially complete assignment answers, code, reports, diagrams, designs, or project features as your own work
- Paste AI-generated output without understanding, testing, and adapting it
- Bypass assignment requirements, course materials, templates, constraints, required styles, libraries, toolkits, or learning objectives
- Hide meaningful AI assistance
- Use AI where an assignment or assessment states that AI use is not permitted
When you use AI meaningfully, disclose the use in the location requested by the assignment. If no location is named, include the disclosure with the submitted work. Include the AI tool, what you asked it to help with, how its response influenced the work, and what you verified, changed, or implemented yourself. When citation is requested or appropriate, follow the NJIT Library AI citation guidance. Disclosure does not make prohibited use acceptable.
You must be able to explain, modify, test, and defend every part of your submitted work. Assignment-specific instructions may narrow or prohibit AI use and take priority over this general policy. Undisclosed or prohibited AI use may receive no credit for the affected work and may be handled under the NJIT Academic Integrity process.
For team work, broad AI-generated codebase changes, especially changes that overwrite another student's work, receive no credit for the affected feature or assignment. Failure to clearly disclose meaningful AI use within this policy's constraints results in a zero for the entire assignment.
The required course templates, lesson code, style, libraries, and project structure still apply when applicable.
Requesting Accommodations
Students who need accommodations due to a disability should contact the Office of Accessibility Resources and Services (OARS) to discuss their needs. A Letter of Accommodation Eligibility from OARS is required before accommodations can be applied.
Religious Observance
Students who expect a course conflict because of a religious observance must complete the accommodation form described in the NJIT Policy on Student Absences for Religious Observances and submit it to the Office of Inclusive Excellence by the end of the second week of class, but no later than two weeks before the anticipated absence. Properly documented absences will be excused without penalty, and students will receive an academically appropriate amount of time to complete missed work.
Resources For NJIT Students
NJIT provides student services including technical support:
Class Etiquette
Come prepared to participate, ask questions, and work respectfully with classmates and the instructor. Questions are encouraged because they make the class more useful and help address problems early.
Team Professionalism
Students are expected to maintain professional conduct. Disrespect, harassment, or abusive communication will not be tolerated.
This course requires team troubleshooting. If there is conflict within a team, troubleshooting the issue is part of the team's responsibility. Students should document concerns, communicate professionally, and contact the instructor early when team issues affect progress and cannot be resolved internally; evidence of attempted resolution will be required.
Students are expected to:
- Respect teammates
- Communicate effectively
- Troubleshoot team conflicts respectfully
- Adhere to NJIT's Code of Student Conduct
Students are responsible for checking Canvas regularly, reviewing each module's posted work, and keeping track of their own progress, deadlines, submissions, team responsibilities, and feedback.
Proctoring
NJIT policy requires midterm and final exams to be proctored regardless of delivery mode unless an assessment type is exempt. The midterm for this course will use Respondus LockDown Browser. Students are responsible for bringing a compatible device that meets the assessment requirements.
Late And Make-Up Policy
Deliverables may receive a 5% penalty per day late based on the posted due date. Canvas will automatically mark late or missing assignments as zero until grading is completed.
Assignments may also have a lock date. After the lock date, an exception is available only at the instructor's discretion and requires either a verified absence from the Office of the Dean of Students or an approved OARS accommodation.
Missed exams or quizzes will result in a zero. The instructor may, at their discretion, approve a make-up within a reasonable timeframe; a make-up requires either a verified absence from the Office of the Dean of Students or an approved OARS accommodation.
If you cannot submit an assignment or participate in scheduled course activity, contact the instructor as soon as possible. Emergency absence situations should go through the Office of the Dean of Students absence verification process. Submit supporting medical or other private documentation to the Office of the Dean of Students, not to the instructor.
Attendance Policy
Students are expected to participate in scheduled course work and complete quizzes, assignments, and project work by the posted deadlines. Attendance and participation count toward your grade as shown in the Grading Breakdown table.
Closing Notes
This syllabus is subject to change. Monitor Canvas and course communications to stay current.