Dizajn softvera. Alati za razvoj softvera

Napomena: Pojam procesa razvoja softvera. Univerzalni proces. trenutni proces. specifičan proces. standardni proces. Poboljšanje procesa. Pull/Push strategije. Klasični modeli procesa: model vodopada, model spirale. Faze i aktivnosti.

Prednost ovog modela bila je ograničenje mogućnosti povratka na proizvoljan korak unatrag, npr. s testiranja na analizu, s razvoja na rad na zahtjevima itd. Uočeno je da takvi povrati mogu katastrofalno povećati troškove projekta i vrijeme njegove provedbe. Na primjer, ako se tijekom testiranja pronađu pogreške u dizajnu ili analizi, njihovo popravljanje često rezultira potpunim redizajnom sustava. Ovaj model dopuštao je samo povratak na prethodni korak, na primjer, od testiranja do kodiranja, od softvera ovaj model aktivno su kritizirali gotovo svi autori odgovarajućih članaka i udžbenika. Postalo je općeprihvaćeno da ne odražava značajke razvoja softvera. Nedostaci modela vodopada su:

  • identifikacija faza i aktivnosti, što za posljedicu ima gubitak razvojne fleksibilnosti, posebice poteškoće u podržavanju iterativnog razvojnog procesa;
  • zahtjev za potpuni završetak faze aktivnosti, fiksiranje rezultata u obliku detaljnog izvornog dokumenta (profesionalni zadatak, specifikacija projekta); međutim, iskustvo u razvoju softvera pokazuje da nije moguće u potpunosti dovršiti razvoj zahtjeva, dizajn sustava itd. - sve ovo je podložno promjenama; a razlozi ovdje nisu samo u tome što je okruženje projekta mobilno, već iu tome što mnoge odluke nije moguće točno odrediti i formulirati unaprijed, one se pojašnjavaju i dorađuju tek kasnije;
  • integracija svih razvojnih rezultata događa se na kraju, zbog čega se problemi integracije osjećaju prekasno;
  • korisnici i kupac ne mogu se upoznati s opcijama sustava tijekom razvoja, a rezultat vide tek na samom kraju; stoga ne mogu utjecati na proces kreiranja sustava, pa se stoga povećavaju rizici od nesporazuma između programera i korisnika/kupca;
  • model je nestabilan na neuspjehe u projektnom financiranju ili preraspodjeli sredstava, započeti razvoj zapravo nema alternative "u hodu".

Međutim, ovaj se model i dalje koristi u praksi - za male projekte ili u razvoju tipičnih sustava, gdje iteracija nije toliko tražena. Uz njegovu pomoć prikladno je pratiti razvoj i provoditi faznu kontrolu nad projektom. Ovaj se model također često koristi u offshore projektima 1 Od engleskog offshore - izvan obale, u proširenoj interpretaciji - izvan jedne zemlje. sa satnicama. Waterfall model je ušao kao sastavni dio drugih modela i metodologija, primjerice, u MSF-u.

spiralni model predložio je Bary Boehm 1988. kako bi se prevladali nedostaci modela vodopada, prvenstveno radi boljeg upravljanja rizikom. Prema ovom modelu, razvoj proizvoda se odvija u spirali, čiji je svaki zavoj određena faza razvoja. Za razliku od modela vodopada, spiralni model nema unaprijed zadani i obvezni set zavoja, svaki zavoj može biti zadnji u razvoju sustava, kada se završi, izrađuju se planovi za sljedeći zavoj. Konačno, zavojnica je samo faza, a ne vrsta aktivnosti, jer se u modelu vodopada u njegovom okviru može odvijati mnogo različitih vrsta aktivnosti, odnosno model je dvodimenzionalan.

Redoslijed poteza može biti sljedeći: u prvom koraku se donosi odluka o svrhovitosti izrade softvera, u sljedećem Zahtjevi sustava , zatim se provodi dizajn sustava itd. Okreti mogu imati i druga značenja.

