Practical one

1. Create a new project

2. Project Scope and Milestones
Practical 2 Results

WHAT ARE THE STAGES OF A PROJECT LIFE CYCLE

A typical project life cycle consists of five main stages:

1. Initiation
o Define the project’s purpose, goals, and feasibility.
o Identify stakeholders and get project approval.
o Output: Project charter or approval document.
2. Planning
o Break down the work into tasks.
o Set timelines, budgets, and resource allocation.
o Identify risks and plan mitigations.
o Output: Project plan.
3. Execution
o Carry out the planned activities.
o Coordinate team members, allocate resources, and communicate progress.
o Output: Deliverables (e.g., software features).
4. Monitoring & Controlling
o Track project performance against the plan.
o Adjust schedules, budgets, or scope if needed.
o Ensure quality control.
o Output: Status reports, change requests.
5. Closure
o Finalize and deliver the project.
o Get client/stakeholder approval.
o Review lessons learned.
o Output: Final report, handover documents.

2. Project Proposal – Software Development Group Project

Introduction
Universities and colleges often face challenges in managing academic records, student registration,
course allocations, and administrative tasks. This project proposes the development of a Smart Campus
Management System – an all-in-one software solution to automate and streamline academic and
administrative processes.

Problem Statement
Currently, most campus operations rely on manual paperwork or fragmented systems, causing delays,
errors, and inefficiencies. Students face difficulties during course registration, payment confirmation,
 and timetable scheduling. Administrators spend excessive time handling routine tasks that could be
automated.

Project Objectives
1. Develop a secure web-based application for student registration, course management, and fee tracking.
2. Automate timetable scheduling and result computation.
3. Provide real-time notifications to students and staff.
4. Ensure data accuracy and easy retrieval through a central database.

Project Scope
The Smart Campus Management System will include:
• Student Module: Registration, course enrollment, payment tracking, profile updates.
• Admin Module: Manage student data, allocate courses, generate reports.
• Lecturer Module: Upload results, view course allocations, communicate with students.
• Notification System: Email/SMS alerts for important updates.
The system will be accessible via web browsers on PCs and mobile devices.

Methodology
We will adopt the Agile Development Methodology for iterative and flexible development.
• Requirement Gathering: Interviews with staff and students.
• Design: UI/UX wireframes and database schema.
• Development: HTML, CSS, JavaScript (frontend), Node.js (backend), MongoDB (database).
• Testing: Unit testing, integration testing, and user acceptance testing.
• Deployment: Hosting on a secure server with HTTPS.
• Maintenance: Regular updates and bug fixes.

Expected Deliverables
• Functional web application (Smart Campus Management System).
• User manuals for students, lecturers, and administrators.
• Technical documentation for future maintenance.

Timeline
Phase Duration Dates

Requirement Gathering 1 week Aug 18 – Aug 24

System Design 1 week Aug 25 – Aug 31

Development 4 weeks Sep 1 – Sep 28

Testing 2 weeks Sep 29 – Oct 12

Deployment & Training 1 week Oct 13 – Oct 19

 Resources Required
• Hardware: Laptops, server hosting space.
• Software: VS Code, Node.js, MongoDB, GitHub.
• Team: 1 project manager, 2 frontend developers, 2 backend developers, 1 tester.

9. Budget Estimate
Item Estimated Cost (₦)

Domain & Hosting 40,000

SMS/Email API 25,000

Miscellaneous 15,000

Total ₦80,000

Expected Benefits
• Faster and more efficient academic operations.
• Reduced human errors in record management.
• Improved communication between students and staff.
• Centralized and secure data storage.
 Practical 3

1. ANALYSE THE GROUP PROJECT REQUIREMENTS USING A RANGE OF TECHNIQUES

To gather and understand requirements for the Smart Campus Management System, multiple
requirement analysis techniques can be applied. This ensures the system reflects real needs and reduces
the risk of missing critical features.

Techniques Used

1. Interviews with Stakeholders

o Who: Students, lecturers, administrative staff.

o Purpose: Identify problems with the current system and desired features.

o Example: Asking the admin staff how they currently process course registration and what
improvements they expect.

2. Questionnaires/Surveys

o Who: Large number of students.

o Purpose: Collect quantitative data about common issues (e.g., payment confirmation
delays, timetable clashes).

3. Observation (Job Shadowing)

o Who: Registry and bursary staff.

o Purpose: Observe how tasks are currently performed to identify inefficiencies.

4. Document Analysis

o Sources: Current manual forms, spreadsheets, and databases used in registration and
results.

o Purpose: Understand existing workflows and data requirements.

5. Prototyping (Low-Fidelity Mockups)

