12 lines
No EOL
6.8 KiB
TeX
12 lines
No EOL
6.8 KiB
TeX
\chapter{Συμπεράσματα}
|
||
Το αποτέλεσμα της εκπόνησης της εργασίας αυτής είναι ένα πλήρης σύστημα διαχείρισης ραντεβού, το οποίο μπορεί να παραμετροποιηθεί επαρκώς έτσι ώστε να καλύψει τις ανάγκες οποιασδήποτε επιχείρισης ανεξαρτήτου ειδικότητας και μεγέθους. Ο αρχικός σχεδιασμός αποδείχθηκε σωστός και έτσι το τελικό προϊόν πληροί τις απαιτήσεις για τις οποίες αναπτύχθηκε.
|
||
|
||
\section{Προβλήματα}
|
||
Σημαντικότερο πρόβλημα σχετικά με την υλοποίηση της εφαρμογής ήταν η χρονική καθυστέρηση μιας και ανάμεσα στην ανάληψη της εργασίας και την περαίωση της, πραγματοποιήθηκε η πρακτική άσκηση σε εταιρεία πληροφορικής, καθώς και εργασία εκτός σχολής με άλλες εταιρείες πληροφορικής. Οι εξωτερικές υποχρεώσεις αυτές αποσπούσαν την συνεχή και ομαλή ανάπτυξη, κάτι που συνεχώς διασπούσε τον ειρμό και τον δημιουργικό οίστρο. Συμπέρασμα αυτού του σημαντικού προβλήματος είναι ότι θα πρέπει να γίνεται σαφής και ορθός προγραμματισμός του χρόνου υλοποίησης ενός έργου γιατί διαφορετικά οι πιθανότητες για χαμηλότερη ποιότητα υπηρεσίας ή ακόμα και αποτυχίας του έργου αυξάνονται εκθετικά.
|
||
|
||
Όσον αφορά την συνεργασία του συστήματος με την υπηρεσία Google Calendar, αλλά και γενικότερα με άλλες πιθανές υπηρεσίες το ζήτημα παραμένει στο πως θα παραμείνουν τα δεδομένα ακέραια και ενημερωμένα και στα δύο συστήματα, όταν δεν υπάρχει ένα κοινό μέσο αποθήκευσης. Το θέμα γιγαντώνεται μάλιστα όταν δεν υπάρχει πρόσβαση στον κώδικα του ενός από τα δύο συστήματα έτσι ώστε να δημιουργηθεί μια "γέφυρα δεδομένων". Για την επίλυση αυτού του θέματος ήταν αναγκαίο να δημιουργηθεί ένας αλγόριθμος συγχρονισμού ο οποίος θα ενεργοποιούνταν από την πλευρά του Easy!Appointments και θα αναλάμβανε την ενημέρωση και τον δύο συστημάτων με τα τελευταία δεδομένα. Για αυτόν τον σκοπό θα έπρεπε να καταγραφούν και να υλοποιηθούν κάποιοι κανόνες συγχρονισμού οι οποίοι θα μετέφεραν επιτυχώς τα ραντεβού αμφίδρομα και στα δύο συστήματα. Στις περιπτώσεις όπου η μεταφορά αυτή θα ήταν αδύνατη (σύγκρουση δεδομένων) ο χρήστης θα έπρεπε να αποφασίσει ποια εκδοχή των δεδομένων θα υπερισχύσει στο τέλος.
|
||
|
||
Ένα ακόμα πρόβλημα που αντιμετωπίστηκε κατά την διάρκεια την ανάπτυξης του έργου ήταν ο διαχωρισμός των δικαιωμάτων των χρηστών μέσα στο σύστημα. Ο κάθε χρήστης αναλόγως το είδος του (διαχειριστής, πάροχως, γραμματέας) έχει διαφορετικές δυνατότητες και δικαιώματα στα δεδομένα που αποθηκεύονται από το σύστημα. Αυτό συμβαίνει γιατί στις περισσότερες περιπτώσεις θα πρέπει να τηρηθεί η ιεραρχία της επιχείρησης, αλλά και επίσης γιατί θα πρέπει να διασφαλιστεί η ακεραιότητα των δεδομένων από τυχόν εσφαλμένες ενέργειες χρηστών σε βασικές ρυθμίσεις του συστήματος. Για τις κυριότερες ρυθμίσεις απαιτούνται τα δικαιώματα διαχειριστή και έτσι το σύστημα χρειάζεται απαραιτήτως πάντα έναν χρήστη διαχειριστή (ο χρήστης που δημιουργείται κατά την εγκατάσταση είναι ουσιαστικά ο πρώτος διαχειριστής της εφαρμογής). Για να λυθεί αυτό το πρόβλημα η εγγραφή του κάθε χρήστης στην βάση δεδομένων συνδέεται με έναν ρόλο, ο οποίος περιέχει τα δικαιώματα που του αντιστοιχούν. Έτσι για παράδειγμα ένας χρήστης που προορίζεται για πάροχος υπηρεσίας, θα έχει τα δικαιώματα που αντιστοιχούν στον ρόλο "Πάροχος Υπηρεσίας", όπως αυτά είναι αποθηκευμένα στην βάση δεδομένων. Έτσι κάθε φορά που συνδέεται ένας χρήστης στο διαχειριστικό κομμάτι της εφαρμογής τα δεδομένα σχετικά με τα δικαιώματα του και τον ρόλο του διαβάζονται από σελίδα σε σελίδα και η εφαρμογή μπορεί και γνωρίζει με ποιόν τρόπο θα πρέπει να εμφανιστούν τα δεδομένα και ποιες ενέργειες είναι διαθέσιμες στην κάθε περίπτωση.
|
||
|
||
\section{Εξέλιξη Της Εφαρμογής}
|
||
Όπως και σε κάθε έργο λογισμικού υπάρχουν πολλά πράγματα τα οποία μπορούν να εξελιχθούν και να βελτιωθούν, καθώς και δυνατότητες οι οποίες μπορούν να προστεθούν για να κάνουν την εφαρμογή πιο εύχρηστη και εύκολη προς την χρήση. |