COMMERCE AND

COMPUTER COLLEGE OF
SOUTH AFRICA (PTY) LTD
Real World Project (RWP) – Software Development
<LEARNER MANAGEMANT SYSTEM!>

Abstract
The main goal of this project is to build an integrated framework to handle all
project activities

Hlengiwe Ntombikayise, Ndlovu

Email Address: hlengiwebhengu05@gmail.com
Student Number im2051bh:
 TABLE OF CONTENTS

Project Proposal 2

Use Case 4

Resource Needs 6
(Human, Hardware and Software)
QA/ Testing Plan 8

Work Breakdown Structure 12

Software Requirements Specification 14

Software Development Methodology 17

User Interface (UI) Screen Shots 18

Mobile Designs 23

Glossary 23

Bibliography 24
Project Proposal
Project Information: Learner Management System 1.0

Project Time Frame: 15/06/2022 – 20/12/2022

Summary: Multifunctional integrated Learner Management System that will be designed to keep
records, also used to update records kept of a particular subject. It will work as a database that will
hold learner’s academic results

Process Impact: This proposal will be used to motivation towards the approval of the project by the
supervisor and any other academic representative.

Background of LMS
Being an Information Technology student for many years It has come to my attention that several IT
and infrastructure based problems precisely the implementation of a proper information
management system which is fully integrated with organizational and national regulations.

Many Private training institutions and practitioners tend to have challenges instead of meeting new
or make rules with inadequate support provided by the relevant infrastructure. The LDMS (learner
database management system) should be designed to be provided across all platforms with
integration services such as the hosting of online examinations, statistical analysis and reporting,
financial services and facilitator reporting services amongst others.

Current Systems
Currently the institutions (FET/HET) are using software handling learner academic data and learner
financial data with no integration between the both. The LDMS will attempt to combine these to
pivotal services into a single application that will provide better decision making.

*SETA’s and CHE (Council of Higher Education) have outsourced their annual reporting services
hence minimizing customer support and response times due to redirection for support services. This
results in latencies and delays in task completion. The current practices do not integrate learner data
provided by institutions via annual reports to that provided by such institutions on the NLRD
(National Learner Records Database), neither does it provide easy verification of programme
accreditation details.

AIM of the project

To develop an easy to use, integrated educational management system that supports both
organizational and national regulations.
Defining Features
- Assessment / Online Examinations with easy uploads from learner using mobile devices or
from their laptops/PCs.
- Financial Integration that will work to hand-in hand-out with S.A.F practices and it will be
fully tested by an auditor.
- Accreditation Integration that supports both FET (Further Education and Training) and HET
(Higher Education and Training) regulations.
- Mobile communication to a central database server (SQL/MySQL) for easy reporting and
uploading to the Questions bank.

Scope
- The application will focus on providing a complete learner management system that
connects facilitators and management to help enforce organizational and national
regulations and reporting practices.
- The software will allow easy reporting and uploading of assessment questions and reports.
- Provided across all platform.
- Allow facilitators access it via mobile apps.
- login security will be implemented.
- Provide secured communication path to the central database.
- Provide accreditation information via easy web links and updated accreditation information.

Deliverables of the project

- Customizable educational management system aligned

to national and organizational requirements.
- Guide/Reference Manual. - Mobile App.

Risks of the project

- Rapidly changing governmental regulations may pose a difficult task to support.

- Opposition from governmental officials and organizations in support of such an application.
- Technical and compatibility difficulties between various devices

- Meeting the time-scale to complete the various functional points or services mentioned.

Rewards of the project

- Should I accomplish this task I would have developed a fully functional and integrated
software that will be highly marketable and useful product across various Private FET and
HET institutions. This can result in revenue and the migration of the sector to such a system.
Learner Management System

Use Case Diagrams

Personal Data

New account

Secondary Admin
Search

Main Admin Ammend Account

Student
Data Import/Export
iImport/Export

Academic Info

Search Student

