CHAPTER I
1 PROJECT BACKGROUND
Introduction
Nowadays because of technology rapid changes. Companies, schools
and universities wanted to adapt in to it. Not because they want to go behind the
rapid changes but because they want to make a better production in a stress-free
way.
The Faculty Loading Scheduling provides the ability to analyze and report
faculty load correspond the contract requirements. Scheduling is a challenging
mission since many processes requires accomplishing the formula a faculty
schedule need edit also desirable desired to ensure each phases you will made
to be accurate and acceptable. At the same time computing the entirety faculty
workloads as well as better than the demands in manual process. Some of the
problems to be resolved by researcher.
1.1
Problem/Opportunity Description

Redundancy of Faculty Schedule
Having similar schedule of different instructor/faculty member and having
similar loading in the same time but different room vice versa. Difficulty to
identify whether the instructor obtain schedule.

Difficulty to locate schedules available
It is hard to identify the vacant and occupied lecture room and laboratory.

Can’t filter the needed information
As a result of manual process it provides a slow transaction to present any
report, giving a wrong and unsecured report to the faculty member.

Computations of total workloads
Difficult to compute the entirety workload of faculty member and it is a
challenge to identify if the professor/faculty member consumed overload,
and also, manual process computation of loads consumed extended
procedures, tardiness and uncertain.

Can’t Manage immediate faculty Request
Time consuming procedures to provide rooms/spaces for events and
remedial classes.
1.2
Benefits
 Faculty
Having Faculty loading Scheduling make possible to each faculty
member get their schedule as soon as possible and otherwise faculty can
also use the mobile FLS application and using android phone, each are
faculty able to view the respective schedule if the admin released the
faculty schedule, using this mobile application each faculty member make
a request for remedial class and school event.

Administrator
Having Faculty loading Scheduling the administrator reduced the
tiredness to creating schedules, computations of total workloads and
provides a schedule to faculty. Give concentration to operate additional
task. Schedule can effortlessly to monitor, check the data without any
additional difficulties and easy to monitor all transaction done by the
different department t using the audit trails.

Proponents
This study will help the proponents develop further his capabilities,
skills, and enhance team to practice communicate, cooperate and explore
knowledge in IT related project/systems.

New Researcher
This study will help to new researcher, it helps us because they
obtain some information they can use in their studies. Although not
a large amount of information presented but its help the new
researcher
to
build
their
plans
and
ideas.
Using
these
documentations will become a guideline to each member of the
new researcher to make their study valuable.
1.3
Goals
To create Faculty Loading and Scheduling an automated “FLS
System” that can operate the transaction and produces functional report
for Faculty Loading Scheduling. The specific objective is to improve
services that can quickly provide schedule to each member of the faculty
members and to load subjects to a faculty, automated computation of total
work load and unit of each faculty member. Easy to research the school
year history, dismiss the redundancy, easy to monitor the vacant and
occupied rooms that haven’t yet scheduled.
1.4
Stakeholders

Client
The client will supply the needed information for the software
development and client provides significant information to construct plans
and ideas each team provides client flow or business process to build a
great project.

Employees
Are the one who will give the needed interface changes?
An employee is one of the most important people to build software
development; employee is participant of surveys, interviews conducted by
teams. This is one helpful resource for project.
The proponents are the people who are responsible for this project.

Adviser
One who will give the approval if the project has the satisfaction
rate and inspire each team make a successful project advisers offer
several method and techniques to build an exceptional and presentable
project
2 PROJECT SCOPE
2.1 Objectives
Rapid changes of technology today, it is merely impossible to run an
effective business without the help of technology. Technology is being utilized
not just to have an accurate output, but to make processes rapidly done.
Having an automated ’Faculty Loading Scheduling can be the way to the
systematized scheduling of a faculty.

Loading – the number of subject and calculation of units to be assigned to
each faculty.

Scheduling – the arrangement of time and room to a faculty given by the
administrators
2.2 Deliverables
Objective 1 – Loading
Project Deliverable
Work Products/Description
Full-time
Maximum of 30 units for each faculty
Part-time
Maximum of 12 units for each faculty
Regular
regular faculty have assigned position in
school but he/she have ability to choose
whether her desire to teach
Objective2 – Scheduling
Project Deliverable
Work Products/Description
Administrators
Division of a larger organization into parts with
specific responsibility
Subject
Subject matter, assigned time and room for
each faculty by the administrators
Course
A unit of instruction lasting one academic term
2.3 Out of Scope
As the title itself FACULTY LOADING SCHEDULING, this proposed system
contain the purpose of loading subjects and give faculty scheduling. The
following are the out of scope, but may affect this proposed system.

Faculty monitoring

Faculty profiling

Faculty evaluation

Deactivate and activate of a faculty

Student Sectioning
3 PROJECT PLAN
Methodology Used
The proponents made the project proposal possible must categorized with 3
(three) parts; Data Gathering, Development and Testing to plan and manage
the systems development process. It also describes activities and functions
that proponents typically perform, regardless of how those activities and
functions fit into a particular methodology.
Data Gathering
During this phase, the proponents found the reasons why the system
should be done and how will it be made through visiting sites and
borrowing books from different libraries to gain information for the
appropriate construction of the system study. Also, the proponents
determined which colleges and universities will be benefited for the
Faculty Loading Scheduling System, which is the college and
university can be used, and how the system will improve the
company’s operation and performance. Estimating the time and cost
benefits that will be used are also considered in planning better
perspective of the system development and the proponents identify
and describe all the system requirements needed. It involves the
possible features that the system can provide such as output, input,
process, performance and control. The interview conducted in different
school obtained information and ideas that the proponents used for the
development of the program, especially the documents gathered from
the schools and university that served as a basis to make reports.
The study used questionnaires and surveys to collect data and
information that are necessary for the system. To be able to know
whether the system met its objective, the proponents conducted a
survey to fit selected respondents who those staff and administrators
from a different colleges and university having knowledge in faculty
loading scheduling. To keep the record of interviews, facts, ideas and
observations for documentation, the proponents used different
software tools such as Ms Word and etc.
Development
The design phase is and it involves the creation and design of the
system. The proponents used Java Netbeans as a tool in developing
the system’s GUI and MySql as a tool for database design and Mysql
workbench that serves as a server to the database and mobile
application for extension and requirement for the project study. The
Faculty Loading Scheduling System was developed using the basic
concept of SDLC and it took a few months to develop the software.
The proponents used The Faculty Loading Scheduling System
contained with different features such as system security, faculty
member schedule monitoring, faculty information & reports. The
system
is
design
to
provide
faster
accessibility
for
the
administration/user.
Testing
In this phase, the proponents are supposed to be ready to present The
Faculty Loading Scheduling System to the responsible individuals who
are involved in developing the system software. Making sure that the
system provides better performance than the manual process, the
proponents asked some IT professors that can be great help in finding
flaws in the system and might as well suggest for improvement and
revisions if there’s any. Some employees were also chosen to evaluate
the system.
Right now, the proponent assumes that the system can be used as a
replacement for the manual process. Also, this phase is the longest
phase as it has no defined endpoint, with the exception of the end of
the system and its users.
The system is ready for any operation
support and maintenance that will be applicable for anyone including
those who have a little knowledge about the system. The proponents
provide backup and recovery maintenance that are already included in
the system. The required periodic maintenance activities are allowed
with/without the permission of the original proponents and can be
repaired or improved by any computer technicians/programmers.
3.2
Project
Timeline
Risk Factor
Employee Risks
Probability Impact
(H-M-L)
(H-M-L)
H
H
Risk Management Action
The proponents should monitor the
technology to be used
Process Risk
M
M
The
proponents
should
know
the
objectives and communicate with the
clients.
Product Size
L
l
The proponents be supposed to make
a contribution
Development
H
H
Risk
The proponents should be prepared
with rapid changes and make an
advance decision plan.
Customer Risk
H
H
The proponents should monitor the
technology to be used
Technology Risk
M
M
The
proponents
should
know
the
objectives and communicate with the
clients.
Business Impact
L
l
The proponents be supposed to make
a contribution
3.3 Success Criteria
This project will be considered as a successful one if all of the following is met.
 Meet the objectives
 Project team satisfaction
 Project team’s budget is below or on target
 Meet the deadline
3.4 Issue and Policy Implications
Faculty loading and schedules
It consists of distributing a faculty schedule and their workloads. The proponents
desired to get needed faculty member data to Human Resources System their
personal information, specialization of the faculty member and Curriculum
System for the subject and other activities to meet the needs of the system. But
the proponents don’t have permission to make changes in data from a different
team. To avoid this problem make certain assurance to those different teams
provides the needed information to proceeds transaction.
3.5 Risk Management Plan

Employee Risks

Process Risk

Product Size

Development Risk

Customer Risk

Technology Risk

Business Impact
3.6 Option Analysis
The PEC suggests using MS SQL in developing the system, but the proponents
decided to use MySQL as another option in which the proponents can is easy to
use and it operates very fast the prescribed system and its Open Source, It is
free and can be used by anyone without any license or permission Easy, Fast
and High Performing, Cross Platform compatibility of MySQL is another
advantage. It can be installed in all major Operating Systems as UNIX, Solaris,
and LINUX in addition to Windows without a loss of performance.
Data security in an utmost necessity. MySQL secures the stored data. This
makes this database system safe and reliable as in popular cloud solutions.
4 TECHNICAL FEATURES
Security
For the security of the proposed system the proponent make sure
na may
siguredad ang systema sa pammagitan ng pag lalagay ng User name at
password for the identity ng bawat user na log-in, Only 3 user can acces the
system, admin , department head of any courses. School Staff. Masasagawa
ang pag subabay (Monitor ) sa bawat User, Transaction done of the user having
Audit Trail the admin can only acces the audit Trail
Testing
For testing of the software development with the help of respective advicers and
surveys, we asked for suggestions regarding to this project study if what will be
improved. Using the tools and skills of each team member, the software will be
successfully test. This includes the motivation of each member and the goal to a better
future.
Deployment of Project
The proponents used Java Netbeans as a tool in developing the system’s
GUI and MySql as a tool for database design and Mysql that serves as a server
to the database and mobile application for extension and requirement for the
project study.
5 PROJECT ORGANIZATIONS AND STAFFING
ROLE
NAME AND
RESPONSIBILITIES
CONTACT INFORMATION
Project Manager