o Purpose: Create simple UI sketches in Figma to visualize the system early, allowing
stakeholders to give feedback.

6. Brainstorming Sessions

o Participants: Project team and a few key users.

o Purpose: Generate creative ideas for features like a notification system, role-based
access, and automation.

7. Use Case Modelling

 o Purpose: Define step-by-step interactions between users (actors) and the system (e.g.,
“Student registers for a course”).

2. Requirements Document

Software Requirements Specification (SRS)

Project Title: Smart Campus Management System (SCMS)

Version: 1.0
Date: 15 August 2025

1. Introduction

The SCMS is designed to automate academic and administrative processes in a higher institution. It will
serve students, lecturers, and administrators by providing an integrated platform for registration,
payments, course management, result processing, and notifications.

2. Purpose

• Improve operational efficiency by replacing manual processes with a centralized, web-based

system.

• Ensure accuracy of records and ease of retrieval.

• Enhance communication between students and staff.

3. Scope

The system will provide:

• Student Module: Registration, course enrollment, payment tracking, profile updates.

• Lecturer Module: Course allocation view, result upload, communication tools.

• Admin Module: Student/lecturer management, timetable creation, report generation.

• Notification System: Email/SMS alerts for updates.

The system will be accessible via desktop and mobile devices with internet connection.
4. Functional Requirements

ID Requirement Description

FR1 Students can create accounts and log in securely.

FR2 Students can register for courses online.
FR3 Lecturers can upload grades for their courses.
FR4 Admins can generate and print student reports.
FR5 System sends notifications to users via email/SMS.
FR6 Admin can create, edit, and delete timetable schedules.

5. Non-Functional Requirements

ID Requirement Description

NFR1 The system should be accessible on desktop and mobile devices.

NFR2 The system should load within 3 seconds for standard broadband users.

NFR3 All data must be stored securely with encryption.

NFR4 The system should handle at least 500 concurrent users.

NFR5 The interface should be user-friendly and intuitive.

6. User Roles

• Student – Access to student dashboard, course registration, payment tracking.

• Lecturer – Upload grades, view allocations, communicate with students.

• Admin – Manage user accounts, approve payments, generate reports.

7. Assumptions

• Users have basic knowledge of computer and internet use.

• Institution has reliable internet for hosting and usage.

8. Constraints

• Budget is limited to ₦80,000 for hosting, domain, and APIs.

• Project completion timeline is 10 weeks.

9. Acceptance Criteria

• The system meets all functional requirements listed above.

• The system passes user acceptance testing by admin staff, lecturers, and a sample group of
students.

• No critical security issues remain before deployment.

 Practical four

Project Group Goals

1. Primary Goal

To design, develop, test, and deploy a Smart Campus Management System that automates student
registration, course management, payment tracking, timetable scheduling, result processing, and
notifications within the agreed 10-week timeframe.

2. Specific Goals

1. Requirement Gathering and Analysis

o Collect and document user needs from students, lecturers, and administrators using
interviews, surveys, and observations.

o Define the system’s functional and non-functional requirements clearly.

2. System Design

o Create user interface prototypes and database designs that meet stakeholder
expectations.

o Ensure design is scalable, responsive, and easy to navigate.

3. Software Development

o Implement frontend using React.js and backend using Node.js with Express.js.

o Integrate MongoDB for secure, scalable data storage.

o Build separate modules for students, lecturers, and administrators.

4. Testing and Quality Assurance

o Conduct unit, integration, and system testing to ensure software stability.

o Perform user acceptance testing with selected users before deployment.

5. Deployment and Training

o Deploy the system to a secure cloud hosting platform.

o Provide training materials and sessions for staff and students.

6. Project Management

o Use Agile Scrum methodology for progress tracking.

o Maintain weekly progress meetings and documentation updates.

7. Security and Data Protection

 o Implement HTTPS, encryption, and role-based access control to protect sensitive data.

o Ensure compliance with data privacy regulations.

Create your group project scheduling and cost estimate

Work schedule

Task Schedule

Cost Overview
 PRACTICAL FIVE

WORK BREAKDOWN STRUCRURE

 PRACTICAL SIX

Create Project estimate table for your group project

Project Time Estimate

Phase / Task Duration Start Date End Date

1. Initiation & Requirements 2 weeks 18 Aug 2025 29 Aug 2025

1.1 Stakeholder Identification 2 days 18 Aug 19 Aug

1.2 Requirements Elicitation (Interviews, Surveys) 4 days 20 Aug 25 Aug

1.3 Requirements Analysis & Specification (SRS) 3 days 26 Aug 28 Aug

1.4 Project Planning (Scope, WBS, Risk, Budget) 1 day 29 Aug 29 Aug