manually
Capture Marks
Main Admin

Generate Reports

Read-only
Read-only
View Academic Info

Export Data Student

Secondary Admin
Auto Update
 Examination

Student exam admission

System Login

Main Admin Manage Exam

\ Manage Question Bank

Student

Examination

Lecturer
Generate Reports

Financials

Login

Manage Financial
data/Transaction
s Read-only
Generate Financial
Student
Clerk report

Export Data
 Learner Management System - Resource Needs
Project Information – Learner Management System
Project: Learner Management System (LMS)
Internal Release Number:
1.0
Project Time-frame:
08/06/2022 – 08/08/2022
Related Documents:
Project proposal
Software development methodology, Glossary

Process impact: Based on the project plan and the worksheet below, this project will need the following
resources to meet its goals. If fewer resources are available, the scope of the release should be reconsidered or
the process must be changed.

Human Resources
Needs
Needs Resources Amount Status Comments/Responsibilities
hours
Project Manager Mrs Ndlovu 15 Assigned Oversee the development
process
Consultation with topic Mr Mkhize 5 Assigned
experts of similar
systems
Training on use of Mrs Ntuli/ 10 Assigned Mrs Ntuli an expert in API usage
component/technology
Mr Mkhize will help by teaching integration
methods
Overall Design Mrs Ntuli 15 Assigned Self-Development with the
overall design reviewed by the
Project Manager
Detailed UI Design Mr Mkhize 15 Assigned
Detailed Database Ms Dlamini 10 Assigned SQL foundation with cross
Design
platform integration with
database systems
Development Mrs Ndlovu 35 Assigned
Technical writing Njabulo 10 Assigned
QA Planning Mr Mkhize 5 Assigned
QA/Defects Testing Mrs Ntuli 5 Assigned Subject Matter Expert and an
administrator to conduct testing
 Technical
Resources Needs
Needs Resources Amount Status Comments

Training material Android and 2 Satisfied Online

VB.net books
Workstation(s) CPU i3 ,500GB , 3 Satisfied Developers will use current
4GB Ram systems
DB Server CPU i3 , 500 GB , 1 Provided DB Server will be developed on
4GB Ram the same machines
Server Name :
HLERH_DB
Load Test Server CPU i4, 360gb HDD, 1 Pending
4GB Ram
ServerName: Hlerh
Load Test Clients 1.3ghz CPU, 180GB 1 Satisfied QA agents will use the same
HDD, 2GB machine for testing.
Ram
IDE Licences Standard N/A Satisfied Utilise open source tools where
development licenses possible. Purchased VB.net
suite/SDK
SCM Licences Standard N/A Satisfied Utilise use open source tools
development licenses

Testing Tool Standard N/A Satisfied Utilise open source tools where
development licenses possible
Licenses
Coding Language VB.net, C# and Java 1 Satisfied Purchased
(s)
Software VB.Net and Android 1 Satisfied Purchased
Plug ins
Development
Environment
Learner Management System - QA/ Testing Plan
Release Information – Quality Assurance Plan

Project: Learner Management System (LMS)

Internal Release 1.0
Number:
Release Audience: Customer-specific release: Nominated Training Centre/Person for Testing
Developer release (Internal usage only for testing)

Attached Worksheets:
Related Documents: Software Requirements Specification
Design
Project plan
Software development methodology

Process impact: This document specifies quality goals, selects strategies for assuring that those goals have
been met, and details a plan of action to carry out those strategies.

Introduction
Why is this QA plan needed?
"Quality" refers to all the good effects that I would like to see in my product. I have to
develop a quality product and ensure that it is of high quality by keeping quality as a key
factor all the time and performing the selected activities below. Testing is one QA activity,
but it is not the best or only one, other QA activities include the use of style guides and
checklists, review meetings, use of analysis tools, and careful quality measurements and
estimates. A plan is needed to select and coordinate all the QA activities.
What QA lessons were learned in previous
releases? None as yet. This is the first edition
release.