Have
the
responsibility
of
the
planning, execution and closing the project

Have the responsibility to handle the
team.
Business
Analyst

Who is analyzing the existing or ideal
organization,
including
businesses,
department and organization
System Analyst

Lead Programmer

His responsibilities are designing and
creating
the
architecture
ensuring
that
software project comes on time.
Document
Specialist

Her work is reviewing, analyzing and
typing the current documentation of the
project.
6 PROJECT BUDGET
Budget Item
Description
Budget Cost
Manual
For reference
₱1,500.00
Interview
Gathering information
₱ 300.00
Mock Defense
Defend
One-time Costs
the
proposed ₱ 5,000.00
system
Total One-time Costs= ₱ 6,800.00
On-going Costs
Broadband Load
For internet
₱ 3,000.00
Foods
For the proponents/panels
₱ 2,000.00
Transformations
For travel
₱ 1,500.00
Total On-going Costs= ₱6,500.00
CHAPTER II
2.0 INTRODUCTION
This chapter introduces the content to the review of Related Studies of the
proposed system. This includes all the Faculty Loading Scheduling (FLS) related
information. It describes the previous works done by different researches.
Review of Related Literature is a foreign and local literature that has been done
by successful researchers and IT pioneers. Review of the Related Studies is a
foreign and local studies that has been done can by previous researchers who
has developed the other schools and other researchers who conducted studies
of the said system. By this, the group can be guided in developing the same
system which is needed to be polished and to be more enhanced.
2.1RELATED STUDIES
2.1.1 Foreign Studies
Montclair State University
According to Article XII of the State Master Contract of MSU, the
basic academic year teaching load is 24 teaching credit hours. All
overloads are voluntary, and overload rates are paid for all voluntary
teaching assignments beyond 24 teaching credit hours. No faculty
member may be assigned more than 15 teaching credit hours per
semester within load. A teaching assignment may not require more than
three different course preparations in any semester. Voluntary teaching
assignments for extra compensation in any academic year shall not
exceed 6 semester hours or 2 courses, whichever is greater. This applies
to normal semesters only, not to summer or any intersession. Overload
compensation is negotiable and the amount is delineated under Article XII
of the State Master Contract.
Teaching load may not exceed six semester hours during the
May/June six-week period ending June 30. Also, faculty teaching load is
limited to one (1) three-semester-hour course taught in the three-week
pre-session or one (1) four-semester-hour course taught in the four-week
pre-session during May/June and one (1) three-semester-hour course
taught in the three-week post-session in August.
In addition, up to four courses may be taught, to a maximum of ten
(10) semester hours within the four-course limitation, over any
combination of the remaining sessions that extend beyond the May/June
six-week period ending June 30. No more than five (5) semester hours
may be taught within any four-week session.
Source:
http://www.montclair.edu/provost/faculty-handbook/personnel/facultyload/#top
North-eastern State University
According to NSU, full-time faculty have instructional and noninstructional duties as assigned by the University. Instructional duties
include but are not limited to the teaching of assigned classes, evaluating
the students in the classes, and meeting with those students who require
assistance in their classes. Non-instructional duties include but are not
limited to conducting research and other scholarly activity, advising
students,
serving
on
committees,
sponsoring
organizations,
and
participating in professional organizations. A full-time faculty member
should generally carry an instructional load of twelve (12) to thirteen and
one-half (13.5) hours per semester and a non-instructional equivalent load
of four and one-half (4.5) to six (6) hours per semester so the full-time load
would be the equivalent of eighteen (18) hours per semester. (RUSO,
3.1.7)
Each full time, the teaching faculty member is expected to keep
eight (8) office hours per week during regular semesters and five (5) per
week in the summer term. Office hours are times set aside for faculty
members to communicate with students, advisees, and colleagues as well
as completing administrative duties. For classes that meet once per week,
it is highly recommended that one of the office hours be scheduled before
or after that class on the campus where the class is held. At least one of
these hours shall be scheduled each weekday that faculty have teaching
responsibilities unless University commitments off campus prohibit it.
Exceptions must be approved by department chairs. Part-time faculty, or
full-time faculty with University obligations other than teaching, will keep a
number of office hours proportional to their teaching load. Faculty teaching
online classes may maintain a proportional amount of their required office
hours online. To qualify as an online office hour faculty must be
immediately available to their students at a regularly scheduled time.
Faculty with reassigned time from teaching provided through a NSU
Faculty Research Grant are full-time and, hence, will maintain the hours
indicated above, but may be authorized to maintain a more flexible weekly
schedule. Once a faculty member has established an office hour schedule
for a semester, s/he will send the schedule to his/her dean who will
forward the information to the Provost/Vice President for Academic Affairs.
Faculty who are assigned as resident status at Broken Arrow or Muskogee
campus will also send one copy of their office hour card to the respective
campus academic affairs/administrative office. (Approved by Faculty
Council, April 3, 2009; approved by Dalton Bigbee, VPAA).
Source:
http://offices.nsuok.edu/academicaffairs/FacultyHandbook/40FullTimeFac
ultyWorkLoad.aspx
North Carolina State University
According to NCSU, the administration uses CAL FTE to examine
relative teaching loads between departments and to redress situations
where there are imbalances. The CAL FTE for each academic unit is
divided by a university wide constant that normalizes this weighted sum for
the University to the budgeted FTE that is computed as discussed
previously. For the two semesters of 1992, the constant ranged between
330 and 430. Note that CAL FTE acknowledges the significant faculty time
commitment required for graduate education.
Faculty appointments adhere to the criteria for appointment that
are given in the NCSU Faculty Handbook. The fall 1992 Office of Civil
Rights report (by the Provost's Office) of faculty qualifications shows that
of instructional faculty (tenure-track only) 1,326 faculty members (97
percent) hold the terminal degree and 3 percent hold other degrees.
Clearly, the University seeks to appoint faculty members with the highest
degree of academic achievement and potential for teaching and
continuing academic achievement. An examination of the curriculum vitae
of faculty shows that the faculty is distinguished by members who are
nationally and internationally recognized. Honors and citations of faculty
members' work abound, as would be expected in an institution with
graduate programs.
The initial responsibility for recommendations regarding selection of
faculty rests with the University's academic departments. In addition to
outlining University requirements, the NCSU Faculty Handbook prescribes
duties of department heads with respect to personnel criteria and
procedures: "All department heads shall review for their faculty at least
once each year all criteria and procedures which do or may affect
departmental personnel actions. In the event there are or may come to be
criteria or procedures affecting personnel recommendations used in a
department or college, which are in addition to University policies and
procedures, these shall be in writing, as approved by the Dean and the
Provost, with copies available to all faculty members concerned"
Source: http://www.ncsu.edu/ncsu/univ_eval/ch08/a8facult_p1.html
City College of New York
According to CCNY, new untenured faculty hired on September 1,
2006 or later must be released from 24 contact hours in their first 5 years
of employment. In the fourth or fifth year, 9 of these hours may be
collected in a single semester in order to secure a release from teaching
for that semester, subject to the approval of the Chair and the President.
The teaching load includes released-time assigned to an individual
and approved by the Dean and the Provost. Employees on the teaching
staff shall not be required to teach an excessive number of contact hours,
assume an excessive student load, or be assigned an unreasonable
schedule. The teaching staff has the obligation, among others, to be
available to students, to assume normal committee assignments, and to
engage in research and community service.
In order to avoid loss of hours due to scheduling difficulties, the
annual workload shall be managed over a three-year period. The intent of
this provision is to ensure that classroom contact hours, under-scheduled
or over-scheduled in one year because the courses assigned to the faculty
member do not permit an exact correspondence with the stated workload,
may be added or subtracted in a subsequent year within a three-year
period. Calculated as a running average over the three-year period, the
average annual teaching contact hour workload of every faculty member
shall equal the number of hours specified above.
All teaching assignments and all approved released-time hours
must be reported and recorded for the semester in which they occur.
Faculty members should not “bank” workloads in excess of the required
limit (overload) to be used for future released-time. The accumulation of
fractional contact hours resulting from thesis supervision or similar
mentoring activity does not count as “banking.”
Source:
http://www.ccny.cuny.edu/academicaffairs/upload/WorkloadGuidelinesDecember-6-2011-1.pdf
Auburn University
The University recognizes the impossibility of creating a “teaching
load” formula that would be applicable to the complex academic programs
embraced
by
the
various
colleges,
schools,
and
departments.
Considerable flexibility is given to the individual department head, in
consultation with the dean, in assigning faculty workloads to meet the
department’s instructional, research, and public service commitments.
Faculty workloads regularly report to the Provost and are utilized by the
central administration of the University in budgetary management of the
academic program.
Although there is no set teaching load formula at the University
level, normally every attempt is made to give an appropriate reduction in
the classroom assignments of those faculties who are significantly
engaged in research, graduate teaching, the direction of graduate student
theses, or University service. Such reduction should be applied equitably
to all eligible faculty. However, the University believes it is important that
senior faculty who have distinguished themselves through research and
publication be directly involved in undergraduate teaching.
Source:http://www.auburn.edu/academic/provost/facultyHandbook/chapter
%204-Instruction.html#teachingloads
2.1.2 Local Literature
UNIVERSITY OF THE PHILIPPINES
DILIMAN, QUEZON CITY
According to the UP Diliman Faculty Manual, a normal teaching load of
12 units per semester or its equivalent in colleges or units observing the trimester or
other systems shall be required of each faculty member;Provided , that no member of
the faculty shall teach less than six (6) units per semester; Provided, further, that the
President or Chancellor may reduce the teaching load to not less than three (3) units
per semester of any faculty member who is actively engaged in research/creative
work, community service, and/or other authorized activities;Provided, finally, that no
faculty member shall be allowed an aggregate teaching load of more than 36 course
credit units for the first and second semesters of any given academic year, including
authorized teaching outside the University of the Philippines System, unless otherwise
given prior authorization by the President or Chancellor due to exceptional
circumstances.
In general, an undergraduate class is open when there are at least 10
students. Any exception to this rule must have the approval of the Chancellor on or
before the last day of registration. While small classes might be best for academic
reasons, the reality of budget constraints dictate that as much as possible small
classes should be avoided or offered only once a year. In the computation of teaching
load, at least 16 hours, evenly distributedthroughout the term, devoted to lecture,
discussion, or recitation, or to any combination of these, or at least 32 hours
supervision of laboratory work, field work, or related student activity, shall be credited
as one unit of teaching load;Provided , that in exceptional cases, the President or
Chancellor, in his/her discretion, may consider at least 24 hours of laboratory or similar
work as the equivalent of one unit of teaching load. A faculty member who combines,
merges, or meets two or more sections as one class shall be credited for teaching one
section only.
In general, a graduate class is opened when there are at least five students.
Any exception to this rule must have the approval of the Chancellor on or before the
last day of registration. In all cases, it is understood that only officially registered
graduate students, fully paid as of the last day of late registration, shall be
counted. Auditors or sit-ins shall not be counted. A faculty member who combines
merges or meets two or more sections as one class shall be credited for teaching one
section only. Thesis advising shall not be given any teaching load credit but shall be
given honorarium in accordance with University rules and regulations
Source:
http://www.academia.edu/2463092/University_of_the_Philippines_Diliman
_Faculty_Manual
WESTERN PHILIPPINES UNIVERSITY
According to the current workload system of WPU faculty, approved
by BOT Res. No. 7, s. 1998 was updated to: a) strengthen the terms of
reference in quantifying the faculty workload; b) revitalize the coordination
and the focus on the use of resources in order to achieve greater outputs;
c) improve the bases for equitable remuneration for services rendered
beyond the full time workload; d) provide updated guidelines on workload
activities other than classroom teaching; and e) establish a more specific
basis for formulating criteria in evaluating the workload performance of a
faculty.
The full-time workload of a faculty shall consist of the workload
units of instruction only, or shall be the sum of the workload units of the
various activities in the functions of instruction, administration, research,
extension, and production. Workload per week in instruction is computed
by multiplying the actual teaching hours by 1.5. A faculty member should
have a minimum of 18 hours and maximum of 24 hours actual teaching
per week.
The maximum load should be satisfied before giving overtime
pay/service credits
Based on Board of Trustees Resolution No. 29, s. 1993, the
approved workload requirement for WPU Faculty is 1:1.5 ratio, that is, 1
hour teaching is equivalent to 1.5 23 units to meet the maximum workload
requirement of 40 hours per week. This will only affect permanent,
temporary and contractual faculty/teachers in the undergraduate level.
The official time based on approved academic load must be
certified by the Dean and approved by the Vice President for Academic
Affairs (VPAA), which will be submitted in four (4) copies to the Vice
President for Academic Affairs (VPAA). One copy each will be provided to
the Records Office, Accounting Office, and HRMO for reference.
Work equivalent of 1:1.5 should only be availed for maximum of
four (4) hours a day.
Source:
http://www.wpu.edu.ph/main/attachments/article/129/wpu_faculty_manual.
pdf
MANILA DOCTORS COLLEGE
According to MDC, the regular teaching load of full-time academic
personnel shall, in no case, exceed 24 units or its equivalent per
semester.
For the College of Nursing, however, the following shall consist the
full load of its faculty members under CMO 14 s. of 2009:
Full-time faculty members may carry a combined RLE and teaching
load of not more than 36 units per semester, which includes consultation
hours and other activities related to RLE instruction, research and
extension services. One (1) hour of RLE supervision is equivalent to one
(1) unit credit.
Part-time load shall consist of not more than 12units or its
equivalent per semester.
For the College of Nursing, a part-time faculty member employed
full-time elsewhere may carry a teaching load of not more than nine (9)
units in all the school in which s/he teaches.
Source: http://www.mdc.edu.ph/new/pdf/fm2010.pdf
HOLY ANGEL UNIVERSITY
Holy Angel University adheres to the rules and regulations of CHED
on matters of teaching loads of its faculty members. In college, the
maximum teaching load of full-time instructors is 24 units a week.
Teaching hours should not be more than 8 hours per day. Instructors must
not have more than four (4) preparations except for those handling major
subjects.
To maximize their efficiency, faculty members shall not be
assigned, nor can they opt to teach, subjects outside their competence.
Faculty members may be given available overloads based on their
qualifications, seniority and availability.
A full-time faculty member must be ready to accept a pre-arranged
schedule prepared by his Dean. In the event that he refuses, the Dean is
not obliged to give a replacement load.
Discontinuity of service due to lack of teaching load arising from low
enrollment shall not be counted against the tenure of the faculty.
Source:
http://www.hau.edu.ph/intranet/pdf/FACULTY_MANUAL_2012_Edition.pdf
DE LA SALLE ARANETA UNIVERSITY
All faculty, as official members of the institution, whether full-time,
permanent or probationary, or part-time, are expected to fully appreciate
and wholeheartedly accept the mission statement of the institution and the
college unit
All faculty, officers, and staff are expected to know in detail the
organizational structures of the institution and the college department, its
academic programs and services, support programs and activities, and
administrative and academic policies and procedures.
Faculty Members are classified either as full-time or part-time.

