Abordări de bază ale dezvoltării software. Abordări tehnologice ale dezvoltării software. Teoria economică pentru manageri

Când luăm în considerare tehnologia de dezvoltare software, este necesar să folosim o abordare sistematică, care implică luarea în considerare nu a unor aspecte individuale ale problemei dezvoltării software, ci a problemei în ansamblu. Abordarea sistemelor este implementată în spațiu și timp.

O abordare sistematică în timp ia în considerare succesiunea etapelor de creare a software-ului din momentul formării unei nevoi nesatisfăcute de software pana se rezolvaşi sprijin în operarea primite produs software.

Abordare sistematică în „spațiu” implică luarea în considerare a software-ului dezvoltat ca parte a sistemului.În același timp, pe baza studierii nevoilor de informații ale sistemului, care va include software-ul dezvoltat, se formulează obiectivele și setul de funcții software, se analizează prototipurile software. Cerințele software sunt generate și documentate.

Tehnologie moderna Dezvoltarea software-ului consideră programarea ca una dintre etapele de dezvoltare dintr-un lanț de etape succesive ale ciclului de dezvoltare. Toate aceste etape sunt unite de conceptul de ciclu de viață al software-ului și trebuie susținute de instrumente software și hardware adecvate.

În conformitate cu standardul internațional ISO/IEC 12207 " tehnologia de informație– Procese ciclu de viață Procesul de dezvoltare software conține următoarele etape ale ciclului de viață al software-ului:

1) analiza Cerințe de sistemși domenii de aplicare;

2) proiectarea arhitecturii sistemului;

3) analiza cerințelor software (specificații, interfețe externe,);

4) proiectarea arhitecturii software;

5) proiectarea detaliată a fiecărei unități software;

6) codare software (programare)

7) testarea unităților software;

8) integrarea (combinația de software) și testarea unui set de unități software;

9) teste de calificare software ( testare cuprinzătoare);

10) unitățile de structură software de integrare a sistemului trebuie să fie integrate cu unitățile hardware;

11) teste de calificare a sistemului;

12) instalarea software-ului.

Astfel, procesul de dezvoltare software începe de la sistemul în care software-ul va fi utilizat și se termină din nou în sistem.

După etapele de dezvoltare din ciclul de viață al software-ului, urmează etapa de operare și întreținere a software-ului în timpul funcționării. Uneori se oferă o listă de etape ale ciclului de viață al software-ului cu unele generalizări (măriri) ale celor 12 etape date. De exemplu, etapele de proiectare a sistemului și determinarea cerințelor software, proiectarea pachetului software, proiectarea algoritmului software, programarea (codarea), depanarea software autonomă, depanarea software integrată, operarea software-ului.

Neglijând etapele proiectării software-ului, dorința de a începe imediat programarea fără a elabora suficient algoritmi și problemele de interacțiune a unităților structurale software duce adesea la un proces haotic de dezvoltare a software-ului cu șanse reduse de succes.

Model în spirală ciclul de viață al software-ului. Tehnologii de dezvoltare software „grele și ușoare” (rapide).

Modelul ciclului de viață (LC) considerat este un model de tip cascadă. Acest tip de model de ciclu de viață este bun pentru software pentru care este posibil să se formuleze complet și precis toate cerințele software chiar la începutul dezvoltării.

Schema unui software de ciclu de viață în spirală. Cu toate acestea, procesul real de creare a software-ului nu se încadrează întotdeauna într-o schemă atât de rigidă și de multe ori este nevoie de a reveni la etapele anterioare cu clarificare sau revizuire a deciziilor luate.

Software-ul, ca și alte sisteme complexe pentru care cerințele inițiale nu sunt suficient de complete, se caracterizează printr-un proces iterativ de dezvoltare. Mai mult, pentru unele tipuri de software este chiar de dorit să treceți la etapa următoare cât mai repede posibil. În același timp, deficiențele care sunt inevitabile cu o astfel de muncă grăbită sunt eliminate la următoarea iterație sau rămân pentru totdeauna.