What is the scope of this QA plan?

The major components and aspects of the system will be evaluated in this release.
I will focus on the following Components/Modules:

• Personal Data
• Academic Data
• Examination Module
• User Portal

What is the summary of this plan?

In this release I will utilise the development approaches that support all of my quality goals,
but I will focus on functional correctness and robustness of each component. I will achieve
this by undertaking the following activities:

• using statements to test preconditions and error statements to test blocks of codes
• conducting frequent reviews of source codes including desk checking of functional
blocks of code
• database and interface testing as per functional area or module

Quality Goals for the Beta Release

• Essential
• Correctness (Semantic and Syntax)
• Robustness (Stability of the software)
• Expected
• Accuracy
• Compatibility

o Semantic and Syntax correctness

o Understand ability and Readability
o Learnability and Memorability
o Security and restricted access to
sensitive data
o Efficiency
o Consistency and Familiarity
• Desired
• o Consistency under load
• o Consistency under concurrency
o Availability under load
o Longevity
o Efficiency
o Scalability
o Performance under load
o Large data volume
o Interoperability with cross
platforms essentially mobile
devices
o Easy to use and understand
o Adaptability to changes in
market and legislation
o Testability
 Quality
Assurance
Activity Coverage Description

Preconditions Every method in each component Utilise if-statements at the beginning of

All public methods that modify data public methods to validate each argument
value. Helps to document assumptions and
catch invalid values before they can cause
faults.

Automated 100% of UI The QA team will utilise the system test

system testing screens and fields automation tool to write and maintain a
100% of specified requirements suite of test scripts to test the entire
system through the user interface.
Regression Run all unit tests before each commit I will adopt a policy of frequently running
testing Run all unit tests all automated tests, including those that
have previously been successful. This will
help catch regressions.
Buddy review All changes to each component Whenever changes must be made to code
All changes the change will be reviewed by another
developer before it is committed. The goal
is to ensure that fixes do not introduce new
defects.
Static analysis Strict compiler warnings I will utilise source code analysis tools to
Detect common errors automatically detect errors. Generally,
those that allow testing on the VB.net and
the Android frameworks.

Unit testing Methods and Statements We will develop and maintain a unit test
suite using the Junit/NUint framework.

Also utilise TypeMock to test unit codes.

Assertions Every private method in each Assertions will be used to verify all
component arguments to private methods. Since these
All private methods that modify data methods are only called from our other
methods, arguments passed to them should
always be considered true, unless our code
is defective. Assertions will also be used to
test class invariants and some post
conditions.
 QA
Evaluations
Goal Preconditions Buddy Unit Manual Overall assurance
review testing system
testing
Functionality Medium Medium Low Medium Strong

Correctness High Medium Medium High Weak

Robustness Medium Medium Low Low Strong

Usability High Medium Low High Weak

Security Medium Low Low Medium Strong

Reliability Medium High Medium Low Weak

Efficiency Medium None Medium Low At-Risk

Reliability none High Low High Weak

Efficiency Low Medium High Medium Weak

Scalability None Medium Medium High Strong

Interoperability Low None Medium High At-Risk

Maintainability Medium Low Medium Low Strong

 High: This activity gives a strong assurance that the goal has been met in development.
 Medium: This activity gives a medium assurance that the goal has been met in development.
 Low: This activity gives only a little assurance that the goal has been met in development.
 None: This activity does not address the goal.

 Strong: The set of activities together provide strong assurance that the goal has been met in
development.

 Weak: The activities together provide limited assurance that the goal has been met in development.
 At-Risk: There is little or no assurance that this goal has been met.
Project Plan - Work Breakdown Structures

Step Description Estimate

1. Preparation

1.1 Developer training 40h

2. Inception

2.1 Requirements gathering 40h

2.2 Requirements specification 20h

2.3 Requirements validation 10h

3. Elaboration

3.1 High-level design 25h

3.2 Low-level design (break down by component) 15h

