Principii generale și abordări ale dezvoltării software. Modele de dezvoltare software Waterfall Waterfall Spiral Extreme Programming UI Prototyping Incremental. Abordarea de sistem a dezvoltării software. Aspecte temporale și „spațiale” ale abordării sistemului

Modele de dezvoltare software Cascada Cascada Spirală Programare extremă Interfață de utilizare Prototipare Testare model W incrementală Proces unificat de dezvoltare software(USDP) Metodologia MSF

Model cascadă Analiza cerințelor Compilarea specificației produsului Proiectare Compilarea arhitecturii produsului Implementare Dezvoltarea codului sursă Integrarea părților separate ale codului sursă Testare și depanare

Programare extremă Analiza cerințelor inițiale Proiectare Integrare Implementare Testare Noi cerințe Examinare/Aprobare/Modificare Planul de dezvoltare Lansarea produsului

UI Prototyping Lansarea produsului Dezvoltarea de software cu schimbări în minte Clarificarea cerințelor și specificațiilor Modificarea prototipului și perfecționarea unor funcționalități Funcționalitate de bază Prototip de interfață Specificație preliminară

Dezvoltare incrementală Iterația 1 Iterația 2 …. Analiza cerințelor Proiectare Implementare Componentă Testare Integrare Testarea întregii iterații N

Procesul de dezvoltare software unificat (USDP) Ø Model de caz de utilizare, descrie cazurile în care va fi utilizată aplicația. Ø Modelul analitic descrie clasele de baza pentru aplicatie. Ø Modelul de proiectare descrie conexiunile și relațiile dintre clase și obiectele selectate Ø Modelul de implementare descrie distribuția software-ului între computere. Ø Modelul de implementare descrie organizarea internă a codului programului. Ø Modelul de testare constă din componente de testare, proceduri de testare și diferite cazuri de testare

Procesul unificat de dezvoltare a software-ului (USDP) Adunarea cerințelor Iter 1…. Iter N Proiectarea Iter 1…. Iter N Implementarea Iter 1…. Iter N Proiectarea Iter 1…. Iter N Testare Iter 1…. Iter N

Componente tipice ale arhitecturii produs softwareși cerințe tipice de software Ø Ø Ø Ø Organizarea programelor Clasele principale de sistem Organizarea datelor Reguli de afaceri Interfață cu utilizatorul Gestionarea resurselor Securitate Performanță Scalabilitate Interacțiune cu alte sisteme (integrare) Internaționalizare, localizare Intrare-ieșire a datelor Gestionarea erorilor

Componente tipice ale arhitecturii produsului software și cerințe tipice software Toleranța la erori este un set de proprietăți ale sistemului care sporesc fiabilitatea sistemului prin detectarea erorilor, recuperarea și izolarea consecințelor nefaste pentru sistem. La proiectarea oricărui sistem real pentru a asigura toleranța la erori, este necesar să se anticipeze toate situațiile posibile care pot duce la o defecțiune a sistemului și să se dezvolte mecanisme de gestionare a defecțiunilor. Fiabilitatea este capacitatea unui sistem de a rezista la diverse defecțiuni și defecțiuni. Eșecul este tranziția sistemului ca urmare a unei erori la o stare complet inoperabilă. O defecțiune este o eroare în funcționarea sistemului care nu duce la defecțiunea sistemului. Cu cât sunt mai puține defecțiuni și defecțiuni pentru o anumită perioadă de timp, cu atât sistemul este considerat mai fiabil.

Componente tipice ale arhitecturii unui produs software și cerințe tipice pentru software Curba de fiabilitate N t 1 t Cu cât mai departe, cu atât va fi mai greu să găsiți o eroare. Cu cât sistemul este mai complex, cu atât este mai mare probabilitatea defecțiunilor și defecțiunilor.

Componente tipice ale arhitecturii produsului software și cerințe tipice software Ø Posibilități de implementare a arhitecturii dezvoltate. Ø Functionalitate excesiva. Ø Luarea deciziei de a cumpăra componente software gata făcute. Ø Schimbarea strategiei.

O listă de întrebări care vă permite să trageți o concluzie despre calitatea arhitecturii: Ø Este clar descrisă organizarea generală a programului; Ø Ø Ø Dacă specificația include o privire de ansamblu asupra arhitecturii și a rațiunii sale. Sunt principalele componente ale programului definite adecvat, domeniile lor de responsabilitate și interacțiunea cu alte componente. Dacă toate funcțiile specificate în specificația cerințelor sunt implementate de un număr rezonabil de componente ale sistemului. Sunt cele mai importante clase descrise și justificate. Dacă se oferă o descriere a organizării bazei de date. Sunt definite toate regulile de afaceri? Este descris impactul lor asupra sistemului?

O listă de întrebări care vă permite să trageți o concluzie despre calitatea arhitecturii: Ø Este descrisă strategia de proiectare a interfeței cu utilizatorul. Ø Este gata interfața cu utilizatorul modular, astfel încât modificările acestuia să nu afecteze restul sistemului. ØDacă este dată descrierea strategiei de intrare/ieșire a datelor. Ø Dacă a fost efectuată analiza performanței sistemului care va fi implementat folosind această arhitectură. Ø Dacă a fost efectuată analiza de fiabilitate a sistemului proiectat. Ø Dacă a fost efectuată analiza problemelor de scalabilitate și extensibilitate a sistemului.

