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

1.Κωδικοποίηση

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

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

Κατά την κωδικοποίηση, πρέπει να ακολουθήσετε το πρότυπο για την επιλεγμένη γλώσσα, για παράδειγμα, για τη γλώσσα C είναι ANSI C και για C++ είναι το ISO/IEC 14882 "Standard for the C++ ProgrammingLanguage".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ένα καλά τεκμηριωμένο PP έχει τα ακόλουθα πλεονεκτήματα.

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

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

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

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

Επιστήμη Υπολογιστών, Κυβερνητική και Προγραμματισμός

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

Μάθημα Νο 20
Γενικές αρχές και προσεγγίσεις για την ανάπτυξη λογισμικού

Μοντέλα ανάπτυξης λογισμικού

1. Vodopadnaya
2. Cascade μοντέλο
3. Σπειροειδής
4. Ακραίος προγραμματισμός
5. Σταδιακή
6. Μεθοδολογία των ΓΧΣ

Μοντέλο καταρράκτη

Σπειροειδές μοντέλο

Σταδιακή ανάπτυξη

Ανάλυση απαιτήσεων

Σχέδιο

Εκτέλεση

Συστατικό

δοκιμές

Ενσωμάτωση

Δοκιμές

ένα σύνολο

Επανάληψη 1 Επανάληψη 2…. Επανάληψη Ν

Ενιαία Διαδικασία Ανάπτυξης Λογισμικού (USDP)

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

Μεθοδολογία των ΓΧΣ

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

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

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

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

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

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

Καθώς και άλλα έργα που μπορεί να σας ενδιαφέρουν
57355.		Ποικιλία οργανικών ενώσεων, ταξινόμηση τους. Οργανικές ουσίες ζωντανής φύσης	48,5 KB
	Η ποικιλία των οργανικών ενώσεων καθορίζεται από τη μοναδική ικανότητα των ατόμων άνθρακα να συνδέονται μεταξύ τους με απλούς και πολλαπλούς δεσμούς να σχηματίζουν ενώσεις με σχεδόν απεριόριστο αριθμό ατόμων συνδεδεμένα σε αλυσίδες: κύκλους, ποδήλατα, τρίκυκλα, πολύκυκλα, πλαίσια κ.λπ.
57359.		Επεξεργασία μοντέλων λεκτικής πληροφόρησης	291 KB
	Βασικές έννοιες: μοντέλο; μοντέλο πληροφοριών; προφορικό μοντέλο πληροφοριών· σχόλιο; αφηρημένη. Σύνοψη Σύνοψη από λατ. Δημιουργήστε μια σημείωση για το 2. Αποθηκεύστε το έγγραφο στον δικό του φάκελο με το όνομα Σημείωση.
57361.		Αριθμός και σχήμα 3. Στοίχιση αριθμών στα όρια 3. Γράψιμο αριθμών 3. Ευθυγράμμιση του αριθμού των αντικειμένων	35,5 KB
	Πόσα πλάσματα υπάρχουν Ποιος κατατάσσεται πρώτος Ποιος κατατάσσεται τελευταίος Ποιος κατατάσσεται στον αριθμό 1 Ποιος κατατάσσεται στον αριθμό 2 Ονομάστε τους γείτονες του σκαντζόχοιρου. Ποιος είναι ο δεξιόχειρας σκίουρος Ποιος είναι ο αριστερόχειρας καμηλοπάρδαλης Ποιος είναι ο μεγαλύτερος Ποιος είναι ο μικρότερος Ποιος στέκεται στη μέση των πλασμάτων Gra Δείξε μου, μη ελέησον.

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

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

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

την αρχή του «διαίρει και βασίλευε» (βλ. υποενότητα 2.1.1).

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

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

η αρχή της αφαίρεσης - ανάδειξη των βασικών πτυχών του συστήματος και αφαίρεση από το ασήμαντο.

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

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

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

DFD (Διαγράμματα ροής δεδομένων) - διαγράμματα ροής δεδομένων.

SADT (Structured Analysis and Design Technique - μέθοδος δομικής ανάλυσης και σχεδιασμού) - μοντέλα και αντίστοιχα λειτουργικά διαγράμματα.

