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

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

Μετρήσεις

Το σύνολο των μετρήσεων που χρησιμοποιούνται περιλαμβάνει:

σειρά ανάπτυξης (εννοείται η ανάλυση των αλγορίθμων από την άποψη της ασυμπτωτικής ανάλυσης και της σημείωσης O),
ανάλυση σημείων λειτουργίας,
αριθμός σφαλμάτων ανά 1000 γραμμές κώδικα,
βαθμός κάλυψης κωδικού με δοκιμή,
αριθμός κλάσεων και διεπαφών,
μετρήσεις πακέτου λογισμικού από τον Robert Cecil Martin,

Κριτική

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

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

δείτε επίσης

Βασικές μετρήσεις κώδικα: LOC, SLOC, Gilb, McCabe, Halstead, OOP και άλλα

Ίδρυμα Wikimedia. 2010.

Οδόμετρο
Στηθοσκόπιο

Δείτε τι είναι το "Software Metrics" σε άλλα λεξικά:

Ποιότητα λογισμικού

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

Μετρήσεις- έχει πολλές έννοιες: Στα μαθηματικά, η μετρική είναι μια συνάρτηση που καθορίζει τις αποστάσεις στο μετρικό χώρο. Το Metric είναι ένα εναλλακτικό όνομα για τον μετρικό τανυστή, συγκεκριμένα Metric of space-time 4 tensor, ο οποίος ... ... Wikipedia

Κάλυψη κωδικού- Αυτός ο όρος έχει άλλες έννοιες, βλέπε Κάλυψη. Η κάλυψη κώδικα είναι ένα μέτρο που χρησιμοποιείται στη δοκιμή λογισμικού. Δείχνει το ποσοστό στο οποίο έχει δοκιμαστεί ο πηγαίος κώδικας του προγράμματος. Η τεχνική κάλυψης κώδικα ήταν... ... Wikipedia

Αριθμός γραμμών κώδικα- Δείτε επίσης: Γραμμές πηγής όγκου κώδικα Το SLOC είναι μια μέτρηση λογισμικού που χρησιμοποιείται για τη μέτρηση του όγκου του μετρώντας τον αριθμό των γραμμών στο κείμενο του πηγαίου κώδικα. Κατά κανόνα, ... ... Wikipedia

Stress Testing- (English Load Testing) προσδιορισμός ή συλλογή δεικτών απόδοσης και χρόνου απόκρισης ενός συστήματος ή συσκευής λογισμικού και υλικού σε απόκριση σε εξωτερικό αίτημα προκειμένου να διαπιστωθεί η συμμόρφωση με τις απαιτήσεις για ένα δεδομένο σύστημα ... Wikipedia

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

Scrum- Ανάπτυξη λογισμικού Διαδικασία ανάπτυξης λογισμικού Βήματα διαδικασίας Ανάλυση Σχεδιασμός Προγραμματισμός Έγγραφο ... Wikipedia

Κυκλοματική πολυπλοκότητα- προγράμματα (Αγγλικά: Cyclomatic complexity of a program) δομικό (ή τοπολογικό) μέτρο της πολυπλοκότητας του προγράμματος, που χρησιμοποιείται για τη μέτρηση της ποιότητας του λογισμικού, με βάση μεθόδους ανάλυσης στατικού κώδικα. Το DSP ισούται με ... ... Wikipedia

Zabbix- 1.1 alpha 6 που εκτελείται υπό GNU/Linux... Wikipedia

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

