TR1332.docx

southdakotascrawnyΔιαχείριση Δεδομένων

29 Νοε 2012 (πριν από 4 χρόνια και 9 μήνες)

420 εμφανίσεις


1







COURSE

CURRICULUM

PLANNING

AND

MANAGEMENT

SYSTEM




MARIN RUDIC










School of Innovation, Design and Engineering

Subject:

Computer Science

Advanced level

30 ECTS Credits

Thesis advanced level, Computer Science

CDT504


Supervisor:

Ivica Crnkovic

Examiner:

Kristina Lundqvist

D
ate: 30.05.2012





2


DEDICATE


This thesis is dedicated to my beloved Family, Teachers and Friends.

Especially
for my parents and sister who wo
ke me

up

all those years.






3


ACKNOWLEDGMENT


I have
had
pleasure to work on this project. However, it would not
have
been so good and interes
ting without support and help of my
supervisor Mr. Ivica Crnkovic. I would like to extend my sincere
thanks to him, to IDT
School

at MDH and all colleagues. They
were

my
support in completion

of
this Master Thesis.





4


ABSTRACT


Curriculum planning is a co
mplex process with many stakeholders,
many parallel activities and many constraints. Due to the complexity
of the process the manual routines lead to many errors and
inconsistency which requires additional efforts and causes decreased
services to students
and teaching staff.

The goal of this project is to
build an information management system to support Curriculum
planning at MDH.

The project work includes collection of information about current
working processes, requirements analysis and data analysis,
m
odelling

current processes in information system and development
software which will implement all of those processes.

The central component of the system is a database on which are
connected functions used for input or presentation of data. The main
funct
ions of the system are web
-
based applications providing a
support for creating a new program, its maintenance, creation and
maintenance of courses, allocation of teaching staff to the courses.

This thesis includes a collection of requirements, design and
i
mplementation of the system, and its testing, discussion of issue
-
management systems, and give some proposal how this information
system can be further improved as an issue
-
management system.






5

TABLE OF CONTENTS

1.

INTRODUCTION

................................
................................
........

9

1.1.

Project motivation

................................
................................
..........

9

1.2.

Current problems

................................
................................
.........

10

1.3.

Thesis overview

................................
................................
...........

10

2.

DEVELOPMENT PROCESS
................................
....................

11

2.1.

Software prototyping development process

................................
.....

11

2.2.

Evolutionary prototyping process

................................
...................

12

2.3.

Prototyping of COSY information system

................................
.......

13

3.

REQUIREMENTS SPECIFI
CATION

................................
........

14

3.1.

Schema of current actions and users

................................
...............

14

3.2.

Requirements specification for COSY

................................
............

15

3.2.1.

Create program

................................
................................
...............................

15

3.2.2.

Create program instance

................................
................................
...................

15

3.2.3.

Approve program

................................
................................
.............................

16

3.2.4.

Approve program instance

................................
................................
................

16

3.2.5.

Edit program

................................
................................
................................
...

16

3.2.6.

Edit program instance

................................
................................
.......................

17

3.2.7.

Delete program

................................
................................
................................

17

3.2.8.

Delete program instance

................................
................................
...................

17

3.2.9.

Create course

................................
................................
................................
..

18

3.2.10.

Create course instance

................................
................................
......................

19

3.2.11.

Approve course

................................
................................
................................

19

3.2.12.

Approve course instance

................................
................................
...................

19

3.2.13.

Edit course

................................
................................
................................
......

19

3.2.14.

Edit courses instance

................................
................................
........................

20

3.2.15.

Delete course

................................
................................
................................
...

20

3.2.16.

Delete courses instance

................................
................................
.....................

20

3.2.17.

Create user

................................
................................
................................
......

20


6

4.

FIRST

PROTOTYPE ARCHITECTU
RE

................................
...

21

4.1.

Structure of the application

................................
............................

21

4.1.1.

The Front
-
end application

................................
................................
.................

21

4.1.2.

The Back
-
end application

................................
................................
..................

22

4.2.

User permissions

................................
................................
..........

23

4.3.

Module components

................................
................................
.....

24

4.3.1.

Filters

................................
................................
................................
.............

24

4.3.2.

Forms

................................
................................
................................
.............

24

4.3.3.

Database

................................
................................
................................
.........

24

5.

FIRST PROTOTYPE IMPL
EMENTATION

...............................

26

5.1.

The Back
-
end application implementation

................................
.......

26

5.1.1.

Program instance list

................................
................................
........................

27

5.1.2.

View/edit program instance

................................
................................
...............

27

5.2.

The Front
-
end application implementation

................................
......

28

5.2.1.

Program instance list

................................
................................
........................

29

5.2.2.

View program instance

................................
................................
.....................

29

5.2.3.

Add new / edit program instance

................................
................................
........

30

6.

ANALYSIS OF THE FIRS
T PROTOTYPE OF THE
APPLICATION

................................
................................
..............

31

6.1.

Description of the first prototype

................................
....................

31

6.2.

Strategy for next prototype

................................
............................

32

7.

CURRENT PROTOTYPE AR
CHITECTURE

...........................

33

7.1.

Application architecture

................................
................................

33

7.1.1.

COSY Application architecture

................................
................................
..........

34

7.1.2.

COSY core
................................
................................
................................
.......

35

7.2.

Users permissions

................................
................................
........

36

7.2.1.

WordPress users

................................
................................
..............................

36

7.2.2.

COSY core users

................................
................................
..............................

37


7

8.

CURRENT PROTOTYPE IM
PLEMENTATION
........................

38

8.1.

COSY module implementation

................................
......................

38

8.1.1.

Program instance list

................................
................................
........................

39

8.1.2.

Add new program instance

................................
................................
................

40

8.1.3.

View program instance

................................
................................
.....................

45

8.1.4.

Edit program instance module

................................
................................
...........

47

8.2.

WordPress implementation

................................
............................

48

8.2.1.

Pages structure

................................
................................
................................

49

8.2.2.

Module details

................................
................................
................................
.

50

8.3.

Database

................................
................................
................................
.........