Full-time Permanent Faculty
A full-time permanent faculty member is one whose duties at De La
Salle Araneta University constitute his/her principal interest. He/She
spends minimum of 40 hours per week on campus engaged in the
following activities:24 hours per week of teaching services;6 hours per
week for academic consultation the schedule of which is to be posted at
the faculty office;6 hours per week for academic pursuits such as course
preparation, library research, correcting papers, attendance record
checking, and other activities;4 hours per week for activities related to
teaching and academic development such as committee work, club
moderator ship, college meeting, in-service training on instructural
improvement, and other official activities requiring faculty attendance; and
additional hour per week for overload.

Part-time Faculty
A part-time faculty member is one who is distinguished by either
one or both of the following:The time spent on another professional
occupation or business concern prevents him/her from devoting five hours
per week on campus as expected of full-time faculty members;He/she
teaches a maximum load of a 15 credit hours per week with or without
other assignments in the college;3 hours for student consultation per
week;
Through all these, the administration expects all faculties to be fully
cognizant of and to appreciate their role in the Lasallian teaching ministry.
Source: http://www.dlsau.edu.ph/pdf/ted-manual.pdf
2.2 ANALYSIS
Based on the proponents’ researches about Faculty Loading Scheduling there are
what they called tenure and non-tenure’ faculty on foreign studies while locally, it was called
full-time and part-time faculty. Foreign studies loads based on hours while in local, they load
based on units that a faculty can get.
The team learned that school and university from foreign and local will have difference
and the same process above mentioned school and university,the team get the methods and
techniques from the research and we will be use it making of this project study.
2.3 SYNTHESIS
Based on proponent’s researches regardinglocal and foreign related
literature in Faculty Loading Scheduling Information System is very helpfulin
every school and university because it’s easy togenerate loading and schedule
instructor/faculty member and also it decreasethe time consuming and it keep
away from their previous problem. Therefore each of us will have more idea and
knowledge to make our proposed system more useful and effective and also time
bounded than their system the team should know first looking for new ideas that
can help to build a plan andcombined their ideas get from the research and build
got a great plan.
Matrix(Comparative Analysis)
Foreign
Montclair
Northeastern
North
City
Auburn
Tertiary
State
State
Carolina
College
University
Faculty
University
University
State
of New
Loading
University
York
Scheduling
✓
Efficiency
✓
Accuracy
Service
Time-saving
✓
✓
✓
✓
✓
✓
✓
✓
✓
Quality
✓
✓
✓
✓
Android
Mobile
Local
Universit
Western
Manila
Holy
De
y of the Philippines
Doctors
Angel
Salle
Faculty
Philippin
College
University
Araneta
Loading
University
Scheduling
✓
✓
University
es
✓
Efficiency
Accuracy
✓
✓
Service
✓
Time-saving
✓
Quality
La Tertiary
✓
✓
✓
✓
✓
✓
✓
✓
✓
Android
Mobile
CHAPTER III
RISK MITIGATION, MONITORING, AND MANAGEMENT PLAN
1.0 Introduction
The rise of Risk Mitigation, Monitoring and Management Plan for Faculty
Loading Scheduling subsystem of Tertiary (Student Information System)
involved in concept to measure the upcoming and encountered risk, the
proponents should ensure to control and the risk should always prioritized
to avoid the any possible problems.
In this chapter, the proponents made some techniques to maintain and a
solution to the said risk, success was met when it was executed well and
helps to avoid any risk.
1.1 Scope and intent of RMMM activities
The proponents want the software to be free of any defect or errors, but it
is hard or at times almost impossible to develop a system that is free of
any defects. To be safe, the proponents would like to have a risk
management plan before encountering any difficulties that may impact the
development or the creation of the software. The goal of this system is to
assist the project team in planning a strategy to deal with the risks. For
this, the proponents will take a look at the possible risks, how to monitor
them and to manage them.
In the software development, to avoid any risk, both the proponents and
the clients need to work together. Decides to change the software,
meaning if the client wants to add some more functions into the software
or to change the requirement, this will have major development of the
software.
1.2
Risk management organizational role
-Technology Risk
-Customer Risk
-Cost Management Risk
-Management Change/s Risk
2.0
Risk Description
This section describes the following risk which the system developer
may encounter during the project
2.1
Risk Table
Category
Risk
Probability Impact
Employee Risks
Lack of training and experience
40%
1
Process Risk
Low product quality
35%
1
Product Size
Where size estimates could be wrong
20%
2
Development Risk
Insuffient Resources
30%
2
Customer Risk
Customer may fail to participate
30%
3
Technology Risk
Obsolete Technology
10%
2
Business Impact
Product may harm the business
10%
3
Table –Risks Table
Impact Values
Description
1
Catastrophic
2
Critical
3
Marginal
4
Negligible
Above is the table that categorizes the risk involved in software development. It
gives brief description of the risk in Risk column and also provides the probability
of risk occurring in percentages in Probability of risk occurring in percentages in
probability column and also the impact of the risk in the Impact column.
The impact values assigned to the each risk are described in this section below
the risk table. It is very convenient way to look at the risk and derive the
information of the risk.
3.0 Risk Mitigation, Monitoring and Management
This section detail describes Risk Mitigation, Monitoring and Management for
each of the possible risks. It will talk about ways to avoid, monitor and to have
ways to manage the risk.
3.1Risk Mitigation for Risk m
In this section several different Risk Mitigation, Monitoring and Management for
each of the possible risks. it will talk about ways to avoid , monitor and to have
ways to manage the risk.
3.1.1 Product Size
In this risk concern id of under or overestimate (mainly underestimation) of the
number of Function points. If we estimate too few LOC (line of code) necessary
for the project we may get wrong cost figures which can prove final to the
software development plan. To avoid this from happening we will use
conservative figures to reduce the probability of the risk. This means we will
overestimate the LOC a little. If we end up finishing the project earlier than that
will not create any troubles. If the software cost estimations are passed with
higher than actual cost required deliver the product on the time ,In normal
circumstances companies are not picky about the product size , so increasing the
number will not cause any troubles in getting approval for the project.
3.1.2 Business Impact
In this risk category we are concerned about the quality of the final product. As
mitigation step we will spend more time with the user to understand their needs.
This way we can gather all the information necessary for the project to be
successful. We will try to understand business environment and can try to
provide the user which help in defining software requirements. More the time
team spends with the customer better understating the team will have regarding
the software. This will help in coming u with just right product at right price for
the customer. Team as to make sure that the palm size PC integration and the
cost of the palm size PC is justified meaning that it really improves inspection
process.
3.1.3 Customer (User) Risk
If the users of the product fail to participate during the different phases of the
software development we fail to recognize problems with the software. Toa avoid
this in the mitigation phase we will try to meet the customer frequently and
present software in phases so that customer betters the understating the team
will have regarding the software. This will help in coming up with jus right product
at the right price for the customer. If customer fails to mention some special
operations that have to be stored separately, software development team does
not know anything about it thus leaving big problem in the software.
3.1.4 Process Risk
We want quality of the product to be as high as possible. To achieve this will set
up guidelines to be followed for each of team member during all the phases of
the software development cycle. The standard will be set and defined for all of
the software development. this will help the team in delivering the high quality
product thus increasing our reputation in the market. This will help more clients
in the future. It will also save customer from getting low quality product.
3.1.5 Technology Risks
To avoid risk of using technology that may become obsolete in few years after
the product have been developed. We will do excessive research on what
technology to use for software development and will use the latest technology
(programming language etc.) to avoid this risk. Software development team has
to make sure that the equipment requested are current and will not be obsolete in
near future.
3.1.6 Development Risk
If the necessary tool is not provided to all the team members, their will work lack
quantity and quality, As mitigation phase we will make sure that the budget
include cost for latest technology and tools needed succeed. As mitigation step
of this risk will make that someone in all of the project development phases
knows exactly what to do and the tools to use to achieve the goals. If the
employees that have little knowledge in the main software implementation
language fails to learn it may cause big problems when coding part begins.
3.1.7 Employee Risks
This risk concerns the knowledge and of the employee and their willingness to
help make the project succeed. As mitigation step of the risk we will make sure
that someone in all of the project development phases knows exactly what to do
and the tools to use to achieve the goals. If the employees that have little
knowledge in the main software implementation language fail to learn it, It may
cause big problems when coding part begins.
3.2 Risk Monitoring for Risk m
In this section we ill identify the conditions to monitor to determine whether risk m
is becoming more or less likely.
3.2.1 Product Size
To monitor step in this risk we will setup user meetings to show them the work
that has been completed and to get user input on the work. We will have meeting
every other week to present the work that has been done from the time of the last
meeting. This will help team in staying in touch with the customer and we will
also be very efficient way to derived customers input on the progress made it will
be also the way to get customer insight on the project, which will help in
determine the changes that we may have to make to the software upon
customers request.
3.2.3 Customer (User) Risk
To monitor the risk we will be monitor the success of the meeting by keeping
track of people that have attended the meeting. If the outcome of the meeting s
low we can contact responsible person to help us overcome this problem. We will
also have the login charts to show the customer who is attending the meeting
and who needs to be reminded to start attending meetings.
3.2.4 Process Risk
To monitor the risk here we will review each other’s work to find the problems
and to help each other in achieving better product quality. We will also have the
general guidelines set of all of the work to be carried on for the software
development. Software development team will constantly check each others
work; will compare it with the set guidelines, and will inform a team member who
is failing to participate in following the guidelines.
3.2.5 Technology Risks
For monitoring phase during the development of the software we will keep eye on
new technology. This will help us to keep with a new technology.
3.2.6 Development Risk
For monitoring phase during the development of the software we will keep eye on
tool being used and their effectiveness. This will be help us to keep up with a
new technology.
3.1.7 Employee Risks (Teammates)
Monitoring and managing of the risk will include looking out of each other, that is
if some team member is having difficulties in performing some task or using
particular tool or techniques other member of that team will help him out. This is
where team member may have to spend little time with each other learning or
teaching what other knows.
3.3 Risk Management for Risk m
In this section we will identify several different software development risks and
will try to manage these risks if they do occur.
3.3.1 Product Size
After careful monitoring of the process, if we still end up with understanding of
the FP, we will put more man-hour into the project. This is only way that we think
we can manage the risk.
3.3.2 Business Impact
If a mistake has been made, user input in the completed work will provide is with
information to fix or improve the software. We have done very many meeting
with the client and plan to do meeting every two weeks; this should clear any
understandings between the software development team and customers.
This is the best way to go at since the work that is done on the project is
revealed during the meeting and customers get chance to make adjustment
necessary.
3.3.3 Customer (User) Risk
If the turn off the meetings is not encouraging we will pass out the questionnaire
to easily gather customers view. We will ask them question rather than waiting
for them to ask us questions. We will also talk to the manager at the DEQ to
help us come up with the plan that will increase the attendance during the
meeting. If the outcomes of the meetings is satisfactory there should not be any
major difficulties regarding customer risks.
3.3.4 Process Risk
If the problem exists with the quality of the work, the quality assurance plan will
be revised in the risk management phase. Other team member will attempt to
take over or swap the work of the member whose work does not meet the quality
standards.
3.3.5 Technology Risks
For monitoring phase during the development of the software we will keep eye on
new technology. If we spot new techniques that can be implementing without
major changes in our project we will included such techniques in the
development of the project. We will also keep a look out for major shift in the
technology and how it affects the software that we are working on. If there is a
need change in the technology will be discussed among the team member and
will be presented to the client. If client agrees necessary changes will be made
with the existing technology.
3.3.6 Development Risks
In the management phase if the funding for the technology and tools are not
enough we will have to reschedule the phases of software development cycle to
allow more time to coding phase. We will provide information on the several
different Palm-size PC’s and will let the customer to choose the one that is most
appreciate for the customer to buy. We will also make sure that the equipment is
allowed to be purchased under government controls and contract.
3.3.7 Employee Risks (Team member)
Monitoring and managing of this risk will include looking out of each other, that
is if some team-member is having difficulties in performing some task or using
particular tool or technique other members of that team will help him out. This is
where team members may have to spend little time with each learning or
teaching what other knows. If team member lacks ability to use certain
programming language or application, other team member will take some time
off to teach the member basic related to that application.
4.0 SPECIAL CONDITIONS
Special conditions that are associated with the software are as follows.
Use of the Palm-size PC:
We need to make sure that all the inspections at the facility are comfortable with
the use of PC. It is hard at the times to write certain characters since the PC has
its own writing software. Use of the software that recognizes the handwriting of
different personal will be used. It is necessary to provide for the entire group of
inspectors to use the writing software.
Saving Check-lists:
We need to make sure that as an inspector goes through a facility to be
inspected using the PC, he or she does not have to save each and every entry
made in the Palm size PC. The PC will automatically save the data after every
entry is made or change has occurred. Save button will used only to finalize the
product.
Login;
Since we are using modular login we need to make sure that the person logged
in will only have access to certain part of the application, this deepened on the
rights granted to the users. We have to explain to each user why he or she is
not able to use certain parts of the applications. We also need to make sure that
users with read only write understand why they are unable to make changes to
other users report.
3.2 SOFTWARE CONFIGURATION MANAGEMENT PLAN
1.0 Introduction
During the time of the software development, the software is having
unexpected changes. Software Configuration Management Plan is
planned so that we can identify the change, control the change, make sure
plan is implemented correctly and to make the changes will be
documented.
1.1Scope and Intent of SCM Activities
The importance of SCM is to provide information and find any
changes made to the original software development plan because of the
unavoidable change plan. The objective of SCM is to limit the impact
changes may have on the entire system and repot and track any changes
made to the original software development plan. It is applied throughout
the software development process and will help us to keep track of
changes also help us go to make more changes.
This will help to
eliminate unnecessary changes, and to monitor and control any necessary
changes. It implemented to help us to find any change and to make any
solution to the changes. SCM will guide us to avoid any questions
regarding the changes and to avoid any unexpected mistakes. We will
also extensively
SCM Activities

