DOCX

nuthookransomBiotechnology

Dec 10, 2012 (4 years and 11 months ago)

609 views

Copyright © 2009 by Elia Kouzari


Διπλωματική

Εργασία

θέμα

Authorship Identification
Methods




Επιβλέπων Καθηγητής:
Σταμέλος

Ιωάννης

Φοιτήτρια:
Κουζάρη

Έλια

ΑΕΜ:
1375



Τμήμα Πληροφορικής, Αριστοτέλειο Πανεπιστήμιο Θεσσαλονίκης

Οκτώβριος
2009

Authorship Identification Methods


Page
ii


Περιεχόμενα

Περιεχόμενα

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

ii

Πλάνο

Εργασίας

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

iii

1.

Software

Forensics

................................
................................
................................
...................
1

1.1

Ορισμός

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

1

1.2

Σκοπός

και

κίνητρα

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

1

1.3

Εφαρμογές

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

2

1.4

Ανάλυση κώδικα

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

3

1.5

Θέματα

εξέλιξης

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

6

2.

Software

Component

Reuse

................................
................................
................................
....
8

2.1

Σκοπός

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

8

2.2

Συστατικά Λογισμικού

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

9

2.3

Επαναχρησιμοποίηση Λογισμικού

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

9

2.4

Στρατηγικές Επαναχρησιμοποίησης Συστατικών Λογισμικού

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

13

2.5

Συμπεράσματα

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

15

3.

Ανάπτυξη
Λογισμικ
ού

Ανοικτού Κώδικα

................................
................................
............
1
6

3.1

Τι προσφέρει

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

1
6

3.2

Προτεινόμενη διαδικασία ανάπτυξης

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

17

3.
3

Χαρακτηριστικά
που παρουσιάζονται

στα έργα ανοικτού κώδικα

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

19

3.4

Ρόλοι της ομάδας ανάπτυξης σε γνωστά έργα ανοικτού κώδικα

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

21

3.5

Γενικά

συμπεράσματα


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

24

4.

Μέθοδοι

αναγνώρισης

συγγραφέα

κώδικα


................................
................................
.........
2
5

4.1

Εισαγωγή

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

25

4.2

The Source Code Author Profile Method (SCAP)

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

26

4.
3

Αναγνώριση

συγγραφέα

μέσω

πιθανοτήτων

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

27

4.
4

Χρήση μετρικών εντροπίας

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

29

4.
5

Αναγνώριση συγγραφέα μέσω ανακάλυψης
αντιγραφής

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

3
1

4.
6

Ιστογράμματα και Γενετικοί αλγόριθμοι

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

3
2

4.
7

Νευρωνικό δίκτυο ταξινόμησης

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

33

5.

Μέθοδοι

αναγνώρισης

συγγραφέα

κειμένου

................................
................................
.......
35

5.1

Εισαγωγή

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

35

5
.
2

Extensible Method

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

36

5
.
3

Chi Square Method

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

37

5
.
4

Author
Identification from Citations
................................
................................
..............................

38

5.5

Bayesian

Multinomial

Logistic

Regression

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

40

5.6

Δειγματοληψία κειμένο
υ για την αναγνώριση συγγραφέα

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

41

5
.
7

Ακολουθίες αναγνωριστικών

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

42

6.

Πειράματα
................................
................................
................................
...............................
45

6.1

Εισαγωγή

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

45

6.2

Source

Code

Author

Profile

Method

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

45

6.3

Αναγνώριση

συγγραφέα

μέσω

πιθανοτήτων

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

48

6.4

Ιστογράματα

και

Γενετικοί

αλγόριθμοι

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

50

6
.
5

Chi Square Method

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

52

6
.
6

Author Identification from Citations
................................
................................
..............................

53

6.7

Bayesian

Multinomial

Logistic

Regression

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

55

6.8

Δειγματοληψία

κειμένου

για

την

αναγνώριση

συγγραφέα

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

5
9

6
.
9

Ακολουθίες αναγνωριστικών

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

61

7
.

Συμπεράσματα
................................
................................
................................
........................
63

7
.1

Σύγκριση Μεθόδων αναγνώρισης συγγραφέα κώδικα

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

63

7
.2

Σύγκριση Μεθόδων αναγνώρισης συγγραφέα κειμένου

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

64

7.3

Συμπεράσματα

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

66

Παράρτημα

A
:
Αναφορές

-

Βιβλιογραφία

................................
................................
.................
67

Authorship Identification Methods


Page
iii


Πλάνο Εργασίας

Ενότητα 1:
Software

Forensics

Στην πρώτη ενότητα της εργασίας παρουσιάζεται η έννοια του
Software

Forensics
.
Συγκεκριμένα, μελετάται ο σκοπός του, οι λόγοι που οδήγησαν στην εδραίωσή του στον τομέα
του λογισμικού καθώς και οι τρόποι με τους οποίους μπορεί να πραγματοποιηθεί μια σε βάθος
μελέτη κώδικα ενός προγράμματος.

Ενότητα

2:
Software

Component

Reuse

Στην εν
ότητα αυτή γίνεται μια σύνδεση με τα συστατικά κώδικα και τη σημασία που αυτά
προσδίδουν στην ανάπτυξη ενός συστήματος. Ακολούθως, τονίζεται η σημασία της
επαναχρησιμοποίησης τέτοιων συστατικών τόσο σε έργα κλειστού όσο και ανοικτού λογισμικού
καθώς και τρ
όποι με τους οποίους αυτό γίνεται εφικτό.

Ενότητα

3:
Ανάπτυξη Λογισμικού Ανοικτού Κώδικα

Όσον αφορά την ανάπτυξη λογισμικού ανοικτού κώδικα γίνεται μια σε βάθος μελέτη της
προτεινόμενης διαδικασίας ανάπτυξης καθώς και στα ιδιαίτερα χαρακτηριστικά που φαίνε
ται να
βοηθούν στην επιτυχία των έργων αυτών. Παρουσιάζονται στη συνέχεια οι διάφοροι ρόλοι που
μπορεί να έχουν τα μέλη της κοινότητας σε συγκεκριμένα μεγάλα έργα ανοικτού λογισμικού
παίρνοντας έτσι μια ιδέα στο ποσοστό συμμετοχής του καθενός στην ολοκλήρω
ση ενός έργου.

Ενότητα

4:
Μέθοδοι αναγνώρισης συγγραφέα κώδικα

Τόσο σε αυτή την ενότητα όσο και στην επόμενη παρουσιάζονται οι κύριες μέθοδοι
αναγνώρισης συγγραφέα. Η τρέχουσα λοιπόν ενότητα πραγματεύεται με αυτές που αφορούν
την αναγνώριση συγγραφέα σε επ
ίπεδο κώδικα. Συγκεκριμένα
,
αναλύονται

οι

μέθοδοι
:



Source

Code

Author

Profile

Method

(
SCAP
)



Αναγνώριση συγγραφέα μέσω πιθανοτήτω
ν



Χρήση μετρικών εντροπίας



Αναγνώριση συγγραφέα μέσω ανακάλυψης αντιγραφής



Ιστογράμματα και Γενετικοί αλγόριθμοι



Νευρωνικό
δίκτυο ταξινόμησης






Authorship Identification Methods


Page
iv


Ενότητα

5:
Μέθοδοι αναγνώρισης συγγραφέα κειμένου

Στην ενότητα αυτή που ακολουθεί τις μεθόδους αναγνώρισης συγγραφέα σε επίπεδο κώδικα
αναφέρονται όλες οι υπόλοιπες μέθοδοι που αφορούν την αναγνώριση συγγραφέα σε επίπεδο
κειμένου
πλέον. Συγκεκριμένα

αναλύονται

οι

μέθοδοι
:



Extensible

Method



Chi

Square

Method




Author

Identification

from

Citations




Bayesian

Multinomial

Logistic

Regression




Δειγματοληψία κειμένου

για την αναγνώριση συγγραφέα





Ακολουθίες αναγνωριστικών
.

Ενότητα 6:
Πειράματα

Στην ενότητα αυτή παρουσιάζονται πειραματικές μελέτες που έχουν γίνει για την πλειοψηφία
των μεθόδων που έχουν αναφερθεί στις δύο προηγούμενες ενότητες με σκοπό την καλύτερη
κατανόηση της λειτουργίας και αποδοτικότητας της κάθε μιας.

Ενότητα 7:
Συμπεράσματα

Τέλος, στην τελευταία ενότητα της εργασίας γίνεται μια σύγκριση των μεθόδων μεταξύ
τους
σύμφωνα με τον τρόπο λειτουργίας της κάθε μιας ξεχωριστά
. Εξετάζεται που υστερεί η κάθε μια
και σε ποιες περιπτώσεις ενδείκνυται η εφαρμογή της. Κλείνοντας
, γίνεται μια σύνοψη σε όλα τα
θέματα που αναπτύσσονται στην εργασία καθώς και εισηγήσεις για μελλοντική εργασία στο
θέμα αυτό.



Authorship Identification Methods


Page
1


1.

Software

Forensics



1.1

Ορισμός

Με τη συνεχή ανάπτυξη της τεχνολογίας και ειδικότερα των κλάδων της Πληροφορικής, γίνεται
ολοένα και εντονότερη η ανάγκη για τον έλεγχο του λογισμικού που χρησιμοποιούν οι προσωπικοί
μας υπολογιστές. Είναι χιλιάδες πλέον οι περιπτώσεις της καθημερινής παρα
βίασης των
προσωπικών δεδομένων των χρηστών που γίνονται στόχοι κακόβουλου λογισμικού.

Είτε πρόκειται για ιούς,
worms
,
ή και
Trojan

horses

το αποτέλεσμα είναι ένα: παράνομη και
κακόβουλη πρόσβαση στο σύστημα. Τις περισσότερες φορές, έχει αποδειχθεί ότι ο
χρήστης
αντιλαμβάνεται την «εισβολή» εφόσον αυτή έχει ολοκληρωθεί όμως αυτό που οι περισσότεροι δεν
γνωρίζουν είναι ότι στο σύστημα εξακολουθούν να παραμένουν κομμάτια του κώδικα που
προκάλεσε τη ζημιά βοηθώντας έτσι στην εξακρίβωση της ταυτότητας του συγγ
ραφέα του

στην
περίπτωση που υπάρχουν καταχωρημένα προφίλ με πληροφορίες για τον ίδιο συγγραφέα
.

Με τον όρο
software

forensics

εννοούμε την ανάλυση του
κακόβουλου
κώδικα που παραμένει
στο
σύστημα μετά την επίθεση εξετάζοντας συγκεκριμένα χαρακτηριστικά του

που σκοπό έχουν να
χρησιμοποιηθούν στην κατασκευή ενός αντιπροσωπευτικού για το συγγραφέα προφίλ το οποίο
στη συνέχεια θα ταυτοποιήσει το συγγραφέα σε περίπτωση που υπάρχει ήδη δείγμα γραφής από
τον ίδιο στη βάση δεδομένων
[1]
. Στο πεδίο αυτό περιλαμβάνον
ται οι περιοχές που αφορούν τη
διάκριση
,
ταυτοποίηση και το χαρακτηρισμό του συγγραφέα (
author

discrimination
,
identification

and

characterization
)

καθώς
και την πρόσθετη ανάλυση του κώδικα

σχετικά με το αν εσκεμμένα
δημιούργησε πρόβλημα ή όχι
.


1.2

Σκοπός
και κίνητρα

Κυριαρχεί η άποψη ότι
ένας από τους παράγ
οντες που προσελκύουν

τα ηλεκτρονικά εγκλήματα
και τις κακόβουλες επιθέσεις είναι η ανωνυμία που αυτά προσφέρουν. Αυτό συμβαίνει γιατί όποια
μέθοδος και αν χρησιμοποιηθεί για μια επίθεση, είναι πολύ δύσκ
ολο να εντοπιστεί στη συνέχεια με
ακρίβεια αυτός που την προκάλεσε. Για το λόγο αυτό, οι συγγραφείς των ιών τους διανέμουν
ανενόχλητοι παντού χωρίς
την ανησυχία να αναγνωριστούν αυτοί ως δημιουργοί τους.

Οποιαδήποτε έρευνα και προσπάθεια στην αντιμετώπιση

αυτού του προβλήματος, όπως η
ανάπτυξη ισχυρών πρωτοκόλλων, αποθαρρύνουν προσωρινά τους επίδοξους χάκερς αλλά χωρίς
επιτυχία. Δυστυχώς, στην προσπάθεια αυτή τροχοπέδη είναι το οικονομικό κόστος αλλά και η
αποτελεσματικότητα, η οποία ποτέ δεν θα μπορέσει ν
α αγγίξει το 100% υπό οποιεσδήποτε
προϋποθέσεις.

Συνήθως, ο κώδικας που παραμένει στο σύστημα μετά από κάποια επίθεση περιλαμβάνει τις
αρχικές εντολές που
δόθηκαν

στο σύστημα με σκοπό να προκαλέσουν τη ζημιά που είχαν ως
σκοπό.

Ως παράδειγμα αναφέρεται ότ
ι ο κώδικας που αφήνουν στο πέρασμά τους οι ιοί βρίσκεται
στα προγράμματα και στα αρχεία τα οποία έχει προσβάλει. Αυτά τα κατάλοιπα λοιπόν του κώδικα
μπορεί να έχουν διάφορες μορφές. Σε κάποιες περιπτώσεις είναι αρχεία πηγαίου κώδικα,
εκτελέσιμος κώδικας ή

ακόμα και αρχεία κειμένου γραμμένα από τον ίδιο τον επιτιθέμενο. Θα ήταν
Authorship Identification Methods


Page
2


επομένως χρήσιμο αν αυτού του είδους οι πληροφορίες μπορούσαν να χρησιμοποιηθούν για τον
εντοπισμό του δημιουργού
τους σε περίπτωση που υπάρχει ήδη αποθηκευμένη πληροφορία και
αφορά
τον συγκεκριμένο
.

Παρόμοια γίνεται και η ανάλυση χειρόγραφων κειμένων από νομικές υπηρεσίες για εξακρίβωση
των δραστών σε υποθέσεις εξιχνίασης εγκλημάτων. Η ανάλυση των χειρόγραφων κειμένων
περιλαμβάνει
την αναγνώριση χαρακτηριστικών του κειμένου
τα οποία