Το πιο ευρέως γνωστό και χρησιμοποιούμενο πρότυπο για την οργάνωση των διαδικασιών ποιοτικού ελέγχου είναι η σειρά προτύπων ISO 9000 Για τη διαδικασία ανάπτυξης λογισμικού, χρησιμοποιείται το πρότυπο ISO 9001, το οποίο περιλαμβάνει σχεδιασμό ανά παραγωγή. Θα πρέπει να σημειωθεί ότι αυτό το πρότυπο είναι δύσκολο να χρησιμοποιηθεί άμεσα στη διαχείριση ποιότητας ανάπτυξης λογισμικού, καθώς αρχικά επικεντρώνεται στην ανάπτυξη βιομηχανικών προϊόντων. Ειδικά για την υποστήριξη των διαδικασιών ανάπτυξης συστημάτων λογισμικού από τον οργανισμό ISO, έχει αναπτυχθεί ο οδηγός ISO 9000-3, ο οποίος διατυπώνει τις απαιτήσεις του ποιοτικού μοντέλου ISO 9001 για την οργάνωση της διαδικασίας ανάπτυξης λογισμικού.

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

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

Μεταξύ των προγραμματιστών λογισμικού, ειδικά στο εξωτερικό (κυρίως στις ΗΠΑ), ένα εναλλακτικό μοντέλο ποιότητας έχει υψηλή βαθμολογία: CMM - SEI. Αυτό το μοντέλο ποιότητας αναπτύχθηκε στο Ινστιτούτο Μηχανικής Λογισμικού υπό τη χορηγία του Υπουργείου Άμυνας των ΗΠΑ. Αρχικά, αυτό το μοντέλο ποιότητας χρησιμοποιήθηκε από κυβερνητικούς, ιδίως στρατιωτικούς, οργανισμούς κατά την υποβολή παραγγελιών για ανάπτυξη λογισμικού. Το πρότυπο χρησιμοποιείται πλέον ευρέως για την ανάλυση και την πιστοποίηση των διαδικασιών ανάπτυξης λογισμικού εταιρειών που παράγουν πολύπλοκο λογισμικό σε κρίσιμους τομείς εφαρμογής. Σημαντικά πλεονεκτήματα του μοντέλου CMM είναι η ιεραρχική ένθεση των μοντέλων ποιότητας, που σας επιτρέπει να μετράτε και να συγκρίνετε τα επίπεδα ποιότητας της διαδικασίας σε διαφορετικούς οργανισμούς και να διασφαλίζετε αποτελεσματική βελτίωση της ποιότητας της διαδικασίας.

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

Από μια άποψη, τα μοντέλα ποιότητας CMM και ISO είναι εναλλάξιμα, ωστόσο, στην ουσία, δεν έρχονται σε αντίθεση μεταξύ τους, αφού βασίζονται στο ίδιο πρότυπο ποιότητας - TQM - Διαχείριση Ολικής Ποιότητας.

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

Ποιότητα προϊόντος λογισμικού

Ποιότητα στοιχείων λογισμικού

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

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

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

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

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

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

Πίνακας 1.3.