51

8.3.1.

WordPre
ss database

................................
................................
.........................

51

8.3.2.

COSY core database

................................
................................
.........................

52

9.

ANALYSIS OF CURRENT
PROTOTYPE

................................

53

9.1.

Description of current prototype

................................
.....................

53

9.2.

Strategy for the next prototype

................................
.......................

54

10.

USED TECHNOLOGIES

................................
..........................

55

10.1.

PHP / MySQL

................................
................................
...........

55

10.1.1.

PHP

................................
................................
................................
...............

55

10.1.2.

MySQL
................................
................................
................................
............

56

10.1.3.

PHP and MySQL in combination

................................
................................
.......

57

10.2.

WordPress

................................
................................
................

57

10.2.1.

The History of WordPress

................................
................................
.................

58

10.2.2.

Requirements

................................
................................
................................
...

59

10.2.3.

Features

................................
................................
................................
..........

59

10.3.

WordPress plug
-
ins

................................
................................
...

62

10.3.1.

PHP Exec

................................
................................
................................
........

62

10.3.2.

Priv
ate only

................................
................................
................................
.....

62

10.3.3.

Role Scooper

................................
................................
................................
...

62

10.3.4.

Xili
-
language

................................
................................
................................
...

63

10.4.

HTML/CSS

................................
................................
..............

65


8

10.4.1.

Hypertext Markup Language (HTML)

................................
................................
.

65

10.4.2.

Cascading Style Sheets (CSS)

................................
................................
............

65

10.4.3.

HTML and CSS in combination

................................
................................
..........

66

10.5.

JQuery

................................
................................
.....................

67

10.5.1.

JQuery Core

................................
................................
................................
....

67

10.5.2.

JQuery UI

................................
................................
................................
.......

67

11.

GOING FORWARD

................................
................................
..

69

12.

CONCLUSIONS

................................
................................
.......

70

13.

REFERENC
ES

................................
................................
.........

71

14.

71

15.

SUPPLEMENTS

................................
................................
......

71





9

1.


INTRODUCTION

This thesis is about
production of

Course System (COSY)

information management system to
support Curriculum planning at MDH.
Course System
is
short of
C
ourse curriculum program
management system. The project COSY information system
includes collection of
information about current working processes, requirement
s analysis and data analysis,
modelling

current processes in information system and development software which will
implement all of those processes.

Current process of course curriculum program
management system is based on manual exchange of document usu
ally in
a
paper form

or

an

email exchange. Overview of available information about courses and programs documents
is not on satisfactory level. With COSY information system we want to improve accessibility
and overview of information and documents of curri
culum process.

1.1.

Project motivation

Motivation for this project is
to
improve
the
curriculum process which repeats
itself
every
academic year
at
MDH. Every academic year
MDH must publish
program of
the
next
academic year with all associated documentation whi
ch must
b
e public for all student
s

and
staff, and delivered to parent institution. Associated documentation must include all courses
and programs of that academic year.

All courses and programs must have documentation which
confirms

verification of
univer
sity

and parent institution.

If some course or a programme is just being introduced, it must first be confirmed by MDH
and after it has all verification from MDH, it must be approved from the parent institution.
Course or programme documentation usually e
xists in a paper form or as an email
communication.

In the other hand, i
f
some

course or programme

has already been held,

it
has

all
documentation but it is usually in
a
paper form or

an

email form
,

archived by some teacher
or secretary. There is no some
unique archive
containing
all
those

courses and programs
documents
.

Programs are
made

of some unique information and associated courses. Courses associated
with
a

program can
be
held

every a
cademic year once or more times or it may not be held at
all.
Every academic year can be specific but
a
program
stays

the
same. If we know that for
a

three year program there is one
study programme

for each year and there are many
programs on
a

university
.

W
e only can imagine
the possible

mess with all those papers.


And that is our motivation to make

COSY information system
to

improve that process.




10

1.2.

Current problems

Motivation of the project is to simplify the management and planning of the courses and
programs inside the university. The current system is based on communication through
emails and documenting the changes in an excel sheet.

The major problems of the cu
rrent system are:



there is no data management
system

(
Data management system care
s

about changes
in
the
data and privileges about changing some data
)



no validation in the data other than manual people work

(
There is no validation of
the
data
and it is possible to make some
collisions

or
loose

data by mistake
)



Lack of visualization of the data

(
Visualization of

the data through

excel sheets are usually
hard and it is impossible to make good relations between data, especially
if it is in di
fferent
datasheet)



presentation of the data is hard to read and analyze



the system does not provide tools
for

better manage
ment of the

courses, programs and assign
staff

(
There is no one place where

it

is possible to have overview of
the
data
,

and the
syst
em does not provide tools
that
can
change that
)

The aim of the project is to offer a web application that would solve these issues and provide
other functionality that would further increase the productivity of the people involved.

That is:



Provide

a simp
lified management of the data about courses, courses instances,
programs, program instances and staff by storing it and protecting it from unwanted
changes



Provide

visual aid to cope with the planning and management of academic year
.

1.3.

Thesis overview

The re
st of the thesis is organized as follows:
Chapter

2
describes
software prototype
development

process
.

Chapter

3
contains

project r
equirements specification
,

to clearly
understand
the
goals of this project. Chapter 4, 5 and 6 contain description of
the
first
application prototype.
Chapter

6 also contain
s

description of
the
strategy for
the
current
prototype which is descri
bed

in chapter 7, 8 and 9.

Chapter 7 descript architecture while
ch
a
pter 8 descript implementation of
the
current prototype. Analysis
of
the
architecture and
implementation is done in chapter 9. Chapter 10 contains description of used technologies.

Chapter 1
1

contains
the discussion
strategy for next prototype
based on

chapter 9

and
validity and suggestions for future work.

Chapter 12

co
ntains the conclusion
.






11

2.

DEVELOPMENT PROCESS

This chapter describes the process of production of the COSY project. When we are
mentioning the COSY project, on which production continually worked a few people, we can
talk about software prototyping method

of development.