μπορούν να διακρίνουν το
συγγραφέα ενός κειμένου ανάμεσα σε άλλους υποψήφιους δημιουργούς του. Ένα χαρακτηριστικό
μπορεί να διακρίνει έναν συγγραφέα από τους υπόλοιπους αν παρουσιάζει μικρές διαφορές
ανάμεσα σε κείμενα του ιδίου συγγραφέα και μεγάλες δια
φορές ανάμεσα σε κείμενα άλλων
συγγραφέων. Ανεξάρτητα όμως από την ύπαρξη ή όχι τέτοιων χαρακτηριστικών, απαιτείται
μεγάλος αριθμός δειγμάτων κειμένων του ιδίου συγγραφέα για να μπορέσει κάποιος να καταλήξει
σε ασφαλή και αξιόπιστα αποτελέσματα.

Ανάλογα,
και στην ταυτοποίηση κώδικα μπορούν να χρησιμοποιηθούν τέτοια χαρακτηριστικά
. Ο
προγραμματισμός (ειδικότερα σε γλώσσες πλούσιες σε τύπους και δομές δεδομένων) μπορεί να
παρουσιάσει ποικιλία και καινοτομ
ίες. Οι προγραμματιστές πολλές φορές αγνοούν ότι ο καθ
ένας
έχει το δικό του προσωπικό στυλ που αναπτύσσει κώδικα και ότι μέσω ανάλυσης αυτού μπορεί να
εντοπιστεί η ταυτότητα του συγγραφέα του. Για να γίνει όμως αυτό χρειάζεται επίμονη μελέτη και
ανάλυση πολλών δειγμάτων κώδικα του ιδίου συγγραφέα καθώς και αν
αγνώριση των
χαρακτηριστικών που στην πλειοψηφία των περιπτώσεων μπορούν να διακρίνουν τους
συγγραφείς (αναφέρονται στην ενότητα 1.4).


1.3

Εφαρμογές
[2]

1.3.1

Διάκριση του συγγραφέα του κώδικα

(
Author

Discrimination
)

Αυτού του είδους η εργασία αφορά την απόφαση κατά

πόσο συγκεκριμένα κομμάτια
κώδικα έχουν γραφεί από το ίδιο άτομο ή από ομάδα αρκετών ατόμων. Μια τέτοια
απόφαση μπορεί να περιλαμβάνει τον υπολογισμό

του αριθμού των ατόμων που
ασχολήθηκαν με τη συγγραφή του συγκεκριμένου κώδικα καθώς και το ποια κομμάτια

γράφτηκαν από το ίδιο άτομο. Για να μπορέσει να γίνει αυτό, χρειάζονται επιπλέον
υπολογισμοί μέτρου ομοιότητας μεταξύ

2 ή περισσότερων τμημάτων κώδικα καθώς και
υπολογισμοί όσον αφορά την «απόσταση» (τη διάκριση) μεταξύ διαφορετικών τμημάτων
κώδικα.

Σε γε
νικές γραμμές, όταν πρόκειται για διάκριση

συγγραφέα περισσότερο ενδιαφέρον
παρουσιάζει

το ποσοστό

βεβαιότητας ότι συγκεκριμένα κομμάτια κώδικα γράφτηκαν από
διαφορετικό συγγραφέα τ
ο καθένα παρά

το ποιος είναι ο κάθε συγγραφέας και ποιο τμήμα
έχει γράψει
ο καθένας.



1.3.2

Ταυτοποίηση του συγγραφέα του κώδικα (
Author

Identification
)

Ο σκοπός αυτής της εργασίας είναι ο καθορισμός της πιθανότητας ένας συγκεκριμένος
συγγραφέας να έχει γράψει ένα συγκεκριμένο αριθμό κομματιών κώδικα. Για να μπορέσει
αυτό να γίνει, πρέπει να υπάρχουν
διαθέσιμα

κομμάτια κώδικα αντιπροσωπευτικά για τον
συγκε
κριμένο συγγραφέα.

Επίσης,
παρόμοια διαδικασία ακολουθείται

και για την ταυτοποίηση ενός τμήματος κώδικα
κάποιου άγνωστου συγγραφέα με κάποιο από τα διαφορετικά τμήματα κώδικα μιας ομάδας
Authorship Identification Methods


Page
3


συγγραφέων. Ακριβώς σε αυτό βασίζεται και η ανάθεση ενός προγράμματ
ος ιού σε
κάποιον συγγραφέα με του οποίου ο συγκεκριμένος κώδικας ταιριάζει στο ήδη υπάρχον
προφίλ.

1.3.3

Χαρακτηρισμός του συγγραφέα του κώδικα (
Author

Characterization
)

Η εργασία αυτή βασίζεται στον εντοπισμό κάποιων ιδιαίτερων χαρακτηριστικών του
προγραμματι
στή όπως η προσωπικότητα και το εκπαιδευτικό υπόβαθρο βασιζόμενοι στο
προγραμματιστικό του στυλ. Εξάλλου, είναι σχετικά εύκολο να αναγνωρίσει κανείς αν ένα
κομμάτι κώδικα φανερώνει ιδιαίτερη εκπαίδευση και δυσκολία παρατηρώντας τη μορφή του
κώδικα και τις
τεχνικές που χρησιμοποιούνται σε αυτόν.


1.3.4

Καθορισμός σκοπιμότητας του συγγραφέα του κ
ώδικα
(
Author

intent

Determination
)

Είναι πιθανό σε κάποιες περιπτώσεις να
εξακριβωθεί

κατά πόσο ένα τμήμα ενός
προγράμματος είχε κάποια αστοχία ή κάποια ανεπιθύμητη εξέλιξη σκοπίμως ή όχι. Σε αυτή
τη λογική βασιζόμαστε στο ότι κανένα πρόγραμμα και ποτέ δεν μπορεί να είναι εντελώς
αλάνθαστο. Συνεπώς, κάποια από τα λάθη που αυτό θα περιλαμβά
νει θα έχουν κάποιες
φορές καταστροφικές συνέπειες εν αγνοία του συγγραφέα του.


1.4

Ανάλυση κώδικα

Οι

τεχνικές

που

χρησιμοποιούνται

στην

ανάλυση

λογισμικού

δεν

ασχολούνται

απλά

με

τα

αρχεία

πηγαίου

κώδικα

του

δημιουργού

του

προγράμματος
.
Αυτό συμβαίνει συνήθως λόγω του ότι ο
πηγαίος κώδικας μεταγλωττίζεται σε
object

code

που με τη σειρά του συνδέεται με τέτοιο τρόπο
ώστε να αποτελέσει τον εκτελέσιμο κώδικα. Αυτό τον εκτελέσιμο κώδικα είναι που εντοπίζουμε στα
αρχεία του υπολογιστή μας μετά

την επίδραση κάποιου κακόβουλου προγράμματος.
Κατά
συνέπεια, με ανάλυση αυτού του εκτελέσιμου κώδικα γίνονται οι προσπάθειες εντοπισμού του
συγγραφέα του.

Βέβαια, είναι δυνατή η μετατροπή του εκτελέσιμου κώδικα σε πηγαίο με συνέπεια όμως την
απώλεια πληρο
φορίας αφού οι μεταγλωττιστές βελτιστοποιούν τον κώδικα και αντικαθιστούν τα
ονόματα των μεταβλητών με διευθύνσεις μνήμης ή ονόματα καταχωρητών.

1.4.1

Ανάλυση εκτελέσιμου κώδικα

Όπως προαναφέρθηκε, τις περισσότερες φορές τα απομεινάρια κακόβουλου κώδικα που
παρ
αμένουν στο σύστημα είναι εκτελέσιμος κώδικας. Δυστυχώς, πολλά από τα
χαρακτηριστικά του κώδικα που θα μπορούσαν να χρησιμοποιηθούν για ανάλυσή του
έχουν πλέον εξαλειφτεί κατά τη μεταγλώττιση. Ως αποτέλεσμα των αλλαγών αυτών ο
εκτελέσιμος κώδικας παρουσιάζ
ει πλέον διαφορετική δομή απ’ ότι είχε στην πηγαία του
μορφή.

Παρ’ όλες τις αλλαγές, τα κομμάτια εκτελέσιμου κώδικα εξακολουθούν να παρουσιάζουν
αρκετά χαρακτηριστικά που βοηθούν στην ανάλυσή του. Τα πιο σημαντικά αναφέρονται
στη συνέχεια:




Δομές Δεδομένω
ν και Αλγόριθμοι

Authorship Identification Methods


Page
4


Από την ανάλυση του εκτελέσιμου κώδικα μπορούν να φανερωθούν οι προτιμήσεις του
προγραμματιστή

σε συγκεκριμένες δομές δεδομένων με τις οποίες έχει περισσότερη
εξοικείωση. Αυτού του είδους παρατηρήσεις μπορούν να οδηγήσουν σε αξιόπιστα
συμπ
εράσματα σχετικά με το υπόβαθρο του συγγραφέα του κώδικα. Για παράδειγμα, είναι
σχεδόν αδύνατο να υποπτευθεί κανείς έναν αρχάριο προγραμματιστή ως το συγγραφέα
κώδικα με εκτεταμένη χρήση Β
-
δένδρου ως δομή αποθήκευσης.

Ανάλογα και με τους αλγορίθμους που
χρησιμοποιούνται στον κώδικα μπορούμε να
καταλήξουμε σε παρόμοια συμπεράσματα, αφού συνηθίζεται ο προγραμματιστής να
χρησιμοποιεί στον κώδικά του αλγορίθμους με τους οποίους είναι πιο σίγουρος.



Μεταγλωττιστής και πληροφορίες Συστήματος

Τα κομμάτια εκτελέσι
μου κώδικα συνήθως περιλαμβάνουν κάποιες πληροφορίες που
«προδίδουν» την καταγωγή τους. Για παράδειγμα, μια συγκεκριμένη διάταξη των εντολών
που εκτελούνται μπορεί να είναι σημάδι ενός συγκεκριμένου
μεταγλωττιστή υποδεικνύοντας
έτσι την πηγή του. Επιπρόσθε
τα, ο κώδικας μπορεί να περιλαμβάνει κλήσεις συστήματος
που χρησιμοποιούνται μόνο σε συγκεκριμένα λειτουργικά συστήματα. Έτσι, στο σύνολό
τους αυτές οι πληροφορίες μπορούν να ταυτοποιήσουν τον συγγραφέα του κώδικα.



Προγραμματιστικές ικανότητες και Γνώση τ
ου συστήματος

Μια ακόμα σημαντική πληροφορία που μπορεί κανείς να διαπιστώσει μετά από ανάλυση
του εκτελέσιμου κώδικα είναι και το επίπεδο εξειδίκευσης του συγγραφέα του
προγράμματος σε σχέση και με το λειτουργικό σύστημα αλλά και με τον προγραμματισμό
γεν
ικότερα. Προγράμματα που παρουσιάζουν χρήση αναδρομής, κλήσεις σε εξελιγμένες
λειτουργίες συστήματος και επαναχρησιμοποίηση κώδικα φανερώνουν το επίπεδο
ικανοτήτων των συγγραφέων τους.


Επίσης, ανάλογη πληροφορία μπορεί να δώσει και η παρουσία κώδικα ελέγχ
ου λαθών στο
πρόγραμμα. Ο συγγραφέας του κώδικα ή θα χρησιμοποιεί πάντα κώδικα ελέγχου
λειτουργίας ή θα χρησιμοποιεί σπάνια (σχεδόν ποτέ). Σε περιπτώσεις που ο συγγραφέας
χρησιμοποιεί κώδικα ελέγχου, είναι πολύ πιθανόν αυτός να χρησιμοποιείται πάντα για το
ν
έλεγχο παρόμοιων λειτουργιών. Έτσι, κοιτάζοντας τις ρουτίνες που ελέγχονται
μπορεί να
εξακριβωθεί και η

ομάδα των ατόμων στην οποία θα μπορούσε να βρίσκεται και ο
δημιουργός της.



Κλήσεις Συστήματος

Οι συναρτήσεις συστήματος που χρησιμοποιούνται στον κώδικα φανερώνουν επίσης
πληροφορία σχετικά με τις γνώσεις του συγγραφέα. Για παράδειγμα, σε κάποια λειτουργικά
συστήματα υπάρχουν περισσότερες από μια συναρτήσεις για την ίδια λειτουργία.
Είναι
λοιπόν επ
όμενο ο ίδιος προγραμματιστής να χρησιμοποιεί συνήθως μόνο μια από αυτές
στα προγράμματά του και όχι διαφορετικές συνεχώς. Επομένως, οι προτιμήσεις σε πιο
«έξυπνες» ή και πιο ευέλικτες συναρτήσεις να φανερώνουν περισσότερη εμπειρία του
συγγραφέα.



Λάθη στο
ν κώδικα

Είναι γνωστό ότι οι προγραμματιστές ακόμη και στα πιο προσεκτικά διορθωμένα
προγράμματα κάνουν λάθη. Επιπλέον, ένας προγραμματιστής έχει την τάση να κάνει
συνεχώς το ίδιο λάθος σε κάποιες συγκεκριμένες εντολές. Αυτό μπορεί να περιλαμβάνει
είτε την

αρχικοποίηση κάποιων μετρητών είτε τα ορθογραφικά λάθη στις εντολές
εκτύπωσης ακόμα και η έξοδος από τους βρόγχους επανάληψης. Μελετώντας λοιπόν τον
κώδικα, τέτοια λάθη είναι εύκολο να διακρίνουν το συγγραφέα ενός προγράμματος από
άλλους για τους οποίους
δεν υπάρχουν αναφορές για τις συγκεκριμένες «παραλείψεις».

Authorship Identification Methods


Page
5


1.4.2

Ανάλυση πηγαίου κώδικα