Ονομα μοντέλου	Φόρμουλα, ονομασία
ΜΕΤΡΗΣΕΙΣ ΠΟΛΥΠΛΟΚΤΟΤΗΤΑΣ
Μετρήσεις Halstead Διάρκεια προγράμματος; Πεδίο εφαρμογής του προγράμματος Αξιολόγηση της εφαρμογής του. Δυσκολία στην κατανόησή του. Κωδικοποίηση έντασης εργασίας. Επίπεδο γλώσσας έκφρασης; Πληροφοριακό περιεχόμενο; Βέλτιστη αρθρωτότητα;	N = n 1 log 1 n 1 + n 2 log 2 n 2 L * = (2 n 2)/ (n 1 N 2) D = (n 1 N 2) (2n 2) = 1/ L * * = V/ D 2 = V/ L * 2
Gilba Metrics Αριθμός δηλώσεων βρόχου; Αριθμός δηλώσεων συνθήκης. Αριθμός ενοτήτων ή υποσυστημάτων. Η αναλογία του αριθμού των συνδέσεων μεταξύ των μονάδων προς τον αριθμό των μονάδων. Ο λόγος του αριθμού των μη κανονικών εξόδων από ένα σύνολο τελεστών προς τον συνολικό αριθμό χειριστών.	f = N 4 SV / L mod f=NSV/L
Μετρήσεις McCabe Κυκλωματικός αριθμός; Κυκλοματική πολυπλοκότητα;	(G) = m – n + p (G) = (G) +1 = m – n + 2
Μετρική Chepin Ένα μέτρο της δυσκολίας κατανόησης προγραμμάτων με βάση τα δεδομένα εισόδου και εξόδου.	H = 0,5T+P+2M+3C
Μετρική Schnadewied Αριθμός διαδρομών στο γράφημα ελέγχου
Μετρική Myers Μέτρο διαστήματος;
Μετρική Hansen Ζεύγος (κυκλωματικός αριθμός, αριθμός τελεστών)
Η μέτρηση του Τσεν Τοπολογικό μέτρο του Τσεν.	M(G) = ((G), C, Q 0)
Woodward μετρική Κομβικό μέτρο (αριθμός κόμβων μετάδοσης ελέγχου).
Kulik μετρική Κανονικός αριθμός (ο αριθμός των απλούστερων κύκλων σε ένα κανονικό διάγραμμα προγράμματος).
Μετρική Hura Κυκλωματικός αριθμός ενός διχτυού Petri που αντικατοπτρίζει τη δομή ελέγχου του προγράμματος.
Metrics of Whitworth, Zulevsky Μέτρο πολυπλοκότητας ροής ελέγχου Ένα μέτρο της πολυπλοκότητας μιας ροής δεδομένων.
Μετρική Peterson Αριθμός κύκλων πολλαπλών εισόδων.
Metrics of Harrison, Majel Λειτουργικός αριθμός (το άθροισμα των μειωμένων πολυπλοκοτήτων όλων των κορυφών του γραφήματος ελέγχου). Λειτουργικός λόγος (ο λόγος του αριθμού των κορυφών του γραφήματος προς τον συναρτητικό αριθμό). Κανονικές εκφράσεις (ο αριθμός των τελεστών, των τελεστών και των παρενθέσεων στην κανονική έκφραση του γραφήματος ελέγχου προγράμματος).	f * = N 1 / f 1
Μετρική Pivovarsky Τροποποιημένο μέτρο κυκλωματικής πολυπλοκότητας.	N(G) = * (G) + P i
Μετρική Pratt Μέτρο δοκιμής;
Μετρικό καντόνι Χαρακτηριστικοί αριθμοί πολυωνύμων που περιγράφουν το γράφημα ελέγχου του προγράμματος.
Μετρική McClure Ένα μέτρο πολυπλοκότητας που βασίζεται στον αριθμό των πιθανών διαδρομών εκτέλεσης του προγράμματος, τον αριθμό των δομών ελέγχου και των μεταβλητών.	C(V) = D(V)J(V)/ N
Μετρική Καφούρ Ένα μέτρο που βασίζεται στην έννοια των ροών πληροφοριών.
Μετρική Schutts, Mohanty Μέτρα εντροπίας;
Κολόφελο μετρικό Ένα μέτρο της λογικής σταθερότητας των προγραμμάτων.
Μετρική Zolnovsky, Simmons, Thayer Σταθμισμένο άθροισμα διαφόρων δεικτών: - (δομή, αλληλεπίδραση, όγκος, δεδομένα). - (πολυπλοκότητα διεπαφής, υπολογιστική πολυπλοκότητα, πολυπλοκότητα εισόδου/εξόδου, αναγνωσιμότητα).
Μέτρηση Berlinger Μέτρο ενημέρωσης;	I(R) = (F * (R) F - (R)) 2
Μετρική Schumann Πολυπλοκότητα από τη σκοπιά της στατιστικής θεωρίας της γλώσσας.
Νεότερη μέτρηση Λογική πολυπλοκότητα λαμβάνοντας υπόψη το ιστορικό των υπολογισμών. Πολυπλοκότητα σχεδιασμού Κορεσμός σχολίων Αριθμός εξωτερικών κλήσεων Αριθμός χειριστών	C c = log 2 (i + 1)[ n Cxy (n)]
ΜΟΝΤΕΛΟ ΠΡΟΒΛΕΨΗ
Μοντέλα Halstead Πρόβλεψη πόρων συστήματος. Πρόβλεψη του αριθμού των σφαλμάτων. μοντέλο IBM Μοντέλο συνολικής πολυπλοκότητας Μοντέλα συνδεσιμότητας Spline μοντέλο	P=3/8 (R a – 1) 2 Ra B = Nlog 2 n / 3000 B = 23M 1 + M 1 0 B = 21,1 + 0,1 V + COMP (S) P ij = 0,15 (S i + S j) + 0,7 C ij P ij = S i (Z ij 2 + N ij 2) ln (Z ij 2 + N ij 2) + + Z i + N 1
ΜΟΝΤΕΛΑ ΕΚΤΙΜΗΣΗ
Γελίνσκι – Μοράντα	R(t) = e - (T – 1 + 1) t
Weiss-Bayes	R 1 (t) = e - - (i –1))t (, /t 1 ,…,t i-1)dd
Chic-Wolverton	R 1 (t) = e - (N – 1 + 1) t i 2 / 2
Littlewood	R 1 (t) = (+ / ++ t) (N – i + 1)
Νέλσον	R j (t) = exp ( ln (1 – P j))
Χαλέτσκι	R j (t) = P- (1- nj) / n j
Μοντέλο εντοπισμού σφαλμάτων	R j (t) =P- f j (,)
Μωσαϊκό μοντέλο	R j (t) = 1 - (- j - 1)

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

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

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

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

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

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

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