Software prototyping refers to the activity of creating prototypes of software applications,
incomplete versions of the software program being developed. It is an activity that can occur
in software development and is comparable to prototy
ping as known from other fields, such
as mechanical engineering or manufacturing. A prototype typically simulates only a few
aspects of, and may be completely different from, the final product.

2.1.

Software prototyping development process

Understanding user re
quirements is an integral part of the information systems design and
is critical to the success of interactive systems. It is now widely understood that successful
systems and products begin with an understanding of the needs and requirements of the
users.

COSY information system is a user oriented information system with a thorough
understanding of the needs and requirements of the users.

Particular problems faced by the analyst are:



addressing complex organizational situations with many stakeholders



users and designers thinking along traditional lines, reflecting the current system and
processes, rather than being innovative



users not knowing in advance what do they want from the future system

Those problems are the reason to go on with the software
prototyping development concept
because it keeps us in a circular contact with the user, reducing the time available for the
user needs analysis and representing the user requirements in an appropriate form.


Figure
1
: Software pr
ototype model



12

The process of prototyping involves the following steps until the user is satisfied:



Identify basic requirements
-

Determine basic requirements including the input and the output
information desired. Details, such as security, can typically
be ignored.



Develop Initial Prototype
-

The initial prototype that includes only user interfaces is
developed.



Review

The customers, in this case our supervisor, examine the prototype and provide feedback on
additions or changes.



Revise and Enhance the Pro
totype
-

Using the feedback both the specifications and the
prototype can be improved. Negotiation about what is within the scope of the product may be
necessary. If changes are introduced then a repetition of the previous and this step may be
needed.

2.2.

Evol
utionary prototyping process

This project is produced in Evolutionary prototyping process. The main goal in using
Evolutionary Prototyping is to build a very robust prototype in a structured manner and
constantly refine it. The reason for this is that the
Evolutionary prototype, when built, forms
the heart of the new system, and then improvements and further requirements will be built.
When developing a system using Evolutionary Prototyping, the system is continually refined
and rebuilt. Evolutionary protot
yping acknowledges that we do not understand all the
requirements and builds only those that are well understood
[9]
. This technique allows the
developer to add features, or make changes that couldn't be conceived during the
requirements and design phase.

In Evolutionary Prototyping, developer is focused to develop parts of the system that he
understands instead of working on the development of th
e whole system.

Prototyping has several benefits: The software designer and implementer can get valuable
feedback from the users early in the project. The client and the contractor can compare if the
software made matches the software specification, accord
ing to which the software program
is built. It also allows the software engineer some insight into the accuracy of initial project
estimates and whether the deadlines and milestones proposed can be successfully met.




13

2.3.

Prototyping of COSY information syste
m

Evolutionary prototyping software development process is used by my supervisor and
previous developer on this project. I started working on the project when its first application
prototype was done. Description of first prototype is processed in chapters

4

First prototype
architecture

and
4

First prototype architecture

The prototype was created using PHP framework Symfony 1.4 with Doctrine. The MySQL
database management system is used and set
-
up based on tutorial
[17]
.

The symfony is running locally on WAMP server. The project itself is located at host server.

The information about database is provided in the following section. There is a MySQL
Workbench 5.2 CE connected to the database to help inspecting generate
d database.

Files and the module structure of the project
is

generated using terminal with
Symfony

scripts.

2.4.

Structure of the application

The main structure of the project was implied by the framework and it was kept consistent
throughout the project.

This

prototype of the application used a concept of dividing application in two applications:



Front
-
end application

This application will be used by all users and it has limited privileges to change data in
information system



Back
-
end application

This applicat
ion will be used by COSY administrator and users will have privileges to change
all data in the information system.

2.4.1.

The Front
-
end application

The Front
-
end application provides functionalities that are accessed by the common system
users for all their func
tions.

There are four main modules in the front
-
end of the application, like you can see on the
Figure
3
:
The main structure of COSY web system pages in the front
-
end of
application



Course


manage information data about courses



course instance
-

manage information data about course instances



program
-

manage information data about programs



program instance
-

manage information data about program insta
nces

Each module has several sub
-
folders:



actions



templates


14



one created by developer


config

The config was created in order to provide information of who has a permission to access the
module.

The following listing of user permissions will explain mai
n folders inside the project.



Figure
3
:
The main structure of COSY web system pages in the front
-
end of application

2.4.2.

The Back
-
end application

The Back
-
end application is intended to provide a possibility to manipulate data only for a
few privileged users (like administrator) and an access to the components of the
management system for groups, permissions, etc.


15



Figure
4
: The main structure of COSY web system pages in the back
-
end of application




16

2.5.

User permissions

Users are divided in six groups and each group has different privileges like it is showed in

Table
1
:

Permissions for user groups inside the system
.

Types of users in the system:



EL
-

Education Administrator and Education Leader (one role for the first iteration)



DV
-

Division Manager



PC
-

Program Coordinat
or



CR
-

Course Responsible Person



TA
-

Teacher & teacher assistant



A


Admin

Table
1
:

Permissions for user groups inside the system



EL

DV

PC

CR

TA

A

Create program

x









x

Create program instance

x



x





x

Approve program

x









x

Approve program instance

x









x

Edit program

x



x





x

Edit program instance

x



x





x

Delete program

x









x

Delete program instance

x



x





x

Create course

x

x

x

x

x

x

Create course instance

x

x

x

x



x

Approve course

x









x

Approve course instance

x









x

Edit course

x





x



x

Edit courses instance

x

x

x

x

x

x

Delete course

x









x

Delete courses instance

x

x

x

x



x

Create user











x

Edit user

x

x

x

x

x

x

Delete user











x





17

2.6.

Module

components

Inside of each module of the application next components are implemented:

2.6.1.

Filters

Filters are an important part of reducing the amount of results in screen. This helps the user
to find particular entries easier. File filters on a single table a
re easy to create. The
description of the filter is placed in
\
lib
\
filter
\
doctrine. The symfony documentation
provides information required to create them. On the other hand, it was messy when it
comes to filtering on tables with relations to other tables.