Σε αντίθεση με την ανάλυση του εκτελέσιμου κώδικα, η ανάλυση πηγαίου κώδικα μπορεί να
προσφέρει πολύ πλούσια βάση προγραμματιστικών χαρακτηριστικών τα οποία
διευκολύνουν σε μ
εγάλο βαθμό την αναγνώριση του συγγραφέα. Τα πιο σημαντικά
αναφέρονται στη συνέχεια.




Γλώσσα Προγραμματισμού


Η γλώσσα προγραμματισμού είναι ίσως το πιο εμφανές στοιχείο στην ανάλυση του κώδικα
ενός προγράμματος. Αυτό που δεν είναι τόσο εμφανές ίσως είναι το γεγονός ότι υπάρχουν
κάποιοι λόγοι για τους οποίους η γλώσσα αυτή έχει προτιμηθεί από τον εκάστοτε
συγγραφέ
α. Κάθε γλώσσα προγραμματισμού έχει διαφορετικά επίπεδα ασφάλειας και
αξιοπιστίας, διαφορετικές κλήσεις σε λειτουργίες του συστήματος και διαφορετική
προσέγγιση σε συναρτήσεις ανάλογα με το λειτουργικό σύστημα. Επίσης, υπάρχουν και
γλώσσες που είναι πιο πο
λύπλοκες από κάποιες άλλες ή που αξιοποιούνται καλύτερα από
προγραμματιστές με μεγάλη πείρα. Έτσι, ανάλογα με τους
υποψήφιους

συγγραφείς
μπορούμε να συμπεράνουμε ποιος προγραμματίζει σε ποια γλώσσα (ανάλογα βέβαια και
με τα δείγματα κώδικα που έχουμε από τ
ον καθένα).



Μορφοποίηση


Η μορφοποίηση του κώδικα φανερώνει σχεδόν πάντα ένα πολύ προσωπικό στυλ
προγραμματισμού για τον κάθε προγραμματιστή. Έρευνες έχουν δείξει ότι ακόμα και σε
διαφορετικά προγράμματα γραμμένα από τον ίδιο προγραμματιστή το στυλ παραμέν
ει
σταθερό. Το στυλ του κάθε συγγραφέα καθορίζεται από τον τρόπο που χρησιμοποιεί για τη
δήλωση των εντολών (μια εντολή ή περισσότερες ανά γραμμή), τον τρόπο που δηλώνει τις
μεταβλητές και τα ορίσματα των συναρτήσεων και πολλά άλλα χαρακτηριστικά.



Ειδικοί

χαρακτήρες και εντολές


Κάποιοι μεταγλωττιστές υποστηρίζουν τη χρήση
pragmas

ή ειδικών
macros

που δεν
υπάρχουν σε όλα τα συστήματα. Η παρουσία οποιωνδήποτε από αυτών των εντολών
προσδίδει στοιχεία σχετικά με το περιβάλλον ανάπτυξης λογισμικού που χρησιμοπ
οίησε ο
συγγραφέας. Παρόμοιες πληροφορίες μπορούν να εξαχθούν με τη χρήση συγκεκριμένων
εντολών δήλωσης και αρχικοποίησης αρχείων.



Σχόλια


Κάθε

συγγραφέας

έχει

το

δικό

του

τρόπο

να

συμπεριλαμβάνει

(
ή

όχι
)
σχόλια

στον

κώδικά

του
.
Κάποιοι προγραμματιστές τοποθετούν σχόλια μιας γραμμής στο τέλος κάθε εντολής,
άλλοι τοποθετούν ολόκληρες παραγράφουν με σχόλια πάνω από κάθε συνάρτηση, ενώ
άλλοι δεν χρησιμοποιούν σχεδόν καθόλου σχόλια.

Η συχνότητα και το επίπεδο λεπτομέρειας των σχολίων

σε ένα πρόγραμμα είναι επομένως
διακριτικό του συγγραφέα του και έτσι με χρήση κατάλληλων μέτρων υπολογισμού μπορεί
να εντοπιστεί η ομοιότητα ή όχι ανάμεσα σε διαφορετικά προγράμματα.



Ονομασία και δήλωση μεταβλητών

Ίσως ένα από τα πιο σημαντικά στοιχεία
στην ανάλυση κώδικα είναι ο τρόπος με τον οποίο
δηλώνονται οι μεταβλητές του προγράμματος αλλά και τα ονόματα που αυτές έχουν.
Υπάρχουν προγραμματιστές που συνηθίζουν να ενώνουν τις διαφορετικές λέξεις μιας
μεταβλητής με κάτω παύλα (για παράδειγμα
first
_
co
unter
) ενώ άλλοι προτιμούν να
γράφουν με κεφαλαίο το πρώτο γράμμα της κάθε λέξης (για παράδειγμα
FirstCounter
)
.
Ανάλογα με την πολυπλοκότητα του προγράμματος και επομένως και το επίπεδο
Authorship Identification Methods


Page
6


προγραμματισμού του συγγραφέα, μπορεί μπροστά από κάθε μεταβλητή να τοποθετείται
και ένδειξη για τον τύπο της (για παράδειγμα
intFirstCounter
).

Ανεξάρτητα όμως από αυτού του είδους την ονομασία υπάρχουν και προγραμματιστές που
θέλουν να κρατούν τα ονόματα

των μεταβλητών τους όσο γίνεται πιο σύντομα.
Συνοψίζοντας λοιπόν τα πιο πάνω, η χρήση της κατανομής των
Hamming

αποστάσεων
μεταξύ των ονομάτων των μεταβλητών μπορεί να αποδειχθεί πολύτιμη για την αναγνώριση
του συγγραφέα.



Ορθογραφία και Σύνταξη

Χωρίς να
αποτελεί ένα από τα κυριότερα χαρακτηριστικά που βοηθούν στην αναγνώριση
του συγγραφέα, η ορθογραφία και η σύνταξη κυρίως των σχολίων μπορεί να είναι
καθοριστική. Το ιδιαίτερο στυλ του κάθε προγραμματιστή μπορεί να γίνει αρκετά ευδιάκριτο
αν υπάρχουν δείγμ
ατα προηγούμενων προγραμμάτων του.
Αντιπροσωπευτικός μπορεί να
είναι ο τρόπος γραφής (με συντομογραφίες ή χωρίς), τα κενά μεταξύ των λέξεων (ένα ή
δύο), η γλώσσα γραφής των σχολίων κτλ.



Χρήση των χαρακτηριστικών της γλώσσας προγραμματισμού

Ο τρόπος με τον
οποίο οι συγγραφείς χρησιμοποιούν την γλώσσα προγραμματισμού
μπορεί επίσης να τους διακρίνει μεταξύ τους. Κάποιοι προγραμματιστές μπορεί να
επιμένουν να χρησιμοποιούν συνεχώς μια ομάδα χαρακτηριστικών της γλώσσας (όπως
κάποιο συγκεκριμένο βρόγχο επανάληψης
) ακόμα και αν υπάρχει η δυνατότητα να
χρησιμοποιηθεί κάποιος άλλος στη θέση του ενώ κάποιοι άλλοι μπορεί να χρησιμοποιούν
με την ίδια συχνότητα όλες της δυνατότητες της γλώσσας.

Κάτι ανάλογο συμβαίνει και με τον τρόπο επιστροφής των τιμών από συναρτήσεις στο
κυρίως πρόγραμμα, με τους τύπους δεδομένων που δηλώνονται από τους
προγραμματιστές καθώς και με τη δημιουργία των δομών αποθήκευσης των δεδομένων.
Επίσης, η επιλογή για χρήση
αναδρομής εμπίπτει και πάλι στις ικανότητες του συγγραφέα
ο οποίος μπορεί να την χρησιμοποιήσει ή και να την αγνοήσει εντελώς.



Λάθη στον κώδικα (
Bugs
)

Κάποιοι

προγραμματιστές

συνεχώς

κάνουν

τα

ίδια

λάθη

στον

κώδικα

τους
.

Συνήθως, αυτά
τα λάθη δεν δημιουργ
ούν πρόβλημα κατά την εκτέλεση του προγράμματος, αλλά μπορεί να
τερματίσουν με λάθος τιμές στις μεταβλητές τύπου μετρητή. Για το λόγο αυτό, αφού στο
τέλος ενός προγράμματος σπάνια ενδιαφέρεται κανείς για τις τιμές κάποιων μετρητών, ο
συγγραφέας μπορεί συνε
χώς να επαναλαμβάνει το ίδιο λάθος. Ως αποτέλεσμα, ακόμη και
αυτά τα «εσκεμμένα» λάθη μπορούν να αναγνωρίσουν έναν προγραμματιστή ως το
συγγραφέα ενός τμήματος κώδικα.



1.5

Θέματα εξέλιξης

Σε

γενικές

γραμμές
,
είναι

πλέον

φανερό

πως

η

ανάλυση

του

κώδικα

με

σκοπό

την

αναγνώριση

του

συγγραφέα

του

είναι

πολύ

χρήσιμη

δίνοντας

ιδιαίτερη

βαρύτητα

στην

αντιμετώπιση

των

κακόβουλων

προγραμμάτων
.

Στην ιδανική περίπτωση, η ανάλυση κώδικα βοηθά αρχικά στον
εντοπισμό ενός μικρού συνόλου υπόπτων συγγραφέων όπου στη συνέχε
ια και με χρήση μετρικών
και θεωρίας πιθανοτήτων μπορεί να εξακριβωθεί ο υπεύθυνος. Σε αυτή τη φάση πολύ σημαντική
είναι και η ύπαρξη αποθηκευμένων δεδομένων στα οποία με αναζήτηση θα εντοπίζεται άμεσα ο
συγγραφέας του κώδικα.

Authorship Identification Methods


Page
7



Στην πραγματικότητα όμως, όπ
ως προαναφέρθηκε, δεν παραμένει στη διάθεσή μας ολόκληρος ο
κακόβουλος κώδικας παρά μόνο ένα μικρό τμήμα του. Έτσι, επικεντρωνόμαστε στην εξαγωγή
χαρακτηριστικών που μετά από ανάλυση και σύγκριση με δείγματα κώδικα θα ταυτοποιήσουν το
συγγραφέα. Αυτή η σύγ
κριση πρέπει να γίνεται με πολύ μεγάλη προσοχή αφού είναι πολύ
σημαντικό να μην προκύψει αποτέλεσμα που να εντοπίζει ως συγγραφέα κάποιον
προγραμματιστή που στην πραγματικότητα δεν είναι αλλά ούτε και να προκύπτει αποτέλεσμα που
να μην αναγνωρίζει τον συγγ
ραφέα ενώ υπάρχουν τα κατάλληλα δείγματα για να γίνει αυτό(
false

positives
,
false

negatives
).

Προχωρώντας, για να μπορέσει να γίνει σωστά η σύγκριση, πρέπει κομμάτια κώδικα να
συγκρίνονται με δείγματα ανάλογου μεγέθους για να υπάρχει επάρκεια αποδεικτικών στοιχείων
σχετικά με την ορθότητα του αποτελέσματος. Παρόλα αυτά, σε περίπτωση επαναχρησιμοποί
ησης
κώδικα το μέγεθος του δείγματος δεν μπορεί να είναι αντιπροσωπευτικό. Σε αυτές τις περιπτώσεις,
το αποτέλεσμα των μετρικών θα δείξει ή μεγαλύτερη ομοιότητα απ’ ότι πραγματικά υπάρχει, είτε
μικρότερη τη στιγμή που ο κώδικας μπορεί στην πραγματικότητα ν
α είναι όντως του ίδιου
συγγραφέα.

Ακόμα δυσκολότερη είναι και η ταυτοποίηση συγγραφέα όταν ο κώδικας έχει γραφεί σε
συνεργασία με πολλούς άλλους προγραμματιστές. Αν για παράδειγμα έχουμε κώδικα κάποιου
έργου ο οποίος αναπτύχθηκε με τη μέθοδο προγραμματι
σμού σε ζεύγη, τότε είναι πολύ δύσκολο
να εντοπιστούν οι συγγραφείς του. Αυτό συμβαίνει επειδή όχι μόνο ο καθένας γράφει τον κώδικα
με το δικό του στυλ, αλλά επεμβαίνει κιόλας τη στιγμή που προγραμματίζει ο άλλος με αποτέλεσμα
η σκέψη του ενός να αποτυπώνε
ται πολλές φορές με το προγραμματιστικό στυλ του συνεργάτη
του.

Συνοψίζοντας, ένας
ενημερωμένος

προγραμματιστής που γνωρίζει για την ανάλυση κώδικα και το
σκοπό της, με αρκετή προσπάθεια μπορεί να «μεταμορφώσει» τον κώδικά του. Δυστυχώς αυτό
είναι εφικτό
με χρήση διαφορετικών αλγορίθμων απ’ ότι θα χρησιμοποιούσε στην πραγματικότητα
καθώς και χρήση διαφορετικών δομών δεδομένων.
Με την χρήση όμως καινούριων για το
συγγραφέα δομών και αλγορίθμων,
παρόλο που τέτοιες ενέργειες
θα δυσχέραιναν την
ταυτοποίησή του

με βάση τα εσωτερικά χαρακτηριστικά του κώδικα θα είναι πιο πιθανό ο κώδικας
αυτός να είναι περισσότερο επιρρεπής σε λάθη τα οποία στην τελική περίπτωση θα τον
εμποδίσουν να λειτουργήσει σωστά με αποτέλεσμα να αποτύχει το πρόγραμμα.

Το γενικό συμπέρασμα
που προκύπτει, είναι ότι
πολλή δουλειά έχει γίνει μέχρι σήμερα σχετικά με
την ανάλυση και την ανάθεση του κώδικα. Ως αποτέλεσμα, μελλοντικά θα είναι δυσκολότερο να
εισβάλει κανείς στο σύστημα του χρήστη χωρίς αυτό να συνεπάγεται συνέπειες στον ίδιο τον
προ
γραμματιστή.

Όπως παρατηρείται και στις ενότητες που ακολουθούν υπάρχουν αρκετές
μέθοδοι σήμερα που με σημαντική ακρίβεια μπορούν να διακρίνουν κώδικα ενός

σ
υγγραφέα
ανάμεσα σε πολλούς άλλους
φτάνει βέβαια να γίνει η κατάλληλη εκπαίδευση με προηγούμενα
δεί
γματα γραφής των προγραμματιστών αυτών.