3.2A Object design 10h

3.2B User interface design 20h

3.2C Database design 10h

3.3 Design review and evaluation 20h

4. Construction

4.1A System implementation/Development 10h

4.1.A.1 Implement/Develop PersonalData 20h

4.1.A.2 Implement/Develop AcademicData 10h

4.1.A.3 Implement/Develop FinancialData 10h

4.1.A.4 Implement/Develop ExamModule 10h

4.1.A.5 Integrate Components 15h

(mostly done during component
implementation)

4.1B Technical documentation (break down by 10h

component)
 4.1C User documentation (break down by 35h
component)

4.1D Testing 40h

4.1.D.1 Test planning 15h

4.1.D.2 Test code implementation (break down by 20h

component)

4.1.D.3 Test execution 25h

4.2 Implementation review and evaluation 20h

5. Transition

5A Release packaging 7h

5B Documentation for other groups 7h

6. Reflection

6.1 Postmortem report 15h

Total 479h
Software Requirements Specification (SRS)
Project: Learner Management System
Internal Release
Version 1.0
Number:
Attached worksheets:
Related Documents: Project proposal
Glossary

Process impact: The SRS specifically defines the software product that will be developed. Decisions made in
writing the SRS are based on information in the project proposal and needs documents. The SRS sets
requirements that must be satisfied by the system design. The SRS is verified and validated by activities
outlined in the QA plan.
Introduction

Being a part/a student of the South African education sector for many years I have had experience
with several IT and infrastructure based problems shared by educators and others. Problems lie in
the implementation of a proper information management system that provides easy integration and
compliance with organizational and national regulations.

Many private training centres and practitioners tend to have problems in respect of meeting new or
established regulations with inadequate support provided by the relevant structures. The LMS
(learner management system) will be designed to provide cross platform interoperability with
learner integration services such as the hosting of online examinations, online libraries, statistical
analysis and reporting, financial services and facilitator reporting services amongst others.
User Needs
The initial project requirement was to provide a simple fully integrated and easy to use application
that allows users to access information readily in terms of organizational requirements.
After much review all stakeholders fully agreed on the need for transparency in the software to help
ensure its integrity. The need was further made bigger for possible integration with national
requirements and reporting structures to help reduce administrative workloads and human error. It
was agreed on to having the product interface or interact with mobile devices and services.
The physical requirements of the system include a dedicated SQL Server that provides 24x7
controlled access. A secondary SQL server will be setup to provide load balancing and fault-
tolerance. The servers will sit in a DMZ behind a firewall and authentication server running at
minimum Microsoft Windows Server 2000 with Active Directory.
Most users to the system will be from their laptops or desktops however the application should be
able to run on hand held devices (mobile).
 Functional Points/Requirements
The primary functional requirements of the proposed project/software include the feature(s):

Module1: Student Biographical Data

F101: Student
Registration
F102: View Student
Profile
F103: Edit Student Profile
F104: Import Images and scans
F105: Export to Excel for EDUDex import to HEQCIS and NRLD (National Records Learner
Database)
F106: Print Profile information

Module 2: Examination/Assessment Management

F201: Register an Examination to obtain authorization code
F202: View Examination schedules or timetables
F203: Edit an Examination Booking
F204: Access the Question bank
F205: Upload or Append questions to the Question Bank (QB)
F206: Link and monitor live examinations
F207: Backup and restore features

Module3: Student Academic Data

F301: Search for Student by name, ID or Student Number
F302: Generate Academic Reports {passed, failed, comprehensive}
F303: View Academic progress
F304: Provide feedback on results {Assessor or Moderator feedback}

Module4: Lecturer Teaching and Reporting

F401: Register an Academic Staff Member
F402: Append Registration Details and level of Access
F403: Upload teaching plans and progress reports
F404: View latest teaching and learning policies and regulations
F405: Upload weekly OHS, Academic and Technical reports

Module5: Financial Data