ERD (Entity-Relationship Diagrams) - διαγράμματα οντοτήτων-σχέσεων.

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

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

Στο στάδιο της διαμόρφωσης απαιτήσεων λογισμικού, τα μοντέλα SADT και DFD χρησιμοποιούνται για την κατασκευή του μοντέλου "AS-IS" και του μοντέλου "TO-BE", αντικατοπτρίζοντας έτσι την υπάρχουσα και προτεινόμενη δομή των επιχειρηματικών διαδικασιών του οργανισμού και την αλληλεπίδραση μεταξύ τους. χρήση μοντέλων SADT, κατά κανόνα, περιορίζεται μόνο σε αυτό το στάδιο, καθώς δεν προορίζονταν αρχικά για σχεδιασμό λογισμικού). Με τη βοήθεια του ERD, μια περιγραφή των δεδομένων που χρησιμοποιούνται στον οργανισμό πραγματοποιείται σε εννοιολογικό επίπεδο, ανεξάρτητα από τα εργαλεία υλοποίησης της βάσης δεδομένων (DBMS).

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

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

Η θεματική περιοχή για τα περισσότερα από τα παραδείγματα διαγραμμάτων που δίνονται σε αυτό το κεφάλαιο είναι το φορολογικό σύστημα της Ρωσικής Ομοσπονδίας, η πληρέστερη περιγραφή του οποίου περιέχεται στον Φορολογικό Κώδικα της Ρωσικής Ομοσπονδίας. ΤΕΧΝΟΛΟΓΙΑ της ΠΛΗΡΟΦΟΡΙΑΣ, που χρησιμοποιούνται στο φορολογικό σύστημα της Ρωσικής Ομοσπονδίας, έχουν ορισμένα χαρακτηριστικά.

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

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

1. Η αρχή του «διαίρει και βασίλευε».

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

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

1. Η αρχή της αφαίρεσης - ανάδειξη των ουσιαστικών πτυχών του συστήματος και αφαίρεση από το ασήμαντο.

2. Η αρχή της συνέπειας, της εγκυρότητας και της συνέπειας των στοιχείων του συστήματος.

3. Αρχή δόμησης δεδομένα - δεδομέναπρέπει να είναι δομημένο και ιεραρχικά οργανωμένο.

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

· DFD (Διαγράμματα ροής δεδομένων) - διαγράμματα ροής δεδομένων.

· SADT (Structured Analysis and Design Technique - μεθοδολογία δομικής ανάλυσης και σχεδίασης) - μοντέλα και αντίστοιχα λειτουργικά διαγράμματα: σημειώσεις IDEF0 (λειτουργική μοντελοποίηση συστημάτων), IDEF1х (εννοιολογική μοντελοποίηση βάσεων δεδομένων), IDEF3х (κατασκευή συστημάτων για την αξιολόγηση της ποιότητας έργο ενός αντικειμένου? γραφική περιγραφήροή διαδικασιών, αλληλεπίδραση διεργασιών και αντικειμένων που αλλάζουν από αυτές τις διαδικασίες).

· ERD (Entity - Relationship Diagrams) - διαγράμματα οντοτήτων-σχέσεων.

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

1. Διαγράμματα που απεικονίζουν τις λειτουργίες που πρέπει να εκτελεί το σύστημα και τις σχέσεις μεταξύ αυτών των λειτουργιών - DFD ή SADT (IDEF0).

2. Διαγράμματα που μοντελοποιούν δεδομένα και τις σχέσεις τους (ERD).

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

Στο στάδιο της διαμόρφωσης απαιτήσεων λογισμικού, τα μοντέλα SADT και DFD χρησιμοποιούνται για την κατασκευή του μοντέλου «AS-IS» και του μοντέλου «TO-BE», αντικατοπτρίζοντας έτσι την υπάρχουσα και προτεινόμενη δομή των επιχειρηματικών διαδικασιών του οργανισμού και την αλληλεπίδραση μεταξύ τους. τη χρήση μοντέλων SADT όπως συνήθως περιορίζονται μόνο σε αυτό το στάδιο, καθώς δεν προορίζονταν αρχικά για σχεδιασμό λογισμικού). Με τη βοήθεια του ERD, πραγματοποιείται περιγραφή των δεδομένων που χρησιμοποιούνται στον οργανισμό σε εννοιολογικό επίπεδο, ανεξάρτητα από τα εργαλεία υλοποίησης της βάσης δεδομένων (DBMS).

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