Authorship Identification Methods


Page
8


2.

Software Component Reuse



2.1

Σκοπός

Η ανάπτυξη έργων λογισμικού πάντοτε επισκιαζόταν από τις μεγάλες πιθανότητες παρουσίασης
αστοχιών στη λειτουργία των συστημάτων. Παράγοντες που την επηρέαζαν σημαντικά ήταν η
πολυπλοκότητα του προς επίλυση προβλήματος και η αβεβαιότητα που συνοδεύει πάντα
τις
εξελισσόμενες τεχνολογίες.

Με την ανάπτυξη λογισμικού που βασίζεται στην χρήση συστατικών (
Component

Based

Software

Development

-

CBSD
)
,
οι επιχειρήσεις μπορούν να εκμεταλλευτούν την χρήση τμημάτων κώδικα
που δουλεύουν απρόσκοπτα με αποτέλεσμα την εγγ
υημένη λειτουργία των συστημάτων που
αναπτύσσουν. Για να είναι όμως αυτό εφικτό, απαιτείται η επαναχρησιμοποίηση συστατικών που
μεταξύ άλλων, σκοπό έχει να ελαχιστοποιήσει το χρόνο και το κόστος της ανάπτυξης.

Σύμφωνα με τον
McBride

[3]
, το ένα τρίτο όλων

των χρημάτων που ξοδεύονται στην ανάπτυξη των
πληροφοριακών συστημάτων χρησιμοποιούνται για την μετατροπή των έργων λογισμικού που
αναπτύσσονται και δεν ικανοποιούν τις απαιτήσεις των χρηστών.

Επίσης, έχει σημειωθεί ένα
ποσοστό της τάξης του 31.1% που αφ
ορά τα έργα λογισμικού

που ματαιώνονται πριν καν

ολοκληρωθεί η ανάπτυξή τους. Ο λόγος που συμ
βαίνουν όλα αυτά είναι η ύπαρξη
τεχνικών

που
δεν επαρκούν
για τον ακριβή υπολογισμό του κόστους και χρόνου ανάπτυξης των έργων, η
αναποτελεσματική συνεργασία της ο
μάδας ανάπτυξης καθώς και η
μη επιτυχημένη

συνεργασία
του πελάτη με τους σχεδιαστές του έργου που ζητά.

Για την διασφάλιση της επιτυχίας της ανάπτυξης ενός έργου λογισμικού εξαπλώθηκε η ανάπτυξη
λογισμικού βασισμένη σε συστατικά. Ακολουθώντας αυτό τον τρ
όπο ανάπτυξης, εξασφαλίζεται η
ελεγχόμενη αύξηση του κόστους και γενικά τίθεται
σε κάποια χρονικά όρια η όλη διαδικασία
ανάπτυξης.

Υπό τους ρυθμούς ανάπτυξης της τεχνολογίας σήμερα, θεωρείται σχεδόν αδύνατο από τους
developers

και τις επιχειρήσεις για τις

οποίες εργάζονται η κατασκευή ενός έργου εξολοκλήρου
από την αρχή. Αντίθετα, είναι πλέον προτιμότερο και καταλληλότερο να χρησιμοποιούνται
πρακτικές που επιτρέπουν την επαναχρησιμοποίηση τεχνικών,
συστατικών λογισμικού

αλλά και
μοντέλων ελέγχου έτσι ώστε
να εξασφαλίζεται η αξιοπιστία των νέων έργων χωρίς να χρειάζεται να
γίνουν εξαντλητικοί έλεγχοι που θα διαρκέσουν μεγάλο χρονικό δι
άστημα.

Βέβαια, απαραίτητη
προϋπόθεση στην επαναχρησιμοποίηση συστατικών λογισμικού που ήδη βρίσκονται
ενσωματωμένα σε διαφορ
ετικά έργα είναι οι έλεγχοι όσον αφορά την σύνθεσή τους και την
εξακρίβωση του κατά πόσο όλα μαζί σε ένα νέο έργο λογισμικού θα λειτουργούν χωρίς κανένα
πρόβλημα.

Για να είναι όμως αυτό εφικτό 2 είναι οι παράγοντες κλειδιά στη διαδικασία της
ανάπτυξης: Ο έ
νας είναι ο σχεδιασμός
συστατικών

λογισμικού που μπορούν να
επαναχρησιμοποιηθούν και ο άλλος είναι η επαναχρησιμοποίηση
συστατικών
λογισμικού που ήδη
υπάρχουν

διαθέσιμα μέσω προηγούμενων έργων
. Επιπλέον, λόγω της κρισιμότητας της
επαναχρησιμοποίησης
συστατ
ικών

λογισμικού οι επιχειρήσεις πρέπει να κατανοήσουν τα θέματα
και τις προκλήσεις που αντιμετωπίζονται όσον αφορά την επαναχρησιμοποίηση λογισμικού σε
εξελισσόμενα πληροφοριακά συστήματα

στον τομέα των επιχειρήσεων
.

Στις επόμενες ενότητες του κεφαλαίου αυτού αναφέρονται έννοιες κρίσιμες για τη χρήση
συστατικών λογισμικού, για την επαναχρησιμοποίηση λογισμικού καθώς και στρατηγικές με την
οποία αυτή μπορεί να εφαρμοστεί.

Authorship Identification Methods


Page
9


2.2

Συστατικά Λογισμικού (
Software

Components
)

Ο όρ
ος συστατικό (
component
) χρησιμοποιείται με πολλούς διαφορετικούς τρόπους στη
βιομηχανία της ανάπτυξης λογισμικού. Σύμφωνα όμως με τον
Brown

[4], ένα συστατικό λογισμικού
είναι ένα ανεξάρτητο και λειτουργικό κομμάτι που παρέχει πρόσβαση στις υπηρεσίες του
μέσω
ενδιάμεσων (
interfaces
)
.

Η ευκολία της χρήσης του έγκειται στο γεγονός ότι αναπτύσσεται μόνο μια
φορά και μπορεί να χρησιμοποιηθεί πολλές φορές εξοικονομώντας χρόνο και προσπάθεια.
Επιπρόσθετα, είναι σημαντικό για ένα συστατικό λογισμικού να
μπορεί
συ
νδυαστεί και να συντεθεί
με άλλα συστατικά λογισμικού επειδή ένα συστατικό θεωρείται ότι επιτυγχάνει το σκοπό για τον
οποίο δημιουργήθηκε μόνο όταν χρησιμοποιείται σε συνεργασία με άλλα συστατικά. Το ενδιάμεσο
που προαναφέρθηκε, αφορά τον τρόπο με τον οποί
ο ο χρήστης αντιλαμβάνεται το συστατικό.

Ένα από τα χαρακτηριστικά ενός συστατικού λογισμικού που διευκολύνει τη συνεργασία του με
άλλα, είναι η ατομικότητα του

[5]
. Κάθε συστατικό είναι αυτόνομο, με καθορισμένη λειτουργία και
διασύνδεση χρήστη που του επ
ιτρέπουν να εκτελεί πλήρως τις λειτουργίες για τις οποίες έχει
αρχικά φτιαχτεί.

Με το συγκεκριμένο λοιπόν σχεδιασμό ενός συστατικού, η χρήση συστατικών και η
ανάπτυξη συστημάτων βασισμένη στην επαναχρησιμοποίηση τους, επιτρέπει στους οργανισμούς
την ολοκλή
ρωση έργων σε προκαθορισμένα και στενά χρονικά και οικονομικά όρια. Τόσο η
ποιότητα όσο και η εξοικονόμηση χρόνου που επιτυγχάνεται με τον τρόπο αυτό τοποθετεί την
επαναχρησιμοποίηση συστατικών λογισμικού ψηλά στις προτιμήσεις των επιχειρήσεων και των
ομά
δων ανάπτυξης.



2.3

Επαναχρησιμοποίηση Λογισμικού (
Software

Reuse
)

Ως επαναχρησιμοποίηση λογισμικού [6] ορίζεται η διαδικασία κατά την οποία ένας οργανισμός
καθορίζει ένα σύνολο από λειτουργικές διαδικασίες για τον ορισμό, την παραγωγή, την ανάκληση
και την υιοθέτηση τμημάτων λογισμικού με σκοπό την επαναχρησιμοποίηση του
ς στις διαδικασίες
ανάπτυξης των έργων της.

Η επαναχρησιμοποίηση λογισμικού μπορεί να γίνει με 2 τρόπους. Ο πρώτος ονομάζεται «μαύρο
κουτί» και ο δεύτερος «άσπρο κουτί» (
black

box

και

white

box
). Επαναχρησιμ
οποιώντας μαύρο
κουτί στόχος είναι η

ολοκλήρωση και επέκταση ενός συστήματος χωρίς να τροποποιηθεί καθόλου
το λογισμικό που επαναχρησιμοποιείται. Με χρήση άσπ
ρου κουτιού από την άλλη, μπορούν

να
τροποποιηθούν παράμετροι του λογισμικού που επαναχρησιμοποιείται πριν την ενσωμάτωσή του
στο νέο
σύστημα. Για τους χρήστες, είναι πιο κατανοητή η χρήση άσπρου κουτιού αφού η
διαδικασία εφαρμογής του επιτρέπει επέμβαση από το χρήστη και καλύτερη κατανόηση της
λειτουργίας του λογισμικού. Όμως,
χρησιμοποιώντας άσπρα κουτιά τα πλεονεκτήματα είναι
λιγότερα

απ’ ότι με απευθείας χρήση έτοιμου λογισμικού (μαύρο κουτί) αφού απαιτείται
μεγαλύτερη προσπάθεια για κατανόηση και επέμβαση από τους εκάστοτε χρήστες.

2.3.1


Ποια η σχέση επαναχρησιμοποίησης λογισμικού και ανάπτυξης συστήματος με χρήση
συστατικών λογισμικού

Αρχικά, από πλευράς σκοπού τόσο η επαναχρησιμοποίηση λογισμικού όσο και η χρήση
συστατικών για την ανάπτυξη συστημάτων αποσκοπούν στην αύξηση της
παραγωγικότητας και της ποιότητας. Όμως διαφέρουν όσον αφορά τη σημαντικότητα
αυτών των στόχων για την κάθε δι
αδικασία καθώς και στον τρόπο με τον οποίο
προσεγγίζουν αυτούς. Οι σημαντικότερες διαφορές τους αναλύονται στη συνέχεια.

Authorship Identification Methods


Page
10


ΟΙ μέθοδοι επαναχρησιμοποίησης λογισμικού δίνουν αρχικά έμφαση στη μείωση του
κόστους αλλά στοχεύοντας ταυτόχρονα στην αύξηση της παραγ
ωγικότητας. Ως
αποτέλεσμα υπάρχουν αρκετοί τρόποι με τους οποίους αυτό γίνεται εφικτό. Από τη μια,
μπορεί να γίνει χρεολυσία των κοστών κατασκευής και συντήρησης του συστήματος κατά
τη διάρκεια του χρόνου. Από την άλλη, μπορεί να αποφευχθεί η έγερση οικονο
μικών
δυσκολιών σε μεταγενέστερα έργα με παρόμοια λειτουργικότητα.

Ως αποτέλεσμα της επικέντρωσης στην μείωση του κόστους, οι μέθοδοι
επαναχρησιμοποίησης

λογισμικού

παρουσιάζουν τα ακόλουθα χαρακτηριστικά
:



Το όλο θέμα της επαναχρησιμοποίησης είναι η δημιουργία οποιουδήποτε τμήματος που
μπορεί να χρησιμοποιηθεί στην ανάπτυξη αλλά και στη συντήρηση ενός συστήματος.
Τέτοια τμήματα μπορεί να είναι οι αρχικές απαιτήσεις του συστήματος, ο υλοποιημένος
κώδικας μιας

λειτουργίας ή ακόμα και τα μοντέλα που χρησιμοποιούνται για τον έλεγχο των
διαφόρων λειτουργιών.



Οι μέθοδοι επαναχρησιμοποίησης λογισμικού επικεντρώνονται επίσης και στην τέλεια
οργάνωση της διαδικασίας η οποία θα χρησιμεύσει και μελλοντικά

Από την άλλη
πλευρά, οι μέθοδοι χρήσης συστατικών για την ανάπτυξη ενός συστήματος
επικεντρώνονται στη βελτίωση της παραγωγικότητας μειώνοντας τον χρόνο ανάπτυξης και
βελτιώνοντας την ευελιξία των συστημάτων. Λαμβάνοντας αυτά λοιπόν υπόψη προκύπτουν
διαφορετικές τεχνικ
ές αλλά και οργανωτικές διαστάσεις.

Η

πιο σημαντικ
ή

τεχνικ
ή

διαφορ
ά

είναι επομένως
η

ακόλουθ
η
: Στην περιοχή της χρήσης
συστατικών αναπτύσσονται τεχνικές και οι μηχανισμοί που επιτρέπουν την εύκολη σύνθεση
και αναβάθμιση των συστατικών σε συστήματα που κατα
σκευάστηκαν εξ αρχής με τελείως
ανεξάρτητα τμήματα λογισμικού.

Όσον αφορά όμως την επαναχρησιμοποίηση λογισμικού,
οι μέθοδοι είναι ουδέτερες απέναντι στις τεχνικές απαιτήσεις του συστήματος που θα
κατασκευαστεί. Και οι 2 προσεγγίσεις όμως στηρίζονται στην
άρτια αρχιτεκτονική σχεδίαση
και στη συμβατότητα των συστατικών της.

Από τη σκοπιά της οργάνωσης, η επαναχρησιμοποίηση λογισμικού διαφέρει από την
επαναχρησιμοποίηση συστατικών αφού στη δεύτερη τα συστατικά μπορεί να προέρχονται
είτε από παρόμοια έργα της

ίδιας επιχείρησης είτε από ξένες μετά από χρηματική
συμφωνία. Σε αντίθεση, στην επαναχρησιμοποίηση λογισμικού συνήθως