Identify Change

Control Change

Ensure that change is being properly implemented

Document Change
1.2 SCM Organizational Role
Since we have a small software development team, each
proponent has the responsibility for software configuration management.
We will also keep the entire members on client side to be informed of all
changes for acceptances. The changes that do not really affect user’s
knowledge of the software will be presented to a selected member on the
client’s side.
We will also keep all the members on the client’s side inform of all
the changes for acceptance. The changes that do not really affect user’s
knowledge of the software will be presented to a selected member on the
client’s side. These changes will be noted in a specific section so that we
can refer back to them to know what the original plan was and why the
changes were made. If the changes are made or suggested so that they
will affect the way customer uses the software, then those changes will be
discussed with the entire client team. Once a client has decided the go
with the change then and only then will changes be implemented. We will
also extensively report or document all the changes so that client will have
access to it after the software is packed and delivered.
2.0 SCM Tasks
In this section we will try to detail all-important SCM tasks and will assign
responsibilities for each. All of the SCM tasks will be performed by three
members of the software development team members. We will try to keep
one – person from the client’s team informed of all the changes that do not
affect users. All the changes that affect the use of the software will be
discussed with entire team on the client’s team during the meeting.
2.1 Identification
In this section we will describe the way software configuration items will be
identified for the software configuration management plan.
2.2 Configuration Control
In this phase described how proponents will control the changes in the
system. The proponent should be always prepare and monitor to any
changes will be happened, to control a lot of changes each member of the
team must be assure that the proposed system is functioning more
effective.
2.2.1 Description