Svaka zavojnica ima sljedeću strukturu (sektore):

  • definiranje svrhe, ograničenja i alternativa projekta;
  • procjena alternativa, procjena i rješavanje rizika; moguće je koristiti izradu prototipova (uključujući izradu niza prototipova), simulaciju sustava, vizualno modeliranje i analizu specifikacija; fokusiranje na najrizičnije dijelove projekta;
  • razvoj i testiranje - ovdje je moguć vodopadni model ili korištenje drugih modela i metoda razvoja softvera;
  • planiranje za sljedeće iteracije - analiziraju se rezultati, planovi i resursi za kasniji razvoj, donosi se (ili ne) odluka o novom krugu; analizira se ima li smisla nastaviti razvijati sustav ili ne; razvoj se može obustaviti, na primjer, zbog prekida u financiranju; spiralni model omogućuje vam da to učinite ispravno.

Jedna spirala može odgovarati razvoju neke softverske komponente ili uvođenju sljedećih promjena na proizvod. Dakle, model može imati treću dimenziju.

Spiralni model nije primjereno primjenjivati ​​u projektima s niskim stupnjem rizika, s ograničenim proračunom, za male projekte. Osim toga, odsutnost dobar novac izrada prototipova također može učiniti nezgodnom upotrebu spiralnog modela.

spiralni model nije pronađeno široka primjena u industriji i važan je, prije, u povijesnom i metodološkom smislu: to je prvi iterativni model, ima prekrasnu metaforu - spiralu, i, kao i model vodopada, kasnije je korišten za stvaranje drugih modela procesa i metodologija razvoja softvera.

Razvoj softverskih proizvoda poznaje mnoge vrijedne metodologije - drugim riječima, dobro uspostavljene najbolje prakse. Izbor ovisi o specifičnostima projekta, proračunskom sustavu, subjektivnim preferencijama, pa čak i temperamentu upravitelja. U članku su opisane metodologije s kojima se redovito susrećemo u Edisonu.

1. "Model vodopada" (kaskadni model ili "vodopad")



Jedan od najstarijih, uključuje uzastopni prolazak faza, od kojih svaka mora biti u potpunosti dovršena prije početka sljedeće. Lako je upravljati projektom u modelu Vodopad. Zbog svoje krutosti, razvoj je brz, cijena i vrijeme su unaprijed određeni. Ali ovo je dvosjekli mač. Model vodopada dobro će funkcionirati samo za projekte s jasno definiranim zahtjevima i načinom na koji će se oni provoditi. Ne postoji način da se napravi korak unatrag, testiranje počinje tek nakon što je razvoj dovršen ili gotovo dovršen. Proizvodi razvijeni prema ovom modelu bez opravdanog izbora mogu imati nedostatke (popis zahtjeva se ne može prilagoditi u bilo kojem trenutku), koji postaju poznati tek na kraju zbog strogog slijeda radnji. Trošak unošenja izmjena je visok jer morate čekati da cijeli projekt završi da biste ga pokrenuli. Međutim, fiksni trošak često nadmašuje nedostatke pristupa. Ispravak nedostataka uočenih tijekom izrade je moguć, a prema našem iskustvu zahtijeva jedan do tri dodatna dogovora uz ugovor s malom tehničkom specifikacijom.

Uz pomoć modela vodopada stvorili smo mnoge projekte od nule, uključujući razvoj samo tehničkih specifikacija. Projekti o kojima piše na Habréu: srednji - , mali - .

Kada koristiti metodologiju vodopada?

  • Tek kada su zahtjevi poznati, shvaćeni i fiksni. Nema proturječnih zahtjeva.
  • Nema problema s dostupnošću programera potrebnih kvalifikacija.
  • Za relativno male projekte.

2. "V-model"



Naslijedio strukturu korak po korak od modela vodopada. Model u obliku slova V primjenjiv je za sustave koji su posebno važni za nesmetan rad. Na primjer, aplikacijski programi u klinikama za praćenje pacijenata, integrirani softver za upravljačke mehanizme zračnih jastuka za hitne slučajeve u vozilima i tako dalje. Značajkom modela može se smatrati da je usmjeren na temeljitu provjeru i testiranje proizvoda, koji je već u početnim fazama dizajna. Faza testiranja provodi se istodobno s odgovarajućom razvojnom fazom, na primjer jedinični testovi se pišu tijekom kodiranja.