Το πρώτο μέτρο τοπολογικής πολυπλοκότητας είναι το κυκλωματικό μέτρο McCabe. Βασίζεται στην ιδέα της εκτίμησης της πολυπλοκότητας του λογισμικού από τον αριθμό των βασικών διαδρομών στο γράφημα ελέγχου του, π.χ. τέτοια μονοπάτια, συνθέτοντας τα οποία μπορεί κανείς να λάβει όλα τα πιθανά μονοπάτια από την είσοδο του γραφήματος προς τις εξόδους. Ο κυκλωματικός αριθμός (G) ενός διγράφου G με n-κορυφές, m-τόξα και p συνδεδεμένα συστατικά είναι η ποσότητα (G) = m – n + p.

Υπάρχει ένα θεώρημα ότι ο αριθμός των βασικών μονοπατιών σε ένα δίγραμμα είναι ίσος με τον κυκλωματικό του αριθμό αυξημένο κατά ένα. Στην περίπτωση αυτή, η κυκλωματική πολυπλοκότητα ενός λογισμικού P με γράφημα ελέγχου G ονομάζεται τιμή (G) = (G) +1 = m – n + 2. Στην πράξη, η κυκλωμική πολυπλοκότητα ενός λογισμικού είναι ίση με τον αριθμό των κατηγορημάτων συν ένα, που επιτρέπει τον υπολογισμό του χωρίς την κατασκευή γραφήματος ελέγχου με απλή μέτρηση των κατηγορημάτων . Αυτό το μέτρο αντικατοπτρίζει την «ψυχολογική» πολυπλοκότητα του λογισμικού.

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

Ο J. Myers πρότεινε το διάστημα [1 2] ως μέτρο πολυπλοκότητας, όπου το 1 είναι ένα κυκλωματικό μέτρο και το 2 είναι ο αριθμός των μεμονωμένων συνθηκών συν ένα. Σε αυτήν την περίπτωση, ο τελεστής DO θεωρείται ως μία συνθήκη και CASE με n - αποτελέσματα για n - 1 συνθήκες. Το εισαγόμενο μέτρο ονομάστηκε μέτρο διαστήματος.