Sarcina principală este de a realiza un software de lucru cât mai repede posibil, activând astfel procesul de clarificare și completare a cerințelor. Acesta este așa-numitul model spiral al ciclului de viață al software-ului.

La fiecare tură a spiralei, este creată o versiune a produsului, sunt specificate cerințele software și este planificată activitatea următoarei ture. Modelul spiralat al ciclului de viață al software-ului reflectă procesul existent în mod obiectiv de dezvoltare iterativă a software-ului (Fig. 8.2).

Se crede că schema spirală a ciclului de viață a software-ului este destinată nu atât dezvoltatorilor grăbiți, cât și software-ului ale căror prime versiuni de calitate scăzută sunt acceptabile pentru scopul funcțional al software-ului.

Există o direcție de „Tehnologii rapide” de dezvoltare software (Agile Software Development), care oferă o justificare ideologică pentru opiniile asociate cu modelul spiral al ciclului de viață. Aceste tehnologii se bazează pe patru idei:

Interacțiunea interactivă a indivizilor este mai importantă decât procedurile și instrumentele formale,

Software-ul care funcționează este mai important decât a avea documentație pentru el,

Cooperarea cu clientul este mai importantă decât contractele formale,

Răspuns rapid la modificări externe mai important decât respectarea strictă a planurilor.

Orez. 8.2 - Schema software-ului ciclului de viață în spirală

Cu alte cuvinte, tehnologiile rapide vizează înlocuirea procedurilor de interacțiune documentate formale și intensive în muncă în timpul dezvoltării cu unele interactive, ceea ce este posibil cu o dimensiune redusă a proiectului, calități ale angajaților selectate, plasarea dezvoltatorilor și clienții „în aceeași cameră” și pentru dezvoltarea software pentru sisteme necritice.

Corectitudinea acestor principii într-o anumită măsură, atunci când dezvoltarea de software este realizată de un număr mic de „fani”) calificați și dedicați pentru dezvoltarea anumitor tipuri de software, este greu de contestat. Cu toate acestea, tehnologiile Agile și ideologii lor recunosc acest lucru, sunt aplicabile în proiectele software de o anumită clasă și scară, la fel ca modelul ciclului de viață în spirală în general, și anume acolo unde erorile software duc la unele inconveniente sau pierderi de fonduri recuperabile.

În cazul în care software-ul defectuos duce la o amenințare la adresa vieții umane sau la pierderi materiale mari, ar trebui utilizate tehnologii cuprinzătoare și bine gândite pentru a asigura fiabilitatea produsului software.

Odată cu creșterea dimensiunii unui proiect software și creșterea numărului de persoane care participă la acesta, crește nevoia de tehnologie de dezvoltare rigidă care alcătuiește un ciclu de viață software în cascadă. Aici este nevoie de documentare, deoarece pierderea oricăruia dintre dezvoltatori este posibilă în orice moment, este necesară oficializarea conexiunilor între programe, gestionarea modificărilor software etc. Nu degeaba modelul ciclului de viață în cascadă este inclus în software. standarde de dezvoltare. În același timp, vă permite, de asemenea, să implementați un proces de dezvoltare iterativ datorită etapelor stipulate în proiectarea STS și software pentru acestea.

Pentru proiectele software foarte mari (o echipă de dezvoltatori de peste 100), tehnologia de dezvoltare este un factor cheie care influențează nu numai calitatea software-ului, ci și însăși posibilitatea creării acestuia.

Tehnologii de dezvoltare software „grele și ușoare”. . Dezvoltatorii multor tipuri de software consideră că modelul ciclului de viață al cascadei este prea înregimentat, prea documentat și greu și, prin urmare, irațional. Există o direcție de „Tehnologii rapide” (tehnologii ușoare) de dezvoltare software (Agile Software Development), care oferă o justificare ideologică pentru aceste opinii. Aceste tehnologii se bazează pe patru idei:

1. interacțiunea interactivă a indivizilor este mai importantă decât procedurile și instrumentele formale,

2. software-ul care funcționează este mai important decât a avea documentație pentru el,

3. cooperarea cu clientul este mai importantă decât contractele formale cu acesta,