2. Κύκλος ζωής προγράμματος. Η κυκλική φύση της ανάπτυξης. Βασικές έννοιες της τεχνολογίας προγραμματισμού. Διαδικασίες και μοντέλα. Φάσεις και στροφές. Ορόσημα και αντικείμενα. Ενδιαφερόμενα μέρη και εργαζόμενοι.

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

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

5. Μοντέλα της διαδικασίας ανάπτυξης. Μοντέλα καταρράκτη και μεταφορέων. Σπειροειδή και αυξητικά μοντέλα. Μοντέλα ευέλικτων διαδικασιών ανάπτυξης.

6. Κατασκευή μοντέλου διεργασίας. Προσδιορίστε τις απαιτήσεις της διαδικασίας. Φάσεις, ορόσημα και αντικείμενα που χρησιμοποιούνται. Επιλογή αρχιτεκτονικής διαδικασίας. Διαδικασία για την εκτέλεση ενός τυπικού έργου. Τεκμηριωμένες διαδικασίες.

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

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

9. Η φύση του προγραμματισμού. Η επιστήμη του προγραμματισμού. Η τέχνη του προγραμματισμού. Η τέχνη του προγραμματισμού. Παραδείγματα προγραμματισμού. Δομημένος προγραμματισμός. Λογικός προγραμματισμός. Αντικειμενοστραφής προγραμματισμός.

10. Αρχιτεκτονική λογισμικού. Διαχείρηση γεγονότων. Αρχιτεκτονική πελάτη/διακομιστή. Υπηρεσίες. Αρχιτεκτονική τριών επιπέδων. Σχεδιασμός προγράμματος. Εννοιολογική σχεδίαση. Λογικός σχεδιασμός. Λεπτομερές σχέδιο.

1. Προσεγγίσεις Novikov στην ανάπτυξη λογισμικού» http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Ακραίος προγραμματισμός. – Αγία Πετρούπολη: Peter, 2002.

3. Τεχνολογία ανάπτυξης λογισμικού. - Αγία Πετρούπολη. : Peter, 2004.

4. Μπρουκς Τζούνιορ. σχεδιάζονται και δημιουργούνται συστήματα λογισμικού. Μ.: Nauka, 1975; νέα έκδοση της μετάφρασης: The Mythical Man-Month. SPb.: SYMBOL+, 1999.

5. Αλγόριθμοι + δομές δεδομένων = προγράμματα. Μ., Μιρ, 1978.

6. Συστηματικός προγραμματισμός. Εισαγωγή. Μ.: Μιρ, 1977.

7. Δομημένος προγραμματισμός. Μ.: Μιρ, 1975.

8. Πειθαρχία προγραμματισμού. Μ.: Μιρ, 1978.

9. Τεχνολογίες ανάπτυξης λογισμικού. – Αγία Πετρούπολη: Peter, 2002.

10. Προγραμματισμός Terekhov. Μ.: BINOM, 2006.

11. Rambo J. Ενοποιημένη διαδικασία ανάπτυξης λογισμικού. Αγία Πετρούπολη: Peter, 2002.

Οικονομική θεωρία για μάνατζερ

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

Μάθημα οικονομικής θεωρίας: εγχειρίδιο για τα πανεπιστήμια / Εκδ. . –Kirov: “ASA”, 2004. Kolemaev - mathematical modeling. Μοντελοποίηση μακροοικονομικών διαδικασιών και συστημάτων: σχολικό βιβλίο. M.: UNITY-DANA, 2005. Bazhin cybernetics. Kharkov: Consul, 2004. Εργαστήριο Leushin σχετικά με τις μεθόδους μαθηματικής μοντελοποίησης: εγχειρίδιο. Πολιτεία Νίζνι Νόβγκοροντ τεχν. πανεπιστήμιο - N. Novorod, 2007. Πολιτικοί για τα οικονομικά: Διαλέξεις βραβευθέντων με Νόμπελ στα οικονομικά. Μ.: Σύγχρονη οικονομία και δίκαιο, 2005. Cheremnykh. Προχωρημένο επίπεδο: Textbook.-M.:INFRA-M, 2008. Εξέλιξη θεσμών μίνι-οικονομίας. Ινστιτούτο Οικονομικών Επιστημών, Παράρτημα Ural της Ρωσικής Ακαδημίας Επιστημών, - M.: Nauka, 2007.