Ο W. Hansen σκέφτηκε να λάβει ένα ζεύγος (κυκλωματικός αριθμός, αριθμός χειριστών) ως μέτρο πολυπλοκότητας λογισμικού. Είναι γνωστό ένα τοπολογικό μέτρο Z(G) που είναι ευαίσθητο στη δομή του λογισμικού. Επιπλέον, είναι Z(G) = V(G) (ίσο με κυκλωμική πολυπλοκότητα) για δομημένα προγράμματα και Z(G) V(G) για μη δομημένα προγράμματα. Οι παραλλαγές του μέτρου κυκλωματικής πολυπλοκότητας περιλαμβάνουν επίσης το μέτρο M(G) = (V(G),C,Q), όπου C είναι ο αριθμός των συνθηκών που απαιτούνται για την κάλυψη του γραφήματος ελέγχου με έναν ελάχιστο αριθμό διαδρομών και Q είναι το βαθμός συνδεσιμότητας της δομής του γραφήματος του προγράμματος και το μήκος του .

Τα μέτρα πολυπλοκότητας που λαμβάνουν υπόψη την ένθεση των δομών ελέγχου περιλαμβάνουν το μέτρο δοκιμής M και το μέτρο Harrison-Magel, που λαμβάνουν υπόψη το επίπεδο ένθεσης και το μήκος του λογισμικού, το μέτρο Pivovarsky - κυκλωμική πολυπλοκότητα και βάθος φωλιάς και το McClure μέτρο - η πολυπλοκότητα του σχεδίου διαμερισμάτων λογισμικού σε ενότητες λαμβάνοντας υπόψη τις μονάδες ένθεσης και την εσωτερική πολυπλοκότητά τους.

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

Το μέτρο Pivovarsky στοχεύει να λάβει υπόψη, κατά την αξιολόγηση της πολυπλοκότητας του λογισμικού, τις διαφορές όχι μόνο μεταξύ διαδοχικών και ένθετων δομών ελέγχου, αλλά και μεταξύ δομημένων και μη δομημένων προγραμμάτων. Εκφράζεται με τη σχέση N(G) = * (G) + P i , όπου * (G) είναι η τροποποιημένη κυκλωμική πολυπλοκότητα, που υπολογίζεται με τον ίδιο τρόπο όπως η V(G), αλλά με μία διαφορά: ένας τελεστής CASE με Οι n-outputs θεωρούνται ως ένας λογικός τελεστής, παρά ως n – 1 τελεστές. P i – βάθος ένθεσης του i – αυτή η κορυφή κατηγορήματος.

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

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

Ένα μέτρο δοκιμής M είναι ένα μέτρο πολυπλοκότητας που ικανοποιεί τις ακόλουθες συνθήκες:

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

2. M ((F1; F2; …;Fn)) = i n M(Fi);

3. M (ΑΝ P ΤΟΤΕ F1 ΑΛΛΟ F2) = 2 MAX (M (F1), M (F2));

4. M (ΕΝΩ P DO F) = 2 M(F).

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

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

Το τοπολογικό μέτρο του Chen εκφράζει την πολυπλοκότητα ενός προγράμματος από τον αριθμό των τομών των ορίων μεταξύ των περιοχών που σχηματίζονται από το διάγραμμα ροής του προγράμματος. Αυτή η προσέγγιση ισχύει μόνο για δομημένα προγράμματα που επιτρέπουν μόνο διαδοχική σύνδεση δομών ελέγχου. Για μη δομημένα προγράμματα, το μέτρο του Τσεν εξαρτάται σημαντικά από κλάδους υπό όρους και άνευ όρων. Σε αυτήν την περίπτωση, μπορείτε να καθορίσετε τα άνω και κάτω όρια του μέτρου. Ο κορυφαίος είναι m+1, όπου m είναι ο αριθμός των λογικών τελεστών όταν είναι ένθετοι. Το χαμηλότερο είναι ίσο με 2. Όταν το γράφημα ελέγχου ενός προγράμματος έχει μόνο ένα συνδεδεμένο στοιχείο, το μέτρο Chen συμπίπτει με το κυκλωματικό μέτρο McCabe.

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

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

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

Berg O.Yu.

ΜΕΤΡΗΣΕΙΣ ΓΙΑ ΤΗΝ ΑΞΙΟΛΟΓΗΣΗ ΤΗΣ ΠΟΙΟΤΗΤΑΣ ΛΟΓΙΣΜΙΚΟΥ

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

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

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