Primjer našeg rada po V-metodologiji - mobilna aplikacija za europski mobilni operater, što štedi troškove roaminga tijekom putovanja. Projekt se provodi prema jasnom TOR-u, ali uključuje značajnu fazu testiranja: praktičnost sučelja, funkcionalnost, opterećenje, uključujući integraciju, koja bi trebala potvrditi da nekoliko komponenti različitih proizvođača radi zajedno stabilno, krađu novca i zajmovi su nemogući.

Kada koristiti V-model?

  • Ako je potrebno temeljito testiranje proizvoda, tada će V-model opravdati temeljnu ideju: validaciju i provjeru.
  • Za male i srednje projekte gdje su zahtjevi jasno definirani i fiksni.
  • S obzirom na dostupnost inženjera s potrebnim kvalifikacijama, posebno ispitivača.

3. "Inkrementalni model" (inkrementalni model)

U inkrementalnom modelu, kompletni zahtjevi sustava podijeljeni su u različite sklopove. Terminologija se često koristi za opisivanje postupne izgradnje softvera. Postoji više razvojnih ciklusa, a zajedno čine životni ciklus s više vodopada. Ciklus je podijeljen na manje lako kreirane module. Svaki modul prolazi kroz faze definiranja zahtjeva, dizajna, kodiranja, implementacije i testiranja. Razvojni postupak prema inkrementalnom modelu uključuje puštanje proizvoda u prvu veću fazu osnovne funkcionalnosti, a zatim dosljedno dodavanje novih značajki, tzv. "inkremenata". Proces se nastavlja sve dok se ne stvori kompletan sustav.


Inkrementalni modeli se koriste tamo gdje su pojedinačni zahtjevi za promjenama jasni i mogu se lako formalizirati i implementirati. U našim smo projektima njime izradili čitač DefView, a potom i mrežu digitalnih knjižnica Vivaldi.

Kao primjer, opišimo bit jednog inkrementa. zamijenio DefView. DefView se prije povezivao s jednim poslužiteljem dokumenata, ali sada se može povezati s mnogima. Na stranici institucije koja svoj sadržaj želi emitirati određenoj publici, instaliran je poslužitelj za pohranu podataka koji izravno pristupa dokumentima i pretvara ih u željeni format. Pojavio se korijenski element arhitekture - središnji Vivaldi poslužitelj, koji djeluje kao jedan pretraživač na svim poslužiteljima za pohranu instaliranim u raznim institucijama.

Kada koristiti inkrementalni model?

  • Kada su osnovni zahtjevi za sustav jasno definirani i razumljivi. Istodobno, neki se detalji s vremenom mogu poboljšati.
  • Zahtijeva rano lansiranje na tržište.
  • Postoji nekoliko rizičnih značajki ili ciljeva.

4. "RAD Model" (model brzog razvoja aplikacija ili brzi razvoj aplikacija)

RAD model je varijacija inkrementalnog modela. U RAD modelu, komponente ili funkcije razvija nekoliko visoko kvalificiranih timova paralelno, poput nekoliko mini-projekata. Vremenski okvir jednog ciklusa je strogo ograničen. Stvoreni moduli se zatim integriraju u jedan radni prototip. Sinergija vam omogućuje da klijentu brzo predstavite nešto što radi na pregled kako biste dobili povratnu informaciju i napravili promjene.


Model brzog razvoja aplikacije uključuje sljedeće faze:

  • Poslovno modeliranje: definiranje popisa protoka informacija između različitih odjela.
  • Modeliranje podataka: Informacije prikupljene u prethodnom koraku koriste se za definiranje objekata i drugih entiteta potrebnih za kruženje informacija.
  • Modeliranje procesa: Tokovi informacija povezuju objekte radi postizanja ciljeva dizajna.
  • Aplikacija za izradu: koristi alate za automatsku izradu za pretvaranje CAD modela u kod.
  • Testiranje: testiraju se nove komponente i sučelja.
Kada se koristi RAD model?

Može se koristiti samo s visoko kvalificiranim i visoko specijaliziranim arhitektima. Proračun projekta dovoljno je velik da plati ove stručnjake, zajedno s cijenom gotovih automatiziranih alata za montažu. RAD model možete odabrati ako pouzdano poznajete ciljni posao i trebate hitno proizvesti sustav u roku od 2-3 mjeseca.

5. "Agilni model" (metodologija agilnog razvoja)