Refactorizarea software Refactorizarea implică adaptarea software-ului la un nou hardwareși la noi sisteme de operare, noi instrumente de dezvoltare, noi cerințe și arhitectură și funcționalitate software. Aceasta este o modificare a structurii interne a software-ului fără modificarea comportamentului său extern, menită să asigure modificarea software-ului. Motive rezonabile pentru refactorizare: Codul este repetitiv; implementarea metodei este prea mare; prea multă imbricare a buclelor sau bucla în sine este foarte mare; clasa are conectivitate slabă (proprietățile și metodele clasei ar trebui să descrie doar 1 obiect); o interfață de clasă nu formează o abstractizare consistentă; metoda ia prea mulți parametri. Ar trebui să încercați să mențineți numărul de parametri la un minim rezonabil; părțile individuale ale clasei se schimbă independent de celelalte părți ale clasei;

Refactorizarea software-ului la schimbarea programului necesită o schimbare paralelă a mai multor clase. Dacă apare o astfel de situație, este necesară reorganizarea cursurilor pentru a minimiza locurile viitoare posibile modificări; trebuie să schimbe mai multe ierarhii de moștenire în paralel; trebuie să schimbați mai multe blocuri de caz. Este necesar să se modifice programul în așa fel încât să se facă implementarea blocului de caz și să-l numească de numărul necesar de ori în program; membrii de date înrudiți utilizați împreună nu sunt organizați în clase. Dacă utilizați în mod repetat același set de elemente de date, atunci este recomandabil să luați în considerare combinarea acestor date și plasarea operațiunilor efectuate asupra lor într-o clasă separată;

O metodă de refactorizare software utilizează mai multe elemente dintr-o altă clasă decât ale sale. Aceasta înseamnă că metoda trebuie mutată într-o altă clasă și apelată din cea veche; tipul de date elementare este supraîncărcat. Pentru a descrie esența lumii reale, este mai bine să folosiți o clasă decât să supraîncărcați orice tip de date existent; clasa are o funcționalitate prea limitată. Este mai bine să scăpați de această clasă prin transferul funcționalității acesteia într-o altă clasă; Datele „rătăcite” sunt transmise de-a lungul lanțului de metode. Datele care sunt transmise unei metode doar pentru a fi transmise unei alte metode se numesc date rătăcite. Când apar astfel de situații, încercați să schimbați arhitectura claselor și metodele pentru a scăpa de ele.

Refactorizarea obiectului media nu face nimic. Dacă rolul unei clase este de a redirecționa apelurile de metodă către alte clase, atunci cel mai bine este să eliminați acel proxy și să faceți apeluri către alte clase direct; o clasă știe prea multe despre o altă clasă. În această situație, este necesar să se facă încapsularea mai strictă pentru a se asigura că moștenitorul are cunoștințe minime despre părintele său; metoda are nume gresit; membrii datelor sunt publici. Acest lucru estompează linia dintre interfață și implementare, întrerupe inevitabil încapsularea și limitează flexibilitatea programului; postați comentarii în cod sursa;

O subclasă de refactorizare software utilizează doar o mică parte din metodele strămoșilor săi. Această situație apare atunci când o nouă clasă este creată doar pentru a moșteni câteva metode din clasa de bază și nu pentru a descrie vreo entitate nouă. Pentru a evita acest lucru, este necesară transformarea clasei de bază în așa fel încât să dea acces la noua clasă doar metodelor de care are nevoie; codul conține variabile globale. Numai variabilele care sunt utilizate efectiv de întregul program ar trebui să fie globale. Toate celelalte variabile trebuie să fie fie locale, fie trebuie să devină proprietăți ale unui obiect; programul conține cod care poate fi necesar într-o zi. Când se dezvoltă un sistem, este recomandabil să se prevadă locuri unde codul sursă poate fi adăugat în viitor.

Adnotare: O abordare flexibilă a dezvoltării software, sunt luate în considerare principiile de bază ale dezvoltării flexibile. Este furnizată o listă de tehnici care, într-o anumită măsură, corespund principiilor dezvoltării software flexibile. Sunt analizate valorile și principiile cheie ale dezvoltării agile.

Puteți descărca prezentarea pentru această prelegere.

Scopul prelegerii:

Obțineți o înțelegere a scopului și a principiilor de bază ale dezvoltării agile de software.

Introducere

Metodologie de dezvoltare software agilă concentrat pe utilizarea unei abordări iterative, în care software se creează treptat, în pași mici, inclusiv implementarea unui anumit set de cerințe. Se presupune că cerințele se pot schimba. Echipele care utilizează metodologii agile sunt formate din dezvoltatori versatili care îndeplinesc diverse sarcini în procesul de creare a unui produs software.

Atunci când se utilizează metodologii agile, minimizarea riscului se realizează prin reducerea dezvoltării la o serie de cicluri scurte numite iterații, cu durata de 2-3 saptamani. O iterație este un set de sarcini programate pentru a fi finalizate într-o anumită perioadă de timp. În fiecare iterație, este creată o versiune funcțională a sistemului software, în care cea mai mare prioritate (pentru această iterație) cerintele clientului. Fiecare iterație îndeplinește toate sarcinile necesare pentru a crea software de lucru: planificare, analiza cerințelor, proiectare, codificare, testare și documentație. În timp ce o singură iterație nu este în general suficientă pentru a elibera versiune noua produs, se înțelege că curentul software gata de lansare la sfârșitul fiecărei iterații. La sfârșitul fiecărei iterații, echipa re-prioritizează cerințele pentru produsul software, eventual făcând ajustări la dezvoltarea sistemului.

Principiile și semnificația dezvoltării agile

Pentru metodologia de dezvoltare agilă sunt declarate postulate cheie care permit echipelor să atingă performanțe ridicate:

oamenii și interacțiunea lor;
livrare de software de lucru;
cooperarea cu clientul;
răspuns la schimbare.