Τεχνολογίες για την ανάπτυξη και τη λήψη αποφάσεων διαχείρισης [N]

Η λήψη αποφάσεων ως βάση της δραστηριότητας ενός μάνατζερ. Εισαγωγή στη θεωρία αποφάσεων. Βασικές έννοιες της θεωρίας αποφάσεων. Μοντέλα διοίκησης επιχειρήσεων και ο αντίκτυπός τους στη λήψη αποφάσεων. Διάφοροι τρόποιταξινόμηση των λύσεων. Ταξινομήσεις: ανάλογα με τον βαθμό τυπικότητας, σύμφωνα με το βαθμό ρουτίνας, ανάλογα με τη συχνότητα, ανάλογα με το επείγον, ανάλογα με το βαθμό επίτευξης των στόχων, σύμφωνα με τη μέθοδο επιλογής εναλλακτικής λύσης. Βασικές μέθοδοι λήψης αποφάσεων. Εκούσιες μέθοδοι λήψης αποφάσεων. Στόχοι λήψης αποφάσεων. Χρόνος αναζήτησης λύσεων. Βασικά λάθη Μαθηματικές μέθοδοι λήψης αποφάσεων. Μαθηματικές πτυχές της θεωρίας αποφάσεων. Επιχειρησιακή έρευνα. Μαθηματική προσέγγιση στη λήψη αποφάσεων. Δέντρο απόφασης. Μοντέλα ανάπτυξης και λήψης αποφάσεων. Θεωρία παιγνίων. Μαθηματικές μέθοδοι λήψης αποφάσεων. Μαθηματικές πτυχές της θεωρίας αποφάσεων. Μοντέλα θεωρίας ουρών. Μοντέλα διαχείρισης αποθεμάτων. Μοντέλο γραμμικού προγραμματισμού. Εργασίες μεταφοράς. Μοντελοποίηση προσομοίωσης. Ανάλυση δικτύου. Οικονομική ανάλυση. Περιορισμοί ορθολογικών μοντέλων. Χαρακτηριστικά ανάπτυξης και λήψης αποφάσεων σε μια ομάδα. Μια μέθοδος για τον προσδιορισμό της συνοχής της ομάδας με βάση τον βαθμό συνδεσιμότητας των συνόλων. Μέθοδοι λήψης συλλογικών αποφάσεων. Συναινετική μέθοδος. Μέθοδοι ψηφοφορίας. Δημιουργικές μέθοδοι λήψης αποφάσεων. Καταιγισμός ιδεών. Διάσκεψη ιδεών. Συμβούλιο του πλοίου. Η μέθοδος «Thinking Hats» του De Bono. Θεωρία της εφευρετικής επίλυσης προβλημάτων (TRIZ). Η τέλεια λύση στο τέλος. Παραδείγματα προβλημάτων και οι λύσεις τους χρησιμοποιώντας το TRIZ. Εφαρμογή των μεθόδων TRIZ κατά τη λήψη μοναδικών και δημιουργικών αποφάσεων. Μέθοδοι για την ανάπτυξη ιδεών λύσης και την προσαρμογή τους στην κατάσταση. Μοντέλο δέντρου στόχου. Στρατηγική συντονισμού συμφερόντων. Διαμόρφωση αποφάσεων συντονισμού συμφερόντων. Μέθοδοι προσδιορισμού των συμφερόντων των αντισυμβαλλομένων. Συστήματα υποστήριξης αποφάσεων (expert systems). Ιστορία της δημιουργίας συστημάτων λήψης αποφάσεων. Ταξινόμηση συστημάτων λήψης αποφάσεων. Τυπική δομήειδικό σύστημα. Μέθοδοι παρουσίασης της γνώσης. Μέθοδοι λογικών συμπερασμάτων. Εφαρμογή έμπειρων συστημάτων στην πράξη.