2. System Design 1.5 weeks 1 Sep 10 Sep

2.1 UI/UX Design (Wireframes, Prototypes) 3 days 1 Sep 3 Sep

2.2 Architecture & Database Design 4 days 4 Sep 9 Sep

2.3 Security Design 1 day 10 Sep 10 Sep

3. Implementation 4 weeks 11 Sep 8 Oct

3.1 Frontend Development (React) 10 days 11 Sep 24 Sep

3.2 Backend Development (Node.js/Express) 10 days 11 Sep 24 Sep

3.3 Database Setup & Integration 3 days 25 Sep 29 Sep

3.4 External Integrations (Email, SMS, Payment) 3 days 30 Sep 2 Oct

3.5 Module Integration (Full System) 4 days 3 Oct 8 Oct

4. Testing & QA 2 weeks 9 Oct 22 Oct

4.1 Test Planning & Test Data 2 days 9 Oct 10 Oct

4.2 Automated Testing 3 days 13 Oct 15 Oct

4.3 Manual Testing (Integration, UAT) 5 days 16 Oct 22 Oct

5. Deployment & Training 1 week 23 Oct 29 Oct

5.1 Deployment (Staging → Production) 2 days 23 Oct 24 Oct

5.2 User Training (Students, Lecturers, Admin) 3 days 27 Oct 29 Oct

 6. Post-Deployment Support 1 week 30 Oct 5 Nov

6.1 Hypercare & Bug Fixes 5 days 30 Oct 5 Nov

Total Estimated Project Duration: ~10 weeks

• Development-heavy period: 11 Sep – 8 Oct

• Testing & deployment: 9 Oct – 29 Oct

• Support period: 30 Oct – 5 Nov

 PRACTICAL SEVEN

PERT CHART FOR THE PROJECT

Critical path (computed from the durations & dependencies)

Using working days and the dependency graph above, the project duration = 54 days and the critical path
(zero float) is:

A → B → C → D → F → (H & I in parallel) → J → K → L → M → N → O

Because J must wait for both H and I, both are on the critical path.
Two equivalent critical path sequences (showing either parallel branch) are:

• A–B–C–D–F–H–J–K–L–M–N–O

• A–B–C–D–F–I–J–K–L–M–N–O

Slack / near-critical notes

• E (UI/UX Design) has ~1 day float (must finish before H to avoid delaying the critical path).

• G (Security Design) has large slack (it only needs to finish before Testing starts).
 PRACTICAL EIGHT

NETWORK DIAGRAM FOR THE PROJECT

 PRACTICAL NINE

1. RMMM Table

Risk Risk Probability Impact (I) Risk Mitigation Monitoring Management

ID Description (P) (₦ or Exposure Strategy Approach /
days) (RE = P × Contingency
I) Plan

R1 Delay in 0.4 5 days 2 days Schedule Track If delay

requirement meetings meeting exceeds 3
gathering early, send attendance days, escalate
due to reminders weekly to supervisor
unavailability and use
of email-based
stakeholders requirement
collection

R2 Key team 0.2 ₦50,000 ₦10,000 Cross-train Monitor Hire a

member (extra members health temporary
falling sick resource to handle updates freelancer if
during critical cost) multiple and illness >3 days
phase roles workload

R3 Technical 0.3 7 days 2.1 days Allocate Weekly Use

challenge in extra technical alternative
integrating research progress payment API
payment time review if delay >5
gateway before days
integration

R4 Scope creep 0.5 ₦80,000 ₦40,000 Clearly Monitor Negotiate

from define change new timeline
additional scope in requests or budget if
features contract weekly change is
requested by approved
client

R5 Server 0.1 3 days 0.3 days Use Monitor Switch to

downtime reliable server backup server
during hosting uptime if downtime
testing provider daily >12 hours
with
uptime SLA
 R6 Data loss due 0.15 ₦100,000 ₦15,000 Implement Monitor Restore from
to system (recovery daily backup logs latest backup
crash cost) backups weekly immediately

2. Risk Exposure Calculation

Formula:

Risk Exposure=Probability×Impact\text{Risk Exposure} = \text{Probability} \times \text{Impact}

Impact can be in days (time risk) or ₦ (cost risk), depending on what is affected.

Total Risk Exposure = Sum of all RE values:

• Time-based RE total = 2 + 2.1 + 0.3 = 4.4 days

• Cost-based RE total = ₦10,000 + ₦40,000 + ₦15,000 = ₦65,000

✅ This RMMM table gives a clear view of risks, preventive actions, monitoring, and contingency plans,
while the total exposure tells you how much time and money you should reasonably expect to buffer in
the plan.
PRACTICAL TEN