Identify change
During the Faculty Loading Scheduling development phases, if the
proponents compiled all the changes according to the said agreement and
they need to have meetings to settle these changes, but initially the
proponents must learn first about the advantages/disadvantages of the
changes happen and make sure that the changes will not affect the users.

Approve Change
For acceptance or approve changes, the proponents need to be able to
control any changes within the software. The user can configure what
have been made even without the proponent’s attention. The user will be
easily make changes on its own, contact or send requests through
developers via email to approve change requests.

Ensure that change is being properly implemented.
Since all the proponents will be working separately, it is possible to make
mistakes in implementing changes. To make sure this won’t happen, the
proponents must have a time for monitoring and consulting with each
other in finalizing and implementation of changes.

Document the change.
Since change has to be documented from the time that the proponents
and the clients suggest the change still the time it’s finalized, the
proponents will end up documenting any changes.
2.3 Version Control
2.3.1 Description
As a result of changes, the version number of various modules will be
increased accordingly. We will be using a universal number system for all
modules. We will also have a final version in entire product.
2.3.2 Increasing Version Number
When a change request is filed, a changes report will be created.
2.3.3 Work Products and Documentation
A single document titled Faculty loading and Scheduling Revision History
will be used to document all the version revisions. Having Help Button the
client understand and aware to any changes happen in the system and
using the email address of each member of the team, client able to
connect with the developers .
2.4. Configuration Status Accounting (CSA)
We will be using three different ways to communicate with the team
member and to inform other that changes may concern.
2.4.1 Description
Three way or three tools that we will use to communicate with every
proponents and the people associated with the software development
.

Online Send Request
The client can submit send request through email to communicate with the
proponents. In responding send request, the proponents will contact the
client to discuss the desired change request.

Change Request Report
If the proponents finalized all the changes requested by the client, the
proponents will be making a list of change history report.

Verbal Communication
Since our software development team is small and all the proponents are
in constant touch with each other, it would be better to communicate
verbally.
2.4.2 Work product and documentation
 Online Send Request
 Change request report generator
 Emails
 Test error
 All suggestions collected will be kept
3.2
SOFTWARE QUALITY ASSURANCE PLAN
3.3.1.0
Introduction
The SQA plan provides a road map for instituting Software Quality
Assurance for Faculty Loading Scheduling in any colleges and university
effective to assure improvements of their business process. This document
contains the guideline to maintain the quality of the project.
3.3.1.1
Scope and Intent of SQA Activities
The use of this plan will help assure the following:

To determine the objectives of the software which are to be accomplished;

To establish software plans, when the objectives are determined; &

To monitor and adjust software plans to satisfy user requirements.
3.3.1.2
Organizational Role
The SQA organizational role is to review the product(s) at specific time
during product implementation. Upon reviewing, the SQA team’s duties will be to
evaluate the software at its current development stage and recognize any defects
in the subsequent stage (design or implementation). The SQA team will be
having group discussions, discussing any errors or possible enhancements that
have been identified. In addition, the SQA team will ensure that the software
engineering team has not deviated in any way from the initial design
specifications.
Head
SQA Unit
(1)
SQA Operations
(2)
SQA Development
and Maintenance
(2)
Head SQA Unit (Project Manager):
Zarah Jane D. Jolejole
SQA Operations (Business Analyst/Documentation Specialist):
Cherrylyn V. Barruga/Liezl Mae P. Arroza
SQA Development and Maintenance (Programmer/System Analyst):
John Rainier D. Paraiso/Charles Ian C. Sadio
3.3.2.0
SQA TASKS
The main task of the SQA team is to check whether the procedures are
followed properly and that standards are handled correctly as defined in the
RMMM and SCM.
Additionally, the proponents inspect whether all group members fulfill their
tasks as defined according to the parts of the quality assurance applying to their
specific tasks.
-
Monitor
-
Documentations
-
Test
3.3.2.1
Task Overview
The tasks that described above will cover up evaluation, processes and
quality assurance of the Faculty loading scheduling software. The proponents
inspect whether all group members fulfill their tasks as defined according to the
parts of the quality assurance applying to their specific tasks.
3.3.2.2
Standard, Practices and Conventions (SPC)
Monitor
The System Analyst will check with the Requirements Specification to
make sure that what he is coding conforms to the original design. This process
will ensure that the product meets the client’s expectations and standards and
that the engine, up to its current point, is working properly.
Documentations
Any major deviations that occur will be documented and will be expressed
to the other group members. Documentation will ensure that each group member
is aware of the change(s) made to the software so that each part of the project
can be adjusted accordingly.
Test
There will be a testing of the user-interface. Criteria will be: ease of use,
any logic errors and/or software glitches that occur, and any desired
enhancements. This is done to ensure that the user-interface is tested, and
remains easily understandable.
3.3.2.3
SQA Resources
People

Arroza, Liezl Mae P.

Barruga, Cherrylyn V.

Jole-jole, Zarah Jane D.

Paraiso, John Rainier D.

Sadio, Charles Ian C.
Software-Server Side

Windows 7 Ultimate

Windows XP

Android Ice Cream Sandwich 4.0.4

MySQL

Java Netbeans 7.3.1

Adobe Photoshop
Software-Client Side
3.3.3.0

Google Chrome

Internet Explorer

Microsoft Office (Word, Excel, MS Visio, MS Project)

Nitro Pro (PDF Reader)
Reviews and Audits
A formal technical review is a software quality assurance activity
performed by software engineers (and others). The objectives of the FTR are
(1) To uncover errors in function, logic, or implementation for any representation
of the software;
(2) To verify that the software under review meets its requirements;
(3) To ensure that the software has been represented according to predefined
standards;
(4) To achieve software that is developed in a uniform manner; And
(5) To make projects more manageable.
In addition, the FTR serves as a training ground, enabling junior engineers
to
observe
different
approaches
to
software
analysis,
design,
and
implementation. The FTR also serves to promote backup and continuity because
a number of people become familiar with parts of the software that they may not
have otherwise seen.
The FTR is actually a class of reviews that includes walkthroughs,
inspections, round-robin reviews and other small group technical assessments of
software. Each FTR is conducted as a meeting and will be successful only if it is
properly planned, controlled, and attended. In the sections that follow, guidelines
similar to those for a walkthrough are presented as a representative formal
technical review.
3.3.3.1
Generic Review Guidelines
Listed below is a set of guidelines for all formal technical reviews (FTRs)
that will be used in assessing work products during FTRs.
3.3.3.1.1
Conducting a Review
The software will have scheduled reviews to detect any problems and to
determine some notable enhancements that shouldn’t be implemented prior to
submit the software.
The client and the proponents need to set a review in order to ensure that the
maximum number of possible defects are accounted and get the total number of
changes.
For the changes that will affect the client’s performance when they use the
software, we have to consult them first. But before take the cases to the client,
the entire team has to agree to change. And keep a good record of the record of
the project before and after the change.
3.3.3.1.2
Roles and Responsibilities
Each proponent will be responsible to do the assigned task with each
other. Once the task has already done, the client will be informed that the
documentation is ready for review. As stated in 1.2 SQA Organizational role, the
role of each team member will be very confusing since the proponents have a
relatively small team.
These the people involved during the configuration changes;
Head
SQA

Project Manager

Unit
Zarah
Jane
D.
Jole-jole
SQA

Business Analyst
Operations

Documentation
Specialist

Cherrylyn
V.
Barruga

Liezl
Mae
P.
Arroza
SQA

Programmer
Development

System Analyst
and
Maintenance

John
Rainier D.
Paraiso

Charles
Ian
C.
Sadio
Head SQA Unit (Project Manager): Zarah Jane D. Jolejole
SQA Operations (Business Analyst/Documentation Specialist):
Cherrylyn V. Barruga/Liezl Mae P. Arroza
SQA Development and Maintenance (Programmer/System Analyst):
John Rainier D. Paraiso/Charles Ian C. Sadio
3.3.3.1.3
Review Work Product
The head will keep a defect log. The defect log contains all defects and
enhancements, as well as a priority rank for each. The following will also be
noted in the defect log:

Whether or not the defect or enhancement has been handled;

Which software engineering oversaw the correction; and

What date the correction was completed.
3.3.3.2
Formal Technical Reviews
Specific character and intent of each major FTR conducted during the
software process:

Walk-throughs