4. răspunsul rapid la schimbările externe este mai important decât respectarea strictă la planurile planificate.

Corectitudinea acestor principii, cu excepția celui de-al treilea într-o anumită măsură (dezvoltarea software-ului este realizată de un număr mic de programatori calificați - „fani” care nu au nevoie de control și motivație suplimentară) pentru dezvoltarea de software este dificil de contestat. Cu toate acestea, tehnologiile Agile, și acest lucru este recunoscut de ideologii lor, sunt aplicabile în proiectele software de o anumită clasă și scară, precum și modelul ciclului de viață în spirală în general, și anume acolo unde erorile software duc la unele inconveniente sau pierderi de fonduri recuperabile și unde cerințele software sunt în continuă schimbare, deoarece au fost prost definite în prealabil și este necesară o adaptare rapidă la aceste schimbări.

tehnologii rapide -încearcă să ajungă la un compromis între disciplina strictă a dezvoltării și absența sa completă în numele reducerii fluxului de lucrări care însoțesc dezvoltarea Tehnologiile rapide nu pot asigura o fiabilitate ridicată a unui produs software tocmai din cauza minimizării lucrărilor care confirmă legal responsabilitatea dezvoltatorului. .

Un exemplu de tehnologii Agile este Extreme Programming (XP). Iterațiile în XP sunt foarte scurte și constau în patru operațiuni: codificare, testare, ascultare a clientului, proiectare. Principiile XP - minimalism, simplitate, participarea clientului, ciclu scurt, interacțiune strânsă între dezvoltatori - ar trebui să stea în aceeași cameră, întâlnirile operaționale zilnice cu clientul par rezonabile și au fost folosite de mult timp nu numai în tehnologiile rapide, ci și în XP. sunt duse la valori extreme.

O analiză a multor proiecte software a arătat că tehnologiile ușoare care propovăduiesc principiile auto-organizării, punând accent pe utilizarea abilităților individuale ale dezvoltatorilor, iterații scurte de dezvoltare într-un model în spirală, XP, SCRUM sunt comune și adesea conduc la succes, făcând cele mai multe caracteristici ale lucrului în echipe mici.

În cazul în care software-ul care funcționează incorect duce la o amenințare la adresa vieții umane sau la pierderi materiale mari, ar trebui utilizate tehnologii „grele” oficializate ordonate, pe deplin gândite și previzibile, asigurând fiabilitatea produsului software chiar și în cazul dezvoltatorilor cu calificare medie. Odată cu creșterea dimensiunii proiectului software, creșterea numărului de participanți În acest domeniu, este în creștere nevoia unei tehnologii de dezvoltare rigide și formale care să stabilească responsabilitatea fiecărui participant la dezvoltare care alcătuiește ciclul de viață al software-ului în cascadă. . Nu degeaba modelul ciclului de viață în cascadă este inclus în standardele de dezvoltare software.

În echipele mari de dezvoltare, problema managementului iese în prim-plan.

Pentru proiectele software foarte mari, problemele de dezvoltare ordonată, coordonată: structurarea, integrarea, asigurarea interacțiunii corecte a programelor, organizarea implementării corecte și coordonate a schimbărilor inevitabile sunt cheie. și influențează însăși posibilitatea creării lor.

În proiectele software mici, perfecționările algoritmice și influența indivizilor talentați individuali joacă un rol decisiv, în timp ce în proiectele mari acești factori sunt nivelați și nu au o influență decisivă asupra progresului dezvoltării.

Dezvoltatorii de software cu capacități medii, care este majoritatea și care mențin disciplina tehnologică în cadrul tehnologiei potrivite, trebuie să dezvolte software de calitatea cerută. „Păstrează ordinea și el te va sprijini.”

Modele de dezvoltare software Waterfall Model în cascadă Spiral Extreme Programming UI Prototyping Incremental W-Model Testing Proces unificat de dezvoltare software(USDP) Metodologia MSF