δεν
περιλαμβάνεται η «αγορά» κώδικα από άλλες επιχειρήσεις μιας και αυτό δεν θα
συμφωνούσε με τον κύριο στόχο της που είναι η μείωση του
οικονομικού, μεταξύ άλλων,
κόστους ανάπτυξης. Επομένως, επικεντρώνεται κυρίως στην επαναχρησιμοποίηση
λογισμικού εντός της ίδιας της επιχείρησης. Εξαίρεση αποτελεί η χρήση κώδικα που μπορεί
να γίνει διαθέσιμος μέσω έργων Ανοικτού Κώδικα αφού στην προκειμέν
η περίπτωση αυτό
δεν θα αυξάνει το κόστος.



2.3.2

Προοπτικές για λειτουργική επαναχρησιμοποίηση λογισμικού



Απαιτήσεις

Λογισμικού

(
Requirements
):
Συνήθως οι απαιτήσεις ενός έργου λογισμικού

είναι αποτέλεσμα έντονης μελέτης και πολλών συναντήσεων με τους πελάτες. Σε αυτή την
επίπονη διαδικασία συμμετέχουν αναλυτές, ειδικοί του τομέα καθώς ακόμα και οι
προγραμματιστές.

Ως αποτέλεσμα, εταιρείες που ασχολούνται και ζητούν συνεχώς την
ανάπτυξη ν
έων πληροφοριακών συστημάτων μπορούν να επωφεληθούν από την
επαναχρησιμοποίηση των απαιτήσεων σε κάποιους τομείς που αυτό είναι δυνατό.


Authorship Identification Methods


Page
11




Αρχιτεκτονική Συστήματος:
Οι αρχιτεκτονικές περιγράφουν τις βασικές αρχές που
ακολουθούνται από τη σκοπιά της οργάνωση
ς σε ένα σύστημα.
Ιδανικά, οι περιγραφές που
συνοδεύουν την αρχιτεκτονική ενός συστήματος περιλαμβάνουν σημαντικές σχεδιαστικές
αποφάσεις και το λόγο που αυτές προτιμήθηκαν έναντι άλλων. Συνήθως οι αρχιτεκτονικές
είναι αποτέλεσμα μεγάλων συζητήσεων μεταξύ
έμπειρων σχεδιαστών οι οποίοι γνωρίζουν
πολύ καλά πως μπορούν να αποτυπώσουν στο σύστημα τις ανάγκες του χρήστη. Ως
αποτέλεσμα, αυτές οι σχεδιαστικές αρχές που χρησιμοποιούνται σε ένα σύστημα, μπορεί
μέχρις ενός σημείου να ταιριάζουν και για κάποιο παρόμοι
ο ή ακόμα καλύτερα και για μια
μετεξέλιξη του ιδίου έργου. Για το λόγο αυτό, η επαναχρησιμοποίηση αρχιτεκτονικής είναι
από τις πιο διαδεδομένες στην πορεία εξέλιξης ενός συστήματος. Εννοείται όμως πως η
παρουσία ειδικού είναι απαραίτητη αφού είναι αδύνατο
η αρχιτεκτονική να χρησιμοποιηθεί
αυτούσια, ως έχει. Στη φάση αυτή, ο ειδικός είναι και αυτός που θα κρίνει αν κάποιες
σχεδιαστικές αποφάσεις πρέπει να αναθεωρηθούν ή όχι ανάλογα με το περιεχόμενο και το
έργο κάθε φορά.



Σχεδίαση:
Όσον αφορά τη σχεδίαση,
μπορεί να επαναχρησιμοποιηθεί η λεπτομερής
περιγραφή και σχεδίαση ενός υποσυστήματος ή ακόμα και ενός τμήματος ενός
υποσυστήματος. Οι σχεδιαστικές αρχές μπορεί επίσης να είναι γενικές ή εξειδικευμένες
ανάλογα με το τμήμα της εφαρμογής. Η πιο διαδεδομένη αρ
χή σχεδίασης είναι αυτή που
χρησιμοποιεί σχεδιαστικά πρότυπα (
design

patterns
)

και που χρησιμοποιείται κυρίως για
προβλήματα που προκύπτουν αναδρομικά
.

Ολοένα και μεγαλύτερη υποστήριξη στην
επαναχρησιμοποίηση των σχεδιαστικών προτύπων παρατηρείται σήμερα καθώς
αναπτύσσονται και πολλά εργαλεία βοηθητικά προς τη σχεδίαση.

Ένα τυπικό παράδειγμα καλής σχεδιαστικής αρχής είναι η χρήση διαγραμμάτων
UML

τα
οποί
α μπορούν να επαναχρησιμοποιηθούν ως βάση για την υλοποίηση σε διαφορετικές
πλατφόρμες ή σε παρόμοια προβλήματα.



Υλοποίηση:
Ο κώδικας ενός προγράμματος είναι η ουσιαστική υλοποίηση ενός
προβλήματος. Παρόλα αυτά, διαφορετικά είδη κώδικα προσφέρουν και διαφο
ρετικές
δυνατότητες επαναχρησιμοποίησης.
Ο κώδικας ενός προγράμματος ο οποίος είναι δυνατό
να επαναχρησιμοποιηθεί μπορεί να πάρει διαφορετικές μορφές: εκτελέσιμος, πηγαίος,
macro

s
, εντολές μηχανής,
scripts

για μεταγλώττιση ή εκτέλεση, βιβλιοθήκες κτλ. Υπά
ρχει η
δυνατότητα ο πηγαίος κώδικας να αποθηκε
ύεται σε δια
φορετικού μεγέθους αρχεία,
να
διαχωρίζεται με πακέτα κλάσεων, με μεθόδους ακόμα και προσωπικές βιβλιοθήκες του
προγραμματιστή.
Ο λόγος για τον οποίο είναι ελκυστική η επαναχρησιμοποίηση κώδικα
είναι

η άμεση λύση που παρέχει σε κάποιο πρόβλημα χωρίς κόπο και επιπλέον ελέγχους
για την ορθή λειτουργία του. Όμως, παρόλα αυτά η επαναχρησιμοποίηση πηγαίου κώδικα
πρέπει να γίνεται με προσοχή όσον αφορά τις λειτουργικές απαιτήσεις αλλά και τις μη
-
λειτουργικ
ές (χρόνος απόκρισης, ποιότητα αποτελέσματος κτλ).



Διασφάλιση Ποιότητας / Εγκυρότητα:

Όσον αφορά την εγκυρότητα

κάποιου τμήματος
που επαναχρησιμοποιείται, καλό είναι να προσεχθούν τα ακόλουθα:

-

Επισκόπηση και κατανόηση της λειτουργίας τους καθώς και της λε
ιτουργίας στην οποία
θα αποτελέσει πιθανώς τη λύση

-

Έλεγχος: χρήση
text

cases

για την εξασφάλιση της σωστής λειτουργίας του
συστήματος με την ενσωμάτωση του συγκεκριμένου τμήματος

-

Χρήση

σχολίων

και

εγγράφων

(
documentation

templates
)
για την ενημέρωση των
επόμενων μηχανικών σχετικά με τις σχεδιαστικές αποφάσεις που πάρθηκαν και το
λόγο που αυτές υιοθετήθηκαν.


Authorship Identification Methods


Page
12


2.3.3

Παράγοντες επιτυχίας και αποτυχίας της επαναχρησιμοποίησης λογισμικού

Όταν επιχειρείται η επαναχρησιμοποίηση λογισμικού δεν πρ
έπει η ολοκλήρωσή της να
γίνεται επιπόλαια. Υπάρχουν αρκετά πράγματα που μπορεί να παν στραβά αν δεν
ακολουθηθούν πιστά όλοι οι απαραίτητοι έλεγχοι και αν δεν εμπλακούν ειδικοί στη
διαδικασία. Με την πάροδο του χρόνου, όλο και περισσότερα έρχονται στο φως
σχετικά με
την κατάλληλη διαδικασία που πρέπει να ακολουθηθεί. Πλέον

πολλά ζητήματα που
οδηγούν σε επιτυχή εφαρμογή της επαναχρησιμοποίησης είναι γνωστά. Μάλιστα, ένα από
τα πρώτα μαθήματα που πρέπει να πάρει κανείς απευθύνεται στις συνθήκες που πρέπει να
ικανοποιούνται για την εξασφάλιση ότι όντως υπάρχει κάποιο ζήτημα το οποίο μπορεί να
αντιμετωπιστεί άμεσα με επαναχρησιμοποίηση λογισμικού.

Οι ακόλουθοι παράγοντες βοηθούν στο να καθοριστεί αν δεδομένου ενός προβλήματος η
επαναχρησιμοποίηση μπορεί να είνα
ι η λύση:

-

Το λογισμικό πρέπει να ανήκει σε ένα συγκεκριμένο και κοινό πεδίο και όχι σε κάποιο
εξειδικευμένο έργο.
Η ομοιότητα με το νέο έργο πρέπει να αναγνωριστεί μέσω
ανάλυσης του πεδίου του προβλήματος και να «συλληφθεί» μέσω της αρχιτεκτονικής
τους.

-

Πρ
έπει να έχει αναπτυχθεί ένα μεγάλο μέρος του λογισμικού από το νέο έργο για να
είναι εμφανή τα σημεία στα οποία θα μπορούσε να προστεθεί κομμάτι έτοιμου κώδικα.

-

Το τμήμα που θα επαναχρησιμοποιηθεί θα ήταν προτιμότερο να έχει αναπτυχθεί και
εφαρμοστεί αρκετ
ό καιρό πριν για να είναι βέβαιη η σωστή λειτουργία του και να
εκπληρώνεται σίγουρα ο σκοπός για τον οποίο χρειάζεται.


Παρακάτω ακολουθούν κάποιες παροτρύνσεις που σκοπό έχουν τη σωστή ένταξη της
επαναχρησιμοποίησης λογισμικού σε μια επιχείρηση:

-

Καλύτερα
θα ήταν αν η ένταξη του νέου τρόπου ανάπτυξης γινόταν σταδιακά σε ένα
μικρό ποσοστό έργων που δεν έχουν ως στόχο την υλοποίηση προβλημάτων
ασφάλειας ή κρίσιμων λειτουργιών για τον άνθρωπο.

-

Είναι προτιμότερο να εξασφαλιστεί μια διαδικασία ανάπτυξης που θα υ
ποστηρίζει και
θα διευκολύνει την επαναχρησιμοποίηση. Για παράδειγμα, μπορεί να χρειαστεί να
ενσωματωθούν διαδικασίες ελέγχου διαχείρισης καθώς και παράμετροι για τη μέτρηση
της ποιότητας.

-

Πρέπει να οργανωθούν σεμινάρια εκπαίδευσης και ενημέρωσης τν υπαλλ
ήλων σχετικά
με την επαναχρησιμοποίηση λογισμικού με στόχο την εξοικείωσή τους με τις
παραμέτρους που αυτή σχετίζεται και τον πειραματισμό τους με παραδείγματα έργων.


Από τη στιγμή που μια επιχείρηση ασχολείται με την επαναχρησιμοποίηση στα πλαίσια της
αν
άπτυξης νέων έργων, τα παρακάτω βοηθούν στην ολοένα και καλύτερη εφαρμογή της με
περισσότερα ωφελήματα στη διάρκεια του χρόνου:

-

Εφαρμογή αυστηρών κριτηρίων για την είσοδο στη βιβλιοθήκη τμημάτων
επαναχρησιμοποίησης κάποιου τμήματος λογισμικού. Αυτό θα βοηθ
ήσει στη διατήρηση
ενός υψηλού επιπέδου προγραμματισμού και στην συγκέντρωση σε εργασίες που
συχνά χρησιμοποιούνται σχεδόν ολόιδιες σε διαφορετικά έργα.

-

Συλλογή μετρικών επαναχρησιμοποίησης έτσι ώστε να μπορεί να γίνει διαχείριση και
εύκολη αποτίμηση των α
ποτελεσμάτων από την εφαρμογή της. Ένα πρόγραμμα
Authorship Identification Methods


Page
13


επαναχρησιμοποίησης πρέπει να καθοδηγείται από αντικειμενικούς επαγγελματικούς
στόχους και όχι από την ευκολία υλοποίησής του. Έτσι, για να μπορέσει να γίνει
αντιληπτό αν ακολουθείται ο ορθός τρόπος ανάπτυξη
ς πρέπει να παρακολουθείται
στενά η παραγωγικότητά του και η πρόοδός του σε κάθε στάδιο ανάπτυξης.

-

Καλό είναι να υπάρχει και συνεχής ενημέρωση σχετικά με το τι χρησιμοποιείται κάθε
στιγμή στις υπόλοιπες επιχειρήσεις σχετικά πάντα με τις μεθόδους και τους
τρόπους
εφαρμογής της επαναχρησιμοποίησης. Με τον τρόπο αυτό, πάντα θα υπάρχει άμεση
ενημέρωση για τους νέους τρόπους που μπορεί παλιό λογισμικό να ενσωματωθεί σε
νέα έργα με παρόμοιους στόχους.


2.4

Στρατηγικές Επαναχρησιμοποίησης Συστατικών Λογισμικού

Είναι

πλέον αποδεδειγμένο ότι η επαναχρησιμοποίηση λογισμικού προαπαιτεί οι εμπλεκόμενοι σε
αυτήν να μπορούν να κατανοήσουν την προσοχή που χρειάζεται τόσο όσον αφορά τεχνικά θέματα
όσο και μη τεχνικά. Σκοπός είναι πάντα η διασφάλιση της επιτυχίας στην επαναχρη
σιμοποίηση
συστατικών λογισμικού.
Στην πλειοψηφία των περιπτώσεων, τα μη τεχνικά ζητήματα αποδείχτηκαν
πιο περίπλοκα και δυσνόητα. Τα 9 κυριότερα εμπόδια και προβλήματα που αντιμετωπίζονται
συχνά στην υιοθέτηση λογισμικού με σκοπό την επαναχρησιμοποίηση συνοψίζονται στον πίνακα 1
και μπορο
ύν να κατηγοριοποιηθούν σε:
τεχνικά, διαχείρισης και πολιτισμικά/ψυχολογικά

[5]
.


Πίνακας 1: κυριότερα προβλήματα στην επαναχρησιμοποίηση λογισμικού