For example, the course instance
inherits the course name from a course table. In the course instance table the user would like
to filter on course name
and there

have emerged

many

problems
.

2.6.2.

Forms

Forms are a big part of the application and symfony provid
es lots of widgets to make
validation and presentation easier. As in all parts of symfony, executing forms on a single
database table is rather straight forward and adding some additional functionality from
other tables requires “merge” and “embedding” to
be correctly saved in the database.

2.6.3.

Database

This project is using Doctrine
-

PHP Object Persistence Libraries, which is part of Symfony
project. The MySQL database is called “cosy” and database ER diagram is presented on
(Some of the tables like user pr
ofile and program documents have been removed from
diagram in order to improve the readability).



schema.yml

This file contains description of the database tables and relations in YAML language. Simply
put, this is the database structure.

Location: config
\
doctrine
\
schema.yml



fixtures.yml

This file contains basic information to be loaded into the database in YAML language. Some
are required for the system to run (e.g. the possible user’s roles in the system) and the others
are there for the test purposes (du
mmy records).

Location: data
\
fixtures
\
fixtures.yml



databases.yml

This file describes the location, type and the connection details of the database to be created
and loaded for the project. The file is written in YAML language



18


Figure
5
: ER diagram of COSY application first prototype





19

First prototype implementation
. Analysis of that

prototype is done with the supervisor’s
consultation in the chapter
6

Analysis of the first prototype of

the application
.

That prototype of the application helps me in better understanding of the user’s needs and
necessary functionalities which must be supported. Also it gives me experience with the
prob
lems related with the implementation and usage of some tools, which we can improve
and correct inside the next prototype.




20

3.

REQUIREMENTS SPECIFI
CATION

This chapter
provides

detail
s

about current process of

the

curriculum planning at MDH

which yields

actions and requiremen
ts of COSY system. Requirement
s

specification in the
second article is

the result of the

analysis
of the
role and activity
showed
in

the

first article.

3.1.

Schema of current actions and users

Next figure
Figure
2
:
P
eople and activity in c
urrent process

describe
s

roles and activit
ies

during current process.


Administrator

Lecturer

Secretary

Management
Board

Education
Leader

Head of Division

Course Planning
Group

International
Coordinator

Configure

Import/Export Data

Define Program
Proposal

Program
Coordinator

Initiate New
Program Creation

Define Program
Curriculum

Approve Program
Curriculum

Define Program
Schedule

Define Program
Popular Description

Define Detailed
Program
Description

Define Courses
Involved in
Program

Define Program
Description for the
catalogue

Enters Data in DSI

Define Course Plans

Define New
Course

Cancel Courses

Define Course
Instance

Define Course
Plans

Manages Data of
Free Places and
Enrollment
Statistic
of Courses

Review/Accept
Course Plans

Figure
2
:
P
eople and activity in c
urrent process


21

3.2.

Requirements specification for COSY

Requirements are described w
ith identification of the necessar
y data and short description
on
how to fill that data.

3.2.1.

Create program

Data requirement:



Program code



T
itle (English), Title (Swedish)



Degree



School



Coordinator



Syllabus link



Language of Instructio
ns



Duration



Courses



Description
(English) Description
(Swedish)



Comment (English) Comment
(Swedish)

Description:

Input form must be in English and Swedish where the names of the form fields will be visible
on current active language, and if some field is select type of input field it will be in current
active language too. Courses
can dynamically add or
remove until form isn’t complete.


Fields: Title (English), Title (Swedish) Degree, School and Coordinator are required and
form can’t be complete
before that fields are filled
.

3.2.2.

Create program instance

Data requirement:



Program



Coordinat
or



Syllabus link



Academic year



Courses

Description:

Input form must be in English and Swedish where the names of the form fields will be visible
on current active language, and if some field is select type of input field it will be in
current
active language too. Course instances can dynamically added in information system from this
form with help in fill data if any previous interesting course instance exists in system.
Course instance can be connected with new program instance which
will be created in this
form.

Fields: Program,

Academic year

and Coordinator are required and form can’t be complete
before
those fields

are filled
.




22

3.2.3.

Approve program

Data requirement:



Status

Description:

Administrator and Education leader must have
privilege
s

to
change program

status
.

A
fter
program is once approved
it

is no
longer

possible to make changes on its data.

3.2.4.

Approve program instance

Data requirement:



Status

Description:

Administrator and Education leader must have
privilege
to
change
program instance

status.

A
fter program

instance

is once approved
it

is no
longer

possible to make changes on its data.

3.2.5.

Edit program

Data requirement:



Program code,



Title (English), Title (Swedish)



Degree,



School,



Coordinator,



Syllabu
s link,



Language of Instructions,



Duration,



Courses,



Description (English) Description
(Swedish)



Comment (English) Comment
(Swedish)

Description:

Input form must be in English and Swedish where the names of the form fields will be

visible
on current active language, and if some field is select type of input field it will be in current
active language too. Courses can dynamically add or remove until form isn’t complete.

Fields: Title (English), Title (Swedish) Degree, School and Co
ordinator are required and
form can’t be complete
before that fields are filled
. Edit form is accessible only if program
isn’t approved.




23

3.2.6.

Edit program instance

Data requirement:



Program,



Coordinator,



Syllabus link,



Academic year,



Courses,

Description:

Input form must be in English and Swedish where the names of the form fields will be visible
on current active language, and if some field is select type of input field it will be in current
active language too.
Course instances can dynamically added in information system from this
form with help in fill data if any previous interesting course instance exists in system.
Course instance can be connected with new program instance which will be created in this
form.

Fields: Program, Academic year and Coordinator are required and form can’t be
complete
before those fields are filled
. Edit form is accessible only if program instance isn’t
approved.

3.2.7.

Delete program

Description:

Deleting a

program is possible form
the
pag
e with full description about
the
program
,

and
system must ask
if the
user is sure about that action.

3.2.8.

Delete program instance

Description:

Delet
ing a

program instance is possible
from the

page with full description about

the

program instance
,
and system mu
st ask
if the
user is sure about that action.




24

3.2.9.

Create course