Model cascadă Analiza cerințelor Dezvoltarea unei specificații de produs Proiectarea Dezvoltarea unei arhitecturi de produs Implementarea Dezvoltarea codului sursă Integrarea părților individuale ale codului sursă Testarea și eliminarea defectelor

Programare extremă Analiza cerințelor inițiale Proiectare Integrare Implementare Testare Noi cerințe Analiza/Aprobarea/modificarea planului de dezvoltare Lansarea produsului

UI Prototyping Lansarea produsului Dezvoltare software ținând cont de modificări Clarificarea cerințelor și specificațiilor Modificarea prototipului și finalizarea 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 Testarea componentelor 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 alocate Ø Modelul de implementare descrie distribuția software-ului între computere. Ø Modelul de implementare descrie organizarea internă codul programului. Ø Un model de testare constă din componente de testare, proceduri de testare și diferite opțiuni de testare.

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

Componente tipice ale arhitecturii unui produs software și cerințe tipice pentru software Ø Ø Ø Ø Organizarea programelor Clase de bază ale sistemului 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

Componentele tipice ale arhitecturii unui produs software și cerințele software tipice Toleranța la erori este un set de proprietăți ale sistemului care mărește fiabilitatea acestuia prin detectarea erorilor, recuperarea și localizarea consecințelor negative pentru sistem. La proiectarea oricărui sistem real pentru a asigura toleranța la defecțiuni, este necesar să se prevadă toate situațiile posibile care pot duce la defecțiuni ale sistemului și să se dezvolte mecanisme pentru gestionarea defecțiunilor. Fiabilitatea este capacitatea unui sistem de a rezista la diverse defecțiuni și defecțiuni. Eșecul este trecerea unui sistem ca urmare a unei erori la o stare complet inoperabilă. Eșecul 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 într-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 mergeți 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 unui produs software și cerințe tipice software Ø Posibilitatea implementării arhitecturii dezvoltate. Ø Functionalitate redundanta. Ø 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; Ø Ø Ø Specificația include o privire de ansamblu asupra arhitecturii și a rațiunii sale. Componentele majore ale programului, responsabilitățile și interacțiunile lor cu alte componente sunt definite în mod adecvat? Dacă toate funcțiile specificate în specificația cerințelor sunt implementate de un număr rezonabil de componente ale sistemului. Există o descriere a celor mai importante clase și a rațiunii lor? Este oferită 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. Ø Există o descriere a strategiei de intrare/ieșire a datelor? ØA fost efectuată o analiză de performanță a sistemului care va fi implementat folosind această arhitectură? ØA fost efectuată o analiză de fiabilitate a sistemului proiectat? ØA fost efectuată o analiză a problemelor de scalabilitate și extensibilitate a sistemului?

Refactorizarea software Refactorizarea implică adaptarea software-ului la nou hardwareși la noi sisteme de operare, noi instrumente de dezvoltare, noi cerințe, precum ș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 se repetă; implementarea metodei este prea mare; există prea multă imbricare de bucle sau bucla în sine este foarte mare; clasa are o coeziune 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. Este necesar să se încerce să se păstreze numărul de parametri rezonabil de minim; părțile individuale ale clasei se schimbă independent de celelalte părți ale clasei;

Refactorizarea software: Când schimbați un program, mai multe clase trebuie schimbate în paralel. Dacă apare o astfel de situație, este necesară reorganizarea cursurilor pentru a minimiza locurile pe viitor posibile modificări; trebuie să modificați mai multe ierarhii de moștenire în paralel; trebuie să schimbați mai multe blocuri de caz. Este necesar să modificați programul în așa fel încât să implementați blocul de caz și să îl numiți de numărul necesar de ori în program; elementele de date asociate utilizate împreună nu sunt organizate în clase. Dacă utilizați în mod repetat același set de elemente de date, atunci este util să luați în considerare combinarea acestor date și plasarea operațiunilor efectuate asupra lor într-o clasă separată;