Τεχνικά

Διαχείρισης

Πολιτισμικά/Ψυχολογικά

Λανθασμένη δομή

Απότομη εναλλαγή θεμάτων

Διαφωνίες σε θέματα
υποδομής

Διαμάχες όσον αφορά την υιοθέτηση
λύσης

Προβλήματα έλλειψης χρόνου και
χρημάτων (έλλειψη πόρων)

Απάθεια σχετικά με την τελική λύση

Σύνδρομο χρήσης τεχνολογίας με την
οποία η εταιρεία είναι είδη
εξοικειωμένη

Φόβος για το άγνωστο



Ό
σον αφορά το θέμα της λανθασμένης δομής, είναι ίσως το πρώτο που εμφανίζεται σχεδόν σε
όλους τους οργανισμούς που επαναχρησιμοποιούν συστατικά λογισμικού. Αυτό οφείλεται στο
γεγονός ότι μέχρι σήμερα οι περισσότεροι από αυτούς έχουν προχωρήσει στην υιοθέτησ
η θεσμών
στην επιχείρησή τους που δεν προάγουν την επαναχρησιμοποίηση λογισμικού. Αυτό μπορεί να
οφείλεται είτε στη λανθασμένη χρήση εργαλείων ανάπτυξης, είτε στην πρώτη εκπαίδευση των
σχεδιαστών και των προγραμματιστών που δεν αφορούσε καν τα συστατικά εί
τε και στη δυσκολία
της ανάπτυξης από την αρχή ενός συστήματος με σκοπό την ενσωμάτωση σε αυτό έτοιμων
συστατικών.
Εξάλλου, η ανάπτυξη συστήματος που βασίζεται στη χρήση συστατικών περιπλέκεται
ακόμη πιο πολύ από τη στιγμή που δεν υπάρχουν στην αγορά τα κα
τάλληλα εργαλεία για την
κατασκευή συστημάτων με χρήση προτύπων, μοντέλων και υποδομών λογισμικού. Το μόνο που
μπορεί να γίνει για την αντιμετώπιση αυτού του θέματος είναι η ανάπτυξη τέτοιων εργαλείων που
θα ενθαρρύνουν τους σχεδιαστές στη χρήση τους.

Με α
ιτία
τ
ις υπάρχουσες τεχνικές ανάπτυξης συστημάτων, η απότομη εναλλαγή θεμάτων όσον
αφορά τη χρήση συστατικών σε ένα σύστημα είναι αναπόφευκτη. Πρέπει να εστιάσουν οι
σχεδιαστές στην εφεύρεση και εφαρμογή νέων μεθόδων εργασίας έτσι ώστε να υπάρχει μια λογικ
ή
σειρά και μια προσιτή σύνθεση στα συστατικά ενός συστήματος. Ο καλύτερος τρόπος για να
πραγματοποιηθεί αυτό είναι η διαμοίραση του έργου σε αρκετά μικρότερα, το καθένα από τα οποία
Authorship Identification Methods


Page
14


θα περιλαμβάνει συστατικά με παρόμοια λειτουργικότητα και που ανάμεσα στα

τμήματα θα είναι
ομαλή η διαφορά ανάμεσα στη λειτουργικότητα.

Από τη σκοπιά της διαχείρισης πολλοί είναι οι οργανισμοί που εφαρμόζουν ακόμα και σήμερα
διαχείριση έργων λογισμικού σε σχέση με την υπάρχουσα τεχνολογική υποδομή χρησιμοποιώντας
διεργασίες κ
αι κριτήρια που συμβαδίζουν με τις μέχρι τώρα αρχές της επιχείρησης τους. Αυτή η
υποδομή όμως πρέπει να διαφοροποιηθεί για να μπορέσουν να εφαρμοστούν πλήρως οι αρχές
ανάπτυξης συστήματος με χρήση συστατικών. Ως αποτέλεσμα, προκύπτουν διαφωνίες σχετικά με
τις νέες τεχνολογίες που θα υιοθετηθούν και το πώς αυτές θα εφαρμόζονται ανάλογα με το στάδιο
ανάπτυξης ενός συστήματος.

Προβλήματα επίσης προκύπτουν λόγω περιορισμού χρημάτων, χρόνου και προσπάθειας. Κάθε
οργανισμός αγωνίζεται να μεγιστοποιήσει τους πόρου
ς του με στόχο την κατασκευή ολοένα και
μεγαλύτερων αλλά και πιο επικερδών συστημάτων. Πρέπει επομένως να διασφαλιστεί ο ρόλος του
κάθε ατόμου ξεχωριστά σε κάθε οργανισμό για να γνωρίζουν όλοι ανά πάσα στιγμής ποιος είναι
υπεύθυνος και για τι στο υπό ανάπτ
υξη έργο.

Το σύνδρομο «δεν το δημιουργήσαμε εμείς» (
not

invented

here

syndrome
) είναι επίσης ένα
εμπόδιο που προκύπτει συνήθως κατά τη μετάβαση μιας επιχείρησης στην επαναχρησιμοποίηση
συστατικών

[5]
. Αυτό μπορεί να οφείλεται στο γεγονός ότι πολλοί σχεδια
στές πιστεύουν έντονα
στην άποψη ότι οι δικές τους λύσεις είναι και οι πιο αποδοτικές για ένα πρόβλημα του οργανισμού
τους παρά από τη λύση που χρησιμοποιήθηκε σε κάποια άλλη επιχείρηση. Εκτός από τα επιτυχή
παραδείγματα που μπορούν να χρησιμοποιηθούν για
την εξασφάλιση του σωστού αποτελέσματος,
το προσωπικό πρέπει να πιεστεί έτσι ώστε να αντιμετωπίσει με αισιοδοξία τις νέες πρακτικές που
θα εφαρμοστούν και τα πλεονεκτήματα που θα προκύψουν από αυτές.

Μια από τις σημαντικότερες στρατηγικές για την εφαρμογή
της επαναχρησιμοποίησης είναι η
καλλιέργεια του ενθουσιασμού προς την επαναχρησιμοποίηση που προτάθηκε από τον
Griss

[7].
Η

σωστή αντιμετώπιση προς κάτι νέο
βοηθά πάντα στην ομαλή υιοθέτησή του από την ομάδα
ανάπτυξης προκαλώντας και ενθουσιασμό για την εφ
αρμογή του καινούριου.

Την επιτυχία
διασφαλίζουν επίσης η παρότρυνση και η ενθάρρυνση των διαχειριστών των έργων προς το
υπόλοιπο προσωπικό. Εξάλλου, όπως τονίζει και ο
Schmidt

[8], τα θετικά αποτελέσματα της
επαναχρησιμοποίησης συστατικών είναι ακόμα μεγα
λύτερα όταν υπάρχουν στην ομάδα ικανότεροι
διαχειριστές και πιο έμπειροι σχεδιαστές. Γενικότερα, οι πιο έμπειροι και πιο ικανοί σχεδιαστές που
μπορούν να δημιουργήσουν, αιτιολογήσουν και να υποστηρίξουν λογισμικό είναι και αυτοί που θα
μπορέσουν να βοηθήσο
υν τους πιο νέους και να τους καλλιεργήσουν την ικανότητα της ανάπτυξης
λογισμικού σε συνδυασμό με την επαναχρησιμοποίηση συστατικών κάποιας άλλης εταιρίας.

Προσοχή χρειάζεται επίσης και ο τομέας της συνεργασίας στον οποίο πρέπει να δοθεί ιδιαίτερη
υποστήριξη. Για την πραγματοποίηση αυτού υπάρχει ανάγκη να δημιουργηθούν κίνητρα τα οποία
θα επιτρέψουν στους σχεδιαστές να μοιραστούν τα ωφελήματα της επαναχρησιμο
ποίησης και έτσι
με ταχύτερους ρυθμούς να γίνει συντομότερα επικερδής για την εταιρία η επένδυση στην
επαναχρησιμοποίηση συστατικών.
Τα κίνητρα αυτά τα οποία θα δοθούν από την επιχείρηση
πρέπει ιδανικά να συνδέονται με μετρικές της επαναχρησιμοποίησης με στόχο την άμβλυνση του
κενού μεταξύ των διαφόρων σταδίων ανάπτυξης και της καθημερινής εργασίας του προσωπικού.
Ως αποτέλεσμα, θα μπορ
εί κάθε σχεδιαστής να παρατηρεί και να αντιλαμβάνεται πως οι δικές του
κινήσεις επαναχρησιμοποίησης επηρεάζουν θετικά την όλη ανάπτυξη του έργου και γενικότερα το
όφελος που αυτό προσθέτει στον οργανισμό. Ως προσωπικό όφελος για τον καθένα θεωρείται η
αναγ
νώριση που θα κερδίζουν μέσω της καθημερινής δουλειάς τους και της παραγωγικότητάς
τους στο σύνολο του έργου.

Η ανάπτυξη ενός συστήματος με χρήση συστατικών δεν μοιάζει με την ανάπτυξη συστήματος με
απλή επαναχρησιμοποίηση προτύπων και ενδιάμεσων. Για την

λειτουργικότητα της
επαναχρησιμοποίησης χρειάζεται κατάλληλη τεκμηρίωση του κώδικα που περιλαμβάνεται σε κάθε
Authorship Identification Methods


Page
15


συστατικό. Με τον τρόπο αυτό είναι πιο εύκολο για την ομάδα ανάπτυξης να εντοπίσει και να
επαναχρησιμοποιήσει τα κατάλληλα συστατικά λογισμικού σ
το κατάλληλο τμήμα του προς
ανάπτυξη συστήματος. Για το λόγο αυτό άλλωστε πολλοί είναι αυτοί που υποστηρίζουν ότι το
κλειδί για την επιτυχία της επαναχρησιμοποίησης συστατικών είναι οι σωστές απαιτήσεις και τα
τεκμηριωμένα τμήματα κώδικα που περιέχονται σε

κάθε ένα.

Τα περισσότερα από τα συστατικά των τελευταίων χρόνων δεν έχουν επαναχρησιμοποιηθεί. Ένας
από τους κυριότερους λόγους είναι ο ακατάλληλος σχεδιασμός της δομής τους. Είναι απαραίτητο
να κατασκευάζεται ένα σύνολο από συστατικά που επεκτείνουν και

αλληλοσυμπληρώνουν τον
αντικειμενικό σκοπό του συστήματος. Ο
Latchem

[9]
εισηγείται η δομή ενός συστατικού να
σχεδιάζεται με μεγάλη προσοχή για να διαχωρίζονται οι λειτουργίες και να διασφαλίζεται η λογική
σύνδεση μεταξύ των συστατικών ενός συστήματος. Γι
α την επιτυχία του σκοπού αυτού ο
σχεδιαστής μπορεί να χρησιμοποιήσει ένα σύνολο επιπέδων στο σχεδιασμό των συστατικών με
προαποφασισμένες λειτουργίες για το καθένα ξεχωριστά. Τέλος, τα συστατικά μπορούν να
διαχωριστούν με βάση τις υπηρεσίες που παρέχουν ή

με βάση τα επαγγελματικά μοντέλα μέσα
στα οποία αυτά λειτουργούν.


2.5

Συμπεράσματα

Η ανάπτυξη των πληροφοριακών συστημάτων πάντα συνοδεύεται από έρευνες σχετικά με τις
πιθανότητες αποτυχίας τους. Ως κυριότεροι λόγοι της αποτυχίας αυτής μπορούν να θεωρηθούν
η
πολυπλοκότητα του κάθε έργου σε συνδυασμό με την αβεβαιότητα που μπορεί να προκύψει σε
κάποια τμήματα αυτού. Με την εισαγωγή όμως της ανάπτυξης συστημάτων με την
επαναχρησιμοποίηση συστατικών οι οργανισμοί μπορούν πλέον να χρησιμοποιήσουν την
τεχνολογία
των συστατικών για να μειώσουν τα οικονομικά κόστη αλλά και τις παραμέτρους
αποτυχίας.

Για την μεγιστοποίηση της πιθανότητας επιτυχίας της επαναχρησιμοποίησης συστατικών σε μια
επιχείρηση, σημαντικό ρόλο παίζει η σωστή οργάνωση και η κατάλληλη προετοιμασία

του
προσωπικού. Το πιο σημαντικό είναι ο κάθε οργανισμός να εστιάσει στα πλεονεκτήματα που θέλει
να αποφέρει αυτή η τεχνολογία στον οργανισμό του και στα μέτρα που αυτή θα χρησιμοποιηθεί για
να το πετύχει αυτό.

Όπως έχει ήδη αναφερθεί και σε προηγούμενη

ενότητα
, μπορεί από τη μια η επαναχρησιμοποίηση
συστατικών να λύνει πολλά από τα προβλήματα πολυπλοκότητας των έργων αλλά από την άλλη
χρειάζεται ακόμα μεγαλύτερη προσοχή στην επιλογή αυτών που θα χρησιμοποιηθούν. Για το λόγο
αυτό, δεν αρκεί μόνο η τεκμηρ
ίωση ενός συστατικού αλλά χρειάζεται και γνώση του συγγραφέα ή
των συγγραφέων του καθώς και το πρόβλημα στο οποίο χρησιμοποιήθηκε ως λύση. Στο σημείο
αυτό επεμβαίνει και η αναγνώριση του συγγραφέα σε περιπτώσεις που αυτός είναι άγνωστος για
να μπορέσει να
εξακριβωθεί ο λόγος για τον οποίο ένα συγκεκριμένο συστατικό εισχώρησε στο
σύστημα μιας εταιρίας, είτε από ανθρώπινη απροσεξία είτε από εσκεμμένη πρόκληση
προβλήματος.






Authorship Identification Methods


Page
16


3.

Ανάπτυξη Λογισμικού

Ανοικτού Κώδικα



3.1

Τι προσφέρει

Το λογισμικό ανοικτού κώδικα
είναι λογισμικό του οποίου ο πηγαίος κώδικας είναι διαθ
έσιμος στο
κοινό μέσω αδειών διανομής λογισμικού όπως:

Apache

License
,
BSD

License
,
GNU

General

Public

License
,
GNU

Lesser

General

Public

License
,
MIT