U "agilnoj" metodologiji razvoja, nakon svake iteracije kupac može promatrati rezultat i shvatiti zadovoljava li ga ili ne. Ovo je jedna od prednosti fleksibilnog modela. Njegovi nedostaci uključuju činjenicu da je, zbog nedostatka specifičnih formulacija rezultata, teško procijeniti troškove rada i troškove potrebne za razvoj. Ekstremno programiranje (XP) jedna je od najpoznatijih primjena agilnog modela u praksi.

Ovaj tip se temelji na kratkim dnevnim sastancima - "Scrum" i redovito ponavljajućim sastancima (jednom tjedno, jednom svaka dva tjedna ili jednom mjesečno) pod nazivom "Sprint". Na dnevnim sastancima članovi tima raspravljaju o:

  • izvješće o obavljenom poslu od posljednjeg Scruma;
  • popis zadataka koje zaposlenik mora obaviti prije sljedećeg sastanka;
  • poteškoće koje su se pojavile u toku rada.
Metodologija je prikladna za velike ili dugoročne projekte koji se stalno prilagođavaju tržišnim uvjetima. Sukladno tome, u procesu implementacije zahtjevi se mijenjaju. Vrijedno je zapamtiti klasu kreativnih ljudi koji imaju tendenciju generirati, izdavati i testirati nove ideje tjedno ili čak svakodnevno. Agilni razvoj najbolje odgovara ovoj vrsti vođe. Razvijamo interne startupe tvrtke koristeći Agile. Primjer klijentskih projekata je Elektronički sustav medicinskih pregleda, stvoren za provođenje masovnih medicinskih pregleda u nekoliko minuta. U drugom odlomku ove recenzije naši američki partneri opisali su vrlo važnu stvar, temeljnu za uspjeh na Agileu.

Kada koristiti Agile?

  • Kada se potrebe korisnika neprestano mijenjaju u dinamičnom poslovanju.
  • Agilne promjene provode se po nižoj cijeni zbog čestih povećanja.
  • Za razliku od modela vodopada, agilni model treba samo malo planiranja za početak projekta.

6. "Iterativni model" (iterativni ili iterativni model)

Iterativni model životnog ciklusa ne zahtijeva potpunu specifikaciju zahtjeva za početak. Umjesto toga, izrada počinje implementacijom dijela funkcionalnosti, koji postaje temelj za određivanje daljnjih zahtjeva. Ovaj proces se ponavlja. Verzija možda nije savršena, glavna stvar je da radi. Razumijevajući krajnji cilj, težimo mu tako da svaki korak bude učinkovit, a svaka verzija izvediva.


Dijagram prikazuje iterativni "razvoj" Mona Lise. Kao što vidite, u prvoj iteraciji postoji samo skica Mona Lise, u drugoj se pojavljuju boje, a treća iteracija dodaje detalje, zasićenost i dovršava proces. U inkrementalnom modelu, funkcionalnost proizvoda se gradi malo po malo, proizvod se sastoji od dijelova. Za razliku od iterativnog modela, svaki komad je integralni element.

Primjer iterativnog razvoja je prepoznavanje glasa. Prva istraživanja i priprema znanstvenog aparata započela je davno, u početku - u mislima, zatim - na papiru. Sa svakom novom iteracijom, kvaliteta prepoznavanja se poboljšavala. Međutim, savršeno prepoznavanje još nije postignuto, stoga problem još nije u potpunosti riješen.

Kada je najbolje vrijeme za korištenje iterativnog modela?

  • Zahtjevi za konačni sustav jasno su definirani i unaprijed razumljivi.
  • Projekt je velik ili vrlo velik.
  • Glavni zadatak mora biti definiran, ali detalji implementacije mogu se razvijati tijekom vremena.

7. "Spiralni model" (spiralni model)



„Spiralni model“ sličan je inkrementalnom modelu, ali s naglaskom na analizi rizika. Dobro radi za kritične poslovne izazove gdje je neuspjeh nekompatibilan s poslovanjem tvrtke, novim linijama proizvoda, istraživanjem i terenskim ispitivanjima.

Spiralni model pretpostavlja 4 stupnja za svaki zavoj:

  1. planiranje;
  2. analiza rizika;
  3. građenje;
  4. evaluacija rezultata i, ako je kvaliteta zadovoljavajuća, prijelaz u novi krug.