Metoda de refactorizare software folosește mai multe elemente ale unei alte clase decât ale sale. Aceasta înseamnă că metoda trebuie mutată într-o altă clasă și apelată din cea veche; tipul de date primitiv este supraîncărcat. Pentru a descrie o entitate din lumea reală, este mai bine să folosiți o clasă decât să supraîncărcați un tip de date existent; Clasa are o funcționalitate prea limitată. Este mai bine să scăpați de această clasă mutându-i funcționalitatea într-o altă clasă; Datele „rătăcite” sunt transmise de-a lungul unui lanț de metode. Datele care sunt transmise unei metode doar pentru ca aceasta să le transmită unei alte metode se numesc „rătăcite”. Dacă apar astfel de situații, încercați să schimbați arhitectura claselor și metodelor pentru a scăpa de ele.

Refactorizarea obiectului proxy software 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 un astfel de obiect intermediar ș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; posteaza comentarii pe cod sursa;

Subclasa de refactorizare software folosește 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 mai multe metode din clasa de bază și nu pentru a descrie vreo entitate nouă. Pentru a evita acest lucru, este necesar să se transforme clasa de bază astfel încât să ofere noii clase acces numai la metodele de care are nevoie; codul conține variabile globale. Numai acele variabile 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 unor obiecte; programul conține cod care poate fi necesar într-o zi. Când dezvoltați un sistem, este recomandabil să furnizați locuri unde codul sursă poate fi adăugat în viitor.

Acum, în ingineria software, există două abordări principale ale dezvoltării software-ului IS, diferența fundamentală dintre care se datorează căi diferite descompunerea sistemului: o abordare funcțional-modulară (structurală), care se bazează pe principiul descompunerii funcționale, în care structura sistemului este descrisă în termeni de ierarhia funcțiilor sale și transferul de informații între elementele funcționale individuale și abordare orientată pe obiecte, care folosește descompunerea obiectelor, descrie structura SI în termeni de obiecte și conexiuni dintre ele și comportamentul sistemului în ceea ce privește schimbul de mesaje între obiecte.

Deci, esența abordare structurală la dezvoltarea software-ului IS constă în descompunerea acestuia în funcţii automate: sistemul este împărţit în subsisteme funcționale, care la rândul lor sunt împărțite în subfuncții, ele în sarcini și așa mai departe până la proceduri specifice. În același timp, SI menține integritatea prezentării, unde toate componentele sunt interconectate. La dezvoltarea unui sistem „de jos în sus”, de la sarcini individuale la întregul sistem, integritatea se pierde, apar probleme la descrierea interacțiunea informațională componente individuale.

Principiile de bază ale abordării structurale sunt:

o principiu" împarte și stăpânește”;

o principiu ordonarea ierarhică - principiul organizării sistemelor componente în structuri arborescente ierarhice cu adăugarea de noi detalii la fiecare nivel. Evidențierea a două principii de bază nu înseamnă că principiile rămase sunt secundare, deoarece ignorarea oricăruia dintre ele poate duce la consecințe imprevizibile.

Principalele principii ale acestor principii sunt:

o abstractizare - evidentierea aspectelor esentiale ale sistemului;

o consistență - validitatea și consistența elementelor sistemului;

o structurarea datelor - datele trebuie să fie structurate și organizate ierarhic.

Bazele metodologice ale tehnologiilor de creare de software

Modelare vizuală. În general, un model software este o descriere formalizată a unui sistem software la un anumit nivel de abstractizare. Fiecare model definește un aspect specific al sistemului, folosește un set de diagrame și documente într-un format dat și reflectă gândurile și activitățile diferitelor persoane cu interese, roluri sau sarcini specifice.

Modelele grafice (vizuale) sunt instrumente pentru vizualizarea, descrierea, proiectarea și documentarea arhitecturii sistemului. Compoziția modelelor utilizate în fiecare proiect specific și gradul de detaliere a acestora depind în general de următorii factori:

o dificultăți ale sistemului proiectat;

o caracterul complet necesar al descrierii sale;

o cunoștințele și abilitățile participanților la proiect;

o timpul alocat pentru proiectare.

Modelarea vizuală a influențat foarte mult dezvoltarea instrumentelor CASE în special. Conceptul de CASE (Computer Aided Software Engineering) este folosit într-un sens larg. Sensul original al acestui concept, limitat doar la sarcinile de automatizare a dezvoltării software, a căpătat acum un nou sens, acoperind majoritatea proceselor ciclului de viață al software-ului.