License
,
Eclipse

Public

License

και

Mozilla

Public

License
. Με τον τρόπο αυτό επιτρέπεται στους προγραμματιστές και τους απλούς
χρήστες να το τροποποιήσουν ή να το ενσωματώσουν σε δικά τους προγράμματα

υπό την
προϋπόθεση τήρησης των περιορισμών της κάθε άδειας
. Γενικότερα, το λογισμικό χωρίζεται σε 2
κατη
γορίες: το κλειστό λογισμικό το οποίο παράγεται και ανήκει σε μια επιχείρηση ή σε κάποιο
ιδιώτη και ο κώδικάς του δεν είναι φανερός και άμεσα διαθέσιμος και το ανοικτό λογισμικό του
οποίου ο κώδικας είναι διαθέσιμος στο κοινό μαζί με την εφαρμογή.
Οι χρήστ
ες ενός
προγράμματος ανοικτού κώδικα μπορούν να χρησιμοποιήσουν τον κώδικα, να τον διανέμουν και
να τον τροποποιήσουν.

Στην πράξη, οι διάφορες επιχειρήσεις συνήθως αναπτύσσουν λογισμικό και από τις 2 αυτές
κατηγορίες. Ο κυριότερος λόγος όμως για τον οποίο

προτιμάται η ανάπτυξη λογισμικού ανοικτού
κώδικα είναι γιατί με τον τρόπο αυτό ανεξάρτητα άτομα που δεν ανήκουν στο περιβάλλον της
επιχείρησης μπορούν να βοηθήσουν στην εξέλιξη του έργου και μάλιστα χωρίς κανένα οικονομικό
κόστος.

Μεγάλη σημασία στα οφέλ
η του λογισμικού ανοικτού κώδικα παίζουν οι ακόλουθοι παράγοντες
[10]:



Αξιοπιστία:
καθορίζει το χρονικό διάστημα για το οποίο ένα πρόγραμμα ή σύστημα
μπορεί να παραμείνει σε λειτουργία χωρίς να παρουσιάσει κάποια βλάβη και χωρίς να
χρειαστεί η ανθρώπινη π
αρέμβαση σε αυτό



Ποιότητα:
ο αριθμός των σφαλμάτων
σε καθορισμένο ποσοστό γραμμών κώδικα



Ασφάλεια:

η αντοχή του λογισμικού σε απρόσμενους παράγοντες και η αντίδρασή του σε
αυτούς (π.χ. ιός)



Ευελιξία:

πόσο εύκολα το λογισμικό μπορεί να τροποποιηθεί με σκοπό να ικανοποιήσει
συγκεκριμένες ανάγκες και διαφορετικές συσκευές του συστήματος



Διαχείριση του έργου:

πόσο καλά οργανωμένη είναι η διαδικασία ανάπτυξης του
συστήματος.



Ανοικτά πρότυπα:

τα έγγραφα που

δημιουργήθηκαν με συγκεκριμένο λογισμικό πρέπει
να είναι εφικτό να αναγνωστούν και από άλλες εφαρμογές που υποστηρίζουν ανάγνωση
εγγράφων



Κόστη εναλλαγής:

το κόστος που απαιτείται από την εναλλαγή από ένα συγκεκριμένο
σύστημα σε ένα άλλο



Συνολικό κόστος ι
διοκτησίας:

το συνολικό οικονομικό κόστος που επιβαρύνει τον
ιδιοκτήτη του έργου καθ’ όλη τη διάρκεια ζωής του λογισμικού



Φιλικό προς το χρήστη:

πόσο εύκολα μπορεί ο απλός χρήστης να εξοικειωθεί με το
σύστημα και τι ικανότητες απαιτούνται για τη χρήση του

Authorship Identification Methods


Page
17


Υπάρχουν αρκετοί που υποστηρίζουν ότι τα έργα ανοικτού κώδικα παρουσιάζουν χαλαρή και
λανθασμένη διαχείριση λόγω της πολυπλοκότητας της ομάδας ανάπτυξης. Σε επόμενη ενότητα θα
παρουσιαστούν αναλυτικά και οι ρόλοι που μπορούν να υπάρξουν σε αυτές τις ομάδες

καθώς και
τη σημασία του καθενός ξεχωριστά. Με βάση το πιο πάνω, καταλήγουν λοιπόν στο συμπέρασμα
ότι θα είναι και πιο δύσχρηστα. Για την αντιμετώπιση της κατάστασης αυτής, αναπτύσσονται
σήμερα ολοένα και περισσότερα εργαλεία υποστήριξης της διαχείρισης τ
ων έργων με σκοπό την
αύξηση της φιλικότητας προς το χρήστη.

Τέλος, όσον αφορά τις ανησυχίες που εγείρονται σχετικά με την ιδιοχρησία λογισμικού που ανήκει
σε τρίτους, η κοινότητα του λογισμικού ανοικτού κώδικα απαντά ότι κάτι ανάλογο συμβαίνει
συνήθως κα
ι με το κλειστό λογισμικό και μάλιστα στον τομέα αυτό με καμία νόμιμη άδεια για
κατοχή και τροποποίηση λογισμικού. Έτσι σήμερα πολύ μεγάλες εταιρίες όπως για παράδειγμα η
IBM

και
Hewlett

Packard

διαχειρίζονται και προκηρύσσουν έργα ανοικτού κώδικα και προσκαλούν
τους μελλοντικούς χρήστες στη δωρεάν χρήση τους αρχικά με στόχο την πρόσθετη αξιοπιστία.
Κάτι ανάλογο έγινε και τον τελευταίο καιρό με την
Microsoft

όπου για περίπου ένα χρόνο πριν από
τη
ν κυκλοφορία των
Windows

7
και θέλοντας να αποφύγει την
μη αναμενόμενη αποδοχή

του νέου
προϊόντος όπως έγινε και με τα
Windows

Vista
,
προχώρησε στη δωρεάν προσφορά τους στο
κοινό μέχρι και τον Ιούνιο του 2009 (
Release

Candidate

version
)

για πλήρη δοκιμή κα
ι
παρατηρήσεις με σκοπό πάντα τη βελτίωση του προϊόντος πριν την κυκλοφορία του.



Οι

υποενότητες που ακολουθούν εστι
άζουν

στην διαδικασία ανάπτυξης ενός έργου ανοικτού
κώδικα όπως αυτή γίνεται αντιληπτή μέσω της ομάδας ανάπτυξης. Ποιες τεχνολογίες
ακολο
υθούνται, κατά πόσο η ποιότητα και η αποτελεσματικότητα ενός έργου εξαρτάται από το
μέγεθος της ομάδας ανάπτυξης καθώς και η συμπεριφορά των προγραμματιστών στην κοινότητα
ανάλογα με το ρόλο τους στο έργο είναι θέματα που παρουσιάζονται στη συνέχεια. Όλα π
άντως
καταλήγουν στο γεγονός ότι ανεξάρτητα από τους κανόνες, τα άτομα που εμπλέκονται και τη
διαχείριση τα έργα ανοικτού κώδικα ακολουθούν κοινή προσέγγιση και πορεία ανάπτυξης

[11]
.



3.2

Προτεινόμενη Διαδικασία Ανάπτυξης

Καθ’ όλο το μήκος της ενότητας
χρησιμοποιούν
ται οι
προτάσεις που παρουσιάζονται στο έγγραφο


The

Cathedral

and

the

Bazaar

του
Eric

S
.
Raymond

[12]
,

στις οποίες κατά το συγγραφέα
στηρίζεται και η επιτυχής ανάπτυξη ενός έργου ανοικτού κώδικα.

Αρχικά, σύμφωνα πάντα με τον συγγραφέα,
«
ένα
πετυχημένο έργο λογισμικού ξεκινά ως λύση σε
ένα πρόβλημα που απασχολεί τον προγραμματιστή του
»
.

Επεκτείνοντας, ποιος άλλος καλύτερος
από τον ίδιο τον ενδιαφερόμενο υπάρχει για να κατανοήσει πλήρως τη λειτουργικότητα που
χρειάζεται να του προσφέρει το σύστ
ημα
. Ως αποτέλεσμα, ο ίδιος ο προγραμματιστής με
περισσότερη όρεξη θα κάνει μια δυναμική αρχή για να δώσει μια πρώτη λύση που στη συνέχεια θα
προσφέρεται ως στερεό υπόβαθρο για να το χρησιμοποιήσουν και άλλοι προγραμματιστές.

Στη συνέχεια και σε σύνδεση με

την προηγούμενη ενότητα παρατίθεται η αρχή «ένας καλός
προγραμματιστής γνωρίζει τι πρέπει να γράψει ενώ ένας τέλειος προγραμματιστής γνωρίζει τι
μπορεί να επαναχρησιμοποιήσει». Εξάλλου είναι πάντα καλύτερο να ξεκινά κανείς από ένα καλό
σημείο και να προχω
ρά παρά να αρχίζει από το μηδέν. Σε αυτό στηρίζονται και όλα τα
πλεονεκτήματα της επαναχρησιμοποίησης αφού ο κάθε ένας προγραμματιστής μπορεί να έχει
πρόσβαση στα κομμάτια κάποιου άλλου τα οποία μπορεί και ο ίδιος να χρησιμοποιήσει,
τροποποιήσει, ενσωματώσ
ει στο δικό του έργο.

Στη διάρκεια της διαδικασίας ανάπτυξης πολλές φορές προβληματίζεται κανείς όταν εκ των
υστέρων ανακαλύψει ότι θα μπορούσε με διαφορετικό τρόπο και πιο ευέλικτο να αποτυπώσει μια
Authorship Identification Methods


Page
18


συγκεκριμένη λειτουργία. «Αν σκέφτεσαι να απορρίψεις ένα

υπάρχον τμήμα της λύσης τότε στο
τέλος αυτό θα κάνεις». Και πράγματι, από τη στιγμή που αντιλαμβάνεται ο προγραμματιστής ότι
εξελίσσοντας μια λειτουργία θα πλησιάσει περισσότερο στο επιθυμητό αποτέλεσμα γιατί να μην
προχωρήσει στην αλλαγή; Βέβαια, σε τέτο
ιες περιπτώσεις είναι καλύτερα να διαγραφεί απ’ το
μυαλό (και από το σύστημα) το συγκεκριμένο κομμάτι και να ξαναγραφεί εντελώς από την αρχή
ακριβώς όπως πιστεύεται ότι θα είναι η λύση.


Προχωρώντας, καθώς
υλοποιείται
η λύση ενός προβλήματος συνεχώς παρουσ
ιάζονται νέα υπό
προβλήματα που αφορούν είτε τον τρόπο ανάπτυξης, είτε την επακριβή υλοποίηση με
συγκεκριμένους αλγορίθμους. «Προχωρώντας με τη σωστή στάση και συμπεριφορά εγείρονται
ενδιαφέροντα προβλήματα». Αυτό οφείλεται στο γεγονός ότι
ο προγραμματιστή
ς
συνεχώς
αντιλαμβ
άνεται

την πορεία στην οποία θα οδηγηθε
ί

με την επιλογή της συγκεκριμένης λύσης. Ως
αποτέλεσμα, παρουσιάζονται αρκετές δυσκολίες αλλά και εμπλοκές καμιά φορά που απαιτούν
χρόνο και προσπάθεια για να ξεπεραστούν.
Εντέλει, καμιά φορά προκύπ
τει και αδιέξοδο οπότε
ακολουθείται η παρότρυνση «όταν χαθεί το ενδιαφέρον για ένα έργο, το τελευταίο καθήκον προς
αυτό είναι η ανάθεσή του σε κάποιον που έχει ήδη επιτύχει στον τομέα αυτό».

Δεν σημειώθηκε ακόμα η σημαντικότητα της κοινότητας κατά τη διάρκ
εια ανάπτυξης ενός έργου
ανοικτού κώδικα. Όχι μόνο παίζει μεγάλο ρόλο στην μετέπειτα εξέλιξη του έργου, αλλά οι χρήστες
που ανήκουν στην κοινότητα είναι αυτοί που θα υποδείξουν τις ανάγκες που πρέπει να
ικανοποιηθούν στη συνέχεια. Αυτοί ε
ίναι που επικροτού
ν

την παροχή νέας λειτουργικότητας και
αυτοί είναι που μελλοντικά ίσως γίνουν μέλη της ομάδας ανάπτυξης.


Λόγω της διάθεσης του κώδικα σε όλο τον κόσμο, είναι πολύ πιθανόν οι χρήστες του
προγράμματος να ενεργήσουν ως χάκερς. Στην περίπτωση αυτή όμως κάθε ά
λλο παρά πρόβλημα
θα είναι για την περαιτέρω ανάπτυξη του συστήματος αφού οι ίδιοι οι χρήστες του μπορεί να
εντοπίσουν αδύναμα σημεία, λάθη, καλύτερους τρόπους προσέγγισης με αποτέλεσμα την ακόμα
πιο γρήγορη και ασφαλή ανάπτυξη του έργου. Για το λόγο αυτό
λοιπόν «το να συμπεριφέρεται ο
προγραμματιστής στους χρήστες του προγράμματός του ως συνάδελφους, είναι η πιο αναίμακτη
προσέγγιση για την γοργή βελτίωση του κώδικα του έργου». Βέβαια, με την προσέγγιση αυτή
μειώνεται και στο ελάχιστο ο χρόνος δοκιμών για
τον εντοπισμό σφαλμάτων αφού αυτά θα γίνονται
σε ένα μεγάλο ποσοστό αντιληπτά από την κοινότητα πριν καν την ολοκλήρωση του
προγράμματος.

Στις περισσότερες επιχειρήσεις που ασχολούνται με έργα κλειστού κώδικα το τελικό προϊόν
παρουσιάζεται στους χρήστες το
υ όταν πλησιάζει προς το τέλος. Αντίθετα, στα έργα ανοικτού
κώδικα είναι σχεδόν απαραίτητη η έκδοση πολλών και συχνών εκδόσεων πριν το τελικό
έργο
ελευθερωθεί στην αγορά. Με
τον τρόπο αυτό, οι χρήστες μπορούν να τροφοδοτήσουν την ομάδα
ανάπτυξης με πολύ ση
μαντικές πληροφορίες που αφορούν τη φιλικότητα του προγράμματος, τις
λειτουργίες που παρέχει, ακόμα και εισηγήσεις για περαιτέρω ανάπτυξη
και εμπλουτισμό. Έτσι «οι