Ι. Θεωρία Λήψης Αποφάσεων: Σχολικό βιβλίο. - Μ.: Εξεταστική, 2006. - 573 σελ. I. Λήψη αποφάσεων. Θεωρία και μέθοδοι για την ανάπτυξη διοικητικών αποφάσεων. Φροντιστήριο. - M.: MarT, 2005. - 496 pp. Ανάπτυξη διαχειριστικών αποφάσεων - M.: Publishing House "Delo", 2004 - 392 pp. Ζ. Εκτιμήσεις εμπειρογνωμόνων και λήψη αποφάσεων - M.: Patent, 1996. - 271 p. Taha // Introduction to Operations Research = Operations Research: An Introduction. - 7η έκδ. - M.: “Williams”, 2007. - Σ. 549-594. Γ. Θείλ. Οικονομικές προβλέψεις και λήψη αποφάσεων. Μ.: “Πρόοδος” 1970. K. D. Lewis. Μέθοδοι πρόβλεψης οικονομικών δεικτών. M.: “Finance and Statistics” 1986. G. S. Kildishev, A. A. Frenkel. Ανάλυση χρονοσειρών και πρόβλεψη. M.: “Statistics” 1973. O. Kim, C. W. Muller, U. R. Klekka και άλλοι Παράγοντες, διακρίσεις και ανάλυση συστάδων. Μ.: «Οικονομικά και Στατιστική» 1989. Αποτελεσματικός διευθυντής. Βιβλίο 3. Λήψη αποφάσεων. – MIM LINK, 1999 Turevsky και διαχείριση μιας επιχείρησης μηχανοκίνητων μεταφορών. - M.: Higher School, 2005. , ; επεξεργάστηκε από . Ανάλυση συστήματος στη διαχείριση: φροντιστήριο. – M.: Finance and Statistics, 2006. , Tinkov: σχολικό βιβλίο. – Μ.: KNORUS, 2006.

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

Με ποιες αρχές διακρίνονται οι επιχειρηματικές διαδικασίες; Ποιο είναι το πρόβλημα μιας ολιστικής περιγραφής των επιχειρηματικών διαδικασιών; Τι είναι ένα σύστημα, τι ιδιότητες έχει; Ο ρόλος της ανάλυσης συστημάτων στη μοντελοποίηση επιχειρηματικών διαδικασιών; Η διαδικασία ως αντικείμενο ελέγχου. Περιβάλλον διαδικασίας. Βασικά στοιχεία μιας επιχειρηματικής διαδικασίας. Πλεονεκτήματα και μειονεκτήματα της λειτουργικής διαχείρισης και διαχείρισης διαδικασιών. Κύκλος διαχείρισης PDCA. Στάδια του κύκλου διαχείρισης της διαδικασίας. Κύκλος PDCA και εφαρμογή των απαιτήσεων ISO 9001:2008. Μεθοδολογία SADT (Structured Analysis and Design Technique - μέθοδος δομικής ανάλυσης και σχεδίασης). Ουσία. Βασικές διατάξεις. Πώς αναπαρίσταται το λειτουργικό μοντέλο δραστηριότητας στη μεθοδολογία IDEF0; Τι σημαίνουν οι δραστηριότητες στα διαγράμματα λειτουργικών μοντέλων, πώς εμφανίζονται σύμφωνα με τη μεθοδολογία IDEF0; Σε τι χρησιμεύουν τα βέλη στα διαγράμματα λειτουργικών μοντέλων, ποιοι είναι οι τύποι και οι τύποι τους; Μεθοδολογία DFD. Ουσία. Βασικά στοιχεία των διαγραμμάτων DFD. Ποια είναι τα χαρακτηριστικά των διαγραμμάτων DFD και τι περιγράφεται σε αυτά; Ποια είναι τα χαρακτηριστικά των αντικειμένων του διαγράμματος DFD; Τι σημαίνουν τα βέλη σε ένα διάγραμμα DFD; Μεθοδολογία IDEF3. Ουσία. Εργαλεία τεκμηρίωσης και μοντελοποίησης. Ποια είναι τα χαρακτηριστικά των διαγραμμάτων IDEF3 και τι περιγράφεται σε αυτά; Ποια είναι τα χαρακτηριστικά των αντικειμένων του διαγράμματος IDEF3; Και ο σουτέρ; Ταξινόμηση διεργασιών. Τυπικές επιχειρηματικές διαδικασίες. Ο ανασχεδιασμός και η τεχνολογία του. Πότε είναι σκόπιμο να χρησιμοποιείτε το reengineering κατά τη διαχείριση μιας εταιρείας; Διαδικασίες παρακολούθησης και μέτρησης. Δείκτες οργανωτικών διαδικασιών. Αριθμητικές και βαθμολογικές αξιολογήσεις διεργασιών.