Data requirement:



Program code,



Title (English), Title (Swedish)



Level



Marks



Examination



Credits



Area of education



Subject



School



Responsible



Language of Instructions



Syllabus link



Main field of study



Prerequisites
(English),Prerequisites (Swedish)



Objectives (English),Objectives
(Swedish)



Learning objectives (English),
Learning objectives (Swedish)



Content (English), Content
(Swedish)



Teaching methods (English),
T
eaching methods (Swedish)



Workload (English), Workload
(Swedish)



Environmental aspects (English),
Environmental aspects (Swedish)



Other Regulations (English), Other
Regulations (Swedish)



Literature (English),Literature
(Swedish)



Comment



Valid from sem
ester



Valid from

Description:

Input form must be in English and Swedish where the names of the form fields will be visible
on current active language, and if some field is select type of input field it will be in current
active languag
e too. Examinations can dynamically add or remove until form isn’t complete,
if some examination is selected than it is required to all fields about that examination.
Credits of
course are sum of all selected examination credits.
Fields: Title (English),
Title
(Swedish)
, Level, Marks, Examination, Credits, Area of education, Subject, School,
Responsible and Prerequisites (English), Prerequisites (Swedish)
are required and form can’t
be complete before that fields

are filled
.
Valid from is date type of fiel
d.




25

3.2.10.

Create course instance

Data requirement:



Course



Estimated number of students



Actual number of students



Planned budget in hours



Workload



Staff



Location



Syllabus link




Academic year




Periods

Description:

Input form must be in English and Swedish where the names of the form fields will be visible
on current active language, and if some field is select type of input field it will be in current
active language too. Course instance can be made of any existing
course
.

Fields: Course,
planed budget in hours, Workload, location and Academic Year are required and form can’t
be complete
before those fields are filled
.

3.2.11.

Approve course

Data requirement:



Status

Description:

Administrator and Education leader must have
privilege to change
course
status
. A
fter
course

is once approved
it

is no
longer

possible to make changes on its data.

3.2.12.

Approve course instance

Data requirement:



Status

Description:

Administrator and Education leader must have privilege to change course ins
tance status
.
A
fter course instance is once approved
it

is no
longer

possible to make changes on its data.

3.2.13.

Edit course

Data requirement:



Same data as in
0

Create course

Description:

Same form description as in
0

Add new course, but p
age for edit data is accessible only while
course isn’t approved.




26

3.2.14.

Edit courses instance

Data requirement:



Same data as in
0

Create course instance

Description:

Same form description as in
0

Create cour
se instance, but page for edit
ing the

data is
accessible only while course isn’t approved.

3.2.15.

Delete course

Description:

Deleting a
course is possible
from the

page with full description about
course, and

system
must ask
the
user
if it
is sure about that
action.

3.2.16.

Delete courses instance

Description:

Delet
ing a
course instance is possible
from the

page with full description about course
instance
,

and system must ask
the
user
if it
is sure about that action.

3.2.17.

Create user

Data requirement:



Us
ername



E
-
mail



First Name



Last Name



Password



Confirm password



Send password



User group

Description:

Administrator can add
a
new user
s
, this form do
esn
’t
have to

be
in English and Swedish.

Fields: Username, email, password, confirm
password and user group are required field and
form can’t be complete before
those

fields

are filled
.
Generating

of
the
password and send
ing

connection data to
the
new user by email

are required functionalities
.




27

4.

FIRST PROTOTYPE ARCH
ITECTURE

The prototype was created using PHP framework Symfony 1.4 with Doctrine. The MySQL
database management system is used and set
-
up based on tutorial
[17]
.

The symfony is running locally on WAMP server. The project itself is located at host server.

The information about database is provided in the following section. There is a MySQL
Workbench 5.2 CE connected to the database to help inspecting generate
d database.

Files and the module structure of the project
is

generated using terminal with
Symfony

scripts.

4.1.

Structure of the application

The main structure of the project was implied by the framework and it was kept consistent
throughout the project.

This

prototype of the application used a concept of dividing application in two applications:



Front
-
end application

This application will be used by all users and it has limited privileges to change data in
information system



Back
-
end application

This applicat
ion will be used by COSY administrator and users will have privileges to change
all data in the information system.

4.1.1.

The Front
-
end application

The Front
-
end application provides functionalities that are accessed by the common system
users for all their func
tions.

There are four main modules in the front
-
end of the application, like you can see on the
Figure
3
:
The main structure of COSY web system pages in the front
-
end of
application



Course


manage information data about courses



course instance
-

manage information data about course instances



program
-

manage information data about programs



program instance
-

manage information data about program insta
nces

Each module has several sub
-
folders:



actions



templates



one created by developer


config

The config was created in order to provide information of who has a permission to access the
module.

The following listing of user permissions will explain mai
n folders inside the project.


28



Figure
3
:
The main structure of COSY web system pages in the front
-
end of application

4.1.2.

The Back
-
end application

The Back
-
end application is intended to provide a possibility to manipulate data only for a
few privileged users (like administrator) and an access to the components of the
management system for groups, permissions, etc.



Figure
4
: The main structure of COSY web system pages in the back
-
end of application




29

4.2.

User permissions

Users are divided in six groups and each group has different privileges like it is showed in

Table
1
:

Permissions for user groups inside the system
.

Types of users in the system:



EL
-

Education Administrator and Education Leader (one role for the first iteration)



DV
-

Division Manager



PC
-

Program Coordinat
or



CR
-

Course Responsible Person



TA
-

Teacher & teacher assistant



A


Admin

Table
1
:

Permissions for user groups inside the system



EL

DV

PC

CR

TA

A

Create program

x









x

Create program instance

x



x





x

Approve program

x









x

Approve program instance

x









x

Edit program

x



x





x

Edit program instance

x



x





x

Delete program

x









x

Delete program instance

x



x





x

Create course

x

x

x

x

x

x

Create course instance

x

x

x

x



x

Approve course

x









x

Approve course instance

x









x

Edit course

x





x



x

Edit courses instance

x

x

x

x

x

x