Ovaj model nije prikladan za male projekte, razuman je za složene i skupe, kao što je razvoj sustava za upravljanje dokumentima za banku, kada svaki sljedeći korak zahtijeva više analize za procjenu posljedica nego programiranje. Na projektu razvoja EDMS-a za ODU Sibira SO UES, dva sastanka o promjeni kodifikacije odjeljaka elektroničke arhive oduzimaju 10 puta više vremena nego programeru koji kombinira dvije mape. Državni projekti u kojima smo sudjelovali započeli su pripremom stručne javnosti jednog skupog koncepta, koji nipošto nije uvijek beskoristan, jer se isplati u nacionalnim razmjerima.

Sažmimo



Slajd pokazuje razlike između dvije najčešće metodologije.

U suvremenoj praksi razvojni modeli softver su multivarijantni. Ne postoji isti za sve projekte, početne uvjete i modele plaćanja. Čak ni svima nama toliko dragi Agile ne može se primijeniti svugdje zbog nepripremljenosti pojedinih kupaca ili nemogućnosti fleksibilnog financiranja. Metodologije se djelomično preklapaju u sredstvima i donekle su slične jedna drugoj. Neki drugi koncepti korišteni su samo za promicanje vlastitih prevoditelja i nisu donijeli ništa novo u praksu.

O razvojnim tehnologijama:
.
.
.
.

Koje metodologije koristite?

Identificiraju se i karakteriziraju glavne faze razvoja softvera. Za svaku etapu navedena su i opisana sredstva koja se mogu primijeniti za postizanje ciljeva etape.

1. Terminologija

Prije nego što prijeđemo na razmatranje razvojnih alata koji se mogu koristiti za izradu programa, potrebno je odrediti osnovne pojmove i termine koji će se koristiti u članku. U skladu s temom članka, osnovni pojam za nas je, naravno, "alati za razvoj softvera". U odnosu na područje razvoja softvera, ova definicija može zvučati ovako:

Alati za razvoj softvera- skup tehnika, metoda, tehnika, kao i skup programa alata (kompilatori, aplikacijske/sustavne biblioteke, itd.) koje razvijač koristi za stvaranje programskog koda Programa koji zadovoljava navedene zahtjeve.

Uzeti u obzir ovu definiciju pojam "Razvoj programa" zvučao bi ovako:

Razvoj softvera – komplicirano proces čija je glavna svrha kreiranje i održavanje programskog koda koji osigurava potrebnu razinu pouzdanosti i kvalitete. Za postizanje glavnog cilja razvoja softvera koriste se alati za razvoj softvera.

2. Osnovni alati korišteni u različitim fazama razvoja programa

Ovisno o predmetnom području i zadacima dodijeljenim programerima, razvoj softvera može biti prilično složen proces korak po korak koji uključuje veliki broj sudionika i raznih sredstava. Kako bismo utvrdili kada iu kojim slučajevima se koji alati koriste, ističemo glavne faze razvoja softvera. Za problematiku razmatranog pitanja od najvećeg su interesa sljedeće faze razvoja:

  1. Dizajn aplikacije.
  2. Implementacija aplikacijskog koda.
  3. Testiranje aplikacije.

Ovdje su namjerno izostavljene faze vezane uz pisanje tehničkog zadatka, planiranje rokova, proračun itd. Razlog tome je što se u tim fazama, uz rijetke iznimke, ne koriste praktički nikakvi specifični razvojni alati.

2.1 Alati za dizajn aplikacije

U fazi projektiranja aplikacije, ovisno o složenosti softverskog proizvoda koji se razvija, a koja izravno ovisi o zahtjevima, obavljaju se sljedeći zadaci dizajna:

  1. Analiza zahtjeva.
  2. Razvoj arhitekture budućeg softvera.
  3. Razvoj uređaja glavnih programskih komponenti.
  4. Razvoj izgleda korisničkog sučelja.