Inspections
3.3.3.2.n.1 Description of Review Walk-throughs
This review mainly focuses on the function of the system software. The
proponents will be having a review regarding this software to detect if there is
any problem or error exists.
3.3.3.2.n.2 Description of Review Inspection
This review mainly focuses on testing the proposed system. The
proponents will allow an authorized person to do a test without interrupting the
developer.
3.3.3.2.1
System Specification Review
The main purpose of FLS is to help automate the entire process that the
School Department Heads, School Administrator, Human Resource (HR) staff
members perform throughout the subject loading and scheduling. For more
information, please see the document “3.4 System Specification”.
3.3.3.2.2
Software Project Plan Review
The purpose of Software Project Plan provides background information for
the rest of the documents. It briefly describes the project, the client deliverables,
the project milestones, and expected document changes.
3.3.3.2.3
RMMM Review
The rise of Risk Mitigation, Monitoring and Management Plan for Faculty
Loading Scheduling subsystem of Tertiary (Student Information System) involved
in concept to measure the upcoming and encountered risk, the proponent would
ensure to control and the risk should always priorities to avoid the any possible
problems. For more information, please see the first document titled “RMMM”.
3.3.3.2.4
Requirements Reviews (Models, Specification)
To create a better system that costumer needed and the flow of the
system must be same of what they want and perform Faculty Loading system.
For more information, please see the “SRS” document.
3.3.3.2.5
Data Design Review
During the design review that all aspects of the database and
application code are reviewed for efficiency, effectiveness, and accuracy. It is
imperative that all database applications, regardless of their size, are reviewed to
assure that the application was design properly, efficient coding techniques were
used, and the database is accessed and modified correctly and efficiently. The
design review is an important process for checking the validity of design
decisions and correcting errors before applications and databases are promoted
to production status.
3.3.3.2.6
Architectural Design Review
The objective of this review is to ensure that the proponents can
effectively evaluate an organization’s architecture and technical infrastructure.
The content covers the development, acquisition and implementation of IS
architectures and associated operational practices to ensure efficiency and
information security.
3.3.3.2.7
Interface (GUI)
As of now, there are ten interfaces planned. The proponents are still
planning to add more interfaces. It was designed using JAVA Netbeans IDE
7.3.1.
3.3.3.2.8
Component Design Review
3.3.3.2.9
Code Review
3.3.3.2.10
Test Specification Review
To make Faculty loading and Scheduling in a simple way to produce
productive and excellence process, in the right time and proper methods in
software development to do that the software has to go through a series of test
before its final release. Having a mistake is free in the software is extremely
difficult to achieve. The proponents follow step by step, item by item, to test all
the necessary objects, data flows, limits, boundaries, and constraints of the
software.
3.3.3.2.11
Change Control Reviews and Audits
An important component of many IT audits is the review of an
organization's change control environment. Simply stated, change control is the
process used to request, review, specify, plan, approve, and implement changes
to a system. When it's properly implemented, change control assures that
unplanned changes don't happen and that planned changes are well managed.
3.3.3.3
SQA Audits
Regular audits of the SQA activities will be held. These audits will require
the proponents to determine which SQA activities are working to deter product
defects and assess how well each SQA activity is being conducted.
The proponents will generate and maintain an Audit Schedule. Audits will
occur at the end of each development phase as indicated in the SMP. The
results of audits will be discussed with the individual most responsible for the
production of the deliverable.
Audit reports, and recommended corrective actions generated by SQA will
be brought to the attention of the individual most responsible for producing the
software deliverable. Corrective action will be recommended and reviewed with
the individual and SPM. The results of audits of the SQA function will be kept by
the PAM.
The audits will assist in keeping the proponents on track, as well as
enhance beneficial activities or eliminate useless activities. Each activity will be
assessed to determine how well it is affecting product quality. The defect log will
be reviewed to determine what methods of SQA have been most useful and
which have been less useful.
3.3.4.0 Problem Reporting and Corrective Action/Follow-up
This section describes problem reporting mechanisms that occur as a
consequence of the FTR's that are conducted and the means for corrective
action and follow-up.
The team has five members to implement and develop the proposed
system.
Head SQA Unit
Zarah Jane D. Jole-jole
The
problem
will
be
reported to the head of
the team. The head is the
ones
who
will call
a
meeting to analyze the
problem and to give a
solution to that.
SQA Operations
Cherrylyn V. Barruga
These team members
will be the people who
Liezl Mae P. Arroza
are assigned to analyze
and
document
the
problems and update the
software’s
documentation.
SQA
John Rainier D. Paraiso
After analyzing the
Development and
Charles Ian C. Sadio
problem reported,
Maintenance
the
programmer
and
system
analyst
will
implement
the
given solution.
3.3.4.1
Reporting Mechanisms
All defects or enhancements referred to the project manager. If a defect
occurs between team meetings, the defect will be reported to the system analyst
and programmer, so that the proponents can analyze the defect and assign a
priority level to it.
This can occur either by word of mouth (so long as the
documentation specialist is taking note), email, or a handwritten report.
3.3.4.2
Responsibilities
The entire proponents have a responsibility for corrective actions and
follow-up to ensure quality. Each proponent has their own portion of the project
they will be working on. These members are responsible for fixing the problems
associated with their portion, but quality assurance falls on the entire team.The
project manager will check on each portion at a time to ensure that there is no
overlapping done.
Head SQA Unit (Project Manager):
Zarah Jane D. Jolejole
SQA Operations (Business Analyst/Documentation Specialist):
Cherrylyn V. Barruga/Liezl Mae P. Arroza
SQA Development and Maintenance (Programmer/System Analyst):
John Rainier D. Paraiso/Charles Ian C. Sadio
3.3.4.3
Data Collection and Valuation
Each proponent is responsible for all data collection and evaluation. Any
product defect or enhancement will be reported to the project manager so that he
can record the problem and evaluate its priority level. The data are collected by
keeping a record of each team meeting and keeping track of all problem
submissions outside of the meetings.
3.3.4.4
Statistical SQA
The statistical quality assurance is the application of statistical principle
and techniques at all stages of production, design, maintenance and services,
directed toward the economic satisfaction of demand.
The statistical quality assurance is a system of the application that
embraces all formal quantitative aspects of planning, design, purchase,
production, services, marketing and redesign of products, it helps to find
problems to state them in meaningful terms and to solve them, it provides a plan,
a road-map, that leads to a better competitive position. The great advantages of
statistical thinking are that it allows managers to differentiate between common
causes and special causes of trouble. Common causes constitute most of the
problem; they are faults of the system, they affect all members of a work group
equally.
A first observation regarding the loading of a faculty closely related to the
measurement, if loads are to be at all helpful, there must be a consistent
understanding about exactly how they are to be collected, this involves having
operational definitions for quantities to be observed and personal who have been
well trained in using the definitions and any relevant measurement equipment.
Second, data have to do with when and where they are gathered, the
closer in time and space that data are taken for an operation whose performance
they are supposed to portray.
Third, data collections should be made as convenient as possible and
where at all feasible, the methods used should make the data immediately
useful.
Fourth, observation is documentation, also data have to do with volume.
Finally, one must take careful account of human nature, psychology and
politics when assigning data collection tasks. People who are to collect data
needs sufficient motivation to believe that data can help them do a better job and
help their organization be more successful.
3.3.5.0
Software Process Improvement Activities
Determinants for Software Quality and Organizational Effectiveness
3.3.5.1
Goal and Object of SPI
Process improvement goals

Understand existing processes

Introduce process changes to achieve organizational objectives which are
usually focused on quality improvement, cost reduction and schedule
acceleration

Most process improvement work so far has focused on defect reduction.
This reflects the increasing attention paid by industry for quality

However, other process attributes can be the focus of improvement
3.3.5.2
SPI Tasks and Responsibilities
Working group team members are expected to participate in pilots of the
deliverables and in roll-outs of new processes. Responsibility for each milestone
on the SPI Roadmap will be accepted as a working group to address the
improvement recommendations in that milestone.
The responsibilities of the Software Process Improvement are:

documenting the organization’s strategic action plan (this document)

creating a schedule identifying activities, resources, and effort

tracking progress against the plan

reviewing project team and working group action plans

collecting status biweekly from the project teams and working groups

summarizing and reporting status monthly at the MSC meeting

suggesting corrective action to the MSC when actual progress deviates too
far from the plans

acquiring and coordinating resources for training and consulting
.
3.5.6.0
Software Configuration Management and Overview
During the time of the software development having an unexpected
change. Software Configuration Management Plan is so that we can identify the
change, Control the change, make sure the plan is implemented correctly and to
make the changes will be documented. For further information about this topic,
please go to the document titled “Software Configuration Management Plan”.
3.5.7.0
SQA Tools, Techniques, Methods
The specialized tools used by the team will include:

MySQL

JAVA Netbeans

Microsoft Office;

E-Mail clients; and

Each team member’s PC.
Each proponent will be using their own techniques to complete the SQA
tasks that are assigned to them. Every member of the team has confidence in
the other team member’s ability to use their best judgement when approaching
these SQA tasks. Frequent team meetings, emails, and phone calls will keep the
team as a whole informed of progress and the status of SQA tasks.
The methods that will be used to complete the SQA tasks will include
basic code reviews, team meetings, testing according to the test specification
document, database surveillance, and reviewing the functionality of the software
which includes observing how it performs as it is being used as it is intended to
be by volunteers and the client.
3.4
SYSTEM SPECIFICATION
3.4.1 Introduction
This section describes the general view of specification for Faculty
Loading Scheduling (FLS). It provides the technical standard of the
system. The technical requirements for the System will be documented
through
a
series of
specifications.
This document, the System
Specification defines the functional data description and includes the
subsystem description and enchanced interface prototyping.
3.4.1.1 Goals and Objectives
The main purpose of FLS is to help automate the entire process that the
School Department Heads, School Administrator, Human Resource (HR)
staff members perform throughout the subject loading and Scheduling.
The goals of FLS are:

Can quickly provide schedule and to load subjects to a faculty member

Dismiss the redundancy

Monitor the vacant and occupied rooms that haven’t yet scheduled

To provide a searchable database of all past Schedules and Loading
3.4.1.2 System Statement of Scope
The system intent to produce the following. An accurate schedule of a
certain faculty. A complete and detailed faculty loading. Exact computation of
units loaded in a particular faculty. There are major function that the proponents
decided to implement on the system. These are a tool to monitor and ensure
college policies on pay and workload are accurately implemented, a method of
tracking teaching and non-teaching
assignments of full-time, part-time and
associate faculty throughout the college and to produce anything needed report.
3.4.1.2.1 General Requirements
The following general requirement was laid out for our project named
Faculty Loading Schedule.

The system shall handle schedule conflicts.

The system shall support make-up class upon request

The system shall have audit trail

A way in which staff members could load subject to designated faculty

A way in which staff members could make a schedule to all class section
given

A way to print the schedule created

A way to search which room is occupied/vacant depending on time and
day

A search on all electronic faculty loads and schedules

Interface Enhancement
The team members of FLS decided to enhance a few interface
enhancements that will increase the usability of the product for the
department
heads
and
administrator.
3.4.1.3 System Context
The Faculty Loading Scheduling System can perform the computerize
process for scheduling the duty of the faculty, so the assigning of the
schedule to a faculty will be faster and the record
will be save
automatically at the database.
The Faculty loading scheduling system can execute more integration with
the other subsystem. The software links all the data required. Therefore
the other subsystem can simply
3.4.1.4 Major Constraints