Tehnologia CASE este un set de metode de proiectare software, precum și un set de instrumente care vă permit să modelați vizual domeniul subiectului, analizează acest model în toate etapele dezvoltării și întreținerii software și dezvoltă aplicații în conformitate cu nevoile de informare ale utilizatorilor. Majoritatea instrumentelor CASE existente se bazează pe metode de analiză și proiectare structurale sau orientate pe obiecte, folosind specificații sub formă de diagrame sau texte pentru a descrie cerințele externe, relațiile dintre modelele de sistem, dinamica comportamentului sistemului și arhitectura software.

Informatică, cibernetică și programare

Iterația N Procesul de dezvoltare software unificat USDP Modelul de caz de utilizare descrie cazurile în care va fi utilizată aplicația. Modelul analitic descrie clasele de bază pentru aplicație. Modelul de proiectare descrie conexiunile și relațiile dintre clase și obiecte dedicate. Modelul de implementare descrie distribuția software-ului între computere.

Lecția nr. 20
Principii generaleși abordări ale dezvoltării software

Modele de dezvoltare software

Vodopadnaya
Model în cascadă
Spirală
Programare extremă
incremental
Metodologia MSF

Model cascadă

Model în spirală

Dezvoltare incrementală

Analiza cerințelor

Proiecta

Implementarea

Componentă

testarea

Integrare

Testare

un întreg

Iterația 1 Iterația 2…. Iterația N

Procesul de dezvoltare software unificat (USDP)

Modelul de caz de utilizare descrie cazurile în care va fi utilizată aplicația.
Modelul analitic descrie clasele de bază pentru aplicație.
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.
Un model de testare constă din componente de testare, proceduri de testare și diferite cazuri de testare.

Metodologia MSF

Componentele tipice ale arhitecturii produsului software și cerințele software tipice

toleranta la greseliun set de proprietăți ale sistemului care mărește fiabilitatea acestuia prin detectarea erorilor, restabilirea și localizarea consecințelor negative pentru sistem. La proiectarea oricărui sistem real pentru a asigura toleranța la defecțiuni, este necesar să se prevadă toate situațiile posibile care pot duce la defecțiuni ale sistemului și să se dezvolte mecanisme pentru gestionarea defecțiunilor.

Fiabilitate capacitatea sistemului de a rezista la diverse defecțiuni și defecțiuni.

Refuz aceasta este o tranziție de sistemca urmare a erorii într-o stare complet inoperabilă.

Prăbușire 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 într-o anumită perioadă de timp, cu atât sistemul este considerat mai fiabil.

Precum și alte lucrări care te-ar putea interesa
57355.		Varietate de compuși organici, clasificarea lor. Substanțe organice ale naturii vii	48,5 KB
	Diversitatea compușilor organici este determinată de capacitatea unică a atomilor de carbon de a se conecta între ei prin legături simple și multiple pentru a forma compuși cu un număr aproape nelimitat de atomi legați în lanțuri: cicluri, biciclete, tricicluri, policcicluri, cadre etc.
57359.		Prelucrarea modelelor informaţionale verbale	291 KB
	Concepte de bază: model; model informativ; model informativ verbal; adnotare; abstract. Sinopsis Sinopsis din lat. Creați o notă pentru 2. Salvați documentul în propriul folder sub numele Notă.
57361.		Numărul și figura 3. Alinierea numerelor la granițe 3. Scrierea numerelor 3. Alinierea numărului de obiecte	35,5 KB
	Câte creaturi sunt Cine ocupă primul loc Cine ocupă ultimul Cine ocupă locul 1 Cine ocupă locul 2 Numiți vecinii ariciului. Cine este veverița dreptaci Cine este girafa stângacă Cine este cel mai mare Cine este cel mai puțin Cine stă în mijlocul creaturilor Gra Arată-mi, nu ai milă.

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. Diagramă 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ții și recenzii. Testarea obiectivelor. Verificare, validare și testarea sistemului. Întreținere și dezvoltare continuă.

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