F501: Search for Student by name, ID or student number
F502: Create or append Student invoices (Qualification, apparel, books, student cards etc)
F503: Create or append payment entries
F504: Generate Financial Reports (Daily, 3 months, 12 months
etc)

Non -Functional Requirements

Usability requirements?
The ease of use of the software will sorely depend on the UI guidelines and layout of popular applications. I
will maintain common interfaces where possible. Drop-down lists, toolbar options and other controls in order
to allow faster and easier interaction with the software will be employed.
Reducing the number of events, a user has to undergo in order to execute a task will also be one of the
primary methods in promoting usability and it will also reduce human error.

The software will include an online help feature and tool tips for support.

Security requirements?

• Access will be controlled with usernames and passwords (Login).

Details of Passwords:

Passwords must be 8-18 characters long

Passwords must be alphanumeric

• Only administrators will have access to administrative functions, typical users will not.
Details of Restrictions:
Only Administrators will be able to append Student results.

Only Administrators will be able to append Lecturer submissions or reports

Maintainability and upgradability requirements?

Maintainability the ability to make changes to the product over time. I would need a high degree of
maintainability in order to retain early customers. This will be addressed by anticipating several types of
changes, and by carefully documenting the design and implementation thereof.

Upgradability is the ability to cost-effectively deploy new versions of the product to customers with minimal
downtime or disruption. A key feature supporting this goal is automatic download of patches and upgrade of
the enduser's machine. Also, I shall use data file formats that include enough meta-data to allow us to reliably
transform existing customer data during an upgrade.

Learner Management System – Software Development Methodology

The Software development methodology chosen will be the Rapid Application Development
approach. The motivation behind the RAD it is speed and cost effectiveness in delivering a useable
prototype. RAD allows the software to be broken into smaller more manageable
components/segments. This will allow for quick and proper testing of the segment without
concentrating on the others.

The entire approach will encapsulate the iterative framework of development with feedback from
the client contributing to its development. This approach allows each component to focus on the
business needs more accurately promoting a Joint Application Development Approach by
concentrating on essential system elements from the user viewpoint.

The following diagram illustrates the RAD Development Cycle

Drawbacks of this methodology:

- It can result in too many requirements from the user/client perspective limiting the time
required to complete the entire project.
- Due to the Rapid approach the product could miss a few of the business requirements.
- Speed of the project could lower the quality of the product.
User Interface (UI) Screen Shots

Log in: img 1

Main Menu: Img 2

 Add Student: Img3

Search Student: Img4

Examination: Img5
Financial Info: Img6
Glossary

QA Quality Assurance

RAD Rapid Application

Development
RTF Rich Text Format

UI User Interface
Bibliography

1. Brock S, Hendricks D, Linnell S, & Smith D. (2003). A balanced approach to IT project

management. Proceedings of the 2003 Annual Research Conference of the South African
Institute of Computer Scientists and Information Technologists on Enablement through
Technology (pp. 2-10).
2. Du, S. M. Johnson, & Kiel M. (2004). Project management courses in IS graduate programs:
What is being taught?, Journal of Information Systems Education, 15(2), 181-187.
3. Stuart Palmer., (2005). An Evaluation of On-Line Assignment Submission, marking and
Return, University of Melbourne 34(2), 57-67.
4. Ellen, N., & West J., (2003). Classroom management of project management: A review of
approaches to managing a student’s information system project development. Journal of
American Academy of Business, 3(1/2), 93-97.
5. William ibbs C., Young hoon kwak., (2000). Assessing project management maturity, The
George Washington University, School of Business and Public Management, Department of
Management Science volume 31(1), 32-43.
6. ] Subversion version control: using the Subversion version control system in development
projects / William Nagel, Upper Saddle River (N.J.): Prentice Hall/PTR, c2005
7. Systems Analysis and Design Shelly Cashman Adamski Boston 1991
8. Software Engineering Roger S.Pressman UK, c2000, 5th Ed.