Delete course

x









x

Delete courses instance

x

x

x

x



x

Create user











x

Edit user

x

x

x

x

x

x

Delete user











x





30

4.3.

Module

components

Inside of each module of the application next components are implemented:

4.3.1.

Filters

Filters are an important part of reducing the amount of results in screen. This helps the user
to find particular entries easier. File filters on a single table a
re easy to create. The
description of the filter is placed in
\
lib
\
filter
\
doctrine. The symfony documentation
provides information required to create them. On the other hand, it was messy when it
comes to filtering on tables with relations to other tables.

For example, the course instance
inherits the course name from a course table. In the course instance table the user would like
to filter on course name
and there

have emerged

many

problems
.

4.3.2.

Forms

Forms are a big part of the application and symfony provid
es lots of widgets to make
validation and presentation easier. As in all parts of symfony, executing forms on a single
database table is rather straight forward and adding some additional functionality from
other tables requires “merge” and “embedding” to
be correctly saved in the database.

4.3.3.

Database

This project is using Doctrine
-

PHP Object Persistence Libraries, which is part of Symfony
project. The MySQL database is called “cosy” and database ER diagram is presented on
(Some of the tables like user pr
ofile and program documents have been removed from
diagram in order to improve the readability).



schema.yml

This file contains description of the database tables and relations in YAML language. Simply
put, this is the database structure.

Location: config
\
doctrine
\
schema.yml



fixtures.yml

This file contains basic information to be loaded into the database in YAML language. Some
are required for the system to run (e.g. the possible user’s roles in the system) and the others
are there for the test purposes (du
mmy records).

Location: data
\
fixtures
\
fixtures.yml



databases.yml

This file describes the location, type and the connection details of the database to be created
and loaded for the project. The file is written in YAML language



31


Figure
5
: ER diagram of COSY application first prototype





32

5.

FIRST PROTOTYPE IMPL
EMENTATION

This chapter describes the structure of the COSY information system implemented in
Symfony framework as one module
of
a back
-
end and
front
-
end application
. The
front
-
end

application is visible for all users

and they can use

all functionalities.
The back
-
end
application is visible only for administrators which can use all functionalities of front
-
end
and back
-
end application.

5.1.

The Back
-
end application implementatio
n

The back
-
end application is generated by symfony framework and it
has

unfinished design.
On homepage

Figure
6
: Back
-
end application homepage

is visibl
e that there
are

more
options
than

in front end application describe
d

in

the

next chapter
Figure
9
: COSY
homepage
.



Figure
6
: Back
-
end application homepage




33

5.1.1.

Program instance list

After click on Program Instances button in main menu information system taking
Figure
7
:
Program instance module

screen.


Figure
7
: Program instance module

5.1.2.

View/edit program instance

After click on some program instances on the list of existing program instances in
Figure
7
:
Program instance module

screen page view/edit selected program instance data will be
shown
Figure
8
: Program instance view/ edit module
.


Figure
8
: Program instance view/ edit module



34

5.2.

The Front
-
end application implementation

In this chapter one module of COSY application of first prototype will be presented, the same
module as will be presented for the current prototype implementation to se difference
between first and current implementation. Analysis of first prototype is written in detail in
the next chapter and those in this chapter will not be discussion about it.

The

project

design

is

created

as

suggested

by

framework,

using

decorator

design

pa
ttern

and

a

combination

of

HTML

and

CSS.

The

main

layout

is

described

in

main.css

layout

for

front
-
end.

The

logo

was

created

using

font

“Jokerman”.

Homepage
with the logo
is visible on
Figure
9
: COSY homepage
.



Figure
9
: COSY homepage




35

5.2.1.

Program instance list

After click on Program Instances but
ton in main menu information system taking
Figure
10
:
Program instance module

screen.


Figure
10
: Program instance module

5.2.2.

View

program instance

After click on some program instances on the list of existing program instances in
Figure
10
:
Program instance module

screen page

with detail information about selected program
instance will be shown
Figure
11
:
View program instance module
.


Figure
11
:
View program instance module




36

5.2.3.

Add new / edit program instance

By click on “Edit” button under main menu on the
Figure
11
:
View program instance
module

screen page edit program instance module will be shown
Figure
12
: Edit program
instance module
.


Figure
12
: Edit program instance module




37

6.

ANALYSIS OF THE FIRS
T PROTOTYPE OF THE
APPLICATION

Evolutionary Prototyping software development is a group of software d
evelopment methods
based on iterative and incremental development, where requirements and solutions evolve
through collaboration. It promotes adaptive planning, evolutionary development and
delivery, a time
-
boxed iterative approach, and encourages rapid an
d flexible response to
change. It is a conceptual framework that promotes foreseen interactions throughout the
development cycle.

6.1.

Description of the first prototype

Symfony is an Object
-
Oriented framework and it prefers to manipulate objects whenever it is

possible. For example, instead of writing SQL statements to retrieve records from the
database it is preferred to use objects.

The relational database information is mapped in an object model. This can be done with an
ORM tool and thankfully, Symfony come
s bundled with two of them: Propel and Doctrine.

The description model of the database used in the project provides adding new columns or
tables in the database and relations between tables without any problems. But the problem
comes in defining the displa
y and manipulation of data.

Project was developed following the step by step directions of official tutorial of Symfony
framework based on development of the “Jobeet” application.

Within the documentation there is description on how to make multi language
applications
using Symfony framework. At the beginning of the project the use of multiple languages was
not anticipated, all description was how to make one language site. The adaptation of the
web pages for multiple languages is on the end of the demo pro
ject described through
translation of the names of some links and categories that are manually entered into the
database via a file with initial data in the database. There is no dynamics that we need and
there are no more tutorials which can help us to ma
ke everything what we need in COSY
project.

Symfony framework is based on MVC (Model View Control) model and generating View and
Control parts according to database Model of application thus reduces the dynamics of
manipulation with forms. Making customize
d forms and available data in forms thought
description files is more complicated than simple use of PHP and HTML and some solutions
are impossible to make because they are not provided by Symfony.