Izlaz dizajna obično je dokument o dizajnu softvera ili dokument o arhitekturi softvera. Zadatak "Analiza zahtjeva" najčešće se izvodi metodama sistemologije (analiza i sinteza), uzimajući u obzir stručno iskustvo projektanta. Rezultat analize obično je smisleni ili formalizirani model procesa funkcioniranja programa. Ovisno o složenosti procesa, za izradu ovih modela mogu se primijeniti različite metode i pomoćni alati. U općem slučaju, za opisivanje modela obično se koriste sljedeće oznake (u zagradama su dane softver, koji se mogu koristiti za dobivanje modela):

  • BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
  • Dijagrami toka (Vizija 2003 i mnogi drugi).
  • ER dijagrami (Visio 2003, ERWin, Sybase Power Designer i mnogi drugi).
  • UML dijagrami (Sybase Power Designer, Rational Rose i mnogi drugi).
  • rasporedi, mat-modeli itd.

Ponekad, kada je programski proizvod koji se razvija namijenjen automatizaciji neke složene aktivnosti, zadatak analize (modeliranja) se izvodi prije izrade tehničkih zahtjeva za budući proizvod. Rezultati analize omogućuju formiranje razumnih zahtjeva za pojedinu funkcionalnost razvijenog programa i izračunavanje stvarne koristi od uvođenja razvijenog proizvoda. Štoviše, inače se ispostavlja da se na temelju rezultata analize početni ciljevi i zadaće automatizacije dramatično mijenjaju ili se na temelju rezultata ocjenjivanja učinkovitosti razvoja i implementacije donosi odluka da se proizvod ne razvija.

Svrha drugog i trećeg zadatka iz gornjeg popisa zadataka je razviti model (opis) budućeg sustava koji je razumljiv enkoderu - osobi koja piše programski kod. Ovdje je od velike važnosti koja se programska paradigma (programska paradigma mora se smatrati i razvojnim alatom) mora koristiti pri pisanju programa. Kao primjer glavnih paradigmi treba navesti sljedeće:

  • Funkcionalno programiranje;
  • Strukturirano programiranje;
  • imperativno programiranje;
  • Logičko programiranje;
  • Objektno orijentirano programiranje (izrada prototipa; korištenje klasa; subjektivno orijentirano programiranje).

Njegov izbor uvelike ovisi o prevladavajućim navikama, iskustvu, tradiciji, alata od strane razvojnog tima. Ponekad je softverski proizvod koji se razvija toliko složen da se koriste različite paradigme za rješavanje niza problema u različitim komponentama sustava. Treba napomenuti da izbor jednog ili drugog pristupa nameće ograničenja na sredstva koja će se koristiti u fazi implementacije programskog koda. Rezultat rješavanja ovog problema, ovisno o pristupu, može biti (u zagradi su navedeni programski alati pomoću kojih se oni mogu dobiti):

  • dijagram klasa itd. (Ration Rose, Sybase PowerDesigner i mnogi drugi).
  • opis strukturnih modula i njihovo programsko sučelje (na primjer, Sybase PowerDesigner i mnogi drugi).

Izrada izgleda korisničkog sučelja podrazumijeva kreiranje vizualnog prikaza kako će izgledati pojedine video forme, prozori u aplikaciji koja se razvija. Rješenje ovog problema temelji se na korištenju dizajnerskih alata, koji se neće razmatrati u ovom članku.

2.2 Načini implementacije programskog koda