6. Construirea unui model de proces. Identificați cerințele procesului. Etape, repere și artefacte utilizate. Alegerea unei arhitecturi de proces. Procedura de realizare a unui proiect standard. Proceduri documentate.

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

8. Modele de echipa de dezvoltare. Model de echipă ierarhică. Metoda echipei chirurgicale. Modelul echipei de egali.

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

10. Arhitectura software. Management de evenimente. Arhitectura client/server. Servicii. Arhitectură cu trei straturi. Proiectarea programului. Design conceptual. 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. sunt proiectate și create sisteme software. M.: Nauka, 1975; noua ediție a traducerii: The Mythical Man-Month. SPb.: 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. Programarea 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. Atenuarea 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ă pragul de rentabilitate. Metodologia de implementare a politicii investiționale.

Curs de teorie economică: manual pentru universităţi / Ed. . –Kirov: „ASA”, 2004. Kolemaev - modelare matematică. Modelarea proceselor și sistemelor macroeconomice: manual. M.: UNITATEA-DANA, 2005. Bazhin cibernetica. Harkov: 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. M.: Economie și drept modern, 2005. Cheremnykh. Nivel avansat: Manual.-M.:INFRA-M, 2008. Evoluţia instituţiilor mini-economiei. Institutul de Economie, Filiala Ural a Academiei Ruse de Științe, - M.: Nauka, 2007.

Tehnologii pentru dezvoltare și luarea deciziilor de management [N]

Luarea deciziilor ca bază a 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. Obiectivele luării deciziilor. Timp când căutați soluții. Greșeli de bază Metode matematice de luare a deciziilor. Aspecte matematice ale teoriei deciziei. 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 deciziei. Modele ale teoriei 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ă de determinare a coeziunii de grup pe baza gradului de conectivitate al mulțimilor. Metode de luare a deciziilor colective. Metoda consensului. Metode de vot. Metode creative de luare a deciziilor. Brainstorming. Conferinta de idei. Consiliul navei. Metoda „Pălăriilor gânditoare” a lui De Bono. Teoria rezolvării inventive a problemelor (TRIZ). Soluția finală perfectă. Exemple de probleme și soluțiile lor folosind TRIZ. Aplicarea metodelor TRIZ la luarea deciziilor unice și creative. Metode de dezvoltare a ideilor de soluții și de adaptare la situație. Modelul arborelui obiectivelor. Strategie de coordonare a intereselor. Formarea deciziilor de coordonare a intereselor. Metode de determinare a intereselor contrapartidelor. Sisteme de sprijin pentru decizii (sisteme expert). Istoria creării sistemelor decizionale. Clasificarea sistemelor decizionale. Structura tipică a unui sistem expert. Metode de prezentare 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. Teorie și metode de elaborare a deciziilor de management. Tutorial. - M.: MarT, 2005. - 496 p. Elaborarea deciziilor de conducere - 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. - P. 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, U. R. Klekka și alții. 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. , ; editat de . 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

După ce principii se disting procesele 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 - metoda de analiza structurala si proiectare). Esență. Dispoziții de bază. Cum este reprezentat modelul funcțional de activitate în metodologia IDEF0? Ce înseamnă activitățile 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 și ce este descris în acestea? Care sunt caracteristicile obiectelor diagramă DFD? Ce înseamnă săgețile de pe o diagramă DFD? Metodologia IDEF3. Esență. Instrumente de documentare și modelare. Care sunt caracteristicile diagramelor IDEF3 și ce este descris în acestea? Care sunt caracteristicile obiectelor diagramă IDEF3? Și trăgătorul? Clasificarea proceselor. Procese tipice de afaceri. Reinginerie și tehnologia acesteia. Când este indicat să folosiți reinginerie atunci când conduceți o companie? Procese de monitorizare si masurare. Indicatori ai proceselor organizatorice. Evaluări numerice și de rating ale 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?" publicarea "Dialog-MEPhI" 2004 Modelarea Dubeykovsky cu AllFusion Process Modeler (BPwin). publicarea "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Metodology of structural analysis and design SADT" 1993 lucrare clasică asupra metodologiei SADT. Analiza sistemelor: tehnologii IDEF, Atelierul de modelare și analiză M.: Finanțe și statistică, 2001. „Modele de afaceri structurale: tehnologii DFD” http://www.ItemId=5810 „Teoria și practica reorganizării proceselor de afaceri " 2003/ P50.1.. Metodologia modelării funcționale. M.: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Modelarea proceselor de afaceri folosind BPwin http://www. /department/se/devis/7/ IDEF0 în modelarea proceselor de management al afacerii http:///content/view/21/27/ http://www /dir/ cat32/subj45/file1411/view1411.html http://www. .