συχνές νέες εκδόσεις του προγράμματος και η αξιοποίηση της πληροφορίας που θα λαμβάνεται
από

τους χρήστες»

είναι παράγοντες κλειδιά σχετικά με την πολυπλοκότητα του τελικού προϊόντος.

Πολύ μεγάλη σημασία στη λειτουργικότητα του κώδικα παίζουν και οι δομές δεδομένων που
χρησιμοποιούνται. «Έξυπνες και λειτουργικές δομές δεδομένων σε συνδυασμό με κα
κογραμμένο
κώδικα λειτουργούν πολύ καλύτερα απ’ ότι σν ισχύει το ακριβώς αντίθετο». Αυτό συμβαίνει γιατί
κώδικας ο οποίος είναι μεν σωστός αλλά όχι ευέλικτος μπορεί να λειτουργήσει αποδοτικά όταν η
διαχείριση των δεδομένων γίνεται σε κατάλληλες δομές δεδομ
ένων. Στην αντίθετη περίπτωση και
όταν υπάρχουν δηλαδή πολύ απλές δομές σε συνδυασμό με τον καλύτερο δυνατό κώδικα, η
επεξεργασία των δεδομένων μπορεί να γίνεται σωστά αλλά δεν σημαίνει ότι σωστά γίνεται και η
αποθήκευση ή και η ανάκλησή τους.

Όπως προανα
φέρθηκε, είναι μεγάλης σημασίας η υποστήριξη από τους χρήστες του έργου. Εκτός
όμως από τη βοήθεια στον εντοπισμό και τη διόρθωση των λαθών πολύ σημαντική είναι και η
Authorship Identification Methods


Page
19


προσφορά τους σε ιδέες και εισηγήσεις σχετικά με την επέκταση του έργου. «Το επόμενο καλύ
τερο
πράγμα από τις έξυπνες ιδέες της ομάδας ανάπτυξης είναι αναγνώριση των καλών ιδεών των
χρηστών». Η αναγνώριση ότι ο ίδιος ο προγραμματιστής δεν είχε σκεφτεί μια συγκεκριμένη
παράμετρο δεν αποτελεί μειονέκτημα για τον ίδιο αλλά προτέρημα αφού αναγνωρίζ
ει τη βοήθεια
που του προσφέρουν οι άλλοι με στόχο ο ίδιος να γίνει καλύτερος μέσα από αυτό.
«Η τέλεια
σχεδίαση επιτυγχάνεται όχι όταν δεν υπάρχει κάτι άλλο για να προστεθεί, αλλά όταν δεν υπάρχει
κάτι άλλο που να μπ
ορεί να αφαιρεθεί». Συμπέρασμα που προκύ
πτει

λοιπόν
:

όσο ο κώδικας
απλουστεύεται και γίνεται πιο κατανοητός σε όλους, τότε είναι που
αντιλαμβάνεται κανείς

ότι είναι
και ο καταλληλότερος για μια συγκεκριμένη λειτουργία.

Όσον αφορά την μετέπειτα εξέλιξη του έργου, δεν αρκεί μόνο η ομάδα ανάπτυξης
να συμπεριλάβει
τις λειτουργίες που αυτή θεωρεί σημαντικές. Είναι απαραίτητο να ικανοποιήσει και τις ανάγκες των
υπολοίπων χρηστών. Δεν αρκεί μόνο αυτό, πρέπει το όλο έργο να κρατηθεί απλό και κατανοητό σε
όλους. Μέσα στην επέκταση του έργου πρέπει να περι
λαμβάνονται επίσης και εργαλεία
υποστήριξης με προοπτικές ανάπτυξης και συμπερίληψης καινούριων μελλοντικά. «Κάθε εργαλείο
πρέπει να έχει κάποιο λόγο ο οποίος να το θεωρεί χρήσιμο αλλά ένα εξαιρετικό εργαλείο είναι αυτό
που θεωρείται απαραίτητο για την ανά
πτυξη ακόμα περισσότερων, που υπερβαίνει τις προσδοκίες
της ομάδας ανάπτυξης». Απαραίτητη λοιπόν προϋπόθεση για την εδραίωση του έργου είναι η
προσοχή στις εισηγήσεις των χ
ρηστών ανεξαρτήτως του γεγονότο
ς ότι αυτοί δεν πληρώνουν
πλέον για την ολοκλήρωση το
υ έργου αυτού.

Μια από τις καλές αρετές του προγραμματισμού σε έργα ανοικτού κώδικα είναι η μη εγωιστική
προγραμματιστική στάση. Εξάλλου είναι λογικό ότι «πολλά μυαλά είναι πάντα καλύτερα από ένα».
Για το λόγο αυτό οι διαχειριστές του έργου δεν είναι κτητ
ικοί με τους συναδέλφους τους και τα
τμήματα κώδικα που γράφει ο καθένας. Αντίθετα, ενθαρρύνουν ο ένας τον άλλο καθώς και τα
υπόλοιπα μέλη της κοινότητας να ψάξουν για τυχόν σφάλματα, πάντα με κύριο στόχο την ποιότητα
του τελικού προϊόντος για το οποίο όλο
ι αγωνίζονται. Δεν είναι τυχαίο το γεγονός ότι μεγάλη
επιτυχία παρουσιάζουν τα έργα ατόμων που ξεκινούν δειλά δειλά

την ανάπτυξη ενός έργου για την
επίλυση ενός προβλήματος που αφορά πολλούς και σταδιακά προσελκύουν νέους χρήστες και
προγραμματιστές με στό
χο την αποδοτική συνεργασία για την επίτευξη ενός κοινού στόχου. Μέσα
από την εθελοντική βοήθεια και το ενδιαφέρον μπορεί σε πολύ μικρό χρονικό διάστημα να
ολοκληρωθεί σημαντικό μέρος της δουλειάς και μέσα από αυτό να προκύψουν και νέα ζητήματα
που θα το ε
ξελίξουν ακόμα περισσότερο.


3.3

Χαρακτηριστικά
που παρουσιάζονται

στα έργα ανοικτού κώδικα

Στην ενότητα αυτή
αναφέρονται
τα χαρακτηριστικά
που παρουσιάζονται συνήθως
στα έργα
ανοικτού κώδικα.
Από πόσα άτομα αποτελείται η ομάδα ανάπτυξης, ποιο ρόλο αυτοί
κατέχουν
στην πορεία του έργου και πόσο χρόνο αφιερώνουν σε αυτά καθώς και τα άτομα που
περιλαμβάνονται στην κοινότητα των χρηστών και η δική τους σημασία στην εξέλιξη του έργου
.

Παράγοντες που είναι πολύ σημαντικοί αφού μέσα από αυτούς καθορίζεται η όλη π
ορεία
ανάπτυξης ενός έργου, το βάθος και η πολυπλοκότητά του.

Σύμφωνα με μελέτες που έγινα
ν

σχετικά με το θέμα αυτό [13],
το 49% των έργων ανοικτού κώδικα
έχουν μόνο ένα προγραμματιστή στην ομάδα ανάπτυξης ενώ 15% έχουν μόνο δύο με τρεις. Μόνο
6% των έργω
ν έχουν ομάδα ανάπτυξης που αριθμεί πέραν των 20 ατόμων. Σωστό είναι να
διευκρινιστεί εδώ ότι αναφερόμαστε μόνο στα άτομα που προσφέρουν με κώδικα στην εξέλιξη του
έργου και όχι στην κοινότητα των χρηστών που το χρησιμοποιούν. Ως αποτέλεσμα των ποσοστών
πο
υ προαναφέρθηκαν, τα περισσότερα έργα έχουν πολύ μικρή διάρκεια, είναι απλά και δεν
υποστηρίζονται από πολλούς προγραμματιστές.

Authorship Identification Methods


Page
20


Όταν γίνεται αναφορά

σε μεγαλύτερα έργα, θα περίμενε κανείς αυτά να έχουν και μεγάλη ομάδα
ανάπτυξης. Αυτό στην πραγματικότητα
δεν ισχύει αφού έχει παρατηρηθεί ότι λιγότερα άτομα
παράγουν την ίδια ποσότητα κώδικα όταν πρόκειται για έργο το οποίο προσδοκούν να επικρατήσει
για καιρό ανάμεσα στην κοινότητα. Όμως, δεν είναι όλοι οι προγραμματιστές μιας ομάδας
ανάπτυξης που συμμετέχουν

με ζήλο καθ’ όλη τη διάρκεια ζωής του έργου στην ανάπτυξη του
.
Για
το λόγο αυτό οι προγραμματιστές μιας ομάδας ανάπτυξης χωρίζονται σε 2 κατηγορίες: τους
σταθερούς προγραμματιστές και τους περιοδικούς. Ως περιοδικοί ορίζονται οι προγραμματιστές οι
οποίοι
σε οποιοδήποτε σημείο της εξέλιξης του έργου προσέφεραν έστω και ένα τμήμα κώδικα. Ως
σταθεροί ορίζονται οι προγραμματιστές που ενίσχυσαν το έργο με περισσότερα από ένα τμήματα
κώδικα σε διαφορετικά επίπεδα του έργου που έχουν σημαντικό ρόλο στη λειτουργικ
ότητά του.

Στα
περισσότερα έργα και σε ποσοστό που ανέρχεται στο 73% υπάρχει μόνο ένας σταθερός
προγραμματιστής, πράγμα αναμενόμενο τη στιγμή που όπως σημειώθηκε είναι πολύ μεγάλος ο
αριθμός των έργων με ένα μόνο άτομο στην ομάδα ανάπτυξης.




Ο αριθμός τ
ων μελών της κοινότητας και πιο συγκεκριμένα ο αριθμός των χρηστών που
χρησιμοποιούν ένα έργο ανοικτού κώδικα φανερώνει το ποσοστό επιτυχίας του. Σύμφωνα πάντα
με την ίδια έρευνα, 81% των έργων ανοικτού κώδικα έχουν λιγότερους από 11 χρήστες
εγγεγραμμένους

στην κοινότητα ενώ αντίστοιχα μεγάλο ποσοστό παρουσιάζουν και τα έργα με
μόλις 2 άτομα στην κοινότητα.

Μόλις το 10% των έργων έχουν περισσότερους από 20 χρήστες και
1% μόνο έχει περισσότερους από 100. Παράγοντες που επηρεάζουν το μέγεθος της κοινότητας
είναι μεταξύ άλλων και ο χρόνος ζωής του έργου. Είναι ουσιαστικά σχεδόν αδύνατο ένα έργο που
δημιουργήθηκ
ε χθες να έχει σήμερα 100 άτομα ως χρήστες. Ο λόγος είναι ότι στα αρχικά στάδια
του έργου αυτό μπορεί να μην παρουσιάζει λειτουργικότητα που να προσελκύει το ενδιαφέρον των
χρηστών που ψάχνουν για κάτι προχωρημένο. Όμως δεν σημαίνει επίσης ότι ένα έργο 2 κ
αι πλέον
χρόνων θα έχει τεράστια κοινότητα χρηστών τη στιγμή που αναπτύσσεται από 1 ή 2
προγραμματιστές. Καταλήγουμε λοιπόν στο συμπέρασμα ότι έργα που δεν προσελκύουν νέα μέλη
στην ομάδα ανάπτυξης είναι αδύνατο να προσελκύσουν και νέα μέλη στην κοινότητα.

Αντίθετα,
έργα που παρουσιάζουν κινητικότητα όσον αφορά τον αριθμό των χρηστών τους, ενδέχεται να
παρουσιάζουν και
συχνές

αλλαγές στον κώδικά τους και στις λειτουργίες που προσφέρουν.

Ενδιαφέρον παρουσιάζει και η δομή των έργων αλλά και η τεκμηρίωσή τους.

41% των έργων
έχουν μόνο ένα
directory

για το έργο τους ενώ πολύ λίγα είναι αυτά που έχουν 2 ή και
περισσότερα. Παράμετροι όμως που παίζουν σημαντικό ρόλο σε αυτό είναι και το μέγεθος του
έργου που συνεπάγεται και την ποσότητα κώδικα που απαιτείται.


Όσο
ν αφορά την τεκμηρίωση αυτή μπορεί να γίνεται είτε μόνο ως σχόλια στον κώδικα, είτε ως ένα
read

me

αρχείο είτε και ως κανονικό εγχειρίδιο χρήσης σε μορφή μιας μίνι εφαρμογής. Και στην
περίπτωση της τεκμηρίωσης όμως σημαντικός παράγοντας διαμόρφωσής είναι η

ποσότητα του
κώδικα. Μια πολύ μικρή και απλή στη λειτουργία της εφαρμογή μπορεί να αρκεστεί στον
σχολιασμό μέσα στα αρχεία του πηγαίου κώδικα ενώ ένα μεγάλο έργο με περίπλοκη
λειτουργικότητα σίγουρα απαιτεί και την ανάλογη καθοδήγηση προς τους χρήστες του
.

Προχωρώντας και συνδυάζοντας και τις παρατηρήσεις σχετικά με τον αριθμό των σταθερών
προγραμματιστών και των μελών της ομάδας ανάπτυξης παρατηρείται μια στενή σχέση ανάμεσα
στη δομή και την τεκμηρίωση του έργου. Πιο συγκεκριμένα,
η δομή είναι σχεδόν ανύπ
αρκτη όταν
είναι μόνο ένας ο σταθερός προγραμματιστής του έργου ενώ υπάρχει δομή στις ομάδες ανάπτυξης
με περισσότερους από ένα σταθερούς προγραμματιστές. Η εξήγηση
μπορεί να δοθεί αν
αναλογιστεί κανείς

ότι σε περιπτώσεις που η εργασία γίνεται με ομαδικό τρόπο υπάρχει η ανάγκη
επικοινωνίας μέσω του κώδικα και για να γίνει αυτό πρέπει να τηρούνται κάποιοι κανόνες σχετικά