Quality
Quality would typically be restricted by the specifications of the product or
service. Most of the time, if quality is a constraint, one of the other constraints –
time or budget – has to have some give. You can’t produce high quality on a
restricted budget and within a tightly restricted time schedule. Of course, there
are exceptions, but usually not in reality – just in the movies.
3.4.2.0 Functional Data Description
This section describes overall system functions and the information domain in
which it operates.
3.4.2.1 System Architecture
3.4.2.2.1
Architecture
Model
3.4.2.2.1 Subsystem Overview
Creating Faculty Schedule
For creating Faculty schedule the user should know first the faculty
information, specialization and time availability of faculty and
identify the available rooms and date for schedule.
Finding Faculty schedule
To find the faculty schedule the user able to use a search button to
find the specific schedule wanted
Loading subjects in a faculty
Must observe the given subjects in a way to balance the faculty
workloads.
Computing Workloads
To be display in a table. Enabling the user to determine if the
faculty are already overload.
Audit Trail
A set of records that provide documentary evidence of the
sequence of activities done by the user.
Print Reports
to get documents accurately printed on paper.
3.4.2.2 Data Description
3.4.2.2.1 Major Data Objects
Faculty Information
1.
Faculty-ID:
This number is given to each faculty.
2.
Faculty-Name:
Name of the faculty given by the Human Resource
3.
Specialization:
This field is a list of subject of faculty able to teach.
4.
Department:
This field contains the department name of faculty belongs.
5.
Worktype:
Type of work which the faculty employed.
Curriculum Information
1.
Subject-ID:
This number is given to each subject.
2.
Subject-Code:
Code of the subject
3.
Subject-Name:
Name of the subject provided by Curriculum System
4.
Description:
Description of the subject
5.
Units:
This field contains the number of units depends on subject
6.
Subject-Room
This field contains which room the subject belongs. (e.g. Laboratory)
7.
Course
This field contains which course can take the subject
8.
Year:
This field contains which year-level can take the subject
9.
Semester:
This field contains which semester of the subject can be assigned.
Room Information
1.
Room-ID:
This number is given to each room
2.
Room-Name:
Name of the room. Includes the floor number.
3.
Location:
This field contains the location of the room.
4.
Type:
This field determines what type of the room.
5.
Description:
Description of the room
Subject assigned to Faculty
1.
SF-ID:
Number of the data entry
2.
Faculty-Name:
Name of faculty to be assigned
3.
Subject:
List of Subject to be assigned
3.4.2.3 Human Interface Description
3.4.3.0 Subsystem Description
3.4.3.1 Subsystem Flow Diagrams
3.4.3.1.1 Create Checklist
3.4.3.1.2 Print Checklist
3.4.3.1.3 Generate Letter
3.4.4.0 Enhanced Interface Prototyping
3.4.4.1 Prototyping Requirements
3.5 SYSTEM REQUIREMENTS SPECIFICATIONS
3.5.1 Introduction
This section describe the design for the Faculty Loading System (FLS)
comprised of a set if complementary reports, any combination of which can be selected
and produced for an academic year at the university, college, department or individual
level.
3.5.1.1 Goals and Objectives
To create a better system that costumer needed, the flow of the system
must be same of what they want to perform by Faculty Loading Scheduling. The
goals of the Faculty Loading Scheduling are:
•
To avoid redundancy of Faculty Scheduling
•
To make it easy in identifying which is vacant or occupied schedule
•
Ability to filter the information needed
•
To computerize the process of scheduling of the faculty.
•
Easily identify if a facilityhas their schedule
3.5.1.2 System Statement of Scope
This part is about design that easy to understand and to use the system.
The design of the Faculty Loading syste, is base in survey, interview and
research.
3.5.1.2.1 General Requirements
The Faculty Loading System can Load
rooms, time and date of the
Professor and complementary reports, any combination of which can be
selected and produce for an academic year at the University, college,
department or individual level.
The general requirements of Faculty Loading S are:
•
To show all schedules of particular professors.
•
To computerize the assigning of the professor.
•
To show the day/weekly of schedule in particular rooms.
•
To show the number of subject units of the professors.
•
To see the report of their duties and hours of teaching.
•
To print reports.
•
To search the particular faculties scgedule
•
Interface Enhancements
This System is open generic so the interfaces of Faculty Loading System
is simpler to easy and better to uses even the user is not computer
literate.
•
Database Administrative Interface
•
The database of Faculty Loading scheduling System is organize and easily to
find the specific wanted report in this way the user avoid the problem regarding
giving reports .
•
Help
To develop the system with help button for the users if have problem in
the software and in Help button can link to the yahoo mail of the developer
to have contact for updating of the system.
•
Training
The users needed to attend if the software will present to know how to use
it and to familiarize the interface and environments.
3.5.1.2.2 Extended Enhancement
•
Import Database
Import database is useful in sense of transferring the data from the user
computer unit to another computer unit and it help for back up data.
•
Exporting Database
Exporting database it help to back up the data.
3.5.1.3 System Context
The major user of the Faculty Loading System are department heads they
assign professor in particular room, date and time.
3.5.1.4 Major Constraints
•
Time
The other team haven't talk in they database, so that our database is not
yet comply the information needed.
3.5.2.0 Usage Scenario
3.5.2.1 User Profiles
There will be two levels of users:
•
Full Control (Administrator)
•
Read/Write (Department Heads)
3.5.2.2
Use-cases
Read/ Write
This level be can add the loads of the faculty and they can view the
schedules of the faculty.
Full Control
This Level is for the Administrators that can add new Department Heads
account and update the account.
3.5.3.0 Data Model and Description
3.5.3.1 Data Description
3.5.3.1.1 Data Objects and Dictionary
Faculty from HR and Curriculum
•
Faculty ID
This is unique number given by HR to the faculty.
•
Faculty Name
This is the personal information of the faculty came from HR database.
•
Faculty Department
This is the department where faculty belongs to.
•
Faculty Specialization
This information came from the database of the HR and Curriculum where
the faculties have specialization of the subject and department.
•
Subject Unit
The proponents need to know the unit of each subject.
•
Masteral Degree
The professor have taken masteral.
•
Work Status
It is about of the professor if they regular, part time ir full time.
Day Schedule of the faculty
•
Monday
This day can view all faculty have Monday schedule.
•
Tuesday
This day can view all faculty have Tuesday schedule.
•
Wednesday
This day can view all faculty have Wednesday schedule.
•
Thursday
This day can view all faculty have Thursday schedule.
•
Friday
This day can view all faculty have Friday schedule.
•
Saturday
This day can view all faculty have Saturday schedule.
•
Sunday
This day can view all faculty have Monday schedule.
Time Schedule of the Faculty
•
6:00 am – 9:00 am
This is the time of the faculty can view all have schedule in 6:00 am – 9:00
am
•
9:00 am – 12:00 nun
This is the time of the faculty can view all have schedule in 9:00 am –
12:00 noon
•
12:00 nun – 3:00 pm
This is the time of the faculty can view all have schedule in 12:00 nun –
3:00 pm
•
3:00 pm - 6:00 pm
This is the time of the faculty can view all have schedule in 3:00 pm - 6:00
pm
•
6:00 pm – 9:00 pm
This is the time of the faculty can view all have schedule in 6:00 pm – 9:00
pm
Rooms where the faculty assign
•
Room Floor
This is the floor of the school building where assign to teach the
faculty.
•
Room Number
This is the number of the room
•
Room Laborator
This room use in actual teaching.
Faculty Loading
•
Faculty ID
This is unique number given by HR to the faculty.
•
Faculty Name
This is the personal information of the faculty came from HR database.
•
Faculty Department
This is the department where faculty belongs to.
•
Faculty Specialization
This information came from the database of the HR and Curriculum where
the faculties have specialization of the subject and department.
•
Date
This is the table can show all date of faculty schedule per week.
•
Time
This is the table can show the time of faculty schedule.
•
Rooms
This is the table can show where faculty assign.
3.5.3.1.2 Relationships
3.5.3.4.0 Functional
3.5.3.4.1 Subsystem Flow Diagrams
3.5.3.4.1.1 Create Schedule
3.5.3.4.1.2 Print Schedule
3.5.3.4.1.3 Generate Letter
3.5.3.4.2 Human Interface
3.5.3.5 Restrictions, Limitations and Constraints
3.5.3.6 Validation Criteria
3.6 SOFTWARE DESIGN SPECIFICATION
3.6.1 Introduction
This section describes the design for the Faculty Loading Scheduling (FLS) and
provides an overview of the entire design document. This document describes all
data, architectural, interface and component-level design for the software.
3.6.1.1 Goals and Objectives
The main purpose of FLS is to help automate the entire process that the School
Department Heads, School Administrator, Human Resource (HR) staff members
perform throughout the subject loading and Scheduling. The goals of FLS are:

To help the end-user work comfortably with the system environment

Create the fields filled automatically causing a faster process

Fullscreen system

Eliminate same data with the other subsystem

tables are constructed properly and efficiently
3.6.1.2 System Statement of Scope
The Faculty Loading Scheduling (FLS) Design Specification focuses on the
functional and technical design for the FLS Application.
This includes the
Graphical User Interface (GUI).
3.6.1.2.1 General Requirements
The following general requirement were laid out for our project named FLS

A way in which staff members could load subject to designated
faculty

A way in which staff members could make a schedule to all class
section given

A way to print the schedule created

A way to search which room is occupied/vacant depending on time

A search on all electronic faculty loads and schedules

Interface Enhancement

Database Administrarive Interface

Online help

Training
3.6.1.3 System Context
Eventually, multiple users will be using the product simultaneously.
Therefore, concurrent connection will be an issue for implementation. In addition,
this is a pilot product that hopefully, if successful, can be used in other locations
as well. This leads to issues about future support for a larger user base.
3.6.1.4 Major Constraints
The FLS Application will need to be designed to work on major operating
systems (Windows, Mac, Linux). The biggest constraint observed by the FLS
Application will be the need to alert the users in real time when non-trivial motion
has occurred.
3.6.2.0 Data Design
A description of all data structures including internal, global, and
temporary data structures.
3.6.2.1 Database Description
M
1
Faculty
1
M
Room
1
Day
M
M
1
Time
Subjects
1
M
1
M
Section