Symfony framework’s advantage in production of forms and t
heir validation though object
oriented modes is in serialization and readability of source code but it reduces the necessary
freedom to manipulate the data in this project.

This application requires a complete operation and manipulation of multi
-
language d
ata.
Current solution implemented with Symfony is unusable because the used framework in the
project should allow easier and faster operations.


38

I can’t certainly say that given the requirements it isn’t possible to implement the project
using Symfony frame
work, but this solution is useless because it is taking too much time to
discover the possible advanced options to implement specific requirements.

6.2.

Strategy for next prototype

Database model of application implemented with Symfony generated useful relation

database with main structure of tables but tables don’t contain all necessary data columns.

There are many others software solutions that we can use instead of the Symfony framework
and reuse the database generated with Symfony to make changes according
to the selected
solution and missing data.

Solutions that impose itself instead of the Symfony framework are Drupal, WordPress and
specially made CMS for this application. CMS (Content management system) is a computer
system that allows publishing, editi
ng, modifying content and its structure from a central
page independent of application functionality.

The biggest difference between WordPress and Drupal is that Drupal is a Content
Management System, and WordPress was initially a blog engine. This means D
rupal
assumes that there will be many different kinds of users with various levels of control who
are administering a website, and WordPress assumes there will be only one.

WordPress has moved into CMS space, because most people who started off as simply
bloggers have realized that they need more than just a blog, but they already have experience
with WordPress and they are familiar with its
interface. Similarly
, Drupal needs additional
modules to be installed and configured to get exactly the same functio
nality as a WordPress
blog, and considerable time would be needed to do setup and configuration.

We selected WordPress because Drupal is more complicated with user level privileges, i.e.
solution with multiple administrator types that we don’t need on thi
s project. There is only
one level of developer administrator which has access to CMS and privileges to change data
and structure of application. Also we need a welcome page of the application organized like a
blog page where administrator can put news rel
ated to the application, what WordPress
makes more practical option.

WordPress provides us with enough good tools to manage
contents of a webpage.

Making own CMS is discarded because it will take more time than first two solutions and
also it will be more

complicated to build upon in the future for a new developer.

Drupal and WordPress support Multilanguage sites and its structure is of the critical
meaning for this project.

In the next iteration idea is to improve filters on the course, course instances,
programs and
program instances pages to work without refreshing the page. Distribution on front
-
end and
back
-
end application which exists, because it was complicated to present different user
interface to different users, will be abolished and implemented
as one application which
enables that functionality.


39

7.

CURRENT PROTOTYPE AR
CHITECTURE

7.1.

Application architecture

Application is working in a client server architecture based on the HTTP protocol. HTTP
defines a request
-
response protocol in the client
-
server c
omputing model. A web browser,
for example, may be the client and an application, Apache server in this case, running on a
computer hosting a web site is the server. The client submits an HTTP request message to
the server. The server process request forwa
rds it on associated PHP applications which like
result make HTML and other content, or performs other functions on behalf of the client,
returns a response message to the client. The response contains completion status
information about the request and ma
y also contain requested content in its message body.
HTTP is designed to permit intermediate network elements to improve or enable
communications between clients and servers.







Client

Web browser

Server

Apache


Web server (servis)

PHP modul

MySQL server (servis)

request

response


SQL qureys

Database

COSY Applicaton

HTTP

Figure
13
:
Client server architecture


40

7.1.1.

COSY Application architecture

Apache web server forwards HTTP request to COSY
application based on the request’s
message which contains some data used by COSY application. The data that are interesting
for COSY application are in the URL and the post field. URL contains data for navigation on
the web pages mostly used from WordPress

application which is back
-
end part of COSY
application. WordPress is used like a CMS and it takes care about navigation through
modules of COSY core application and currently used language.






COSY application

WordPress

COSY core

Users

Courses

Course Instances

Programs

Program Instances

Users

Admin

Figure
14
: COSY application architec
ture


41

7.1.2.

COSY core

COSY core is core of course and program management information system. It contains
courses, course instances, program, program instances, users and admin modules which
contain its sub modules responsible for

each action of parent module.




All modules are made based on the same pattern to

simply understand concept of work and
file structure of each module. List module presenting table with short description of course,
program or other data for which is that module responsible. View module presenting full
data, edit module provides changing

of data while Add new provide insert new data in
information system.


Module:



List
-

table view of data



View


full data description



Edit


edit data



Add new


add new data





COSY core

Courses

Course Instances

Programs

Program Instances

Users

Admin

Figure
15
: COSY core application architecture


42

7.2.

Users permissions

Users permissions are changed instead of users permissions
used in first prototype described
in the

Table
1
:

Permissions for user groups inside the system
. In this prototype user permissions
can be observed fro
m two points. First point of observation is from WordPress which
observes the users in a two groups, administrators and COSY users, with possibility that an
administrator is COSY user too. Second point of observation is from COSY core, which
observes users

in a few groups depending on a role in the information system.

7.2.1.

WordPress users

In this chapter we will see how WordPress observes users of the information system and
which privileges do they have in the WordPress application.

WordPress uses a concept of R
oles, designed to give the administrator the ability to control
and assign what users can and cannot do on the page or in CMS. An administrator can
manage and allow access to such functions as writing and editing posts, creating Pages,
defining links, crea
ting categories, moderating comments, managing plug
-
ins, managing
themes, and managing other users.

WordPress has five pre
-
defined Roles:



Administrator



Editor



Author



Contributor



Subscriber

Each Role is allowed to perform a set of tasks called Capabilitie
s
[7]
.

In this case WordPress is configured to have users divided in two groups:



Administrators



COSY users

Administrators

have full access to perfo
rm all possible Capabilities
[7]

in WordPress and
administrator role in COSY core system too, which grants them full privileges.

COSY users

don’t ha
ve access to WordPress and don’t have direct access to any Capability.
They only can indirectly access to



add_users



create_users



promote_users



list_users



remove_users



delete_users

Capabilities through COSY core are available if their role in COSY core all
ows that.




43

7.2.2.

COSY core users