"Modeling business processes with AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Creating Information systems with AllFusion Modeling Suite" ed. "Dialog-MEPhI" 2003 "Practice of functional modeling with AllFusion Process Modeler 4.1. (BPwin) Πού; Γιατί; Πώς;" εκδ. "Dialogue-MEPhI" 2004 Dubeykovsky modeling with AllFusion Process Modeler (BPwin). εκδ. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Methodology of structural analysis and design SADT" 1993 classic work on the SADT methodology. Cheremnykh ανάλυση συστημάτων: IDEF-τεχνολογίες, Μοντελοποίηση και ανάλυση συστημάτων. Τεχνολογίες IDEF. ΕΡΓΑΣΤΗΡΙ. M.: Finance and Statistics, 2001. “Structural business models: DFD technology” http://www. /Level4.asp? ItemId=5810 «Θεωρία και πρακτική αναδιοργάνωσης επιχειρησιακών διαδικασιών» 2003/ P50.1.. Μεθοδολογία λειτουργικής μοντελοποίησης. Μ.: Gosstandart της Ρωσίας, 2000. http://www. IDEF0, IDEF3, DFD http://www. Μοντελοποίηση επιχειρηματικών διαδικασιών χρησιμοποιώντας BPwin http://www. /department/se/devis/7/ IDEF0 στη μοντελοποίηση διαδικασιών διαχείρισης επιχειρήσεων http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Αξιολόγηση της αποτελεσματικότητας των προϊόντων λογισμικού

1. Αρχιτεκτονική πληροφορικής

2. Τομείς διαδικασιών διαχείρισης.

3. Λίστα διαδικασιών στον τομέα Σχεδιασμού και Οργάνωσης

4. Λίστα διαδικασιών τομέα Απόκτηση και Υλοποίηση

5. Λίστα διαδικασιών στον τομέα Λειτουργίας και Συντήρησης

6. Κατάλογος διαδικασιών στον τομέα της παρακολούθησης και της αξιολόγησης

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

9. KPI και KGI η σχέση και ο σκοπός τους

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

Cobit 4.1 ρωσική έκδοση.

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

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

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

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

5. Συγκρίνετε τις κύριες διατάξεις νομικής προστασίας της Βάσης Δεδομένων ως αντικείμενο πνευματικής ιδιοκτησίας και ως αντικείμενο συγγενικών δικαιωμάτων.

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

7. Επεκτείνετε το περιεχόμενο των κριτηρίων κατοχύρωσης με δίπλωμα ευρεσιτεχνίας για μια εφεύρεση: καινοτομία. εφευρετικό βήμα? βιομηχανική εφαρμογή.

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

9. Καθορίστε την «τεχνογνωσία» και απαριθμήστε τις συνθήκες κατά τη δημιουργία των οποίων προκύπτει και πραγματοποιείται νομική προστασία των μυστικών παραγωγής.

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

1. Δικαιώματα πνευματικής ιδιοκτησίας σε Ρωσική Ομοσπονδία, σχολικό βιβλίο // M, Prospekt, 2007

2., Δίκαιο Πνευματικής Ιδιοκτησίας, σχολικό βιβλίο // M, RIOR, 2009.

Διαχείριση έργων και ανάπτυξης λογισμικού [I]