Να είναι όσο το δυνατόν απλούστερα, καλά μετρήσιμα και να έχουν χαμηλή διακύμανση.

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

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

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

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

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

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

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

Μετρήσεις που σας επιτρέπουν να προβλέψετε την ποιότητα του αναπτυγμένου λογισμικού. Καθορίζονται στο σετ

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

θα επιτευχθεί στο τέλος.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

η μέτρηση πρέπει να είναι αντικειμενική και ο ορισμός της ξεκάθαρος.

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

η μέτρηση μπορεί να αυτοματοποιηθεί.

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

ΒΙΒΛΙΟΓΡΑΦΙΑ

1. Liu K., Zhou S. Yang H., Quality Metrics of Object Oriented Design for Software Development and Re-development, - Proceedings of the First Asia-Pacific Conference on Quality Software, 2000 IEEE

2. Boehm B. W., Brown J. R., Lipow M. QUANTITATIVE EVALUATION OF SOFTWARE QUALITY Πρακτικά του 2ου Διεθνούς Συνεδρίου για την Μηχανική Λογισμικού στο Διεθνές συνέδριο για τη μηχανική λογισμικού Οκτώβριος 1976

3. Houdek F., Kempter H. Quality patterns - An approach to packaging software engineering experience ACM SIGSOFT Software Engineering Notes, Proceedings of the 1997 Symposium on Symposium on software reusability Μάιος 1997

4. W. Royce Software Project Management, Μόσχα, LORI

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

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

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

Δημιουργία, χρήση και ανάλυση μετρήσεων

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

Μετρήσεις δοκιμαστικής περίπτωσης
Μετρήσεις για σφάλματα/ελαττώματα
Μετρήσεις ανά εργασία

Ας ρίξουμε μια πιο προσεκτική ματιά σε καθένα από αυτά:

Μετρήσεις για δοκιμαστικές περιπτώσεις

Μετρήσεις σφαλμάτων

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

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

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

Λύση κακής ποιότητας στο πρόβλημα (διόρθωση σφαλμάτων)

Δεύτερο παράδειγμαθα δείξει γιατί απαιτείται η μέτρηση "Απορριφθέντα/Ανοιχτά σφάλματα":
Παρατηρούμε ότι το ποσοστό των σφαλμάτων που απορρίφθηκαν είναι πολύ υψηλό. Αυτό μπορεί να σημαίνει:

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

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

Μετρήσεις ανά εργασία

Ονομα	Περιγραφή
Εργασίες ανάπτυξης	Η μέτρηση δείχνει τον αριθμό και τα αποτελέσματα των εγκαταστάσεων εφαρμογών. Η διαδικασία εγκατάστασης της εφαρμογής περιγράφηκε στο άρθρο Διαδικασία εγκατάστασης νέας έκδοσης λογισμικού (Deployment WorkFlow). Εάν ο αριθμός των εκδόσεων που απορρίφθηκαν από την ομάδα δοκιμών είναι εξαιρετικά υψηλός, συνιστάται να αναλύσετε επειγόντως και να εντοπίσετε τους λόγους, καθώς και να λύσετε το υπάρχον πρόβλημα το συντομότερο δυνατό.
Ανοιχτές ακόμα εργασίες	Η μέτρηση δείχνει τον αριθμό των θεμάτων που παραμένουν ανοιχτά. Μέχρι το τέλος του έργου, όλες οι εργασίες πρέπει να έχουν ολοκληρωθεί. Με τον όρο εργασίες εννοούμε τους ακόλουθους τύπους εργασίας: συγγραφή τεκμηρίωσης (αρχιτεκτονική, απαιτήσεις, σχέδια), υλοποίηση νέων ενοτήτων ή αλλαγή υπαρχόντων βάσει αιτημάτων αλλαγής, εργασία για τη δημιουργία περιπτέρων, διάφορες μελέτες και πολλά άλλα.

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

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