In this chapter we will describe how COSY core application observes users and which
privileges they have in the core of information system. Privileges are a little changed since
the first prototype, instead of privileges used
in the first prototype described in

Table
1
:

Permissions for user groups inside the system
.

Types of users and capabilities of each group of users in
the system are represented in

Table
2
: COSY users and privileges
:



A
-

Administrator



EL
-

Education administrator and Education Leader



DV
-

Division manager



TA
-

Teacher and teacher assistant


Table
2
: COSY users and privileges



A

E
L

DV

TA


PC

CR

Create program

X

X










Create program instance

X

X






X



Approve program

X

X










Approve program instance

X

X










Edit program

X

X






X



Edit program instance

X

X






X



Delete program

X

X










Delete
program instance

X

X






X



Create course

X

X

X

X




Create course instance

X

X





X

Approve course

X

X










Approve course instance

X

X










Edit course

X

X








X

Edit courses instance

X

X





X

Delete course

X

X










Delete
courses instance

X

X







X

Create user

X




X








Edit user

X



X





Delete user

X




X









Separated groups:



PC
-

Program Coordinator



CR
-

Course Responsible Person

In
Table
2
: COSY users and privileges

descript

privileges of a user from any group who is
selected for responsible person for some course or program.




44

8.

CURRENT PROTOTYPE IM
PLEMENTATION

In this chapter structure of COSY

information system implemented in WordPress backend
application and one module of COSY core application

are described
. COSY core application
is visible for all users but all u
sers can’t use all functionalities,

it depend
s

on

the

user role and
privileges l
ike it is described in
Error! Reference source not found.
. Also descript
features in WordPress application are visible only for administrator user.

8.1.

COS
Y

module implementation

In this chapter program instances module of COSY information system

is described
.
All
COSY modules visible on
Figure
15
: COSY core application architecture

are made on the
same pattern so there is no need to describe each modules individually.

After signing up in
the COSY information system user is located on

Figure
16
: COSY homepage

from where he
can go to any module.

Program

instances

module is selected because it is the most
complicated module and uses parts of other modules, which will be described too. Also
description is

made for administrator accounts that some options will not be visible or
permitted if you are signed in the system from other non
-
administrator account.



Figure
16
: COSY homepage





45

8.1.1.

Program insta
nce list

After click on Program Instance button in main menu information system taking
Figure
17
:

Program instance list module

screen.


Figure
17
:

Program instance list module

Module presenting the table with the list of existing program instances in the database. Table
content is sortable by all columns and searchable through text input in the top right corner of
table. Content of the t
able is automatically filtered with the search criteria, independently of
which data column satisfies it.

These features are made with the DataTables jQuery plug
-
in. DataTables operates on the
principle of progressive enhancement, whereby an enhanced and
interactive table will be
presented to the end user if their browser has the required capabilities. When you initialize
the jQuery.dataTable object, information about the table is read directly from the HTML
page.




46

8.1.2.

Add new program instance

After clicking on “Add Program Instance” button located in the top left corner of the table
with list of existing program instances visible on
Figure
17
:

Program instance list module

user is redirected on the add new program instance page visible on
Figure
18
: Add new
program instance form
.


Figure
18
: Add new program instance form

Module presenting input form for add
ing a

new program instance in
the
system. To create
new program instance we must first select Program from which we want to make
the
program instance. It
can be done
by

select
ing

one of existing programs or program instance.

Click on
a

button “Select program” will pop up dialog visible on
Figure
19
: Select program
dialog

or “Select program instance” will pop up dialog visible on
Figure
20
: Select program
instance dialog
.


Figure
19
: Select program dialog


Figure
20
: Select program instance dialog



47

We can see similarit
ies
between
the
content of
these

two dialogs and list modules because
they are in close re
lation with list modules. Search
ing

and sort
ing

of data in

the

dialog
is

possible.

After
a
user select
s

one of
the
program
s

or program instance
s,

data
in the
form will be
changed

like it is
shown

on
Figure
21
: Add new program instance form after select
program or program instance
. If
a

program is selected
,

than input form will
show

selected
program data and list of all courses related to that program. I
n other case when
a

program
instance is selected there will be program data of
the
program contain
ed

in that program
instance. On the courses list
there
will be only courses from which selected program instance
contains course instance.


Figure
21
: Add new program instance form after select program or program instance

It is always possible to add some course on the list again

by click
ing

on
the
button “Add
course” and select
ing

it in the dialog

in
Figure
22
: Add course in table dialog
.


Figure
22
: Add course in table dialog

Course is on the list in the dialog if it is contained in selected program list

of courses
.




48

Program instance represents program of one specific academic year with specific course
instances for that year.
A
program instance do
es
n’t
have to

contain all courses of some
program and
nor does it have to

contain same courses each year.
Co
urses have some specific
data each academic year and there can be more same courses
in the

same academic year with
different specific data those COSY system have course

instances. Program instance will be

related
to

course instances

added in list of course
s in Add new program instance form
.

Relation between program instance and course instance can be associated by click
ing on

“New instance” on course
,

if we want associate program instance with instance of course
which still do
es
n’t exist, or “Select Instanc
e” if that course instance already exist in
information system.


Figure
23
: Create course instance dialog

If the user
click
s

on “New
instance” it will pop up dialog shown
in

Figure
23
: Create course
instance dialog


which contain
s form to input data for

new course instance. That form will
have default values from existing course instance in association with selected program

instance in dialog on
Figure
20
: Select program instance dialog

if the user has previously
made that action or it will be empty if the user select
s a

program in dialog
Figure
19
: Select
program dialog
.



49


Figure
24
: Select course instance to gat data

Independent is a user se
lect program or program instance in dialog
Figure
23
: Create course
instance dialog

is possible to click on button “Existing course instance” and get data from
selected course instance in dialog on
Figure
24
: Select course instance to gat data

to form in
Figure
23
: Create course instance dialog
.


Figure
25
: Select user dialog

In
the
form on
Figure
23
: Create course instance dialog

it
is possible to associate users in
information
system with
a

course instance
. By click on “Add Staff” button dialog