Oameni și interacțiune. Oamenii sunt cea mai importantă parte a succesului. Membrii individuali ai echipei și o bună comunicare sunt esențiale pentru echipele performante. Pentru a facilita comunicarea, practicile agile implică discuții frecvente despre rezultatele muncii și modificări ale deciziilor. Discuțiile pot avea loc zilnic timp de câteva minute și la sfârșitul fiecărei iterații cu o analiză a rezultatelor lucrării și o retrospectivă. Pentru o comunicare eficientă în timpul întâlnirilor, membrii echipei trebuie să respecte următoarele reguli cheie comportamente:

respect pentru opinia fiecărui membru al echipei;
fii sincer în orice comunicare;
transparența tuturor datelor, acțiunilor și deciziilor;
încredere că fiecare participant va sprijini echipa;
angajamentul față de echipă și obiectivele acesteia.

Pe lângă o echipă eficientă și o bună comunicare, sunt necesare instrumente software perfecte pentru a crea echipe de înaltă performanță în metodologii agile.

Software-ul de lucru este mai important decât documentația cuprinzătoare. Toate metodologiile agile evidențiază necesitatea de a livra clienților bucăți mici de software de lucru la intervale prestabilite. Software, de regulă, trebuie să treacă nivelul de testare unitară, testare la nivel de sistem. Cantitatea de documente ar trebui să fie redusă la minimum. În timpul procesului de proiectare, echipa ar trebui să țină la zi un scurt document care să conțină justificarea deciziei și o descriere a structurii.

Cooperarea cu clientul este mai importantă decât acordurile formale din contract. Pentru ca proiectul să fie finalizat cu succes, este necesară o comunicare regulată și frecventă cu clientul. Clientul trebuie să participe în mod regulat la discuția cu privire la deciziile luate cu privire la software, să-și exprime dorințele și comentariile. Implicarea clientului în procesul de dezvoltare software este necesară pentru a crea un produs de calitate.

Răspunsul rapid la schimbare este mai important decât respectarea unui plan. Capacitatea de a răspunde la schimbare determină în mare măsură succesul unui proiect software. În procesul de creare a unui produs software, acestea se schimbă adesea cerintele clientului. Clienții de multe ori nu știu exact ce vor până când nu văd că funcționează. software. Se caută metodologii agile părere de la clienți în procesul de creare a unui produs software. Recepția la schimbare este esențială pentru a crea un produs care oferă satisfacție clienților și valoare de afaceri.

Principiile dezvoltării agile sunt susținute de 12 principii. Metodologiile specifice agile definesc procese și reguli care se conformează mai mult sau mai puțin acestor principii. Metodologiile flexibile pentru crearea de produse software se bazează pe următoarele principii:

Prioritatea cea mai mare este satisfacerea dorințelor clientului prin livrarea de software util într-un timp scurt, urmată de actualizări continue. Practicile agile includ lansarea inițială rapidă și actualizări frecvente. Scopul echipei este să livreze o versiune funcțională în câteva săptămâni de la începerea proiectului. Mai departe sisteme software cu funcționalitatea care se extinde treptat, ar trebui să fie livrat la fiecare câteva săptămâni. Clientul poate începe operarea comercială a sistemului dacă îl consideră suficient de funcțional. De asemenea, clientul poate pur și simplu să se familiarizeze cu versiunea actuală a software-ului, să ofere feedback cu comentarii.
Nu ignora cerințele în schimbare, chiar și în curs de dezvoltare. Procesele flexibile permit luarea în considerare a modificărilor pentru a asigura avantajul competitiv al clientului. Echipele care folosesc metodologii agile se străduiesc să facă structura programului de înaltă calitate, cu impact minim al schimbărilor asupra sistemului în ansamblu.
Furnizați noi versiuni de lucru ale software-ului în mod frecvent, la intervale de o săptămână până la două luni, cu preferință pentru termene limită mai scurte. În același timp, scopul este de a livra un program care să răspundă nevoilor utilizatorului, cu un minim de documentație însoțitoare.
Clienții și dezvoltatorii trebuie să lucreze împreună pe tot parcursul proiectului. Se crede că pentru un proiect de succes, clienții, dezvoltatorii și toate părțile interesate trebuie să comunice des și în multe moduri pentru a îmbunătăți în mod intenționat produsul software.
Proiectele ar trebui implementate de oameni motivați. Oferiți echipei de proiect un mediu de lucru sănătos, oferiți sprijinul de care are nevoie și aveți încredere că membrii echipei vor duce treaba la bun sfârșit.
Cea mai eficientă și productivă metodă de a transmite informații echipei de dezvoltare și de a face schimb de opinii în cadrul acesteia este o conversație față în față. În proiectele agile, principalul mod de comunicare este interacțiunea umană simplă. Documentele scrise sunt create și actualizate progresiv pe măsură ce software-ul este dezvoltat și numai atunci când este necesar.
Un program de lucru este principalul indicator al progresului proiectului. Abordarea unui proiect agil până la finalizare este judecată în funcție de cantitatea disponibilă acest moment programul îndeplinește cerințele clientului.
Procesele agile încurajează dezvoltarea pe termen lung. Clienții, dezvoltatorii și utilizatorii trebuie să poată menține un ritm constant la nesfârșit.
O concentrare neobosită pe excelența în inginerie și designul de calitate îmbunătățește rentabilitatea tehnologiilor agile. Membrii echipei Agile se străduiesc să creeze cod de calitate prin refactorizare regulată.
Simplitatea este arta de a obține mai mult făcând mai puțin. Membrii echipei decid sarcini curente cât mai simplu și de înaltă calitate posibil. Dacă există o problemă în viitor, atunci este posibil să faceți modificări la codul de calitate fără costuri mari.
Cel mai cele mai bune arhitecturi, cerințele și proiectele sunt emise de echipe auto-organizate. În echipele flexibile, sarcinile sunt atribuite nu membrilor individuali, ci echipei în ansamblu. Echipa însăși decide cum să implementeze cel mai bine cerințele clientului. Membrii echipei lucrează în colaborare la toate aspectele proiectului. Fiecare participant are voie să contribuie la cauza comună. Niciun membru al echipei nu este singurul responsabil pentru arhitectură, cerințe sau teste.
Echipa ar trebui să se gândească în mod regulat la cum să devină și mai eficientă, apoi să își ajusteze și să își ajusteze comportamentul în consecință. O echipă agilă își ajustează în mod constant organizarea, regulile, acordurile și relațiile.