Evaluarea eficacității produselor software

1. Arhitectura IT

2. Domeniile proceselor de management.

3. Lista proceselor din domeniul Planificare și Organizare

4. Lista proceselor de domeniu Achizitie si Implementare

5. Lista proceselor din domeniul Operare și întreținere

6. Lista proceselor din domeniul Monitorizare și Evaluare

7. Caracteristicile nivelurilor modelului de maturitate a procesului

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

1. 10.Controale IT generale și controale 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 intelectuale asupra rezultatelor activității intelectuale și dezvăluiți conținutul acestora.

2. Enumerați tipurile de acorduri pentru dispunerea drepturilor exclusive. Descrieți fiecare dintre aceste acorduri privind dispunerea drepturilor exclusive.

4. Descrieți principalele prevederi de protecție juridică a unui Program de calculator ca obiect al dreptului de autor.

5. Comparați principalele prevederi de protecție juridică 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 drepturilor de brevet: invenţii; modele de utilitate; desene industriale.

7. Extinderea conținutului criteriilor de brevetare pentru o invenție: 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 perioadele de valabilitate a acestora.

9. Definiți „know-how” și enumerați condițiile în timpul creării cărora 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. Drepturile de proprietate intelectuală în Federația Rusă, manual // M, Prospekt, 2007

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

Management de proiect și dezvoltare software [I]

Ce este metodologia, de ce este necesară. Structura generală a metodologiei, elementele principale ale metodologiei. Principii pentru proiectarea propriei metodologii. Exemple de diverse artefacte, roluri, competențe, condiții de limită. Structura metodologiei conform Cowburn, metrica metodologiei. Criteriile de proiectare ale lui Cowburn. Criterii de alegere a unei metodologii, matricea Cowburn. Ciclul de viață al proiectului. Cascada și modele iterative ale ciclului de viață. Limite de aplicabilitate pentru modele cascade și iterative. RUP ca exemplu de metodologie iterativă. Concepte de bază ale RUP, limite de aplicabilitate. Rolul oamenilor în dezvoltarea software-ului. Metodologii agile, principii de bază ale metodologiilor agile. Motivul apariției metodologiilor flexibile. Scrum ca exemplu de metodologie flexibilă. Roluri, artefacte, activități în Scrum. Limite de aplicabilitate 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 unui proiect și produs, 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), metode de stocare a codului, instrumente. Două principii pentru organizarea muncii cu un sistem de control al versiunilor. Caracteristici ale procesului de lansare/afișare a produsului pentru diferite categorii de produse, exemple de practici. Concepte moderne de arhitectură software, arhitecturi pe mai multe niveluri, criterii de arhitectură. Lista deciziilor necesare la proiectarea software-ului, abordări ale alegerii unui sistem de stocare a datelor.

Kent Beck - Programare extremă Frederick Brooks - Luna-omul mitic sau cum sunt create sisteme software. Tom DeMarco - Termen limită. Un roman despre managementul proiectelor. Tom De Marco, Timothy Lister - Valsul cu urșii. Tom DeMarco, 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 crearea de software. Andriy Orlov - Note ale unui inginer de automatizare. Mărturisire profesională. Philipp Kratchen - Introducere în procesul rațional unificat. Henrik Kniberg - Scrum și XP: note din primele linii. Prezentări de prelegeri la curs