U fazi implementacije programskog koda kodiraju se pojedine komponente programa u skladu s izrađenim tehničkim projektom. Alati koji se mogu primijeniti uvelike ovise o tome koji su pristupi korišteni tijekom projektiranja te, osim toga, o stupnju sofisticiranosti tehničkog dizajna. Ipak, među alatima za izradu programskog koda potrebno je izdvojiti sljedeće glavne vrste alata (primjeri alata navedeni su u zagradama): metode i tehnike algoritama.

  • programski jezici (C++, C, Java, C#, php i mnogi drugi);
  • alati korisničkog sučelja (MFC, WPF, QT, GTK+, itd.)
  • alati za izradu verzija programskog koda (cvs, svn, VSS).
  • alati za dobivanje izvršnog koda (MS Visual Studio, gcc i mnogi drugi).
  • alati za upravljanje bazama podataka (Oracle, MS SQL, FireBird, MySQL i mnogi drugi).
  • programi za ispravljanje pogrešaka (MS Visual Studio, gdb itd.).

2.3 Alati za testiranje programa

Glavni zadaci testiranja su provjeriti zadovoljava li funkcionalnost razvijenog programa početne zahtjeve, kao i identificirati pogreške koje se eksplicitno ili implicitno manifestiraju tijekom rada programa. Ključne aktivnosti testiranja uključuju sljedeće:

  • Testiranje na kvar i oporavak.
  • Funkcionalno ispitivanje.
  • Sigurnosno testiranje.
  • Ispitivanje interakcija.
  • Testiranje postupka instalacije.
  • Testiranje upotrebljivosti.
  • testiranje konfiguracije.
  • Testiranje otpornosti na stres.

Među glavnim vrstama sredstava koja se mogu koristiti za obavljanje dodijeljenog posla su sljedeći:

  • alati za analizu koda, profiliranje (Code Wizard - ParaSoft, Purify - Rational Softawre. Test Coverage - Semantic itd.);
  • alati za testiranje funkcionalnosti (TEST - Parasoft, QACenter - Compuware, Borland SilkTest itd.);
  • alati za testiranje performansi (QACenter Performance - Compuware itd.).

3. Zaključak

Proces razvoja programa je složen proces i koji će se alati koristiti uvelike ovisi o zadacima koji se postavljaju programerima. Neovisno o razvojnim zadaćama, alati se ne mogu ograničiti samo na skup nekih alata, već je potrebno uključiti i metode, tehnike, pristupe i sve ono što se koristi za izradu programa koji zadovoljava zadane zahtjeve.

Isti vidjeti :

Danas se proces stvaranja složenih softverskih aplikacija ne može zamisliti bez podjele na faze životnog ciklusa. Pod životnim ciklusom programa podrazumijevamo niz faza:

  • Analiza predmetnog područja i izrada tehničke specifikacije (interakcija s kupcem)
  • Dizajn strukture programa
  • Kodiranje (skup programskog koda prema projektnoj dokumentaciji)
  • Testiranje i otklanjanje pogrešaka
  • Provedba programa
  • Programska podrška
  • Raspolaganje
Pogledajmo pobliže proces dizajna. Tijekom procesa projektiranja, arhitekt ili iskusni programer izrađuje projektnu dokumentaciju, uključujući tekstualne opise, dijagrame i modele budućeg programa. U ovoj teškoj stvari pomoći će nam jezik UML.

UML je grafički jezik za vizualizaciju, opis parametara, dizajn i dokumentaciju raznih sustava (posebno programa). Dijagrami se izrađuju pomoću posebnih CASE alata kao što su Rational Rose (http://www-01.ibm.com/software/rational/) i Enterprise Architect (http://www.sparxsystems.com.au/). Temeljen na UML tehnologiji, jedinstveni informacijski model. Gornji CASE alati sposobni su generirati kod u raznim objektno orijentiranim jezicima, a također imaju vrlo korisna značajka obrnuti inženjering. (Obrnuti inženjering vam omogućuje stvaranje grafičkog modela iz postojećeg programskog koda i komentara na njega.)

Razmotrite vrste dijagrama za vizualizaciju modela (ovi su obavezni, iako postoji mnogo više vrsta):

Dijagram slučaja uporabe

Dizajnirani sustav je predstavljen kao skup entiteta ili aktera koji su u interakciji sa sustavom koristeći takozvane presedane. U ovom slučaju, akter (glumac) ili akter je bilo koji entitet koji izvana komunicira sa sustavom. Drugim riječima, svaki slučaj upotrebe definira određeni skup radnji koje sustav izvodi kada razgovara s glumcem. Pritom se ništa ne govori o tome kako će se provoditi interakcija aktera sa sustavom.

Dijagram klasa (dijagram klasa)

Dijagram klasa služi za predstavljanje statičke strukture modela sustava u terminologiji klasa objektno orijentiranog programiranja. Dijagram klasa može posebno odražavati različite odnose između pojedinačnih entiteta predmetnog područja, kao što su objekti i podsustavi, a također opisuje njihovu unutarnju strukturu (polja, metode ...) i vrste odnosa (nasljeđivanje, implementacija sučelja . ..). Ovaj dijagram ne pruža informacije o vremenskim aspektima rada sustava. S ove točke gledišta, dijagram klasa je daljnji razvoj konceptualnog modela projektiranog sustava. U ovoj fazi neophodno je poznavanje OOP pristupa i obrazaca dizajna.


Dijagram stanja (dijagram stanja)

Glavna svrha ovog dijagrama je opisati moguće nizove stanja i prijelaza koji zajedno karakteriziraju ponašanje elementa modela tijekom njegovog životnog ciklusa. Dijagram stanja predstavlja dinamičko ponašanje entiteta, temeljeno na specifikaciji njihovog odgovora na percepciju nekih specifičnih događaja.


Dijagram slijeda

Za modeliranje interakcije objekata u UML jeziku koriste se odgovarajući dijagrami interakcije. Interakcije objekata mogu se razmatrati u vremenu, a zatim se dijagram sekvence koristi za predstavljanje vremena prijenosa i primanja poruka između objekata. Objekti u interakciji međusobno razmjenjuju neke informacije. U tom slučaju informacije imaju oblik cjelovitih poruka. Drugim riječima, iako poruka ima informacijski sadržaj, ona dobiva dodatno svojstvo usmjerenog utjecaja na primatelja.

Dijagram suradnje

U dijagramu suradnje objekti koji sudjeluju u interakciji prikazani su u obliku pravokutnika koji sadrže naziv objekta, njegovu klasu i, eventualno, vrijednosti atributa. Kao iu dijagramu klasa, asocijacije između objekata naznačene su u obliku različitih povezujućih linija. U ovom slučaju možete eksplicitno odrediti nazive pridruživanja i uloge koje objekti igraju u ovom pridruživanju.
Za razliku od dijagrama sekvenci, dijagram suradnje prikazuje samo odnose između objekata koji igraju određene uloge u interakciji.

Dijagram komponenti

Dijagram komponenti, za razliku od prethodno razmatranih dijagrama, opisuje značajke fizičkog prikaza sustava. Dijagram komponenti vam omogućuje da odredite arhitekturu sustava koji se razvija uspostavljanjem ovisnosti između softverskih komponenti, koje mogu biti izvorni, binarni i izvršni kod. U mnogim razvojnim okruženjima, modul ili komponenta odgovaraju datoteci. Točkaste strelice koje povezuju module pokazuju odnose ovisnosti slične onima koji se javljaju prilikom prevođenja izvornog koda programa. Glavni grafički elementi dijagrama komponenti su komponente, sučelja i ovisnosti između njih.


Dijagram postavljanja

Dijagram implementacije dizajniran je za vizualizaciju elemenata i komponenti programa koji postoje samo u fazi njegovog izvođenja (runtime). U ovom slučaju prikazane su samo komponente instance programa koje su izvršne datoteke ili dinamičke biblioteke. One komponente koje se ne koriste tijekom izvođenja nisu prikazane u dijagramu postavljanja.
Dijagram postavljanja sadrži grafičke slike procesore, uređaje, procese i veze između njih. Za razliku od logičkih dijagrama prikaza, dijagram implementacije je isti za sustav kao cjelinu, jer mora u potpunosti odražavati značajke njegove implementacije. Ovaj dijagram u biti dovršava OOAP proces za određeni programski sustav a njegov razvoj obično je posljednji korak u specifikaciji modela.

Ovo zaključuje naš pregled dijagrama posebno i dizajna općenito. Vrijedno je napomenuti da je proces dizajna odavno postao standard razvoja softvera, ali često se morate nositi s lijepo napisanim programom, koji zbog nedostatka odgovarajuće dokumentacije dobiva nepotrebne sporedne funkcionalnosti, štake, postaje glomazan i gubi svoju prijašnja kvaliteta. =(

Uvjeren sam da je programer prije svega koder - on NE treba komunicirati s kupcem, NE treba razmišljati o arhitekturi sustava, ne treba izmišljati sučelje programa, on treba samo kodirati - implementirati algoritme, funkcionalnost, izgled, upotrebljivost, ali ne više…. Projektant, počevši od apstraktnih dijagrama (koji opisuju predmetno područje) do dijagrama koji predstavljaju strukturu podataka, klase i procese njihove interakcije, mora sve detaljno opisati korak po korak. Odnosno, složenost posla i plaća dizajnera trebala bi biti red veličine veća od one programera == kodera. Oprostite na laprdanju....



POVEZANI ČLANCI