Principiile de mai sus, într-o anumită măsură, corespund unui număr de metodologii de dezvoltare software:

Modelare agilă	un set de concepte, principii și tehnici (practici) care vă permit să efectuați rapid și ușor modelarea și documentarea în proiecte de dezvoltare software;
Proces unificat agil (AUP)	o versiune simplificată a IBM RationalUnifiedProcess(RUP), care descrie o aproximare (model) simplă și ușor de înțeles pentru construirea de software pentru aplicații de afaceri;
Deschide	este o metodă iterativă-incrementală de dezvoltare software. Poziționat ca o opțiune RUP ușoară și flexibilă;
AgileDataMethod	un grup de metode iterative de dezvoltare software în care cerințele și soluțiile sunt realizate prin colaborarea diferitelor echipe interfuncționale;
DSDM	o metodologie de dezvoltare a sistemelor dinamice bazată pe conceptul de dezvoltare rapidă a aplicațiilor (RapidApplicationDevelopment, RAD). Reprezintă o abordare iterativă și incrementală care pune accent pe implicarea continuă a utilizatorului/consumatorului în proces;
Programare extremă (XP)	programare extremă;
Dezvoltare de software adaptiv (ADD)	dezvoltare de software adaptiv;
Dezvoltare bazată pe caracteristici (FDD)	dezvoltare axată pe adăugarea treptată a funcționalității;
Devin real	o abordare iterativă fără specificații funcționale utilizate pentru aplicațiile web;
MSFfogAgileSoftwareDevelopment	Metodologie de dezvoltare software agilă de la Microsoft;
Scrum	stabilește reguli de gestionare a procesului de dezvoltare și vă permite să utilizați practicile de codificare existente prin ajustarea cerințelor sau făcând modificări tactice [

1. Cascada (cascada engleză) - model de dezvoltare standard

Model de dezvoltare în cascadă - un model în care toate etapele de dezvoltare sunt efectuate secvenţial - următoarea etapă începe după ce cea anterioară este finalizată.

Acest model include următorii pași în procesul de dezvoltare software:

În primul rând, este determinat specificatii tehnice programul viitor, ca urmare, o listă de cerințe software este aprobată. Urmează trecerea la proiectare, în timpul căreia se creează documentația care descrie pentru programatori un plan și o modalitate de implementare a cerințelor.

După ce proiectarea este finalizată, programatorii implementează (construiesc) proiectul. În etapa de implementare, toate componentele proiectului sunt integrate. Numai după finalizarea completă a acestor etape este testarea și depanarea produsului finit. Mai mult, produsul software poate fi implementat și, după implementare, poate oferi suport - introduceți noi funcționalități și eliminați erorile.

Principalele avantaje ale dezvoltării cascadei:

2. Metodologia de dezvoltare software agilă

Un set de metodologii de dezvoltare software care implică colaborarea între reprezentanții clienților și dezvoltatori. Metoda de dezvoltare agilă se bazează pe o abordare iterativă, formarea dinamică a cerințelor și implementarea lor în etape scurte.

Rezultatul fiecărei astfel de etape, inclusiv un ciclu de iterații, este un proiect software în miniatură,

Există mai multe metode de dezvoltare agile, cele mai cunoscute sunt Scrum, Extreme Programming, DSDM.

Principalele avantaje ale dezvoltării agile:

		minimizarea riscului; creșterea treptată a funcționalității produsului software; o cantitate mică de documentație scrisă; lansa versiunea de bază programe cât mai curând posibil.

Există și dezavantaje:
		incapacitatea de a determina cu exactitate bugetul proiectului; imposibilitatea determinării momentului exact de pregătire a proiectului; nu este potrivit pentru organizațiile de stat și bugetare; necesită motivare din partea reprezentanților responsabili ai clientului.

Manifestul dezvoltării software agile

Descoperim în mod constant modalități mai bune de a dezvolta software, dezvoltând direct și ajutându-i pe alții. Datorită muncii depuse, am putut realiza că:

Oameni și interacțiune mai important decât proceseleși unelte

Produs de lucru mai important decât documentația cuprinzătoare

Cooperare cu clientul mai important decât negocierea termenilor contractului

Pregătirea pentru schimbare este mai importantă urmând planul inițial

Adică, fără a nega importanța a ceea ce este în dreapta, tot apreciem mai mult ceea ce este în stânga.

Principii de dezvoltare agilă:

Satisfacția clientului datorită livrării rapide și neîntrerupte a software-ului necesar;
primirea schimbărilor de cerințe chiar și la sfârșitul dezvoltării (acest lucru poate crește competitivitatea produsului rezultat);
livrarea frecventă de software de lucru (în fiecare lună sau săptămână sau chiar mai des);
comunicare strânsă, zilnică, între client și dezvoltatori pe tot parcursul proiectului;
proiectul este realizat de persoane motivate cărora li se asigură condițiile necesare de muncă, sprijin și încredere;
metoda recomandată de transfer de informații este o conversație personală (față în față);
software-ul de lucru este cea mai bună măsură a progresului;
sponsorii, dezvoltatorii și utilizatorii trebuie să poată menține un ritm constant la nesfârșit;
un accent constant pe îmbunătățirea excelenței tehnice și a designului ușor de utilizat;
simplitate - arta de a nu face lucrări inutile;
cele mai bune cerințe tehnice, design și arhitectură provin dintr-o echipă auto-organizată;
adaptare constantă la circumstanțe în schimbare.

1. Scopul tehnologiei de programare. Istoria dezvoltării tehnologiei de programare. Tipuri de proiecte software. Componentele tehnologiei de programare. Proiect, produs, proces și oameni

2. Ciclul de viață al programului. Natura ciclică a dezvoltării. Concepte de bază ale tehnologiei de programare. Procese și modele. Faze și viraje. repere și artefacte. Părți interesate și angajați.

3. Identificarea și analiza cerințelor. Cerințe software. Schema de dezvoltare a cerințelor. Managementul cerințelor.

4. Proiectare arhitecturală și detaliată. Implementare și codare. Testare și verificare. Procesul de control al calității. Metode cutie albă și cutie neagră. Inspecție și recenzii. Testarea obiectivelor. Verificare, validare și testarea sistemului. Întreținere și dezvoltare continuă.

5. Modele de proces de dezvoltare. Modele de cascadă și transportoare. Modele spiralate și incrementale. Modele flexibile de proces de dezvoltare.

6. Proiectarea unui model de proces. Identificarea cerințelor procesului. Faze folosite, repere și artefacte. Alegerea arhitecturii procesului. Procedura de realizare a unui proiect tipic. proceduri documentate.

7. Modele ale echipei de dezvoltare. Natura colectivă a dezvoltării. Dimensiune optimă comenzi. Subordonarea participanților la proiect. Dezvoltarea echipei și dezvoltarea personalului. Specializare, cooperare și interacțiune.

8. Modele ale echipei de dezvoltare. Model de echipă ierarhică. Metoda echipei chirurgicale. Modelul unei echipe de egali.

9. Natura programării. Știința programării. Arta de a programa. Meșteșugul programării. paradigme de programare. Programare structurată. Programare logica. Programare orientată pe obiecte.

10. Arhitectura software. Management de evenimente. Arhitectura client/server. Servicii. arhitectura cu trei straturi. Proiectarea programului. Concept design. Design logic. Design detaliat.

1. Novikov abordări ale dezvoltării software” http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Programare extremă. - Sankt Petersburg: Peter, 2002.

3. Tehnologia de dezvoltare software. - St.Petersburg. : Peter, 2004.

4. Brooks Jr. sistemele software sunt proiectate și create. Moscova: Nauka, 1975; o nouă ediție cu traducere: Omul-lună mitică. Sankt Petersburg: SYMBOL+, 1999.

5. Algoritmi + structuri de date = programe. M., Mir, 1978.

6. Programare sistematică. Introducere. M.: Mir, 1977.

7. Programare structurată. M.: Mir, 1975.

8. Disciplina de programare. M.: Mir, 1978.

9. Tehnologii de dezvoltare software. - Sankt Petersburg: Peter, 2002.

10. Programare Terekhov. M.: BIOM, 2006.

11. Rambo J. Proces unificat de dezvoltare software. Sankt Petersburg: Peter, 2002.

Teoria economică pentru manageri

Teoriile microeconomice de bază. Exemple de aplicare în analiza proceselor economice. Teorii macroeconomice de bază. Exemple de aplicare în analiza proceselor economice. Principii și metode de gestionare a proceselor economice. Instrumente de evaluare a nivelului de dezvoltare a proceselor economice Probleme de reproducere extinsă. Factorii de creștere economică a economiei ruse. Criterii și indicatori ai dezvoltării durabile. Netezirea fluctuațiilor ciclice. Rolul multiplicatorului și acceleratorului în evaluarea ritmului dezvoltării economice. Funcțiile de producție în economie. Exemple de aplicare în analiza proceselor economice. Profit. Calculul indicatorilor care afectează profitul, imagine grafică puncte de rentabilitate. Metodologia de implementare a politicii investiționale.

Un curs de teorie economică: un manual pentru universități / Ed. . -Kirov: „ACA”, 2004. Kolemaev - modelare matematică. Modelarea proceselor și sistemelor macroeconomice: manual. M.: UNITATEA-DANA, 2005. Bazhin cibernetica. Harkiv: Consul, 2004. Atelierul Leushin despre metode modelare matematică: tutorial . Statul Nijni Novgorod tehnologie. univ.- N. Novorod, 2007. Politicieni despre economie: Prelegeri ale laureaților Nobel în economie. Moscova: Modern Economics and Law, 2005. Cheremnykh. Nivel avansat: Manual.-M.:INFRA-M, 2008. Evoluţia instituţiilor mini-economiei. Institutul de Economie al Filialei Ural a Academiei Ruse de Științe, - M.: Nauka, 2007.

Tehnologii pentru dezvoltarea și adoptarea deciziilor manageriale [N]

Luarea deciziilor stă la baza activității unui manager. Introducere în teoria deciziei. Concepte de bază ale teoriei deciziei. Modelele de management al afacerilor și impactul lor asupra luării deciziilor. Diferite căi clasificarea solutiilor. Clasificări: după gradul de formalitate, după gradul de rutină, după frecvență, după urgență, după gradul de realizare a obiectivelor, după metoda de alegere a unei alternative. Metode de bază de luare a deciziilor. Metode volitive de luare a deciziilor. Obiective de luare a deciziilor. E timpul să găsești soluții. Greșeli de bază Metode matematice de luare a deciziilor. Aspecte matematice ale teoriei luării deciziilor. Cercetare operațională. Abordare matematică a luării deciziilor. Arborele de decizie. Modele de dezvoltare și luare a deciziilor. Teoria jocului. Metode matematice de luare a deciziilor. Aspecte matematice ale teoriei luării deciziilor. Modele de teorie a cozilor. Modele de gestionare a stocurilor. Model de programare liniară. sarcini de transport. Modelare prin simulare. Analiza rețelei. Analiză economică. Limitările modelelor raționale. Caracteristici ale dezvoltării și luării deciziilor într-un grup. O metodă pentru determinarea coeziunii de grup bazată pe gradul de conexiune al mulțimilor. Metode de luare a unei decizii colective. metoda consensului. metode de vot. Metode creative de luare a deciziilor. Brainstorming. Conferinta de idei. Consiliul Naval. Metoda pălăriilor mentale de de Bono. Teoria rezolvării inventive a problemelor (TRIZ). Soluția finală ideală. Exemple de probleme și rezolvarea lor folosind TRIZ. Aplicarea metodelor TRIZ în luarea deciziilor unice și creative. Metode de dezvoltare a ideilor de soluții și adaptare la situație. Modelul arborelui țintă. Strategia de coordonare a intereselor. Formarea deciziilor privind coordonarea intereselor. Metode de determinare a intereselor contrapartidelor. Sisteme de sprijinire a deciziei (sisteme expert). Istoria creării sistemelor decizionale. Clasificarea sistemelor decizionale. Structura tipică a unui sistem expert. Modalități de reprezentare a cunoștințelor. Metode de inferență logică. Aplicarea în practică a sistemelor expert.

I. Teoria luării deciziilor: manual. - M.: Examen, 2006. - 573 p. I. Luarea deciziilor. Teoria și metodele de elaborare a deciziilor manageriale. Tutorial. - M.: martie, 2005. - 496 p. Elaborarea unei decizii de management - M.: Editura Delo, 2004 - 392 p. G. Evaluări ale experților și luare a deciziilor.- M .: Patent, 1996. - 271 p. Taha // Introduction to Operations Research = Operations Research: An Introduction. - Ed. a VII-a. - M.: „Williams”, 2007. - S. 549-594. G. Theil. Prognoze economice și luare a deciziilor. M.: Progres, 1970. K. D. Lewis. Metode de prognoză a indicatorilor economici. M.: „Finanțe și statistică” 1986. G. S. Kildishev, A. A. Frenkel. Analiza si prognoza serii temporale. M.: „Statistică” 1973. O. Kim, C. W. Muller, W. R. Klekka și colab.. Analiza factorială, discriminantă și cluster. M.: „Finanţe şi statistică” 1989. Manager eficient. Cartea 3. Luarea deciziilor. - MIM LINK, 1999 Turevsky și conducerea unei întreprinderi de transport cu motor. - M .: Liceu, 2005.,; ed. . Analiza sistemului în management: tutorial. - M .: Finanțe și statistică, 2006. , Tinkov: manual. – M.: KNORUS, 2006.

Modelarea proceselor de afaceri în sisteme integrate de management

Care sunt principiile proceselor de afaceri? Care este problema unei descrieri holistice a proceselor de afaceri. Ce este un sistem, ce proprietăți are? Rolul analizei sistemelor în modelarea proceselor de afaceri? Procesul ca obiect de control. Mediul de proces. Elementele de bază ale unui proces de afaceri. Avantajele și dezavantajele managementului funcțional și de proces. Ciclul de management PDCA. Etapele ciclului de management al procesului. Ciclul PDCA și implementarea cerințelor ISO 9001:2008. Metodologia SADT (Structured Analysis and Design Technique - o metodă de analiză structurală și proiectare). Esență. Dispoziții de bază. Cum este prezentat modelul funcțional de activitate în metodologia IDEF0? Ce înseamnă lucrările din diagramele modelului funcțional, cum sunt afișate conform metodologiei IDEF0? Pentru ce sunt săgețile din diagramele modelului funcțional, care sunt tipurile și tipurile lor? Metodologia DFD. Esență. Componentele de bază ale diagramelor DFD. Care sunt caracteristicile diagramelor DFD, ce este descris în ele? Care sunt caracteristicile obiectelor DFD-diagram? Ce reprezintă săgețile de pe diagrama DFD? Metodologia IDEF3. Esență. Mijloace de documentare și modelare. Care sunt caracteristicile diagramelor IDEF3, ce descriu acestea? Care sunt caracteristicile obiectelor diagramă IDEF3? Și trăgătorul? Clasificarea proceselor. Procese tipice de afaceri. Reinginerie și tehnologia acesteia. Când este oportun să folosim reinginerie în managementul unei companii? Monitorizarea si masurarea proceselor. Indicatori ai proceselor organizației. Evaluarea numerică și de rating a proceselor.

„Modelarea proceselor de afaceri cu AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI” 2003 „Crearea sistemelor informaționale cu AllFusion Modeling Suite” ed. „Dialog-MEPhI” 2003 „Practică modelare functionala cu AllFusion Process Modeler 4.1. (BPwin) Unde? Pentru ce? Cum?" ed. "Dialog-MEPhI" 2004 Modelarea Dubeikovsky cu AllFusion Process Modeler (BPwin). ed. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Metodologia analizei structurale și proiectării SADT" 1993 lucrări clasice pe SADT Metodologii, Cheremnykh Analysis of Systems: IDEF-Technologies, Modeling and Analysis of Systems, IDEF-Technologies, Practicum, M.: Finance and Statistics, 2001, Structural Business Models: DFD-Technologies, http://www./Level4.asp ?ItemId=5810 „Theory and Practice of Business Process Reorganization"2003/ P50.1.. Methodology of Functional Modeling. Moscova: Gosstandart of Russia, 2000. http://www.IDEF0, IDEF3, DFD http://www. BPwin Business Process Modeling http://www./department/se/devis/7/ IDEF0 în Management Business Process Modeling http:///content/view/21/27/ http://www./dir/ cat32/subj45 /file1411/view1411.html http://www.http://www.

Evaluarea eficacității produselor software

1. Arhitectura IT

2. Domeniile proceselor de management.

3. Lista proceselor din domeniul Planificare si Organizare

4. Lista proceselor de domeniu Achizitie si Implementare

5. Lista proceselor din domeniul Operațiuni și Întreținere

6. Lista proceselor din domeniul Monitorizare și Evaluare

7. Caracterizarea nivelurilor modelului de maturitate a procesului

9. KPI și KGI relația și scopul lor

1. 10. Controale IT generale și controale ale aplicațiilor. Domenii de responsabilitate și responsabilități ale afacerii și IT.

Cobit 4.1 ediția rusă.

Reglementarea legală a creării și utilizării proprietății intelectuale

1. Enumerați drepturile de proprietate intelectuală asupra rezultatelor activității intelectuale și dezvăluiți conținutul acestora.

2. Enumerați tipurile de contracte de înstrăinare a dreptului exclusiv. Descrieți fiecare dintre aceste contracte privind înstrăinarea dreptului exclusiv.

4. Descrieți principalele prevederi ale protecției legale a Programului pentru calculator ca obiect al dreptului de autor.

5. Comparați principalele prevederi ale protecției legale a Bazei de date ca obiect al dreptului de autor și ca obiect al drepturilor conexe.

6. Descrieţi condiţiile de brevetabilitate a obiectelor dreptului de brevet: invenţii; modele utile; desene industriale.

7. Extinderea conținutului criteriilor de brevetare a invenției: noutate; activitate inventiva; aplicabilitate industrială.

8. Descrieți condițiile și procedura de obținere a brevetului pentru o invenție, model de utilitate sau desen industrial, precum și condițiile care asigură valabilitatea brevetelor și durata acestora.

9. Dați o definiție a „know-how” și enumerați condițiile în care ia naștere și se realizează protecția juridică a secretelor de producție.

10. Enumeraţi mijloacele de individualizare protejate şi daţi caracteristicile comparative ale acestora.

1., Dreptul de proprietate intelectuală în Federația Rusă, manual // M, Prospect, 2007

2., Legea proprietății intelectuale, manual // M, RIOR, 2009

Management de proiect și dezvoltare software [R]

Ce este o metodologie, de ce este necesară. Structura generală a metodologiei, elementele principale ale metodologiei. Principii de proiectare a metodologiei proprii. Exemple de diverse artefacte, roluri, competențe, condiții de limită. Structura metodologiei Cowburn, metrica metodologiei. Criteriile proiectului Cowburn. Criterii de selecție a metodologiei, matricea Cowburn. Ciclul de viață al proiectului. Cascada și modele iterative ciclu de viață. Limite de aplicabilitate pentru modele cascade și iterative. RUP ca exemplu de metodologie iterativă. Concepte de bază RUP, limite de aplicabilitate. Rolul uman în dezvoltarea software-ului. Metodologii agile, principii de bază ale metodologiilor agile. Originea metodologiilor agile. Scrum ca exemplu de metodologie agilă. Roluri, artefacte, activități în Scrum. Limitele de aplicabilitate ale Scrum. Extreme Programming (XP) Idei, valori, practici de bază, limite de aplicabilitate. Asemănări și diferențe între Scrum și XP. Colectarea și gestionarea cerințelor. Practici de bază, termeni, principii. Abordări ale documentării proiectului și produsului, principalele tipuri de documente. Exemple de practici de management al cerințelor din metodologiile discutate în curs. Planificarea dezvoltării software. Tipuri de planuri, managementul riscurilor, riscuri populare. Exemple de practici de planificare a dezvoltării din metodologiile discutate în curs. Testare în dezvoltarea de software. Conceptul de asamblare (construire) a unui produs software. Metode de testare de bază, termeni. Exemple de practici de testare din metodologiile discutate în curs. Conceptul de asamblare (construire), moduri de stocare a codului, instrumente. Două principii pentru organizarea muncii cu un sistem de control al versiunilor. Caracteristici ale procesului de lansare/amenajare a produsului pentru diferite categorii de produse, exemple de practici. Concepte moderne de arhitectură software, arhitecturi multinivel, criterii de arhitectură. Lista deciziilor necesare la proiectarea software-ului, abordări ale alegerii unui sistem de stocare a datelor.

Kent Beck - Programare extremă Frederic Brooks - Luna-omul mitic sau cum sunt create sistemele software. Tom de Marco - Termen limită. Un roman despre managementul proiectelor. Tom de Marco, Timothy Lister - Valsul cu urși. Tom de Marco, Timothy Lister - Factorul uman_ proiecte și echipe de succes. Alistair Cowburn - Fiecare proiect are propria metodologie. Alistair Cowburn - Oamenii ca fiind neliniari și cele mai importante componente în dezvoltarea de software. Andriy Orlov - Note ale unui automator. Mărturisire profesională. Philip Krachten - Introducere în Procesul Rațional Unificat. Henrik Kniberg - Scrum și XP: note din prima linie. Prezentări cursuri

Model cascadă Analiza cerințelor Proiectare Implementare Integrare Testare Redactarea specificațiilor produsului Redactarea arhitecturii produsului Dezvoltarea codului sursă Integrarea părților codului sursă Testare și depanare

Modelul de caz de utilizare al procesului de dezvoltare software unificat (USDP) descrie cazurile în care va fi utilizată o aplicație. Modelul analitic descrie clasele de bază pentru aplicație. Modelul de proiectare descrie conexiunile și relațiile dintre clase și obiectele dedicate, iar modelul de implementare descrie distribuția software-ului între computere. Modelul de implementare descrie organizarea internă a codului programului. Modelul de testare constă din componente de testare, proceduri de testare și diferite cazuri de testare.

Componente tipice ale arhitecturii produsului software și cerințe tipice ale software-ului Organizarea programelor Clasele principale ale sistemelor Organizarea datelor Reguli de afaceri Interfață cu utilizatorul Gestionarea resurselor Securitate Performanță Scalabilitate Interacțiune cu alte sisteme (integrare) Internaționalizare, localizare Date de intrare-ieșire Tratarea erorilor

Componente tipice ale arhitecturii produsului software și cerințe tipice software Posibilități de implementare a arhitecturii dezvoltate. Posibilitati de implementare a arhitecturii dezvoltate. Funcționalitate redundantă. Funcționalitate redundantă. Decizia privind achiziționarea de componente software gata făcute. Decizia privind achiziționarea de componente software gata făcute. Schimbați strategia. Schimbați strategia.

Este clar descrisă organizarea generală a programului; dacă specificația include o privire de ansamblu asupra arhitecturii și a rațiunii sale. Este clar descrisă organizarea generală a programului; dacă specificația include o privire de ansamblu asupra arhitecturii și a rațiunii sale. Sunt principalele componente ale programului definite adecvat, domeniile lor de responsabilitate și interacțiunea cu alte componente. Sunt principalele componente ale programului definite adecvat, domeniile lor de responsabilitate și interacțiunea cu alte componente. Dacă toate funcțiile specificate în specificația cerințelor sunt implementate de un număr rezonabil de componente ale sistemului. Dacă toate funcțiile specificate în specificația cerințelor sunt implementate de un număr rezonabil de componente ale sistemului. Sunt cele mai importante clase descrise și justificate. Sunt cele mai importante clase descrise și justificate. Dacă se oferă o descriere a organizării bazei de date. Dacă se oferă o descriere a organizării bazei de date. Sunt definite toate regulile de afaceri? Sunt definite toate regulile de afaceri? Este descris impactul lor asupra sistemului? Este descris impactul lor asupra sistemului? O listă de întrebări care vă permite să trageți o concluzie despre calitatea arhitecturii:

O listă de întrebări care vă permite să trageți o concluzie despre calitatea arhitecturii: Este descrisă strategia de proiectare a interfeței cu utilizatorul. Dacă este descrisă strategia de proiectare a interfeței cu utilizatorul. Dacă interfața cu utilizatorul este modulară, astfel încât modificările aduse acesteia să nu afecteze restul sistemului. Dacă interfața cu utilizatorul este modulară, astfel încât modificările aduse acesteia să nu afecteze restul sistemului. Dacă a fost furnizată o descriere a strategiei I/O. Dacă a fost furnizată o descriere a strategiei I/O. Dacă a fost efectuată o analiză de performanță a sistemului care va fi implementat folosind această arhitectură. Dacă a fost efectuată o analiză de performanță a sistemului care va fi implementat folosind această arhitectură. A fost efectuată analiza de fiabilitate a sistemului proiectat? A fost efectuată analiza de fiabilitate a sistemului proiectat? A fost efectuată o analiză a scalabilității și extensibilității sistemului? A fost efectuată o analiză a scalabilității și extensibilității sistemului?

Codul de refactorizare software este repetat; implementarea metodei este prea mare; prea multă imbricare a buclelor sau bucla în sine este foarte mare; clasa are conectivitate slabă (proprietățile și metodele clasei ar trebui să descrie doar 1 obiect); o interfață de clasă nu formează o abstractizare consistentă; metoda ia prea mulți parametri. Ar trebui să încercați să mențineți numărul de parametri la un minim rezonabil; părțile individuale ale clasei se schimbă independent de celelalte părți ale clasei; Refactorizarea implică adaptarea software-ului la noul hardware și la noi sisteme de operare, noi instrumente de dezvoltare, noi cerințe și arhitectură și funcționalitate software. Aceasta este o modificare a structurii interne a software-ului fără modificarea comportamentului său extern, menită să asigure modificarea software-ului. Motive rezonabile pentru refactorizare:

Refactorizarea software-ului la schimbarea programului necesită o schimbare paralelă a mai multor clase. Dacă apare o astfel de situație, este necesară reorganizarea claselor pentru a minimiza locurile de posibile schimbări în viitor; trebuie să schimbe mai multe ierarhii de moștenire în paralel; trebuie să schimbați mai multe blocuri de caz. Este necesar să se modifice programul în așa fel încât să se facă implementarea blocului de caz și să-l numească de numărul necesar de ori în program; membrii de date înrudiți utilizați împreună nu sunt organizați în clase. Dacă utilizați în mod repetat același set de elemente de date, atunci este recomandabil să luați în considerare combinarea acestor date și plasarea operațiunilor efectuate asupra lor într-o clasă separată;

Refactorizarea obiectului media nu face nimic. Dacă rolul unei clase este de a redirecționa apelurile de metodă către alte clase, atunci cel mai bine este să eliminați acel proxy și să faceți apeluri către alte clase direct; o clasă știe prea multe despre o altă clasă. În această situație, este necesar să se facă încapsularea mai strictă pentru a se asigura că moștenitorul are cunoștințe minime despre părintele său; metoda are un nume nefericit; membrii datelor sunt publici. Acest lucru estompează linia dintre interfață și implementare, întrerupe inevitabil încapsularea și limitează flexibilitatea programului; plasați comentarii în codul sursă;