Schedule
Entities
Each word in the entity represents a(n)...
FACULTY
faculty
SUBJECT
subject
TIME
time
DAY
day
ROOM
room
SECTION
section
SCHEDULE
list of schedules
member
Faculty
This entity is provided by the HR subsystem. This field contains the details
about faculty

Subject
This entity is provided by the Curriculum subsystem. This field contains the
details about the different subjects.

Time
This field is constant. (e.g. 6am to 9am, 9am to 12nn)

Day
This field is constant (e.g. Monday, Tuesday)

Room
This field is produced by the FLS software. A list of all rooms and about its
details

Section
This entity is provided by the Admission and Enrollment subsystem. This field
Is a list of section

Schedule
The output of the Software
3.6.3.0 Architectural and Component-Level Design
3.6.3.1 Program Structure
3.6.3.1.1 Overall
Login
Main Screen
File
Edit
FILE

Import

Export

Print

Switch User
EDIT
View
Settings
Help

Loading

Schedule
VIEW

Faculty

Full time

Part time

Day

Monday

Tuesday

Wednesday

Thursday

Friday

Saturday

Sunday

Time

Room

Subject

Course

Vocational

Bachelor

Reports
SETTINGS

Text size

Themes
HELP

Getting started

Contacts us

About us
3.6.3.1.2 Create Loading
Create
Loading
-Select faculty
-Select subject
Check if is
already exist
Save
Print loading
3.6.3.1.3 During Loading
View
Loading
Count number of
subject assigned
already
3.6.3.1.4
Create
Schedule
Create
-Select time
-Select day
-Select room
Check if is
already exist
Schedule
Save
Print
sS
3.6.3.1.4 During Schedule
View
Schedule
-Check Section
-Check room
vacancy
Save
Print
3.7 TEST SPECIFICATION
1.0 Introduction
This section gives a general overview of the Test Specification for the Faculty
Loading System.
1.1 Goal and Objectives
The team wants to make a testing to avoid the misunderstanding to the clients
Faculty loading and Scheduling in a simple way to produce productive and
excellence process, in the right time and proper methods in software
development to do that the software has to go through a series of test before its
final release. Having a mistake is free in the software is extremely difficult to
achieve. The team follows the step by step, item by item, to test all the necessary
objects, data flows, limits, boundaries, and constraints of the software.
The team would like to have a test specification to counter any difficulties that
may impact the development and the future performance of the faculty loading
and scheduling system. The teas goal is to make a system that will help to speed
up the process faculty loadings scheduling want to avoid the errors and resolve
it.
3.7.1.1
1.2 Statement of Scope
An overall plan for integration of the software and description of specification test
are documented in this section. Below is the different kind of test that the team
ensures the quality of the software.
Unit Testing

Desktop

Laptop
To be said the system will be ready to use
Integration Testing

Desktop

Laptop
Validation Testing

Desktop

Laptop
High-order Testing

Desktop

Laptop
1.3 Major Constraints
In this section we will discuss about the common testing, problem encountered
related constraint that may keep us from performing all tests necessary.
1. The team does not have enough time to test the software due to the different
schedule of each member of the team; we have access to testing during
available time of each member. So time schedule will be major constrain
when we talk about testing.
2. The team will have their own devices, but it will not deliver a quality service
needed and the team will be having software testing in their computers.
3. The team also don’t know about the any security to protect the software
4. The team has not been tested when software having a multiple user what will
happen and what will be the problem in software.
2.0 Testing Plan
2.1 Software (SCIs) to be tested
In this phases discuss about the modules to be tested. The team
wants to make sure that we will prepared to any errors detected
2.1.1 Interfaces
The test to carry on these interface windows are described below.
Login Window
We will make sure that the users access to the system , so will be testing
login window , We will also test OK and Cancel Buttons and attempt when
a user information entered is incorrect, on this window by performing the
test.
Main Menus Window
This is the main window that we will use to access the database using net
bean. We will several different drop-down menus in this window. File, Edit,
View, Help are the drop down menu that will be available in this window
we will try to use all the menus and then different option available in each
of the each.
File:
When file button clicked user will be shown 5 choices.
Import:
Import data into databases from back end bring to the system.
Export
Export data from the system convert to the Microsoft Office excel,
Microsoft Office Word and PDF file.
Print:
When select this choice will be able to print the specific wanted printed
report
Exit:
The function is to exit out the user.
Edit:
When edit button is clicked we be able to create a faculty load and
scheduling.
View
When select this button we have a several different drop-down menus in
this button you can view the faculty information’s, day, time, subject,
rooms and course for scheduling.
Help:
About us:
When we select these choices we will present with about software
information.
Contact us:
When we select this button you can see about the information about the
team.
Inspection
When inspection button is clicked user will be shown choices
Help
When we select this choice will be presented about the
2.2 Testing Strategy
In the following section we will describe the strategy. We will use four different
methods to test our product.
2.2.1 Unit Testing
In the unit test case will be testing individually. We will test the
components by passing data from front end to backend to find the errors.
The test primarily be carried out by the programmer who designed and
Implemented to module lead tester will than carry out test on the modules
to finalize the testing.
2.2.2 Integration Testing
The team is seeking a way to have a connection with each integrated
system. The team is seeking software that can be used to connect to each
other and secured the purpose it is useful to carry out properly the project
Integration testing is the procedure to connect to other computer
sand provides the needed requirement, in this method of testing we will
implement the software.
2.2.3 Validation Testing
The team will consider validation defines as the process of evaluating
software during or at the end of the development process to determine
whether it satisfies specified requirements.
The team says that the project succeeded when all designated
requirement and used the proper procedures and achieved the goal of this
project.
2.2.4 High-Order Testing
There are many different types of test there is the possibility of
Considerable redundancy across tests and the potential to waste effort.
We will test for several different conditions by following several different
test methods.
Recovery testing
Ability to retrieve or restore data lost in case of system shutdown of the
system it ceases.
Security testing
Having username and password. The report will be secured
Stress Testing
In this method of test try if the service provided by the software is enough
due to simultaneous use. The team ensure that the software service
provided is enough and avoid problem even use it simultaneous.
Performance Testing
In this method measure or test the service capacity and effectiveness
provided to the user and minimize stress level that is caused to user using
of our software.
2.3 Testing Resources
As of now only prototype do we have we will use several different
resources to carry out the test in software following is non-detailed
description of test resources. Even prototype just done. The team carried
out software testing the following is non-detailed description of the test
resources.
 Software Test by Adviser
 Software Test by team
2.4 Test Record Keeping
Test record keeping and Test work Product are described in section of the
Test Specifications Document. For information regarding these topics,
please refer to section 3.4 of the Test Specification Document.
2.5 Testing Tools and Environment
Testing tools will involve the computer resources form, with the help of
different team the finished project study will test succeeded in the test plan
using the combination of tools and equipment from the deferent integrate
team, The team will also use resources available to during software
development team outside of these two facilities.
2.6 Test Schedule
Following is the tentative schedule for the testing.
Project Test Plan
s
This part the team brainstorming about the project, planning for the system
development requirements, expenses, devices, system boundary ,
System Testing
September 1, 2014
This part the team tests the ability of the system, monitor the service
capacity provided and measure the speed of providing data to the server.
Integration Testing
Oct 25, 2014-Nov 12, 2014
Database Testing
Nov 15, 2014
3.0 Test Procedure
In this section we will describe the test procedure in detail.
3.1 Software (SCIs) to be tested
For detailed list of the software composed items please refer to section 2.1 from
Test Specification document.
3.2 Testing Procedures
In this section we will try to describe over all software specification. We will
describe the methods for the entire different test to be performed and will also
declare the expected output
3.2.1 Unit Test
In this method of testing, we will test the smallest unit of software called
modules. We will describe different test have been done.
Login Window
We will make sure several different names to log in to the system.
We will use correct and incorrect User Name and Password to
access the software and thus access database. The user we will
not allowed logging in using incorrect Username and Password and
the system show error message and if the user rich 3 attempt the
system will be exit when the user name and password is correct we
will able to log in be able to next window the Main menu. so here
we will also test OK and Cancel buttons on this window performing
test.
Menu Window
This is main menu window that will use to access the database
using java net beans. We will have several different drops down
menu in this window. File, Edit, View, Help are the drop down menu
that will be available in this window we will try to use all the menus
and having different option available in each of the window.
File:
When file button clicked user will be shown 5 choices.
Import
We will test the converting will be completed if the Import data into
databases from back end bring to the system.
Export
We will test the converting will be completed if the Export data from
the system convert to the Microsoft Office excel, Microsoft Office
Word and PDF file .
Print:
We want to use print button and to make sure that this will bring up
menu to send print job to desired printer. This should work without
any problem.
Exit
The function is to exit out the user. We want to make sure that user
logged out is or is able to exit out when exit button is selected we
will still test
Edit
We will test if the user edit and updated the selected data.
View
We will test if select this button if the several different drop-down
menus in this button is can view the faculty information’s, day, time,
subject, rooms and course for scheduling and give the specific
needed .
Help:
About us:
We will test if select these choices we will present with about
software information.
Contact us:
We will test if this button you can see about the information about
the team.
3.3.3 Testing Resources and Staffing
We need to have large number of resources available to us in order for us
to test the entire software properly. We will us help form several different
people to be able to.
Resources
-FLS Member
Team conducted an evaluation with the help of respective adviser’s proper
process of testing to attain project objectives as part of validation testing
and each member team will make sure that all testing have done will
recorded.
-Palm-Size Pc.
We will use the available Pc provided by each member of the team. The
pc test if it’s functioning, we need to assured that able transfer data to the
other computer. We will also test it to see if the data stored correct format
and data is not lost.
Test Record Keeping Log
We will use table created to the excel to log the entire test. Describe them
and to record the results of the test. Below is the example of such table.
The table will also be out test work product.