Τι είναι μεθοδολογία, γιατί χρειάζεται. Γενική δομή της μεθοδολογίας, κύρια στοιχεία της μεθοδολογίας. Αρχές για το σχεδιασμό της δικής σας μεθοδολογίας. Παραδείγματα διαφόρων τεχνουργημάτων, ρόλων, ικανοτήτων, οριακών συνθηκών. Η δομή της μεθοδολογίας σύμφωνα με τον Cowburn, μετρήσεις μεθοδολογίας. Τα κριτήρια σχεδίασης του Cowburn. Κριτήρια επιλογής μεθοδολογίας, μήτρα Cowburn. Κύκλος ζωής του έργου. Καταρράκτες και επαναληπτικά μοντέλα κύκλου ζωής. Όρια εφαρμογής για καταρράκτες και επαναληπτικά μοντέλα. Το RUP ως παράδειγμα επαναληπτικής μεθοδολογίας. Βασικές έννοιες του RUP, όρια εφαρμογής. Ο ρόλος των ανθρώπων στην ανάπτυξη λογισμικού. Agile μεθοδολογίες, βασικές αρχές agile μεθοδολογιών. Ο λόγος για την εμφάνιση ευέλικτων μεθοδολογιών. Το Scrum ως παράδειγμα ευέλικτης μεθοδολογίας. Ρόλοι, αντικείμενα, δραστηριότητες στο Scrum. Όρια εφαρμογής Scrum. Extreme Programming (XP) Ιδέες, αξίες, βασικές πρακτικές, όρια εφαρμογής. Ομοιότητες και διαφορές μεταξύ Scrum και XP. Συλλογή και διαχείριση απαιτήσεων. Βασικές πρακτικές, όροι, αρχές. Προσεγγίσεις τεκμηρίωσης έργου και προϊόντος, κύριοι τύποι εγγράφων. Παραδείγματα πρακτικών διαχείρισης απαιτήσεων από τις μεθοδολογίες που συζητήθηκαν στο μάθημα. Σχεδιασμός ανάπτυξης λογισμικού. Τύποι σχεδίων, διαχείριση κινδύνων, δημοφιλείς κίνδυνοι. Παραδείγματα πρακτικών σχεδιασμού ανάπτυξης από τις μεθοδολογίες που συζητήθηκαν στο μάθημα. Δοκιμές στην ανάπτυξη λογισμικού. Η έννοια της συναρμολόγησης (κατασκευής) ενός προϊόντος λογισμικού. Βασικές μέθοδοι δοκιμής, όροι. Παραδείγματα πρακτικών δοκιμών από τις μεθοδολογίες που συζητήθηκαν στο μάθημα. Η έννοια της συναρμολόγησης (κατασκευή), μέθοδοι αποθήκευσης κώδικα, εργαλεία. Δύο αρχές για την οργάνωση της εργασίας με ένα σύστημα ελέγχου έκδοσης. Χαρακτηριστικά της διαδικασίας έκδοσης/εμφάνισης προϊόντος για διαφορετικές κατηγορίες προϊόντων, παραδείγματα πρακτικών. Σύγχρονες έννοιες αρχιτεκτονικής λογισμικού, αρχιτεκτονικές πολλαπλών επιπέδων, κριτήρια αρχιτεκτονικής. Κατάλογος απαραίτητων αποφάσεων κατά το σχεδιασμό λογισμικού, προσεγγίσεις για την επιλογή συστήματος αποθήκευσης δεδομένων.

Kent Beck - Extreme Programming Frederick Brooks - The Mythical Man-Month ή πώς δημιουργούνται τα συστήματα λογισμικού. Tom DeMarco - Προθεσμία. Ένα μυθιστόρημα για τη διαχείριση έργων. Tom De Marco, Timothy Lister - Waltzing with the Bears. Tom de Marco, Timothy Lister - Human factor_ επιτυχημένα έργα και ομάδες. Alistair Cowburn - Κάθε έργο έχει τη δική του μεθοδολογία. Alistair Cowburn - Οι άνθρωποι ως μη γραμμικοί και τα πιο σημαντικά στοιχεία στη δημιουργία λογισμικού. Andriy Orlov - Σημειώσεις μηχανικού αυτοματισμού. Επαγγελματική εξομολόγηση. Philipp Kratchen - Εισαγωγή στην Ορθολογική Ενοποιημένη Διαδικασία. Henrik Kniberg - Scrum και XP: σημειώσεις από την πρώτη γραμμή. Παρουσιάσεις διαλέξεων για το μάθημα